[Netext] next steps for netext
cjbc at it.uc3m.es (Carlos Jesús Bernardos Cano) Thu, 16 April 2009 16:40 UTC
From: "cjbc at it.uc3m.es"
Date: Thu, 16 Apr 2009 18:40:13 +0200
Subject: [Netext] next steps for netext
In-Reply-To: <e71f48650904160925h1d37cb6fl74c902e801c996fd@mail.gmail.com>
References: <49D5BB60.4090407@piuha.net> <Pine.GSO.4.63.0904030724180.13726@irp-view13.cisco.com> <49DA441D.2020501@piuha.net> <a752cd420904070415s2756c132q5c282802f3d86c6f@mail.gmail.com> <787855.23911.qm@web111414.mail.gq1.yahoo.com> <a752cd420904070951k68c8dcf9pe7ba7172a223efbe@mail.gmail.com> <F748BB8E-0494-436A-BDC7-EFCAC0FFF208@gmail.com> <1239839006.4695.116.camel@localhost> <e71f48650904160925h1d37cb6fl74c902e801c996fd@mail.gmail.com>
Message-ID: <1239900013.5254.37.camel@localhost>
Hi John, El vie, 17-04-2009 a las 00:25 +0800, john.zhao escribi?: > Hi Carlos, > > 2009/4/16 Carlos Jes?s Bernardos Cano <cjbc at it.uc3m.es>: > > 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) > [John.zhao]Yes.http://tools.ietf.org/html/draft-zhao-nemo-limitations-ps-00. > > >> > 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. > [John.zhao]My two cents. About the benefits for doing this, it is for > PMIPv6 domian control as mentioned in Page 8 of this draft."This > document recommends that Proxy Mobile IPv6 controls the prefix > management ......". That is from network perspective. On the > contrary,customers can use router without NEMO enble under both of > fixed network and pmip network. Of course, NEMO can make router be > benefited if it would like to be roamed. But no one can claim network > must support the 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. > [John.zhao]So,would you like extend the MAG capability to a moving > router,right? If thus, where is the LMA for this MAG? Well, it can be seen the other way around, to extend the MAG capability to be mobile... Carlos > > > Best Rgds, > Thanks, > > John.zhao > > > > 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 > > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > > > _______________________________________________ > > 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/abba16a4/attachment.bin>
- [Netext] next steps for netext Yungui Wang
- [Netext] next steps for netext Xiangsong Cui
- [Netext] next steps for netext Mohana Jeyatharan
- [Netext] next steps for netext Koodli, Rajeev
- Re: [Netext] next steps for netext netext-bounces
- [Netext] next steps for netext Sri Gundavelli
- [Netext] next steps for netext teemu.savolainen at nokia.com
- [Netext] next steps for netext john.zhao
- [Netext] next steps for netext Carlos Jesús Bernardos Cano
- [Netext] next steps for netext Carlos Jesús Bernardos Cano
- [Netext] next steps for netext Behcet Sarikaya
- [Netext] next steps for netext john.zhao
- [Netext] next steps for netext Carlos Jesús Bernardos Cano
- [Netext] next steps for netext john.zhao
- [Netext] next steps for netext Carlos Jesús Bernardos Cano
- [Netext] next steps for netext Behcet Sarikaya
- [Netext] next steps for netext Jong-Hyouk Lee
- [Netext] next steps for netext Carlos Jesús Bernardos Cano
- [Netext] next steps for netext Carlos Jesús Bernardos Cano
- [Netext] next steps for netext Carlos Jesús Bernardos Cano
- [Netext] next steps for netext Sri Gundavelli
- [Netext] next steps for netext teemu.savolainen at nokia.com
- [Netext] charter in public review Jari Arkko
- [Netext] next steps for netext Qin Wu
- [Netext] next steps for netext Ryuji Wakikawa
- [Netext] next steps for netext Sri Gundavelli
- [Netext] next steps for netext Julien Laganier
- [Netext] next steps for netext Sri Gundavelli
- [Netext] next steps for netext Domagoj Premec
- [Netext] next steps for netext Sri Gundavelli
- [Netext] next steps for netext Sri Gundavelli
- [Netext] Scope of proposed work Ryuji Wakikawa
- [Netext] next steps for netext Sri Gundavelli
- [Netext] Scope of proposed work George Tsirtsis
- [Netext] Scope of proposed work Basavaraj.Patil at nokia.com
- [Netext] next steps for netext Basavaraj.Patil at nokia.com
- [Netext] Scope of proposed work Basavaraj.Patil at nokia.com
- [Netext] Scope of proposed work Hesham Soliman
- [Netext] next steps for netext Marco Liebsch
- [Netext] next steps for netext Sri Gundavelli
- [Netext] next steps for netext Giaretta, Gerardo
- [Netext] next steps for netext Sri Gundavelli
- [Netext] next steps for netext Domagoj Premec
- [Netext] next steps for netext Giaretta, Gerardo
- [Netext] Scope of proposed work Ryuji Wakikawa
- [Netext] next steps for netext Sri Gundavelli
- [Netext] Scope of proposed work Vijay Devarapalli
- [Netext] next steps for netext Sri Gundavelli
- [Netext] Scope of proposed work Vijay Devarapalli
- [Netext] next steps for netext Ryuji Wakikawa
- [Netext] Scope of proposed work Hesham Soliman
- [Netext] next steps for netext Ryuji Wakikawa
- [Netext] next steps for netext Giaretta, Gerardo
- [Netext] next steps for netext Domagoj Premec
- [Netext] Scope of proposed work Ryuji Wakikawa
- [Netext] next steps for netext Sri Gundavelli
- [Netext] next steps for netext Domagoj Premec
- [Netext] Scope of proposed work Koodli, Rajeev
- [Netext] Scope of proposed work Ahmad Muhanna
- [Netext] Scope of proposed work Basavaraj.Patil at nokia.com
- [Netext] next steps for netext Sri Gundavelli
- [Netext] next steps for netext Frank Xia
- [Netext] next steps for netext Basavaraj.Patil at nokia.com
- [Netext] next steps for netext Vijay Devarapalli
- [Netext] next steps for netext Jong-Hyouk Lee
- [Netext] next steps for netext Jari Arkko
- [Netext] next steps for netext Domagoj Premec
- [Netext] next steps for netext George Tsirtsis
- [Netext] next steps for netext Vijay Devarapalli
- [Netext] next steps for netext Giaretta, Gerardo
- [Netext] next steps for netext Hesham Soliman
- [Netext] next steps for netext Xiangsong Cui
- [Netext] next steps for netext Giaretta, Gerardo
- [Netext] next steps for netext Vijay Devarapalli
- [Netext] next steps for netext Carlos Jesús Bernardos Cano
- [Netext] next steps for netext Giaretta, Gerardo
- [Netext] next steps for netext Behcet Sarikaya
- [Netext] next steps for netext Carlos Jesús Bernardos Cano
- [Netext] next steps for netext Carlos Jesús Bernardos Cano
- [Netext] next steps for netext Carlos Jesús Bernardos Cano
- [Netext] next steps for netext Domagoj Premec
- [Netext] next steps for netext pierrick.seite at orange-ftgroup.com
- [Netext] next steps for netext Marco Liebsch
- [Netext] next steps for netext Hesham Soliman
- [Netext] next steps for netext pierrick.seite at orange-ftgroup.com
- [Netext] next steps for netext Hesham Soliman
- [Netext] next steps for netext Hesham Soliman
- [Netext] next steps for netext pierrick.seite at orange-ftgroup.com
- [Netext] next steps for netext Hesham Soliman
- [Netext] next steps for netext Hesham Soliman
- [Netext] next steps for netext Hesham Soliman
- [Netext] next steps for netext Vijay Devarapalli
- [Netext] next steps for netext Giaretta, Gerardo
- [Netext] next steps for netext Koodli, Rajeev
- [Netext] next steps for netext Giaretta, Gerardo
- [Netext] next steps for netext teemu.savolainen at nokia.com
- [Netext] next steps for netext Ryuji Wakikawa
- [Netext] next steps for netext Jari Arkko
- [Netext] next steps for netext Jari Arkko
- [Netext] next steps for netext Jari Arkko
- [Netext] next steps for netext MELIA TELEMACO
- [Netext] next steps for netext Jari Arkko
- [Netext] next steps for netext Koodli, Rajeev
- Re: [Netext] next steps for netext netext-bounces
- [Netext] next steps for netext Sri Gundavelli
- [Netext] next steps for netext Sri Gundavelli
- [Netext] next steps for netext Jari Arkko
- [Netext] next steps for netext Vijay Devarapalli
- [Netext] next steps for netext Basavaraj.Patil at nokia.com
- [Netext] next steps for netext Vijay Devarapalli
- [Netext] next steps for netext Frank Xia
- [Netext] next steps for netext Basavaraj.Patil at nokia.com
- [Netext] next steps for netext Hesham Soliman
- [Netext] next steps for netext George Tsirtsis
- [Netext] next steps for netext teemu.savolainen at nokia.com
- [Netext] next steps for netext Giaretta, Gerardo
- [Netext] next steps for netext Frank Xia
- [Netext] next steps for netext Sri Gundavelli
- [Netext] next steps for netext Basavaraj.Patil at nokia.com
- [Netext] next steps for netext Hesham Soliman
- [Netext] next steps for netext Ahmad Muhanna
- [Netext] next steps for netext Mohana Jeyatharan
- [Netext] next steps for netext Mohana Jeyatharan
- [Netext] next steps for netext Sri Gundavelli
- [Netext] [netlmm] FW: next steps for netext Behcet Sarikaya
- [Netext] next steps for netext Sri Gundavelli
- [Netext] next steps for netext Sri Gundavelli
- [Netext] next steps for netext Rajeev Koodli
- [Netext] next steps for netext Xiangsong Cui
- [Netext] next steps for netext Jari Arkko
- [Netext] next steps for netext pierrick.seite at orange-ftgroup.com
- [Netext] next steps for netext Jari Arkko