Re: [CCAMP] 答复: R: OSPF OTN considerations post IETF 82 (Issue 1/2)
John E Drake <jdrake@juniper.net> Tue, 20 December 2011 16:32 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 5CD4721F8A64 for <ccamp@ietfa.amsl.com>; Tue, 20 Dec 2011 08:32:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.798
X-Spam-Level:
X-Spam-Status: No, score=-2.798 tagged_above=-999 required=5 tests=[AWL=2.149, BAYES_00=-2.599, J_CHICKENPOX_38=0.6, J_CHICKENPOX_46=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152]
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 WI2LEMoSXRLp for <ccamp@ietfa.amsl.com>; Tue, 20 Dec 2011 08:32:40 -0800 (PST)
Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id 21BD321F89BA for <ccamp@ietf.org>; Tue, 20 Dec 2011 08:32:40 -0800 (PST)
Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKTvC4nKVDRVPWSCwZOVzzJDao/9jYk5JV@postini.com; Tue, 20 Dec 2011 08:32:40 PST
Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Tue, 20 Dec 2011 08:29:01 -0800
From: John E Drake <jdrake@juniper.net>
To: Igor Bryskin <IBryskin@advaoptical.com>, Julien Meuric <julien.meuric@orange.com>, Zhangfatai <zhangfatai@huawei.com>
Date: Tue, 20 Dec 2011 08:28:59 -0800
Thread-Topic: [CCAMP] 答复: R: OSPF OTN considerations post IETF 82 (Issue 1/2)
Thread-Index: AQHMvyd67JLgkoA2EEW5b2PJqqKe5JXlKYSA//+2KVCAAAp7IA==
Message-ID: <5E893DB832F57341992548CDBB333163A54B517BB9@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> <CDAC6F6F5401B245A2C68D0CF8AFDF0A08A8B74F@atl-srv-mail10.atl.advaoptical.com>
In-Reply-To: <CDAC6F6F5401B245A2C68D0CF8AFDF0A08A8B74F@atl-srv-mail10.atl.advaoptical.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
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:32:42 -0000
Igor, I think it is fair to say that you share the perspective of Lou and Julien. Thanks, John > -----Original Message----- > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > Sent: Tuesday, December 20, 2011 8:13 AM > To: John E Drake; Julien Meuric; Zhangfatai > Cc: CCAMP > Subject: RE: [CCAMP] 答复: R: OSPF OTN considerations post IETF 82 > (Issue 1/2) > > John, > > > 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. > > You may recall that originally the work was named simply Multi-Region. > It was me who suggested adding Multi-Layer part because of the very > reason that multiple layers may happen within the same technology. > There are certain differences between the cases when two adjacent > layers belong to the same or different technologies. For example, you > will signal connections using different set of signaling objects in the > latter case. However, from the TE routing/PCE perspective IMO it is > quite advantageous to keep these differences to the minimum, and treat > separate layers as separate layers irrespectively whether they belong > to the same or different regions. ODUk is a shining example IMO of the > case where multiple layers co-exist within the same region. From the > server-client relationship point of view two layers are separate when a > connection in one layer could be used as a link in the other. > > Cheers, > Igor > > 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
- [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