Hi Jonne, Thanks for your reply; some comments inline. At 1:17 PM -0800 2/14/08, Soininen Jonne (NSN FI/Espoo) wrote: >Hi Ted, > >I agree with you on the notion that we shouldn't publish anything that we >know already that will need fixes or does not work properly for the intended >use at this point. However, I think it is completely proper to revise >specifications based on operational experience - ever rather quickly after >publishing as a PS. Though, seldom done I have understood it is has been >even the original idea of the three step standardization process. I agree that we should be able to revise specifications very quickly. RFC 2026 is pretty clear, though, that we shouldn't publish things that we believe are missing important pieces: A Proposed Standard should have no known technical omissions with respect to the requirements placed upon it. However, the IESG may waive this requirement in order to allow a specification to advance to the Proposed Standard state when it is considered to be useful and necessary (and timely) even with known technical omissions. The tricky bit here is that the requirements placed on this have shifted since the work was chartered, and it is not clear whether the technical omissions here are meant to be consonant with the original charter, even though they don't meet the technical requirements of the current working scope. As you should also note in reading my mail, I am encouraging the IESG to waive this requirement in order to get this document out in a timely fashion, but with a forward pointer in place that would allow us to indicate we intend to fill the empty slot in the toolbox and, generally speaking, where someone should eventually look for the tool. >However, that is not my main point. And I don't quite agree that this >document in its current format is in a shape where we would have to revise >it right after publishing. > >I would like to comment a bit on your proposal to make the MN-AR draft a >normative reference, and moving MN-AR to standards-track. First of all, I'm >happy to say that the MN-AR draft has been revived and can be found at >http://www.ietf.org/internet-drafts/draft-ietf-netlmm-mn-ar-if-03.txt Good news indeed! >Secondly, taking into account the multiple customers for the pmip6 and the >multitude of environments where PMIP is either going to be used or >potentially going to be used (3GPP, 3GPP2, Wimax to my understanding) I >don't think it is possible to write a MN-AR draft that would cover >adequately those networks and be really useful for them. I think the purpose >of the MN-AN is not to show how PMIP6 should be deployed, but how it could >be deployed. I however do agree that MN-AR draft should go forward in the >working group and it should not be forgotten. I'm glad that you also support MN-AR going forward. I also hope that you are too pessimistic on the possibility of making a general mechanism. While the networks you cite are certainly complex and will no doubt have systems engineering documents which describe exactly how to use PMIP in their environments, that's not the work I'm suggesting the IETF should take on. Instead, I'm suggesting that we need and should complete the work of describing a general mechanism specifying how a mobile node talks to a mobile access gateway. That may well not replace the systems engineering work needed by the current customers for PMIP, but it will make the work more generally useful. It may even be in the fullness of time that the mobile-node to MAG signalling will be used in those environments, once it is generally available. Thanks again for your thoughtful reply, regards, Ted Hardie >I cross-posted this to the netlmm mailing list to make sure everybody knows >this discussion is going on. > >Cheers, > >Jonne. > >On 2/14/08 3:01 AM, "ext Ted Hardie" <hardie@xxxxxxxxxxxx> wrote: > >> Summary: One issue needs resolution. >> >> First, let me start by saying that -09, which was put out for Last Call, was a >> substantial >> improvement over the -08. I normally read Last Call documents using a diff >> tool, >> and the number of really solid additions in this update was quite high. I was >> a bit >> surprised, given the extent of the new text, that there was no WG last call, >> but >> I assume that the WG is reviewing the changes in parallel. I assume that the >> issuance >> of -10, which came out during the last call, was a response to one or more >> reviews >> from the WG or solicited experts. >> >> To call out one particular improvement, I found the update's language around >> multi-homing much clearer, and I believe the risk of assignment of the same >> address to multiple interfaces is much reduced in this version. Given the >> potential consequences (watching your stack scream "I'm melting! I'm >> melting!" >> as someone entertainingly put it), that's a really good thing. >> >> There are still some opportunities for editorial update, and I hope that as >> the IESG enters its discussions that some of those are targets for resolution. >> I'd particularly like to see even more clear light on the description in >> bullet 4 of Section 6.9.1.1, as "predictably knows" is not as clean as >> it might be. (The current sentence is: "The Handoff Indicator field MUST be >> set to >> value 1 (Attachment over a new interface), if the mobile access gateway >> predictably >> knows that the mobile node's current attachment to the network over this >> interface is not as a result of an handoff of an existing mobility session >> (over >> the same interface or through a different interface), but as a result of an >> attachment over a new interface. "). But that is really a language clarity >> problem, at least I hope, at this point. >> >> The big issue that remains is actually one that starts from the scope creep. >> >> I was on the IESG during the period when this charter was approved, and it >> was clear at the time that some of the limitations being put in were intended >> to focus NETLMM on cases where nodes were re-associating at layer 2 with the >> same network. The charter says, for example: "The protocol will not attempt >> to hide handover between two separate interfaces on the mobile node.". >> This document (and, as I understand it, the working group discussion for some >> time) >> has gone beyond that initial scope. A good portion of this document's >> complexity >> is because it does handle the multi-interface case. While it would have been >> nice >> to have the charter updated to state the new scope, I don't personally have a >> problem with the scope. I am concerned, however, that the design constraints >> changed with that new scope and that other parts of the charter are limiting >> folks' understandings of what can be done here, when those restraints are >> really >> salient for the single layer 2 initial scope. >> >> To put it simply, given the inter-technology handoff, signalling from the >> mobile node >> to the network is one of the clearest and most likely to be interoperable ways >> to achieve >> the correct behavior in some of the base cases. At the moment, because the >> mechanisms >> for setting the handoff indicator do not necessarily involve the mobile node >> (and are >> appear to be below IP where between the mobile node and the networ), a mobile >> node with multiple interfaces will not always be able to signal that it >> desires handoff or >> prefers multihoming. The document is now clear that in that case it gets >> multihoming. That's a tremendous advance over the previous state. But the >> really >> big win here would be to enable the signaling . As it stands, the operations >> are based >> on the handoff indicator provided by the MAG, but the document does not >> provide >> any information on how the MAG will know this information. There certainly >> will >> be cases where a network architecture will allow the MAG to use layer 2 >> indicators >> or other mechanisms, but there will also be cases where that set of mechanisms >> is inconsistently available. Adding the higher-layer signalling makes this a > > complete solution. >> >> I'm concerned that sending the document out in its current state will either >> require >> a quick re-spin at PS to enable this once the issues arise in deployment or >> that some of >> the contexts in which this is intended to be used will work around the problem >> in ways which will hinder an interoperable, long-term deployment. >> >> I am very conscious, however, that there is considerable time pressure on this >> document. I propose the following as a way forward which should not add any >> significant delay. >> >> 1) Add an explicit, normative reference to draft-netlmm-mn-ar (which would >> need to be revived) as the basis for a forthcoming above-IP signalling >> mechanism, >> using an RFC-Editor's note. >> >> 2) Put draft-netlmm-mn-ar on the standards track, but make an explicit >> downref statement for this document to the internet-draft. This would allow >> this document to progress without delay, but provide a reference for those who >> will be deploying this in contexts which do not have the same >> highly-structured >> network management of the networks for which this is urgent. When >> draft-netlmm-mn-ar is published, it would be available, of course, to both >> network types. >> >> 3) Go ahead with IESG processing on this document on the basis of the existing >> Last Call >> date, with the understand that the IESG would reconsider only if the second >> Last Call >> with the explicit downref raised new issues. IESG consideration prior to the >> end of a Last Call already occurs in some cases, and it certainly could be >> used in this case to meet the >> time pressures. >> >> >> I'm aware that the charter states that there should be no signalling required >> between the mobile and the network. In the context of the original design >> scope, >> that should have been read quite strictly. In the context of the current >> design scope, >> I believe we have to distinguish between making something required and setting >> a standard way of handling something in the inter-technology case. I do not >> believe >> that adding this normative reference would make it required. It would simply >> show how the IETF intended to meet the need for an interoperable mechanism >> for signalling where the mobile node had the capability and interest. Where >> it did >> not, the basic mechanisms in this draft would suffice. >> >> I understand that this has been an active, and at times contentious, area of >> discussion, >> and I do not want this last call comment to fan any old flames. As an APPs >> guy, trust >> that I'm in favor of pretty much anything that reduces the need for updated IP >> addresses >> and all the concomitant pain. I also see us about to miss an opportunity >> here, by >> setting out a toolkit that is missing a critical tool. I don't believe the >> time pressures >> here should or need to stop us from building the full toolkit, even if the >> first shipment >> of toolboxes goes out simply with the right shape cut out, to be filled later. >> >> regards, >> Ted Hardie >> _______________________________________________ >> Ietf mailing list >> Ietf@xxxxxxxx >> http://www.ietf.org/mailman/listinfo/ietf > >-- >Jonne Soininen >Nokia Siemens Networks > >Tel: +358 40 527 46 34 >E-mail: jonne.soininen@xxxxxxx _______________________________________________ Ietf@xxxxxxxx http://www.ietf.org/mailman/listinfo/ietf