[Netext] next steps for netext

Hi Carlos

2009/4/17 Carlos Jes?s Bernardos Cano <cjbc at it.uc3m.es>:
> 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,
>> >> >
>> >> > 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...
>
[John.zhao]So,is it a method for moving router or MAG? And what is the
difference to the mobile Router to connect to the fixed or mobile
attachment point as you mentioned?

John.zhao

> 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
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>