Re: [netlmm] Last Call: draft-ietf-netlmm-mip-interactions (Interactions betweenPMIPv6 and MIPv6: scenarios and related issues) to Informational RFC

["Giaretta, Gerardo" <[e-mail]>]

Thanks Charlie for the comments and sorry for the delay in addressing them. Most of your comments are editorial and I can produce a new revision since I received also comments from Gen-Art review. 

You have one comment on the recommendation in the draft to have separate binding cache entries. This was extensively discussed in the NETLMM WG and also at the IETF Dublin meeting. There was a mailing list discussion after that in September/October 2008 which led to the conclusion in the current version of the draft. 

You can find more information in the archives at: http://www.ietf.org/mail-archive/web/netlmm/current/msg05533.html 

Thanks
Gerardo

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Charles E. Perkins
> Sent: Monday, May 03, 2010 1:45 PM
> To: [e-mail]; [e-mail]
> Subject: Re: [netlmm] Last Call: draft-ietf-netlmm-mip-interactions
> (Interactions betweenPMIPv6 and MIPv6: scenarios and related issues) to
> Informational RFC
> 
> 
> Hello folks,
> 
> Here is a first installment of comments on the
> abovementioned Internet Draft.
> 
> ====================================================================
> 
> 
>  >                                                  The list is not
>  >    meant to be exhaustive.  Moreover, this document presents and
>  >    identifies all issues pertained to these scenarios and discusses
>  >    possible means and mechanisms that are recommended to enable
> them.
> 
> These two sentences clash, even though it's true
> a logician can make sense of them.
> 
> Figure 2 is out of order.
> 
> The captions to all figures ought to be centered.
> 
>  >    The following figure illustrates an example
> 
> "following figure" --> "Figure 3 below"
> 
>  >    of this scenario, where the MN is moving from an access network
>  >    where PMIPv6 is supported (i.e.  MAG functionality is supported)
>  >    to a network where PMIPv6 is not supported (i.e.  MAG
>  >    functionality is not supported by the AR).  This implies that the
>  >    home link of the MN is actually a PMIPv6 domain.
> 
> It's true that the figure is drawn this way, but there
> might be an unwanted inference that such heterogeneous
> network support _always_ requires PMIP support in the
> home network.  I reckon that was not intended.
> 
>  >    This scenario is very similar to other hierarchical mobility
>  >    schemes, including a HMIPv6-MIPv6 scheme.
> 
> Please make the relevant citations.
> 
>  >    Note that a race condition where the MN registers the
>  >    CoA at the HA before the CoA is actually bound to the MAG at the
>  >    LMA is not possible.
> 
> Better:
>       Note that there is no race condition whereby the MN registers
>       the CoA at the HA before the CoA is actually bound to the MAG
>       at the LMA.
> 
>  >                                   In particular, based on the base
>  >           specification [RFC3775],
> 
> Better:
>                                      In particular, based on [RFC3775],
> Or, even better:
>                                      In particular, the base
>            specification [RFC3775] doesn't require the MN to include
> any
>            identifier, such as the MN-ID [RFC4283], in the Binding
> Update
>            message other than its Home Address.
> 
>  >                                               As described in
>  >         [RFC4877], the identifier of the MN is known by the Home
> Agent
>  >         after the IKEv2 exchange, but this is not used in the MIPv6
>  >         signaling, nor as a lookup key for the binding cache.
> 
> Which naturally leads to the question, "Why Not?"!
> This is a problem that really needs to be fixed.
> 
>  >                                  Therefore PMIPv6 and MIPv6 will
>  >         always create two different binding cache entries in the HA/
>  >         LMA which implies that the HA and LMA are logically
> separated.
> 
> I think this statement is too strong.  If I were building such
> a system, my HA/LMA would probably be aware that the MN-ID was
> tightly bound to the MN-HoA.  So I would almost certainly make
> sure that there was a single binding cache entry.
> 
> If you replace "will always" by "might well", and "are"
> by "might be", then I would agree.
> 
> Also, it's unfortunate if the typography separates "HA" from
> "LMA" in "HA/LMA".
> 
>  >    *  When the mobile node moves from a MIPv6 foreign network to the
>  >       PMIPv6 home domain, the MAG registers the mobile node at the
>  >       LMA by sending a Proxy Binding Update.  Subsequently, the LMA
>  >       updates the mobile node's binding cache entry with the MAG
>  >       address and the MAG emulates the mobile node's home link.
>  >       Upon detection of the home link, the mobile node will send a
>  >       de-registration Binding Update to its home agent.  It is
>  >       necessary to make sure that the de-registration of the MIPv6
>  >       BU does not change the PMIPv6 binding cache entry just created
>  >       by the MAG.
> 
> To me this looks like a major design flaw.
> 
> It would be better if the mobile node were aware that its
> registration authority was delegated to the MAG on the home link.
> Then it would know to avoid this problem.
> 
> Stated another way, this would be a requirement induced by
> PMIP on MIPv6-compliant nodes.  Asking the obvious, one
> wonders why an operator of a home network would
> a) assume that the nodes were MIPv6-unaware, necessitating
>     a PMIP solution, and yet
> b) assume that the nodes might be MIPv6-aware, so that there is
>     danger of conflict with a PMIP solution.
> 
> What am I missing?
> 
>  >      *  MIPv6 and PMIPv6 use different mechanisms for handling re-
>  >         ordering of registration messages and they are sent by
>  >         different entities.
> 
> Looks like another design flaw to me.  If the HA/LMA
> is aware of MIPv6 sequence numbers (i.e., actually _is_
> a HA), why not require the MAG to _use_ sequence
> numbers?  This would be a trivial matter of inclusion
> into the PBA.
> 
> "(or binging cache)" --> "(or binding cache)"
> 	:-)  thanks, I needed that  :-)
> 	:-)  in fact, I need more $$ for my binges  :-)
> 
>  >      *  In this mixed scenario, both host-based and network-based
>  >         security associations are used to update the same binding
>  >         cache entry at the HA/LMA (but see the first bullet of this
>  >         list, as the entry may not be the same).
> 
> Yet more proof that the binding cache entries should
> be the same.
> 
> ====================================================================
> 
> On 5/3/2010 7:24 AM, The IESG wrote:
> > The IESG has received a request from the Network-based Localized
> Mobility
> > Management WG (netlmm) to consider the following document:
> >
> > - 'Interactions between PMIPv6 and MIPv6: scenarios and related
> issues '
> >     <draft-ietf-netlmm-mip-interactions-05.txt>  as an Informational
> RFC
> >
> > The IESG plans to make a decision in the next few weeks, and solicits
> > final comments on this action.  Please send substantive comments to
> the
> > [e-mail] mailing lists by 2010-05-17. Exceptionally,
> > comments may be sent to [e-mail] instead. In either case, please
> > retain the beginning of the Subject line to allow automated sorting.
> >
> > The file can be obtained via
> > http://www.ietf.org/internet-drafts/draft-ietf-netlmm-mip-
> interactions-05.txt
> >
> >
> > IESG discussion can be tracked via
> >
> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag
> =17831&rfc_flag=0
> >
> > _______________________________________________
> > IETF-Announce mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/ietf-announce
> >
> 
> _______________________________________________
> netlmm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netlmm