[Netext] next steps for netext

Hi Ryuji,

	Sorry for the delayerd reply. Comments below...

El mi?, 08-04-2009 a las 18:01 -0400, Ryuji Wakikawa escribi?:
> Hello Carlos,
> 
> On 2009/04/07, at 7:15, Carlos Jes?s Bernardos Cano wrote:
> 
> > 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.
> 
> It sounds interesting, but what is the benefit of this?

First a correction, where I wrote above "so an MR would be able" it
should say "son an MN would be able". This is clearly misleading, sorry
for that.

Once I clariffied this, I clearly see a benefit in extending the PMIPv6
support so MAGs can also be mobile, while not breaking anything from the
point of view of an MN roaming between fixed ("classical") MAGs and
mobile MAGs.

> For supporting NEMO, which prefix will you assign to hosts under the  
> MR (MAG)?

I think that in order to support mobility between fixed and mobile MAGs,
the prefix assigned to hosts under the mobile MAG should be assigned by
the LMA. Otherwise there is no way of ensuring that the MN would
preserve its IPv6 address when moving from the mobile MAG to a fixed
one, right?

> The prefix is not assigned to MAG, but to a mobile host in RFC5213.
> 
> ryuji
> 
> 
> >
> >
> > 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
> 
-- 
   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/43fccfa4/attachment-0001.bin>