Re: [CCAMP] 答复: R: OSPF OTN considerations post IETF 82 (Issue 1/2)
Lou Berger <lberger@labn.net> Tue, 20 December 2011 16:28 UTC
Return-Path: <lberger@labn.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 3EE0521F8AAF for <ccamp@ietfa.amsl.com>; Tue, 20 Dec 2011 08:28:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -93.77
X-Spam-Level:
X-Spam-Status: No, score=-93.77 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_38=0.6, J_CHICKENPOX_46=0.6, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100]
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 iuzprmrWsFlk for <ccamp@ietfa.amsl.com>; Tue, 20 Dec 2011 08:28:16 -0800 (PST)
Received: from oproxy4-pub.bluehost.com (oproxy4-pub.bluehost.com [69.89.21.11]) by ietfa.amsl.com (Postfix) with SMTP id 1F9A421F8B53 for <ccamp@ietf.org>; Tue, 20 Dec 2011 08:28:16 -0800 (PST)
Received: (qmail 17378 invoked by uid 0); 20 Dec 2011 16:27:52 -0000
Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy1.bluehost.com with SMTP; 20 Dec 2011 16:27:52 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=3VYMjc99/JOOR2xIYE7Oee47mh2MtJDg6gZZ3CPE7CQ=; b=l6suJY+0rDKnAZ33/bDjW9cMmZgGOBfax7hKxSnTlmFx6uJLjXxT2VNkTR8GBzBWTpiLHNuu26MV89EpcKC23sjb4xMGY+dSwUDRP9CbvFDzHTroxVw4bC9FBxNMMCU+;
Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from <lberger@labn.net>) id 1Rd2Xg-0002lZ-9K; Tue, 20 Dec 2011 09:27:52 -0700
Message-ID: <4EF0B788.7020700@labn.net>
Date: Tue, 20 Dec 2011 11:27:52 -0500
From: Lou Berger <lberger@labn.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: "Sadler, Jonathan B." <Jonathan.Sadler@tellabs.com>
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>
In-Reply-To: <5292FFA96EC22A4386067E9DBCC0CD2B010A0998FB37@EX-NAP.tellabs-west.tellabsinc.net>
X-Enigmail-Version: 1.0.1
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: 8bit
X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net}
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:28:18 -0000
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