[Netext] next steps for netext

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

Yes, my point was more related with the benefits of doing this instead
of just using NEMO.

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

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 
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
-------------- 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/0424cd94/attachment.bin>