[Netext] next steps for netext

Hi Jong-Hyouk,

El jue, 16-04-2009 a las 10:26 +0900, Jong-Hyouk Lee escribi?:
> Hi. Carlos.
>  
> In the I-D, four types of scenarios are presented. All of them mainly
> focuses on the MR involving nodes hands off between MAGs or LMAs
> (intra-domain handoff and inter-domain handoff). The scenarios for the
> case you mentioned would be covered in the next version of the I-D (I
> hope).

OK, thanks.

>  
> Do you have any issues in mind for the case? 

Well, the particular scenario that I pointed out is not supported with
existing standards. That's why I proposed working on it.

Thanks,

Carlos

>  
> Cheers. 
> 
> 
> 2009/4/16 Carlos Jes?s Bernardos Cano <cjbc at it.uc3m.es>
>         Hi Jong-Hyouk,
>         
>                Sorry for the delayed reply. I'll take a look at that
>         draft and provide
>         comments. Please, let me ask a short question (before I've
>         read the
>         draft): does the I-D look at any scenario involving an MN that
>         changes
>         its point of attachment between an MR (attached to a PMIPv6
>         domain) and
>         a MAG?
>         
>                Thanks,
>         
>                Carlos
>         
>         El jue, 09-04-2009 a las 00:54 +0900, Jong-Hyouk Lee escribi?:
>         > 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/
>         --
>           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
>         +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 
> 
> 
> -- 
> Internet Management Technology Lab, Sungkyunkwan University. 
> Jong-Hyouk Lee.
> 
> #email: jonghyouk (at) gmail (dot) com 
> #webpage: http://hurryon.googlepages.com/
-- 
   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/20090420/64fb5528/attachment.bin>