[Netext] next steps for netext
jonghyouk at gmail.com (Jong-Hyouk Lee) Thu, 16 April 2009 01:26 UTC
From: "jonghyouk at gmail.com"
Date: Thu, 16 Apr 2009 10:26:03 +0900
Subject: [Netext] next steps for netext
In-Reply-To: <1239838985.4695.114.camel@localhost>
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> <f54070070904080854l501eb9e0x18ccd9c0f21f2c66@mail.gmail.com> <1239838985.4695.114.camel@localhost>
Message-ID: <f54070070904151826v3cebb4a7s8eef7960b2b329d9@mail.gmail.com>
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). Do you have any issues in mind for the case? 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/ -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://www.mobileip.jp/pipermail/netext/attachments/20090416/097efffb/attachment-0001.html>
- [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