[Netext] next steps for netext

cjbc at it.uc3m.es (Carlos Jesús Bernardos Cano) Thu, 16 April 2009 16:40 UTC

From: "cjbc at it.uc3m.es"
Date: Thu, 16 Apr 2009 18:40:13 +0200
Subject: [Netext] next steps for netext
In-Reply-To: <e71f48650904160925h1d37cb6fl74c902e801c996fd@mail.gmail.com>
References: <49D5BB60.4090407@piuha.net> <Pine.GSO.4.63.0904030724180.13726@irp-view13.cisco.com> <49DA441D.2020501@piuha.net> <a752cd420904070415s2756c132q5c282802f3d86c6f@mail.gmail.com> <787855.23911.qm@web111414.mail.gq1.yahoo.com> <a752cd420904070951k68c8dcf9pe7ba7172a223efbe@mail.gmail.com> <F748BB8E-0494-436A-BDC7-EFCAC0FFF208@gmail.com> <1239839006.4695.116.camel@localhost> <e71f48650904160925h1d37cb6fl74c902e801c996fd@mail.gmail.com>
Message-ID: <1239900013.5254.37.camel@localhost>

Hi John,

El vie, 17-04-2009 a las 00:25 +0800, john.zhao escribi?:
> Hi Carlos,
> 
> 2009/4/16 Carlos Jes?s Bernardos Cano <cjbc at it.uc3m.es>:
> > Hi Ryuji,
> >        Sorry for the delayed reply. Comments below.
> >
> > El mi?, 08-04-2009 a las 18:04 -0400, Ryuji Wakikawa escribi?:
> >> Hello Carlos,
> >>
> >> On 2009/04/07, at 12:51, Carlos Jes?s Bernardos Cano wrote:
> >>
> >> > Hi Behcet,
> >> >
> >> > I've quickly checked the document. I think it does address the same
> >> > problem I was referring to. This draft addresses the problem of
> >> > delegating a prefix to a router that attaches to a PMIPv6 domain, so
> >> > it can provide connectivity to nodes attached to it. I think this was
> >> > already discussed in a past meeting (a draft with the problem
> >> > statement)
> [John.zhao]Yes.http://tools.ietf.org/html/draft-zhao-nemo-limitations-ps-00.
> 
> >> > and I mentioned that IMHO this can basically be achieved by
> >> > just using plain NEMO support on the router. The only difference in
> >> > this draft is that it doesn't impose the router to be a NEMO RFC3963
> >> > MR, although still it needs to do some additional things that a normal
> >> > router (not mobile) doesn't. Anyway, I'm not against this type of
> >> > support if there are scenarios in which it's useful.
> >>
> >> In the doc, we just specify how to get mobile network prefix from DHCP-
> >> DR.
> >> DHCP-PD is that normal router does, right?
> >
> > Yes, my point was more related with the benefits of doing this instead
> > of just using NEMO.
> [John.zhao]My two cents. About the benefits for doing this, it is for
> PMIPv6 domian control as mentioned in Page 8 of this draft."This
> document recommends that Proxy Mobile IPv6 controls the prefix
> management ......". That is from network perspective. On the
> contrary,customers can use router without NEMO enble under both of
> fixed network and pmip network.  Of course, NEMO can make router be
> benefited if it would like to be roamed. But no one can claim network
> must support the NEMO.
> >
> >>
> >> > However, the kind of NEMO+PMIPv6 support I'm considering goes a little
> >> > bit beyond that, since what I want to enable is node to be able to
> >> > benefit from network based localised mobility support not only when
> >> > roaming between fixed points of attachment (this is what RFC5213 does
> >> > today) but also when roaming between fixed and mobile points of
> >> > attachment. What people do think about this scenario?
> >>
> >> I don't know what is fixed and mobile points of attachment. You can
> >> clarify these.
> >>
> >
> > I've sent another e-mail regarding this (hope there is more clear).
> > Summarising, what I call a fixed point of attachment is a MAG as it is
> > defined in RFC5213 that does not move. I call a mobile point of
> > attachment a MAG that would also be able to move (like an MR) within the
> > PMIPv6 domain.
> [John.zhao]So,would you like extend the MAG capability to a moving
> router,right? If thus, where is the LMA for this MAG?

Well, it can be seen the other way around, to extend the MAG capability
to be mobile...

Carlos

> 
> 
>         Best Rgds,
> Thanks,
> 
> John.zhao
> >
> > Thanks,
> >
> > Carlos
> >
> >> ryuji
> >>
> >> >
> >> >
> >> > Thanks,
> >> >
> >> > Carlos
> >> >
> >> > 2009/4/7 Behcet Sarikaya <behcetsarikaya at yahoo.com>:
> >> >> Hi Carlos,
> >> >>   Check this out:
> >> >> http://tools.ietf.org/html/draft-wakikawa-netext-pmip6-nemo-
> >> >> support-00
> >> >>
> >> >> Regards,
> >> >>
> >> >> Behcet
> >> >>
> >> >> ________________________________
> >> >> From: Carlos Jes?s Bernardos Cano <cjbc at it.uc3m.es>
> >> >> To: Jari Arkko <jari.arkko at piuha.net>
> >> >> Cc: netext at mail.mobileip.jp
> >> >> Sent: Tuesday, April 7, 2009 6:15:42 AM
> >> >> Subject: Re: [Netext] next steps for netext
> >> >>
> >> >> Hi Jari, all,
> >> >>
> >> >> Regarding the NEMO topic, I don't know what Sri has in mind, but my
> >> >> personal view on that is that it'd be nice to extend PMIPv6 to
> >> >> support
> >> >> mobile networks. What I mean here is that it'd be nice to enable MAGs
> >> >> to also move (like MRs, but without even supporting RFC3963), so an
> >> >> MR
> >> >> would be able to move between fixed and mobile MAGs without changing
> >> >> its IP address (same support RFC5213 gives now). There are some
> >> >> interesting scenarios that could benefit from this.
> >> >>
> >> >> What do others think? It is interesting to work on this?
> >> >>
> >> >> Thanks,
> >> >>
> >> >> Carlos
> >> >>
> >> >> 2009/4/6 Jari Arkko <jari.arkko at piuha.net>:
> >> >>> Sri,
> >> >>>
> >> >>> Thanks for your input. Inline:
> >> >>>
> >> >>>> I've a concern with the planned charter. The list is too random and
> >> >>>> cherry picked and I dont believe proper input from all the folks
> >> >>>> went
> >> >>>> into
> >> >>>> this. There are many other items that are required for a reasonable
> >> >>>> deployment of Proxy Mobile IPv6. Many items were proposed over
> >> >>>> the last 2
> >> >>>> years, some of them that were left out in the base spec, some
> >> >>>> that we
> >> >>>> realized as gaps when compared to other SDO protocols and some as
> >> >>>> optimizations that we realized while implementing PMIP6, these
> >> >>>> items
> >> >>>> should be in the initial scope.
> >> >>>>
> >> >>>> I understand the charter needs to be limited in scope, but just 3
> >> >>>> or 4
> >> >>>> random items, I'm not sure if this helps in short term PMIP6
> >> >>>> requirements.
> >> >>>> I've no issue with the currently listed items, but there are
> >> >>>> other items
> >> >>>> that should get equal or higher priority.
> >> >>>
> >> >>> I have no problem with adding more. Even the charter says new
> >> >>> things can
> >> >>> be
> >> >>> added.
> >> >>>
> >> >>> However, from a process perspective what I did was to take the
> >> >>> proposal on
> >> >>> the table, i.e., the full BOF scope and see what parts of that we
> >> >>> already
> >> >>> have an agreement on. I didn't include other things that were not
> >> >>> discussed
> >> >>> in the BOF. Maybe that would have been useful, but they were not
> >> >>> on the
> >> >>> table.
> >> >>>
> >> >>> We could add more items now, if there's general agreement that those
> >> >>> things
> >> >>> are useful. However, I do not want to declare an open season on
> >> >>> doing
> >> >>> everything. We pick a reasonable subset of all proposed work,
> >> >>> based on
> >> >>> priorities, community agreement that they are the right things to
> >> >>> do,
> >> >>> management reasons to ensure that we are not doing too much, etc.
> >> >>>
> >> >>>> For example, item #6, is absolutely required, from the
> >> >>>> perspective of
> >> >>>> having a complete specification of 5213. There we allowed a
> >> >>>> mobile node
> >> >>>> to
> >> >>>> perform handoff betweek two interfaces. We defined all the hooks
> >> >>>> on the
> >> >>>> network side, but we did not provide how a terminal vendor can
> >> >>>> support
> >> >>>> that. A simple informational draft on how some one move prefixes
> >> >>>> between
> >> >>>> interfaces will greatly help. Some guidance on how to create a
> >> >>>> virtual
> >> >>>> interface and also some related notes for each platform (Linux,
> >> >>>> BSD,
> >> >>>> Android ..etc). This should not fall in the controversial
> >> >>>> discussion
> >> >>>> scope
> >> >>>> of same address on two interfaces etc, thats a different problem,
> >> >>>> or
> >> >>>> about
> >> >>>> the issue of enhancing mobile node's capabilities. This is just
> >> >>>> informational work, required to leverage what 5213 already
> >> >>>> supports.
> >> >>>
> >> >>> I suspect this is about the scoping of the handoff work. Lets try to
> >> >>> figure
> >> >>> out what makes sense (I personally believe the above item makes
> >> >>> sense, for
> >> >>> instance) and what doesn't.
> >> >>>
> >> >>> The fact that these parts were not in the charter was not a
> >> >>> declaration
> >> >>> that
> >> >>> we're dismissing them. Its just that we didn't finish the
> >> >>> discussion, but
> >> >>> I
> >> >>> still wanted to let the other things move forward.
> >> >>>
> >> >>>> Item #2, is required. The multimob BOF raised some issues, we
> >> >>>> need to
> >> >>>> show how multicast services can be enabled in PMIP network. May
> >> >>>> be this
> >> >>>> wont require extensions, a simple draft covering those aspects
> >> >>>> will help.
> >> >>>
> >> >>> As you may recall, in the Multimob BOF we did not have an
> >> >>> agreement on
> >> >>> what
> >> >>> exactly is needed, if anything. My own conclusion is that we
> >> >>> probably need
> >> >>> at least an informational document that explains how to use RFC
> >> >>> 5213 for
> >> >>> multicast. I think we discussed the possibility of doing this as
> >> >>> some kind
> >> >>> of AD sponsored document or in one of the relevant WGs, as a joint
> >> >>> work
> >> >>> between PMIP and multicast experts.
> >> >>>
> >> >>> I'm on the fence about adding this work to the charter right now,
> >> >>> mainly
> >> >>> because the BOF back then was very inconclusive. I'd be happier if
> >> >>> I saw
> >> >>> an
> >> >>> actual well written draft from say you and some of the multicast
> >> >>> experts.
> >> >>> There's no problem moving good documents forward, even if they are
> >> >>> not in
> >> >>> the charter of some WG. Then again, I wouldn't necessarily mind a
> >> >>> maintenance like item for this in one of the WG charters either.
> >> >>>
> >> >>>> I think, the charter should be bit more relaxed and more
> >> >>>> extensive. As I
> >> >>>> see it, atleast the folks are interested in doing the work. We
> >> >>>> should add
> >> >>>> atleast 4 or 5 more items to this list.
> >> >>>
> >> >>> Generally speaking IETF WG charters give specific work items that
> >> >>> the WG
> >> >>> should work on. I had hoped that the charter text:
> >> >>>
> >> >>> "The NETEXT working group will also act as the primary forum where
> >> >>> new
> >> >>> extensions on top of the Proxy Mobile IPv6 protocol can be
> >> >>> developed. The
> >> >>> addition of such new extensions to the working group involves
> >> >>> addition of
> >> >>> the extension to this charter through the normal rechartering
> >> >>> process."
> >> >>>
> >> >>> gives an indication that we intend to do more! I am also
> >> >>> personally very
> >> >>> happy to add more items to the group's charter. All in all, I do
> >> >>> know that
> >> >>> the current charter is a bit on the thin side -- mostly because the
> >> >>> multihoming/interaccess issue is under discussion.
> >> >>>
> >> >>> There's also the question of general maintenance items. Some IETF
> >> >>> WGs have
> >> >>> a
> >> >>> general work item to fix problems and issue updates to existing
> >> >>> specifications. I think we need to do that for Proxy Mobile IPv6
> >> >>> as well.
> >> >>> But we have not decided whether that item should go to NETLMM or
> >> >>> NETEXT WG
> >> >>> yet. Please rest assured that the work will be possible regardless
> >> >>> of
> >> >>> this.
> >> >>>
> >> >>>> 1. Dynamic LMA Assignment
> >> >>>>
> >> >>>> In blade architecture systems or in a load balancer
> >> >>>> configuration, the
> >> >>>> PDNGW
> >> >>>> should have the ability to dynamically assign a LMA on the fly,
> >> >>>> along the
> >> >>>> lines of Mobile IPv4 Dynamic Home Agent Address Assignment support
> >> >>>> [RFC-4433].
> >> >>>> Currently, GTP provides such semantics and this is a important
> >> >>>> requirement
> >> >>>> for deployment. Here the goal is to
> >> >>>>
> >> >>>> a.) Expose a single IP address to the SGW
> >> >>>> b.) The exposed IP address should not be in path once the
> >> >>>> assignment is
> >> >>>> done.
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>> [LMA1]---
> >> >>>> | |
> >> >>>> [LMA2]--[LMA]==========[MAG]
> >> >>>> | |
> >> >>>> [LMA3]---
> >> >>>>
> >> >>>>
> >> >>>> Along the lines of:
> >> >>>>
> >> >>>> http://tools.ietf.org/html/draft-korhonen-netext-redirect-01
> >> >>>
> >> >>> This is in the proposed NETEXT charter already.
> >> >>>
> >> >>>> 2. Multicast Support in Proxy Mobile IPv6
> >> >>>>
> >> >>>> We need an informational specification on how multicast support
> >> >>>> can be
> >> >>>> enabled in Proxy Mobile IPv6 environment. Behcet has done extensive
> >> >>>> analysis
> >> >>>> on
> >> >>>> this. This is required and critical for enabling any multicast
> >> >>>> services.
> >> >>>> However,
> >> >>>> Behcet may disagree with the scope of the work.
> >> >>>
> >> >>> See above.
> >> >>>
> >> >>>> 3. Bulk Registration Support
> >> >>>>
> >> >>>> This is a simple extension which helps in signaling optimization,
> >> >>>> along
> >> >>>> the
> >> >>>> lines of:
> >> >>>>
> >> >>>> http://tools.ietf.org/html/draft-premec-netlmm-bulk-re-registration-02
> >> >>>
> >> >>> This is in the charter as well.
> >> >>>
> >> >>>> 4. Partial Failover Support
> >> >>>>
> >> >>>> We need a mechanism to notify the peer on revoke a partial set of
> >> >>>> bindings.
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>> http://tools.ietf.org/id/draft-koodli-netlmm-path-and-session-management-00
> >> >>>> .
> >> >>>> txt
> >> >>>
> >> >>> Hmm. Ok. This needs more discussion.
> >> >>>
> >> >>>> 5. Group Identifier Support for Proxy Mobile IPv6
> >> >>>>
> >> >>>> This provides a simple and a generic semantic for assigning a group
> >> >>>> identifier
> >> >>>> to a mobile node's binding. GTP has very similar semantics,
> >> >>>> Connexion Set
> >> >>>> Id.
> >> >>>> Both #3 and #4 can leverage this. Additionally, in load balancer
> >> >>>> systems
> >> >>>> where
> >> >>>> the load balancer is in path for all signaling messages, it can
> >> >>>> use this
> >> >>>> as
> >> >>>> a
> >> >>>> tag for redirecting the message.
> >> >>>>
> >> >>>> http://tools.ietf.org/html/draft-gundavelli-netext-mn-groupid-option-00
> >> >>>
> >> >>> Since the bulk registration work is in the charter, can't you do the
> >> >>> sensible design (whatever it is) under that? There is no
> >> >>> requirement that
> >> >>> one charter item equals one document.
> >> >>>
> >> >>>> 6. Virtual-Interface Support on IP host for supporting Inter-tech
> >> >>>> handoffs:
> >> >>>>
> >> >>>>
> >> >>>> RFC-5213 supports handoff between two interfaces. The ability to
> >> >>>> move
> >> >>>> prefixes between interfaces. In other words address continuity is
> >> >>>> assured
> >> >>>> with any IPv6 host on the planet and with absolutely no changes.
> >> >>>> This
> >> >>>> meets
> >> >>>> even Dave's comment, that "no changes to any IETF RFC's.". Now,
> >> >>>> what is
> >> >>>> not assured is the aspect of session continuity. Which requires a
> >> >>>> virtual
> >> >>>> interface implementation on the host, by binding the address/
> >> >>>> prefix to a
> >> >>>> virtual interface and by not exposing the physical interface or
> >> >>>> by hiding
> >> >>>> the handoff events from the layer-3 stack.
> >> >>>>
> >> >>>> In essence, we need an informational specification which provides
> >> >>>> some
> >> >>>> general guidance to how to leverage the feature support provided in
> >> >>>> RFC-5213,
> >> >>>> along the lines of:
> >> >>>>
> >> >>>> http://tools.ietf.org/html/draft-yokota-netlmm-pmipv6-mn-itho-support-00
> >> >>>
> >> >>> This is part of the discussion that we need to finish. But I plan
> >> >>> to let
> >> >>> the
> >> >>> rest of the stuff move forward even before we have done that.
> >> >>>
> >> >>>
> >> >>>> 7. Route Optimization for Proxy Mobile IPv6
> >> >>>>
> >> >>>> There were atleast 4 drafts in this area on Route Optimization.
> >> >>>> Marco
> >> >>>> Liebsch
> >> >>>> analyzed this exensively:
> >> >>>>
> >> >>>>
> >> >>>> http://tools.ietf.org/html/draft-liebsch-netext-pmip6-ro-ps-00
> >> >>>>
> >> >>>>
> >> >>>> http://www.ietf.org/internet-drafts/draft-koodli-netext-local-forwarding-00
> >> >>>> .
> >> >>>> txt
> >> >>>
> >> >>> This is in the charter.
> >> >>>
> >> >>>> 8. Prefix Management in Proxy Mobile IPv6 support
> >> >>>>
> >> >>>> Proxy Mobile IPv6 allows the assignment of multiple home network
> >> >>>> prefixes
> >> >>>> to a given mobile node's interface. It might be useful to specify
> >> >>>> how the
> >> >>>> LMA manages this aspects. It can potentially use DHCP PD, Local
> >> >>>> Pools or
> >> >>>> AAA to manage this aspect. Behcet has one draft on this.
> >> >>>
> >> >>> I'm not personally sold on this particular work. But again, this
> >> >>> could be
> >> >>> something to consider.
> >> >>>
> >> >>>> 9. Partial Handoff Support
> >> >>>>
> >> >>>> We are missing some semantics in 5213 for moving a subset of the
> >> >>>> prefixes
> >> >>>> between interfaces as part of the inter-tech handoff. This is about
> >> >>>> defining
> >> >>>> a new handoff value. This allows partial flow management, but
> >> >>>> moving the
> >> >>>> flows associated to a prefix, as a whole group.
> >> >>>>
> >> >>>>
> >> >>>> http://tools.ietf.org/html/draft-jeyatharan-netext-pmip-partial-handoff-00
> >> >>>
> >> >>> A part of the topic we still need to discuss...
> >> >>>
> >> >>>> 10. CMIPv4/PMIP Interworking
> >> >>>>
> >> >>>> This is probably required to specify how an IPv4-only can move
> >> >>>> between
> >> >>>> CMIP and PMIP environments.
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>> http://sunsite.mff.cuni.cz/MIRRORS/ftp.rfc-editor.org/internet-drafts/draft-
> >> >>>> meghana-netlmm-pmipv6-mipv4-00.txt
> >> >>>
> >> >>> Client MIPv6 and Proxy MIPv6 interoperability is already in the
> >> >>> NETLMM
> >> >>> charter, but this work is presumably about interaction with MIPv4.
> >> >>> Might
> >> >>> be
> >> >>> useful work, I wouldn't mind if this was done in NETEXT at some
> >> >>> point. Is
> >> >>> this crucial to be in the first revision of the WG's charter?
> >> >>>
> >> >>>> 11. NEMO/Prefix delegation to Mobile Node in Proxy Mobile IPv6
> >> >>>
> >> >>> Can you expand on this?
> >> >>>
> >> >>> Jari
> >> >>>
> >> >>> _______________________________________________
> >> >>> NetExt mailing list
> >> >>> NetExt at mail.mobileip.jp
> >> >>> http://www.mobileip.jp/mailman/listinfo/netext
> >> >>>
> >> >> _______________________________________________
> >> >> NetExt mailing list
> >> >> NetExt at mail.mobileip.jp
> >> >> http://www.mobileip.jp/mailman/listinfo/netext
> >> >>
> >> >>
> >> >
> >> > _______________________________________________
> >> > NetExt mailing list
> >> > NetExt at mail.mobileip.jp
> >> > http://www.mobileip.jp/mailman/listinfo/netext
> >>
> > --
> >   Carlos Jes?s Bernardos Cano     http://www.netcoms.net
> >   GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67
> > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >                IEEE Network Special Issue on
> >        Advances in Vehicular Communications Networks
> >  http://www.comsoc.org/livepubs/ni/info/cfp/cfpnetwork0110.htm
> > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >
> > _______________________________________________
> > NetExt mailing list
> > NetExt at mail.mobileip.jp
> > http://www.mobileip.jp/mailman/listinfo/netext
> >
> >
-- 
   Carlos Jes?s Bernardos Cano     http://www.netcoms.net
   GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
                IEEE Network Special Issue on
        Advances in Vehicular Communications Networks
 http://www.comsoc.org/livepubs/ni/info/cfp/cfpnetwork0110.htm 
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Esta parte del mensaje est? firmada	digitalmente
URL: <http://www.mobileip.jp/pipermail/netext/attachments/20090416/abba16a4/attachment.bin>