[Netext] next steps for netext

Hi Behcet,

El jue, 16-04-2009 a las 07:35 -0700, Behcet Sarikaya escribi?:
> Hi Carlos,
>   According to Ryuji's draft MN is the MR. Also in RFC 3963 MR is also
> MN for HA. So this architecture is consistent with the original Nemo
> BSP design.

	Agree.

>   It seems like you have a different architecture in mind. I think
> that's where the confusion comes.

	Well, I tried to describe what I have in mind, which is different from
what Ryuji is addressing. Not sure if this time I was more clear.

	Thanks,

	Carlos

>  
> Regards,
>  
> Behcet
> 
> 
> 
> ______________________________________________________________________
> From: Carlos Jes?s Bernardos Cano <cjbc at it.uc3m.es>
> To: Jong-Hyouk Lee <jonghyouk at gmail.com>
> Cc: netext at mail.mobileip.jp
> Sent: Wednesday, April 15, 2009 6:43:05 PM
> Subject: Re: [Netext] next steps for netext
> 
> 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 
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 
> 
-- 
   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/86afae7c/attachment.bin>