[Netext] next steps for netext

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mobileip.jp/pipermail/netext/attachments/20090407/c31342ed/attachment-0001.html>