Re: [CCAMP] 答复: R: OSPF OTN considerations post IETF 82 (Issue 1/2)
John E Drake <jdrake@juniper.net> Tue, 20 December 2011 16:51 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 B7BB321F8B71 for <ccamp@ietfa.amsl.com>; Tue, 20 Dec 2011 08:51:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.193
X-Spam-Level: *
X-Spam-Status: No, score=1.193 tagged_above=-999 required=5 tests=[AWL=-2.456, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, J_CHICKENPOX_38=0.6, J_CHICKENPOX_46=0.6, 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 JkGo+3-J7ySh for <ccamp@ietfa.amsl.com>; Tue, 20 Dec 2011 08:51:51 -0800 (PST)
Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id 8C6D321F8B70 for <ccamp@ietf.org>; Tue, 20 Dec 2011 08:51:50 -0800 (PST)
Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKTvC9I231fOasZbOr/LmwFkYdN6fxi9wE@postini.com; Tue, 20 Dec 2011 08:51:50 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; Tue, 20 Dec 2011 08:50:18 -0800
From: John E Drake <jdrake@juniper.net>
To: Lou Berger <lberger@labn.net>, "Sadler, Jonathan B." <Jonathan.Sadler@tellabs.com>
Date: Tue, 20 Dec 2011 08:50:16 -0800
Thread-Topic: [CCAMP] 答复: R: OSPF OTN considerations post IETF 82 (Issue 1/2)
Thread-Index: Acy/NFPTbH35YCuaSM2GhBCG43y0mgAAqy0A
Message-ID: <5E893DB832F57341992548CDBB333163A54B517BEA@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> <F050945A8D8E9A44A71039532BA344D81918795F@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <F82A4B6D50F9464B8EBA55651F541CF825CB0593@SZXEML520-MBX.china.huawei.com> <4EDE3E19.6010303@orange.com> <F82A4B6D50F9464B8EBA55651F541CF825CC18AB@SZXEML520-MBS.china.huawei.com> <4EF0A18F.4080000@orange.com> <5E893DB832F57341992548CDBB333163A54B517AFD@EMBX01-HQ.jnpr.net> <F050945A8D8E9A44A71039532BA344D819BA8E25@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <5E893DB832F57341992548CDBB333163A54B517B62@EMBX01-HQ.jnpr.net> <5292FFA96EC22A4386067E9DBCC0CD2B010A0998FB37@EX-NAP.tellabs-west.tellabsinc.net> <4EF0B788.7020700@labn.net>
In-Reply-To: <4EF0B788.7020700@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] 答复: R: 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: Tue, 20 Dec 2011 16:51:53 -0000
Hi, I have several observations: 1) We are just repeating ourselves 2) I think both Lou and Julien are close to abusing their positions as WG chairs 3) There seems to be a preponderance of opinion to go with the current design Therefore, I would like to call the question and have Deborah decide what our design direction is to be. Thanks, John > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Tuesday, December 20, 2011 8:28 AM > To: Sadler, Jonathan B. > Cc: John E Drake; BELOTTI, SERGIO (SERGIO); CCAMP > Subject: Re: [CCAMP] 答复: R: OSPF OTN considerations post IETF 82 > (Issue 1/2) > > Jonathan, > This point is precisely (one of) the key reasons I put forward > the > proposal on multiple SC types. > > Lou > > On 12/20/2011 11:12 AM, Sadler, Jonathan B. wrote: > > John, > > > > > > > > While each ODU layer is a single layer network, how the ODUs interact > > with each other (e.g. placing an ODU0 into an ODU1) generates a > > multi-layer network. > > > > > > > > This detail is especially important when dealing with multi-stage > > multiplexing (eg ODU0 over ODU1 over ODU2) AND dealing with different > > adaptation styles (e.g. 2.5G TS vs 1.2G TS) > > > > > > > > CCAMP did get a liaison from ITU-T last year pointing these details > out > > (LS221). > > > > > > > > Jonathan Sadler > > > > > > > > *From:* ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] *On > > Behalf Of *John E Drake > > *Sent:* Tuesday, December 20, 2011 10:02 AM > > *To:* BELOTTI, SERGIO (SERGIO) > > *Cc:* CCAMP > > *Subject:* Re: [CCAMP] 答复: R: OSPF OTN considerations post IETF 82 > > (Issue 1/2) > > > > > > > > Sergio, > > > > > > > > Excellent. Jonathan, check this out. > > > > > > > > Thanks, > > > > > > > > John > > > > > > > > *From:* BELOTTI, SERGIO (SERGIO) [mailto:sergio.belotti@alcatel- > lucent.com] > > *Sent:* Tuesday, December 20, 2011 7:59 AM > > *To:* John E Drake > > *Cc:* CCAMP; Zhangfatai; Julien Meuric > > *Subject:* R: [CCAMP] 答复: R: OSPF OTN considerations post IETF 82 > > (Issue 1/2) > > > > > > > > John, > > > > Just to emphasize what you've already well mentioned about multi- > layer > > in OTN. > > > > > > > > This is what reports the Recommendation representing Optical > Transport > > Network architecture , G.872. > > > > ..... > > > > "Since the resources that support these topological components > support a > > heterogeneous assembly of ODUs, the ODU layer is modelled as a single > > layer network that is independent of bit-rate. The ODU bit-rate is a > > parameter that allows the number of Tributary Slots (TS) for the ODU > > link connection to be determined." > > > > > > > > > > > > > > > > Thanks > > > > > > > > Sergio > > > > > > > > > > > > > > > > > > > > -----Messaggio originale----- > > Da: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] Per conto > di > > John E Drake > > Inviato: martedì 20 dicembre 2011 16.14 > > A: Julien Meuric; Zhangfatai > > Cc: CCAMP > > Oggetto: Re: [CCAMP] 答复: R: OSPF OTN considerations post IETF 82 > > (Issue 1/2) > > > > > > > > Julien, > > > > > > > > I don't know how many times we want to go over this. > > > > > > > > As you might expect, Switching Capability enables path computation to > be > > aware of regions in which there are different switching capabilities. > > It was never intended to delineate sub-regions (layers) within those > > regions. In particular, nowhere in the entire body of the > > Multi-Layer/Multi-Region work is this capability mentioned. > > > > > > > > Further, it is not used in this manner in SDH/SONET which, along with > > OTN, is the best example of a multi-layer network with which we have > to > > deal and the last time we had this discussion, prior to Maastricht, > it > > was stated that the ITU has deprecated the use of the concept of > > multi-layer in its modeling of OTN networks. > > > > > > > > Could we please agree that PSC 1-4 was an aberration that can be > > attributed to inexperience and just erase it from our collective > memory? > > > > > > > > Thanks, > > > > > > > > John > > > > > > > >> -----Original Message----- > > > >> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > Behalf > > > >> Of Julien Meuric > > > >> Sent: Tuesday, December 20, 2011 6:54 AM > > > >> To: Zhangfatai > > > >> Cc: CCAMP > > > >> Subject: Re: [CCAMP] 答复: R: OSPF OTN considerations post IETF 82 > > > >> (Issue 1/2) > > > >> > > > >> Hi Fatai. > > > >> > > > >> About the IGP, I believe we agree on several things: > > > >> - we are dealing with the ODUk layers within the OTN > > > >> technology/regions; > > > >> - the ISCD is an appropriate place to put the information on ODUk > > > >> capabilities of nodes. > > > >> > > > >> What we disagree on: > > > >> - using the term "extension" to refer to encoding the hierarchy > level > > > >> in > > > >> the SC field: the _fact_ is that PSC-[1~4] are part of existing RFCs > > > >> (e.g. 4203); > > > >> - selecting the SC field as an information on the hierarchy level. > > > >> > > > >> This leaves us with an open discussion on the latter. We already > have 2 > > > >> options on the table for the ISCD in IGPs: > > > >> a) multiple SC values, > > > >> b)"Switching Cap & Signal Type (& Encoding Type as well)". > > > >> > > > >> First of all, I do not believe the original intend of SC alone was > to > > > >> reflect the notion of region: xSC acronyms may map to "regions", but > > > >> from a codepoint perspective we can have several values behind a > single > > > >> xSC (e.g. x=P). > > > >> > > > >> Then you propose to use the "[OTN] Signal Type": as opposed to a) > > > >> above, > > > >> this is a new extension, created in > > > >> draft-ietf-ccamp-gmpls-ospf-g709v3-00. As emphasized by Kireeti, the > SC > > > >> field should allow to constrain path computation into a range or a > > > >> sub-part of the hierarchy (without necessarily specifying a full > list). > > > >> The I-D uses a single SC (OTN-TDM) for the whole OTN, which means > the > > > >> SC > > > >> field is useless to prune the network graph when routing an ODUk: > even > > > >> for pruning, a CSFP implementation needs to parse some OTN-specific > > > >> sub-TLVs. Hence I prefer the "old-fashion" approach which represent > the > > > >> hierarchy information at a higher level in the IGP, like it was done > > > >> for > > > >> PBB-TE (RFC 6060). > > > >> > > > >> Regards, > > > >> > > > >> Julien > > > >> > > > >> > > > >> Le 06/12/2011 20:21, Zhangfatai a écrit : > > > >> > Hi Julien, > > > >> > > > > >> > I agree the requirement that you mentioned, but it can be > resovled > > > >> > without extending Switching Cap. > > > >> > > > > >> > It is known that there are two cases described in RFC5212 and > > > >> > RFC5339, one is MRN, another one is MLN. In RFC5212, it says: > > > >> > > > > >> > ======================================================================= > > > >> ======== > > > >> > > > > >> > > > > >> Thus, a control plane region, identified by its switching type value > > > >> (e.g., TDM), can be sub-divided into smaller-granularity component > > > >> networks based on "data plane switching layers". The Interface > > > >> Switching Capability Descriptor (ISCD) [RFC4202], identifying the > > > >> interface switching capability (ISC), the encoding type, and the > > > >> switching bandwidth granularity, enables the characterization of the > > > >> associated layers. > > > >> > > > > >> > In this document, we define a multi-layer network (MLN) to be a > > > >> > Traffic Engineering (TE) domain comprising multiple data plane > > > >> > switching layers either of the same ISC (e.g., TDM) or different > ISC > > > >> > (e.g., TDM and PSC) and controlled by a single GMPLS control > plane > > > >> > instance. We further define a particular case of MLNs. A multi- > > > >> > region network (MRN) is defined as a TE domain supporting at > least > > > >> > two different switching types (e.g., PSC and TDM), either hosted > on > > > >> > the same device or on different ones, and under the control of a > > > >> > single GMPLS control plane instance. > > > >> > > > > >> > ======================================================================= > > > >> ============== > > > >> > > > > >> > > > > >> Therefore, for MRN case, we can use Switching Cap to differentiate > the > > > >> different "layers"; for MLN case (same ISC with different > granularity), > > > >> we can use Switching Cap & Signal Type (& Encoding Type as well) to > > > >> differentiate the different granularity. > > > >> > > > > >> > So, come back to your question, it can be achived by using > Switching > > > >> > Cap&Encoding Type&Signal Type to identify the granularity > requested > > > >> > in OTN networks(e.g., this information can be carried in > > > >> > SERVER_LAYER_INFO sub-object) . > > > >> > > > > >> > Lastly, in my opinion, if there is no issue based on the existing > > > >> > mechnism or definition without extending Switching Cap, I don't > > > >> think > > > >> > we need to extend Switching Cap. > > > >> > > > > >> > > > > >> > Thanks > > > >> > > > > >> > Fatai > > > >> > > > > >> > > > > >> > > > > >> > ________________________________________ 发件人: Julien Meuric > > > >> > [julien.meuric@orange.com] 发送时间: 2011年12月7日 0:08 到: > Zhangfatai > > > >> Cc: > > > >> > CCAMP; pce@ietf.org 主题: Re: [CCAMP] R: OSPF OTN considerations > > > >> post > > > >> > IETF 82 (Issue 1/2) > > > >> > > > > >> > Hi Fatai. > > > >> > > > > >> > As co-author of draft-ietf-pce-inter-layer-ext, I believe you > will > > > >> > agree on the fact that having a Switching Capability per ODUk > layer > > > >> > would make the use of objects including a Switching Cap field > rather > > > >> > straightforward and enables a fine-grained resource description, > > > >> e.g. > > > >> > in: - REQ-ADAP-CAP object, to precisely identify the type of > > > >> > adaptation requested by a higher layer, or to get a clear > feedback > > > >> on > > > >> > the missing adaptation for unsuccessful path computations; - > > > >> > SERVER_LAYER_INFO sub-object, to precisely identify the type of > > > >> > server layer within the ERO. > > > >> > > > > >> > Do not you think that summarizing G.709 by a single Switching Cap > > > >> > value would take some capabilities away? What would you suggest > so > > > >> as > > > >> > to achieve the same level of details in that scenario? > > > >> > > > > >> > Regards, > > > >> > > > > >> > Julien > > > >> > > > > >> > > > > >> > Le 02/12/2011 09:51, Zhangfatai a écrit : > > > >> > > Hi all, > > > >> > > > > > >> > > I agree that there is no need to overload Switching Cap. > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > Thanks > > > >> > > > > > >> > > Fatai > > > >> > > > > > >> > > > > > >> > > -----Original Message----- From: ccamp-bounces@ietf.org > > > >> > > [mailto:ccamp-bounces@ietf.org] On Behalf Of BELOTTI, SERGIO > > > >> > > (SERGIO) > > > >> > > > > > >> > > John, as co-authors, we shared completely your thoughts. > > > >> > > > > > >> > > Thanks Sergio and Pietro > > > >> > > > > > >> > > SERGIO BELOTTI > > > >> > > > > > >> > > ALCATEL-LUCENT Terrestrial System Architect Optics Portfolio > > > >> > > Evolution > > > >> > > > > > >> > > via Trento 30 , Vimercate(MI) Italy T: +39 0396863033 > > > >> > > Sergio.Belotti@alcatel-lucent.com > > > >> > > > > > >> > > > > > >> > > > > > >> > > -----Messaggio originale----- Da: ccamp-bounces@ietf.org > > > >> > > [mailto:ccamp-bounces@ietf.org] Per conto di John E Drake > Inviato: > > > >> > > mercoledì 30 novembre 2011 22.37 A: Lou Berger Cc: CCAMP > Oggetto: > > > >> > > Re: [CCAMP] OSPF OTN considerations post IETF 82 (Issue 1/2) > > > >> > > > > > >> > > 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] Sent: Wednesday, November 30, 2011 > > > >> > >> 1:09 PM To: John E Drake Cc: Daniele Ceccarelli; CCAMP Subject: > > > >> > >> Re: [CCAMP] OSPF OTN considerations post IETF 82 (Issue 1/2) > > > >> > >> > > > >> > >> > > > >> > >> 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 > > > > > > ============================================================ > > The information contained in this message may be privileged > > and confidential and protected from disclosure. If the reader > > of this message is not the intended recipient, or an employee > > or agent responsible for delivering this message to the > > intended recipient, you are hereby notified that any reproduction, > > dissemination or distribution of this communication is strictly > > prohibited. If you have received this communication in error, > > please notify us immediately by replying to the message and > > deleting it from your computer. Thank you. Tellabs > > ============================================================ > > > > > > > > _______________________________________________ > > 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