[Netext] next steps for netext

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) 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?

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

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