[Netext] next steps for netext

Hi, Carlos.

Good to see your posts in this mailing. Anyway, the following document has
been expired would provide some scenarios for NEMO within PMIPv6 networks.

http://tools.ietf.org/html/draft-jhlee-netlmm-nemo-scenarios-01

Have a good day!

2009/4/8 Carlos Jes?s Bernardos Cano <cjbc at it.uc3m.es>

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

-- 
Internet Management Technology Lab, Sungkyunkwan University.
Jong-Hyouk Lee.

#email: jonghyouk (at) gmail (dot) com
#webpage: http://hurryon.googlepages.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mobileip.jp/pipermail/netext/attachments/20090409/5e6e82ee/attachment-0001.html>