Re: [CCAMP] 答复: OSPF OTN considerations post IETF 82 (Issue 1/2)
John E Drake <jdrake@juniper.net> Wed, 07 December 2011 13:24 UTC
Return-Path: <jdrake@juniper.net>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54E7121F8B0E for <ccamp@ietfa.amsl.com>; Wed, 7 Dec 2011 05:24:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.044
X-Spam-Level:
X-Spam-Status: No, score=-2.044 tagged_above=-999 required=5 tests=[AWL=-4.493, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7VKxdTxXJT4l for <ccamp@ietfa.amsl.com>; Wed, 7 Dec 2011 05:24:28 -0800 (PST)
Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by ietfa.amsl.com (Postfix) with ESMTP id C5D4B21F84AE for <ccamp@ietf.org>; Wed, 7 Dec 2011 05:24:27 -0800 (PST)
Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKTt9o+r+SulN08PrxySuEZfdJYkMJETcl@postini.com; Wed, 07 Dec 2011 05:24:27 PST
Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Wed, 7 Dec 2011 05:21:12 -0800
From: John E Drake <jdrake@juniper.net>
To: Lou Berger <lberger@labn.net>, Zhangfatai <zhangfatai@huawei.com>
Date: Wed, 07 Dec 2011 05:21:08 -0800
Thread-Topic: 答复: [CCAMP] OSPF OTN considerations post IETF 82 (Issue 1/2)
Thread-Index: Acy0VawszvKy4qZyQO6+1dExkH3DzAAi0U/w
Message-ID: <5E893DB832F57341992548CDBB333163A4B682A99E@EMBX01-HQ.jnpr.net>
References: <B5630A95D803744A81C51AD4040A6DAA2293E672A9@ESESSCMS0360.eemea.ericsson.se> <4ED64A32.8060707@labn.net> <5E893DB832F57341992548CDBB333163A4B54CA99D@EMBX01-HQ.jnpr.net> <4ED65D2D.2040400@labn.net> <5E893DB832F57341992548CDBB333163A4B54CADAB@EMBX01-HQ.jnpr.net> <4ED69B7D.409@labn.net> <5E893DB832F57341992548CDBB333163A4B54CAEE5@EMBX01-HQ.jnpr.net> <4EDE354F.20803@orange.com> <F82A4B6D50F9464B8EBA55651F541CF825CC18C0@SZXEML520-MBS.china.huawei.com> <4EDE7B04.5000804@labn.net>
In-Reply-To: <4EDE7B04.5000804@labn.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: CCAMP <ccamp@ietf.org>
Subject: Re: [CCAMP] 答复: OSPF OTN considerations post IETF 82 (Issue 1/2)
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ccamp>, <mailto:ccamp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ccamp>
List-Post: <mailto:ccamp@ietf.org>
List-Help: <mailto:ccamp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:ccamp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Dec 2011 13:24:29 -0000
Hi, I am unaware of any requirement to indicate layers in a multi-layer scenario - I went back and looked at both RFC5339 and RFC6001 and didn't see anything. And just to be clear, layers are technology specific. Since you mention RFC6001, I think it should be pointed out that that RFC does not address multi-layer networking, but only multi-region networking. Thanks, John > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Tuesday, December 06, 2011 12:29 PM > To: Zhangfatai > Cc: Julien Meuric; John E Drake; CCAMP > Subject: Re: 答复: [CCAMP] OSPF OTN considerations post IETF 82 (Issue > 1/2) > > > I think Julien has it right (and as I've said on this list), it's a > question of leveraging or deprecating the use of SC as an indicator of > hierarchy. Deprecating this use means that we need to move into a > technology specific hierarchy indicator, which is what you're saying ST > provides. > > The move from generic to technology-specific mechanisms, really runs > counter to the basic principals of GMPLS and is likely to have some > nasty ripple effects. (For example do we just obsolete 6001, or do a > bis which allows for / requires carrying the technology-specific layer > identifier?) > > Lou > > On 12/6/2011 2:34 PM, Zhangfatai wrote: > > Hi Julien, > > > > For TDM networks, Signal Type has beed introduced in RFC4606 or > RFC4328 or G.709V3 drafts to address what you need. > > > > Anything is missed in routing or signaling? > > > > > > Thanks > > > > Fatai > > > > > > _______________________________________ > > 发件人: ccamp-bounces@ietf.org [ccamp-bounces@ietf.org] 代表 Julien > Meuric [julien.meuric@orange.com] > > 发送时间: 2011年12月6日 23:31 > > 到: John E Drake; Lou Berger > > Cc: CCAMP > > 主题: Re: [CCAMP] OSPF OTN considerations post IETF 82 (Issue 1/2) > > > > Hi John, hi Lou. > > > > On the one hand, SONET/SDH and OTN are close: it is highly tempting > to > > prolong control of the former to the latter. Nevertheless, the GMPLS > > deployments on SONET/SDH I am aware of only control high order > > containers (i.e. SDH VC-4/VC-4-nc or SONET STS-1/STS-1-nc). In that > > context, I do not think we can easily generalized protocol extensions > > from an almost single-stage control to a highly multi-stage control. > > > > On the other hand, it seems that PSC-1 to PSC-4 have not been > > implemented much. Reasons behind are only guesses. Mine is that > > upgrading implementations and deployments of MPLS-TE was not worth > the > > pain with respect to the added value of moving to the GMPLS flavor of > > IGPs and RSVP-TE (especially for packet-only operations). Whatever > the > > actual reason for having so few implementations, PSC-n are part of > the > > original GMPLS specification. > > > > Let me quote the section about PSC in RFC 4202: "The various levels > of > > PSC establish a hierarchy of LSPs tunneled within LSPs." This really > > looks like what we are doing in OTN. Yes, the discrete nature of the > > technology will introduce one more information into the SC field, but > > doing otherwise would depreciate existing GMPLS specification. > > > > Furthermore, RFC 4203 says: "When the Switching Capability field is > TDM, > > the Switching Capability specific information field includes Minimum > LSP > > Bandwidth..." In other words, even if not included in the SC field so > > far, one cannot really say that a value per ODUk layer would overload > > the ISCD definition. > > > > Thus, we have legacy vs. depreciation: my understanding of IETF work > is > > to put emphasis on consistency and avoid defining new solutions when > > they already exist, even if not absolutely optimized (we are not > > building G.709 control from scratch). > > > > My 2 cents, > > > > Julien > > > > > > Le 30/11/2011 22:37, John E Drake a écrit : > >> Comments inline. I still think this is a terrible idea and I would > >> like to see what the rest of the WG thinks. > >> > >>> -----Original Message----- From: Lou Berger > >>> [mailto:lberger@labn.net] > >>> > >>> John, > >>> > >>> see below > >>> > >>> > >>> On 11/30/2011 2:59 PM, John E Drake wrote: > >>>> Using Switching Capability to indicate link bandwidth seems > >>>> ill-considered at best, especially since this information is > >>>> carried in other fields, and as Daniele noted, it significantly > >>>> overloads to intended meaning of Switching Capability. > >>> > >>> I agree with the point on BW, but my point was related to the > >>> layer&hierarchy implications of the different ODUk values. I'd > >>> think that using values that are TDM-1 -> TDM-n should make this > >>> clear and remove any ambiguity related to bandwidth. It is also > >>> completely consistent with the base GMPLS definition, i.e., PSC-1 > >>> -> PSC-n. > >> > >> [JD] You are simply asserting that this is a good idea and further > >> asserting that there is "ambiguity related to bandwidth', without > >> providing any evidence. > >> > >> To the best of my knowledge no one ever implemented or deployed the > >> PSC-1 -> PSC-4 hierarchy, simply because no one could figure out > what > >> it meant. To quote from you, below, "Well hopefully we have a > better > >> understanding of the technologies involved than we had in the > past.". > >> I.e., we should all understand that PSC-1 -> PSC-4 was a bad idea > >> (tm) and move on. > >> > >>> > >>>> It also is inconsistent with the usage of Switching Capability in > >>>> SDH/SONET. > >>> > >>> Well hopefully we have a better understanding of the technologies > >>> involved than we had in the past. > >> > >> [JD] I think we had a very good understanding of SDH/SONET then and > >> we have a very good understanding of OTN now, and in both cases the > >> authors saw no requirement to overload switching capability in the > >> manner you are suggesting. > >> > >>> > >>>> > >>>> A more extensive quote from RFC4202 is the following, which > >>>> seems clear enough to me: > >>>> > >>>> "In the context of this document we say that a link is connected > >>>> to a node by an interface. In the context of GMPLS interfaces > >>>> may have different switching capabilities. For example an > >>>> interface that connects a given link to a node may not be able to > >>>> switch individual packets, but it may be able to switch channels > >>>> within an SDH payload. Interfaces at each end of a link need not > >>>> have the same switching capabilities. Interfaces on the same > >>>> node need not have the same switching capabilities." > >>> > >>> Not sure how this helps clarify anything... > >> > >> [JD] I think it clarifies that switching capabilities is meant to > >> describe how a given interface switches the information with which > it > >> is provided. This has nothing to do with the interface's bandwidth. > >> > >>> > >>> Lou > >>>> > >>>>> -----Original Message----- From: Lou Berger > >>>>> [mailto:lberger@labn.net] Sent: Wednesday, November 30, 2011 > >>>>> 8:43 AM To: John E Drake Cc: Daniele Ceccarelli; CCAMP Subject: > >>>>> Re: [CCAMP] OSPF OTN considerations post IETF 82 (Issue > >>> 1/2) > >>>>> > >>>>> Great. Care to substantiate your point? > >>>>> > >>>>> On 11/30/2011 11:14 AM, John E Drake wrote: > >>>>>> I completely disagree. > >>>>>> > >>>>>>> -----Original Message----- From: ccamp-bounces@ietf.org > >>>>>>> [mailto:ccamp-bounces@ietf.org] On > >>>>> Behalf > >>>>>>> Of Lou Berger Sent: Wednesday, November 30, 2011 7:22 AM > >>>>>>> To: Daniele Ceccarelli Cc: CCAMP Subject: Re: [CCAMP] OSPF > >>>>>>> OTN considerations post IETF 82 (Issue > >>>>> 1/2) > >>>>>>> > >>>>>>> Hi Daniele, Since I raised the point, I guess I need to > >>>>>>> champion it! (With chair hat off.) > >>>>>>> > >>>>>>> All, > >>>>>>> > >>>>>>> Daniele said: > >>>>>>>> WRT issue 1: the proposal was to indicate the bottom most > >>>>>>>> ODUk of > >>>>> the > >>>>>>>> muxing hiearachy in the Switching Capability field of the > >>>>>>>> ISCD. > >>>>> After > >>>>>>>> a quick talk with the other authors of the ID, the idea > >>>>>>>> was to > >>>>> reject > >>>>>>>> the proposal as it would lead to an overloading of the > >>>>>>>> meaning of > >>>>> the > >>>>>>>> Switching Capability field. (even if the definition of > >>>>>>>> PSC1-2-3-4 already overloads the meaning of the switching > >>>>>>>> capability field) > >>>>>>> > >>>>>>> This really goes to the interpretation of the intent of > >>>>>>> Switching Capability Types. So we have a few definitions: > >>>>>>> 3471 says "the > >>> type > >>>>> of > >>>>>>> switching that should be performed", 4202 says "describes > >>> switching > >>>>>>> capability of an interface." 3945 doesn't really define the > >>>>>>> term > >>> (it > >>>>>>> just references 4202), but does equate it with a "layer". > >>>>>>> While it allows for hierarchy within a "layer" it also says > >>>>>>> hierarchy > >>> occurs > >>>>>>> "between interface types". > >>>>>>> > >>>>>>> So I interpret Switching Capability Types to represent (a) > >>> different > >>>>>>> switching/technology layers and (b) different levels of > >>>>>>> hierarchy > >>> -- > >>>>>>> even within a layer. I think (a) is identifiable in the > >>> definition > >>>>> of > >>>>>>> the original GMPLS supported technologies (i.e., PSC, L2SC, > >>>>>>> TDM > >>> LSC, > >>>>>>> and FSC), and (b) is identifiable in the original types > >>>>>>> plus the > >>>>> definition > >>>>>>> of PSC-1 through PSC-4. > >>>>>>> > >>>>>>> So how does this apply to our current OTN work? > >>>>>>> > >>>>>>> To me, the first question to ask relates to (a), and is > >>>>>>> should > >>> each > >>>>>>> ODUk be modeled as a separate layer? > >>>>>>> > >>>>>>> I know this has been a much debated point, and it seems to > >>>>>>> me that > >>>>> they > >>>>>>> are, but more for the perspective of switching layers than > >>>>> technology > >>>>>>> layers (i.e., they are clearly the same technology but are > >>> different > >>>>>>> granularity of swicthing.) So this is a yes for me. > >>>>>>> > >>>>>>> I think the second question to ask relates to (b), and is > >>>>>>> does > >>> each > >>>>>>> ODUk represent a different level of hierarchy? > >>>>>>> > >>>>>>> I see this as simply yes, and no different than what has > >>>>>>> been done > >>>>> more > >>>>>>> recently with Ethernet or, even if we do continue to model > >>>>>>> OTN as > >>> a > >>>>>>> single layer, no different than PSC-1 -> PSC-4. > >>>>>>> > >>>>>>> There's also a minor processing efficiency gained by this > >>>>>>> approach > >>>>> for > >>>>>>> nodes that support a smaller set of ODUks than are > >>>>>>> advertised > >>> within > >>>>> an > >>>>>>> IGP. > >>>>>>> > >>>>>>> Based on all this, I believe different ODUk's should use > >>>>>>> different Switching Types. In particular, I'm proposing: > >>>>>>> (1) that either the framework or info documents identify > >>>>>>> that a per-OTUk Switching Capability Types will be used to > >>>>>>> support G.709v3. (2) that > >>>>>>> draft-ietf-ccamp-gmpls-ospf-g709v3 define a different > >>>>>>> Switching Cap field value for each ODUk, and that it state > >>>>>>> that the value corresponding to the signal type identified > >>>>>>> in the #stages=0 of the ISCP be set. (Without any other > >>>>>>> changes to the current definition of ISCD.) (3) that > >>>>>>> draft-ietf-ccamp-gmpls-signaling-g709v3 be updated to match > >>>>>>> above. > >>>>>>> > >>>>>>> To keep thinks generic, we probably should use TDM-1 > >>>>>>> through TDM-n > >>>>> as > >>>>>>> the new Switching Capability Types, but this is a > >>>>>>> secondary > >>>>> discussion. > >>>>>>> > >>>>>>> Comments? > >>>>>>> > >>>>>>> Lou > >>>>>>> > >>>>>>> PS While the above is an important change, it doesn't > >>> significantly > >>>>>>> impact encoding and won't take much text to make the > >>>>>>> actual > >>> change, > >>>>> so > >>>>>>> this is a discussion that can continue until Paris if we > >>>>>>> really > >>> need > >>>>> a > >>>>>>> face to face to resolve the discussion. > >>>>>>> > >>>>>>> On 11/23/2011 1:18 PM, Daniele Ceccarelli wrote: > >>>>>>>> Hi CCAMP, > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> During the OTN OSPF draft presentation at the IETF > >>>>>>>> meeting in > >>>>> Taipei > >>>>>>> two > >>>>>>>> comments were raised with respect to the following > >>>>>>>> issues: > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> - Issue 1: Using different switching caps for each ODU > >>>>>>>> type > >>>>>>>> > >>>>>>>> - Issue 2: Type 2 (unres bandwidth for variable > >>>>>>>> containers) and > >>>>> Type > >>>>>>> 3 > >>>>>>>> (MAX LSP bandwidth foe variable containers always used in > >>>>>>>> tandem? > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> WRT issue 1: the proposal was to indicate the bottom most > >>>>>>>> ODUk of > >>>>> the > >>>>>>>> muxing hiearachy in the Switching Capability field of the > >>>>>>>> ISCD. > >>>>> After > >>>>>>> a > >>>>>>>> quick talk with the other authors of the ID, the idea was > >>>>>>>> to > >>> reject > >>>>>>> the > >>>>>>>> proposal as it would lead to an overloading of the > >>>>>>>> meaning of the Switching Capability field. (even if the > >>>>>>>> definition of PSC1-2-3-4 already overloads the meaning of > >>>>>>>> the switching capability field) > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> WRT issue 2: it is analyzed in section 5.3 of the draft > >>>>>>>> (version > >>> - > >>>>>>> 00). > >>>>>>>> I'm copying it below for your convenience > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> In this example the advertisement of an ODUflex->ODU3 > >>> hierarchy > >>>>> is > >>>>>>>> > >>>>>>>> shown. In case of ODUflex advertisement the MAX LSP > >>>>>>>> bandwidth > >>>>>>> needs > >>>>>>>> > >>>>>>>> to be advertised but in some cases also information about > >>>>>>>> the > >>>>>>>> > >>>>>>>> Unreserved bandwidth could be useful. The amount of > >>> Unreserved > >>>>>>>> > >>>>>>>> bandwidth does not give a clear indication of how many > >>>>>>>> ODUflex > >>>>> LSP > >>>>>>>> > >>>>>>>> can be set up either at the MAX LSP Bandwidth or at > >>>>>>>> different > >>>>>>> rates, > >>>>>>>> > >>>>>>>> as it gives no information about the spatial allocation > >>>>>>>> of the > >>>>>>> free > >>>>>>>> > >>>>>>>> TSs. > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> An indication of the amount of Unreserved bandwidth could > >>>>>>>> be > >>>>>>> useful > >>>>>>>> > >>>>>>>> during the path computation process, as shown in the > >>>>>>>> following > >>>>>>>> > >>>>>>>> example. Supposing there are two TE-links (A and B) with > >>>>>>>> MAX > >>>>> LSP > >>>>>>>> > >>>>>>>> Bandwidth equal to 10 Gbps each. In case 50Gbps of > >>>>>>>> Unreserved > >>>>>>>> > >>>>>>>> Bandwidth are available on Link A, 10Gbps on Link B and > >>>>>>>> 3 > >>>>> ODUflex > >>>>>>>> > >>>>>>>> LSPs of 10 GBps each, have to be restored, for sure only > >>>>>>>> one > >>> can > >>>>>>> be > >>>>>>>> > >>>>>>>> restored along Link B and it is probable (but not sure) > >>>>>>>> that > >>> two > >>>>>>> of > >>>>>>>> > >>>>>>>> them can be restored along Link A. > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> Early proposal was to have, in the case of variable > >>>>>>>> containers advertisements (i.e. ODUflex), the MAX LSP > >>>>>>>> bandwidth TLV (Type 3) > >>>>> as > >>>>>>> a > >>>>>>>> mandatory piece of information and the Unreserved > >>>>>>>> bandiwdth TLV > >>>>> (Type > >>>>>>> 2) > >>>>>>>> as an optional piece of information. > >>>>>>>> > >>>>>>>> The comment received is that optional information can > >>>>>>>> lead to interworking issues and the counter proposal was > >>>>>>>> to have both > >>>>> pieces > >>>>>>> of > >>>>>>>> information as mandatory and, as a consequence, merge the > >>>>>>>> two > >>> TLVs > >>>>>>> into > >>>>>>>> a single one. > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> We'd like to hear the opinion of the WG on both issues > >>>>>>>> before > >>>>>>> proceeding > >>>>>>>> with any modification to the document. > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> Thanks, > >>>>>>>> > >>>>>>>> Daniele > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> *DANIELE CECCARELLI * *System & Technology - DU IP & > >>>>>>>> Broadband* > >>>>>>>> > >>>>>>>> > >>>>>>>> Via L.Calda, 5 Genova, Italy Phone +390106002512 Mobile > >>>>>>>> +393346725750 daniele.ceccarelli@ericsson.com > >>>>>>>> www.ericsson.com > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> <http://www.ericsson.com/> > >>>>>>>> > >>>>>>>> > >>>>>>>> This Communication is Confidential. We only send and > >>>>>>>> receive > >>> email > >>>>> on > >>>>>>>> the basis of the term set out at > >>> www.ericsson.com/email_disclaimer > >>>>>>>> <http://www.ericsson.com/email_disclaimer> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> _______________________________________________ CCAMP > >>>>>>>> mailing list CCAMP@ietf.org > >>>>>>>> https://www.ietf.org/mailman/listinfo/ccamp > >>>>>>> _______________________________________________ CCAMP > >>>>>>> mailing list CCAMP@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/ccamp > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>> > >>>> > >>>> > >>>> > >> _______________________________________________ CCAMP mailing list > >> CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp > >> > > > > _______________________________________________ > > CCAMP mailing list > > CCAMP@ietf.org > > https://www.ietf.org/mailman/listinfo/ccamp
- [CCAMP] OSPF OTN considerations post IETF 82 Daniele Ceccarelli
- Re: [CCAMP] OSPF OTN considerations post IETF 82 John E Drake
- Re: [CCAMP] OSPF OTN considerations post IETF 82 Ong, Lyndon
- Re: [CCAMP] OSPF OTN considerations post IETF 82 … John E Drake
- Re: [CCAMP] OSPF OTN considerations post IETF 82 … Lou Berger
- Re: [CCAMP] OSPF OTN considerations post IETF 82 … John E Drake
- Re: [CCAMP] OSPF OTN considerations post IETF 82 … Lou Berger
- Re: [CCAMP] OSPF OTN considerations post IETF 82 … Lou Berger
- Re: [CCAMP] OSPF OTN considerations post IETF 82 … John E Drake
- Re: [CCAMP] OSPF OTN considerations post IETF 82 … Lou Berger
- Re: [CCAMP] OSPF OTN considerations post IETF 82 … John E Drake
- Re: [CCAMP] OSPF OTN considerations post IETF 82 … Lou Berger
- [CCAMP] R: OSPF OTN considerations post IETF 82 (… BELOTTI, SERGIO (SERGIO)
- Re: [CCAMP] R: OSPF OTN considerations post IETF … Zhangfatai
- Re: [CCAMP] OSPF OTN considerations post IETF 82 … Julien Meuric
- Re: [CCAMP] R: OSPF OTN considerations post IETF … Julien Meuric
- [CCAMP] 答复: R: OSPF OTN considerations post IETF … Zhangfatai
- [CCAMP] 答复: OSPF OTN considerations post IETF 82 … Zhangfatai
- Re: [CCAMP] 答复: OSPF OTN considerations post IETF… Lou Berger
- Re: [CCAMP] 答复: OSPF OTN considerations post IETF… Ong, Lyndon
- Re: [CCAMP] 答复: OSPF OTN considerations post IETF… John E Drake
- Re: [CCAMP] 答复: OSPF OTN considerations post IETF… Lou Berger
- Re: [CCAMP] 答复: OSPF OTN considerations post IETF… John E Drake
- [CCAMP] 答复: 答复: OSPF OTN considerations post IETF… Zhangfatai
- Re: [CCAMP] 答复: OSPF OTN considerations post IETF… Daniele Ceccarelli
- [CCAMP] R: 答复: OSPF OTN considerations post IETF … BELOTTI, SERGIO (SERGIO)
- Re: [CCAMP] OSPF OTN considerations post IETF 82 … Kireeti Kompella
- Re: [CCAMP] R: 答复: OSPF OTN considerations post I… Ong, Lyndon
- Re: [CCAMP] R: 答复: OSPF OTN considerations post I… Varma, Eve L (Eve)
- Re: [CCAMP] 答复: OSPF OTN considerations post IETF… Lou Berger
- Re: [CCAMP] 答复: 答复: OSPF OTN considerations post … Lou Berger
- Re: [CCAMP] 答复: OSPF OTN considerations post IETF… Lou Berger
- Re: [CCAMP] R: 答复: OSPF OTN considerations post I… Rajan Rao
- Re: [CCAMP] OSPF OTN considerations post IETF 82 … neil.2.harrison
- Re: [CCAMP] OSPF OTN considerations post IETF 82 … Julien Meuric
- Re: [CCAMP] 答复: R: OSPF OTN considerations post I… Julien Meuric
- Re: [CCAMP] 答复: R: OSPF OTN considerations post I… John E Drake
- Re: [CCAMP] 答复: R: OSPF OTN considerations post I… John E Drake
- [CCAMP] R: 答复: R: OSPF OTN considerations post IE… BELOTTI, SERGIO (SERGIO)
- Re: [CCAMP] 答复: R: OSPF OTN considerations post I… John E Drake
- Re: [CCAMP] 答复: R: OSPF OTN considerations post I… Sadler, Jonathan B.
- Re: [CCAMP] 答复: R: OSPF OTN considerations post I… Igor Bryskin
- Re: [CCAMP] 答复: R: OSPF OTN considerations post I… John E Drake
- Re: [CCAMP] 答复: R: OSPF OTN considerations post I… Lou Berger
- Re: [CCAMP] 答复: R: OSPF OTN considerations post I… Julien Meuric
- Re: [CCAMP] 答复: R: OSPF OTN considerations post I… John E Drake
- Re: [CCAMP] 答复: R: OSPF OTN considerations post I… John E Drake
- Re: [CCAMP] 答复: R: OSPF OTN considerations post I… John E Drake
- Re: [CCAMP] 答复: R: OSPF OTN considerations post I… John E Drake
- [CCAMP] R: 答复: R: OSPF OTN considerations post IE… BELOTTI, SERGIO (SERGIO)
- Re: [CCAMP] 答复: R: OSPF OTN considerations post I… Lou Berger
- Re: [CCAMP] 答复: R: OSPF OTN considerations post I… John E Drake
- Re: [CCAMP] 答复: R: OSPF OTN considerations post I… Lou Berger
- Re: [CCAMP] 答复: R: OSPF OTN considerations post I… John E Drake
- Re: [CCAMP] 答复: R: OSPF OTN considerations post I… John E Drake
- Re: [CCAMP] 答复: R: OSPF OTN considerations post I… Lou Berger
- Re: [CCAMP] 答复: R: OSPF OTN considerations post I… Lou Berger
- Re: [CCAMP] 答复: R: OSPF OTN considerations post I… John E Drake
- Re: [CCAMP] 答复: R: OSPF OTN considerations post I… Lou Berger
- Re: [CCAMP] 答复: R: OSPF OTN considerations post I… John E Drake
- Re: [CCAMP] 答复: R: OSPF OTN considerations post I… Lou Berger
- Re: [CCAMP] 答复: R: OSPF OTN considerations post I… John E Drake
- Re: [CCAMP] 答复: R: OSPF OTN considerations post I… John E Drake
- Re: [CCAMP] 答复: R: OSPF OTN considerations post I… Sadler, Jonathan B.
- Re: [CCAMP] 答复: R: OSPF OTN considerations post I… John E Drake
- Re: [CCAMP] 答复: R: OSPF OTN considerations post I… Daniele Ceccarelli
- Re: [CCAMP] 答复: R: OSPF OTN considerations post I… John E Drake