Subject: [netlmm] FW: DISCUSS and COMMENT: draft-ietf-netlmm-proxymip6

From: "Sri Gundavelli" <[email-masked]>
Date: Sun, 13 Apr 2008 23:35:52 -0700

FYI. 

From Pasi's review, only one issue remains, on the changes
required to allow multiple prefix assignment.

Sri

> -----Original Message-----
> From: Sri Gundavelli [mailto:[email-masked]] 
> Sent: Thursday, March 27, 2008 4:41 PM
> To: [email-masked]
> Cc: [email-masked]; 
> [email-masked]; 
> [email-masked]
> Subject: RE: DISCUSS and COMMENT: draft-ietf-netlmm-proxymip6 
> 
> Hi Pasi,
> 
> Please see inline. Thanks !
> 
> 
> 
> 
> On Thu, 27 Mar 2008, [email-masked] wrote:
> 
> > Hi Sri,
> >
> > Thanks for a quick response. Please see inline.
> >
> > <snip>
> >
> >>> The specification seems to assume that MN has just _the_
> >>> link-local address. This restriction is not present in the IPv6
> >>> Addressing Architecture (or many common link layers for IPv6, such
> >>> as 802.11), and might not be true in e.g. some SEND
> >>> configurations. Thus, it seems enabling Proxy Mobile IPv6 here
> >>> could break functionality that would work without it? At the very
> >>> least, the document should explain what happens if the client (not
> >>> knowing that Proxy Mobile IPv6 is in use) configures more than one
> >>> link-local address.
> >>>
> >>
> >> The same comment as above. As Jari pointed out, the idea 
> of carrying
> >> the interface-identifier is to ensure there is no address 
> collision,
> >> when a DNAv6 enabled mobile node after handoff skips the DAD
> >> procedure on the link-local address. In the SDO deployments where
> >> this protocol is extected to be deployed, there is context transfer
> >> mechanims in place (such as R4 interface in WiMAX) and the serving
> >> MAG would know the link-local address of the mobile on the link and
> >> so address collision is not an issue. However, for completeness, we
> >> went ahead and also defined mechanisms to store this identifier in
> >> the MN's BCE on the LMA. We assume there is a single link-local
> >> address identifier.
> >>
> >> All though, extending the link-local address option to support
> >> multiple addresses and fixing the related text is not a a big deal,
> >> I suggest we address the above two issues in the new spec.  We can
> >> post a companion document on this topic. But, solving this here
> >> would add to the document size. (On a lighter note, people are
> >> expecting this document to be as readable as a Harry Potter Novel
> >> and expect to understand every bit in one shot and when remembering
> >> it took few iterations for me to understand any of the base MIP
> >> specs :)). So, I suggest we handle the above two items of mutiple
> >> prefix assignment and multiple link-local address 
> configuration in a
> >> new document.
> >
> > One of the environments described in NETLMM goals document 
> (RFC 4831)
> > is WLAN switches. In this environment, the client may not be aware
> > that Proxy Mobile IPv6 is being used, and may attempt to configure
> > multiple link-local addresses (which is a perfectly fine thing to do
> > in WLAN).
> >
> > Given the goal of working with unmodified MNs, at the very least the
> > document needs to describe what happens in this case. (I'm not quite
> > sure what exactly does happen, though.)
> >
> 
> W.r.t to home network prefix, the LMA can only send one 
> prefix. So, the 
> MAG should not be hosting mutiple prefixes on any of the 
> access link and 
> specifically the prefixes that are learnt thru PMIP 
> signaling. Should not 
> break any thing, but, if we want to support it, we have fix 
> the text in 
> some places and specially in multi-homing rules and also extend the
> HNP option. Some processing rules will change.
> 
> On the multiplicity of link-local address configuration, I expect
> deployments to use Context Transfer schemes and that would move the
> whole link to a new MAG and so should not notice any changes w.r.t
> Def-Router address etc. Or, allow a fixes link-local address(es) to
> be configured on all MAG's MN-AR interfaces and assuming there is
> no SEND. But, if both these approaches are not in place, with the
> current text, there is a possibility of collision. We can extend
> the option to carry multiple addresses and store it in MN's BCE.
> 
> 
> 
> >>> The specification is vague on what entity the MN-Identifier
> >>> identifies, or is required to identify. Section 6.6 suggests that
> >>> it could correspond to Chargeable-User-Identity RADIUS 
> attribute --
> >>> but that attribute does not identify a node, it identifies a user
> >>> account that could be used from multiple nodes simultaneously.
> >>> (Some deployments may of course prohibit using the same user
> >>> account from multiple nodes, but in other cases, it's common:
> >>> consider an enterprise user with two laptops, but just a single
> >>> user account.)  The spec needs to say what the uniqueness
> >>> requirements for MN-Identifier are: in particular, is it 
> OK to have
> >>> multiple MNs, connecting via the same MAGs/LMAs, with the same
> >>> MN-Identifier?  (And if this is OK, perhaps the name
> >>> "MN-Identifier" should be changed.)
> >>>
> >>
> >> Section 6.6 talks about the identifiers used for access 
> authentication
> >> (fast reauth ..etc) and the relation to the MN-Identifier. There is
> >> only one identifier that the mobility entities use in the signaling
> >> messages for identifying  a mobile node and it is the 
> MN-Identifier.
> >> However, there are multiple ways in which a MAG can discover this
> >> identifier and one mechanism is the use of CUI.
> >>
> >> We require the MN-Identifier to be unique within a Proxy 
> Mobile IPv6
> >> domain. The below text,
> >>
> >> "All the network entities in a Proxy Mobile IPv6 domain 
> MUST be able
> >>  to identify a mobile node, using its MN-Identifier.  This 
> identifier
> >>  MUST be stable across the Proxy Mobile IPv6 domain and 
> the entities
> >>  must be able to use this identifier in the signaling messages."
> >>
> >> We can add a line on the uniqueness requirement to this.
> >
> > I'd recommend explicitly pointing out the differences between MN
> > identifier and user/account identifier -- I've understood that this
> > distinction has not been obvious in some other SDOs that 
> are planning
> > to use this document (even when they explicitly support using the
> > same user identity from multiple hosts). And it may not be obvious
> > to e.g. enterprises wanting to use this with WLAN switches.
> >
> 
> Sure. Will add this to Section 6.6.
> 
> 
> >>> I couldn't find text saying whether the MAG decrements the Hop
> >>> Limit field or not (for packets it forward to the LMA, from the
> >>> LMA, or between directly connected nodes if EnableMAGLocalrouting
> >>> is enabled). (I'm not sure whether LMA behavior is specified,
> >>> either?)
> >>
> >> For local routing or for reverse tunneling, the standard IP
> >> forwarding or tunneling semantics apply. The MIP functions are not
> >> in the switching path. I dont think, we can really specify 
> any thing
> >> related to forwarding behavior.
> >
> > I'm not quite sure I understand. Certainly *some* document (either
> > this one, or one of its normative references) needs to say when the
> > Hop Limit is decremented and when not? (And if it's one of the
> > normative references, at least a pointer would be very helpful
> > here.)
> >
> 
> I was trying to say, this is a general IP forwarding behavior and
> nothing specific from PMIP perspective. But, as you suggested, we
> should point to the specs that specify these forwarding aspects,
> Ex: RFC-2473 for packet tunneling ... etc. Will add pointers.
> 
> 
> > <snip>
> >
> >>> The statement "This specification [...] does not support
> >>> Shared-Prefix model" seems false, as Appendix B specifies how to
> >>> support it.  (And given that both LMA and MAG require code changes
> >>> to support it in interoperable fashion, I don't quite see how this
> >>> appendix could be called non-normative, either.) I'd suggest
> >>> moving the specification of Shared-Prefix model to a separate
> >>> document.
> >>>
> >>
> >> Text specified in Appendex section should be just informative and
> >> an implemention claiming compliance to this spec, need not 
> implement
> >> this part. Its purely informational purposes and I dont 
> know if this
> >> gets any validity beyond that. A future spec can support this
> >> configuration and define the specification and this approach may
> >> provide some hints for that spec and thats all to it.
> >
> > The appendix contains technical specification text (which describes
> > how some node should behave to achieve interoperability); whether
> > it's a mandatory or optional feature doesn't really change
> > the situation.
> >
> 
> Ok. We can take it out.
> 
> 
> > <snip>
> >>> Section 4 would have been lot easier to understand if it had said
> >>> in the beginning that PBUs don't have the Home Address destination
> >>> option (and PBAs don't have the Type 2 RH with home address).
> >>>
> >>
> >> hmm.... we chose the term PBU/PBA for the messages and it has
> >> its own format and the rules on what options are carried in these
> >> messages. I wonder if that is not an indication that it 
> may not have
> >> the traditional MIP6 PBU elements.
> >
> > It was not obvious (at least to me), so adding a sentence or two
> > to beginning of Section 4 would probably help.
> >
> 
> Sure. Will do that.
> 
> 
> 
> Thanks again.
> 
> Regards
> Sri
> 
> > Best regards,
> > Pasi
> >

_______________________________________________
netlmm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netlmm

---

From: Sri Gundavelli <[email-masked]>
Date: Sun, 13 Apr 2008 23:49:21 -0700 (PDT)

Status:

Where do we stand with the IESG reviews ? Here is the pointer to
the review ballot.

https://datatracker.ietf.org/idtracker/ballot/2698/

Most AD's have signed it off. Couple of issues to close and that
should be it. We will post the updated doc with the resolutions
from the IESG review.

Bottom line, we are almost done !

Thanks
Sri