Re: [netlmm] Review of draft-sgundave-mip6-proxymip6-01.txt and draft-singh-netlmm-protocol-00.txt

[Jari Arkko <[e-mail]>]

Bechet,

Actually, I think Pete raises an important point. The output
from this working group should be consistent with regards
to terminology.

And the consensus call was on approach only. It was clearly
stated that further work is needed. And that we're not
compromising on functionality because of a particular
protocol choice. There was and still is a need to deal with
technical issues, terminology issues, revise drafts etc.
And -- drafts need to meet the expectations of the working
group and trusted reviewers like Pete.

So, lets get to work if we want to have a standard out
at the end.

Jari

Behcet Sarikaya kirjoitti:
> Hi Pete,
>   Were you at SD meeting of netlmm WG?
> If you were you would understand that the consensus was to build
> netlmm solution based on the existing mobility protocol of IETF called
> Mobile IP. I know that you are a co-chair of MIP4 WG so you should
> probably care more about it.
>   netlmm DT protocol clearly did not get the consensus approval, that
> goes with the artificial terminology introduced with it (I can also
> refer you to the confusion caused to the MN-AR draft).
>   At least this was my understanding and I expressed this in several
> occasions on this mailing list.
>  
> Kind regards,
>  
> Behcet
>
> ----- Original Message ----
> From: McCann Peter-A001034 <[e-mail]>
> To: [e-mail]
> Sent: Thursday, January 25, 2007 12:48:04 PM
> Subject: [netlmm] Review of draft-sgundave-mip6-proxymip6-01.txt and
> draft-singh-netlmm-protocol-00.txt
>
> draft-sgundave-mip6-proxymip6-01.txt:
>
> This draft describes a proxy mobile IPv6 procedure where some
> of the existing messages from base mobile IPv6 are reused.
> The Binding Updates and Binding Acks are augmented with a new
> flag that informs the recipient that the registration is
> a proxy registration.
>
> The draft assumes that all the parameters about a mobile node's
> session, such as home address / prefix, address configuration
> modes (stateful vs. stateless, shared-prefix vs. per-mn prefix)
> come from a AAA server to which both the Proxy Mobility Agent (PMA)
> and Home Agent have access.  Thus there is a dependency on the use
> of some link-layer authentication based on the NAI of the user
> that gets re-invoked at each PMA.
>
> The draft describes in detail how the PMA emulates the behavior of
> the home link for both shared link and point-to-point link models.
> Shared-link behavior requires that Router Advertisements be link-layer
> unicast to the MN although they are IP-layer broadcast.
>
> In general this draft meets all of the goals in
> draft-ietf-netlmm-nohost-req-05.txt,
> although it uses different terminology from that draft.  Because
> netlmm-nohost-req
> is in the RFC editor's queue, I suggest adopting its terminology in all
> solution drafts including this one.  This means using the terms "MAG"
> and "LMA" as defined in netlmm-nohost-req.  That will help to alleviate
> confusion
> in readers that pick up the requirements document.
>
> The interaction between the local mobility management defined in this
> document and any global mobility management is unclear because it is
> not certain whether a given "Home Agent" (using the terminology in the
> draft) can be used for global (end-to-end) registrations as well as
> local registrations.  The handling of the sequence number used in global
> registrations needs to be compatible with the new timestamp ordering
> method used for local registrations.
>
> One specific comment:
> Section 4.2 gives an SPD for "mobile node SPD-S".  Should be "Proxy
> Mobility
> Agent SPD-S" or, better yet, "MAG SPD-S".
>
>
> draft-singh-netlmm-protocol-00.txt:
>
> This draft defines yet another proxy Mobile IP scheme, except that
> instead
> of moving the proxy mobility agent from AR to AR, the proxy mobility
> agent (called a PMIP client) stays at a fixed location in the network.
> This simplifies the operation of the protocol and allows for the
> complete
> re-use of existing Mobile IP Home Agents as LMAs.
>
> On the terminology issue, this draft adopts the LMA term but does not
> use the MAG term.  There may be a fundamental disconnect between the
> architecture defined in this document and netlmm-nohost-req-05, which
> states in Section 2:
>
> 2.0   NETLMM Functional Architecture
>       
>      The NETLMM architecture consists of the following components.
>      Localized Mobility Anchors (LMAs) within the backbone network
>      maintain a collection of routes for individual mobile nodes within
>      the localized mobility management domain. The routes point to the
>      Mobile Access Gateways (MAGs) managing the links on which the
>      mobile nodes currently are located. Packets for a mobile node are
>      routed to and from the mobile node through tunnels between the LMA
>      and MAG. When a mobile node moves from one link to another, the MAG
>
>      sends a route update to the LMA. While some mobile node involvement
>
>      is necessary and expected for generic mobility functions such as
>      movement  detection  and  to  inform  the  MAG  about  mobile  node
>
>      movement, no specific mobile node to network protocol will be
>      required for localized mobility management itself. Host stack
>      involvement in mobility management is thereby limited to generic
>      mobility functions at the IP layer, and no specialized localized
>      mobility management software is required.
>
> This paragraph clearly indicates that the MAGs are both the bearer-plane
> and control-plane endpoints of the signaling; thus, there is no clear
> correspondence to the MAG in draft-singh.
>
> The use of a standalone PMIP client allows for the security association
> between the "virtual" MN and the HA to remain across handoff events,
> which matches the behavior of "client" Mobile IP from the perspective
> of the home agent.  If re-use of existing home agents is a goal, this
> draft provides a good starting point.  
>
> The separation of bearer and control offered by this protocol is also
> attractive.  However, the draft calls for a new protocol to be used
> between the PMIP Client and the AR, which is currently unspecified.
> To promote interoperability between PMIP clients and ARs from different
> vendors, the encapsulation protocol should be specified in some future
> revision of this document.
>
> I would also recommend deleting the scenarios describing the use of
> an HMIP MAP.  I don't think these have seen widespread deployment
> and the scenarios given in the draft distract from the main elements
> of the new protocol.
>
> -Pete
>
> _______________________________________________
> netlmm mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/netlmm
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> netlmm mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/netlmm
>   


_______________________________________________
netlmm mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/netlmm