Re: [CCAMP] 答复: OSPF OTN considerations post IETF 82 (Issue 1/2)

Lou Berger <lberger@labn.net> Thu, 08 December 2011 15:16 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 BE13321F8557 for <ccamp@ietfa.amsl.com>; Thu, 8 Dec 2011 07:16:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -97.945
X-Spam-Level:
X-Spam-Status: No, score=-97.945 tagged_above=-999 required=5 tests=[AWL=-2.975, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, IP_NOT_FRIENDLY=0.334, 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 Ir62t7L6YR7G for <ccamp@ietfa.amsl.com>; Thu, 8 Dec 2011 07:16:11 -0800 (PST)
Received: from oproxy7-pub.bluehost.com (oproxy7-pub.bluehost.com [67.222.55.9]) by ietfa.amsl.com (Postfix) with SMTP id 3929C21F8514 for <ccamp@ietf.org>; Thu, 8 Dec 2011 07:16:11 -0800 (PST)
Received: (qmail 4068 invoked by uid 0); 8 Dec 2011 15:15:46 -0000
Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy7.bluehost.com with SMTP; 8 Dec 2011 15:15:46 -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=SupqoCJcDt9a8PkNNYzk5ClqnmIdgkl3LnMab2tdhaA=; b=wlz9TZ8GftpZbuJkvBs7PltHAzxmw9SoBHjpBgAYcyggIV6xc0Yygwvprsvd2L+MzulHmJiZEX7Fha04rpK7F9ozV4JQO89mKLNMUVW0L+2P7wd4ug22lzlEse88lTcy;
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 1RYfhK-0006J8-0R; Thu, 08 Dec 2011 08:15:46 -0700
Message-ID: <4EE0D4A2.7010209@labn.net>
Date: Thu, 08 Dec 2011 10:15:46 -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: John E Drake <jdrake@juniper.net>
References: <B5630A95D803744A81C51AD4040A6DAA2293E672A9@ESESSCMS0360.eemea.ericsson.se> <4ED64A32.8060707@labn.net> <5E893DB832F57341992548CDBB333163A4B54CA99D@EMBX01-HQ.jnpr.net> <4ED65D2D.2040400@labn.net> <5E893DB832F57341992548CDBB333163A4B54CADAB@EMBX01-HQ.jnpr.net> <4ED69B7D.409@labn.net> <5E893DB832F57341992548CDBB333163A4B54CAEE5@EMBX01-HQ.jnpr.net> <4EDE354F.20803@orange.com> <F82A4B6D50F9464B8EBA55651F541CF825CC18C0@SZXEML520-MBS.china.huawei.com> <4EDE7B04.5000804@labn.net> <5E893DB832F57341992548CDBB333163A4B682A99E@EMBX01-HQ.jnpr.net>
In-Reply-To: <5E893DB832F57341992548CDBB333163A4B682A99E@EMBX01-HQ.jnpr.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] 答复: 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: Thu, 08 Dec 2011 15:16:12 -0000

John,
	As I'm sure you are aware, hierarchy within the same technology layer
has been around for a while.  When we defined GMPLS, there was a desire
to represent level of hierarchy within a switching technology.  (This
requirement came in the context of PSC).  At the time we choose to
represent both switching switching technology and level of hierarchy
(within the technology) in the SC field.

On one hand one can argue (as was our thinking at the time) that there
was only a need to represent a few per-technology hierarchies and that
it simplified GMPLS routing to operate on a minimum number of generic
fields.   On the other hand, one could argue that the SC field should
not be overloaded and there should be a separate per-technology
hierarchy indicator field.  Hindsight leaves me feeling that the latter
choice may have been the better one.  I don't recall exactly how we came
to this conclusion, but there were lots or related discussions among the
authors/editors (which includes you too!).  My bet is that it came from
Yakov, myself or Peter... Perhaps your memory is better than mine, but
either way please feel free to blame me ;-)

No matter what, you now raise a good question.  Where do we go from here?
a. Keep SC as it is, with it's overloaded semantics as both a
   common (across technologies) label/ISCD type indicator and
   intra-type hierarchy indicator.
b. Deprecate use of SC as an intra-type hierarchy indicator, and
   add such indication to technology-specific ISCDs.
c. Something else.

I (and I believe Julien) are proposing (a), I believe you and the OTN
co-authors are proposing/implying (b).

Lou

On 12/7/2011 8:21 AM, John E Drake wrote:
> Hi,
> 
> I am unaware of any requirement to indicate layers in a multi-layer
> scenario - I went back and looked at both RFC5339 and RFC6001 and
> didn't see anything.  And just to be clear, layers are technology
> specific.
> 
> Since you mention RFC6001, I think it should be pointed out that that
> RFC does not address multi-layer networking, but only multi-region
> networking.
> 
> Thanks,
> 
> John
> 
>> -----Original Message-----
>> From: Lou Berger [mailto:lberger@labn.net]
>> Sent: Tuesday, December 06, 2011 12:29 PM
>> To: Zhangfatai
>> Cc: Julien Meuric; John E Drake; CCAMP
>> Subject: Re: 答复: [CCAMP] OSPF OTN considerations post IETF 82 (Issue
>> 1/2)
>>
>>
>> I think Julien has it right (and as I've said on this list), it's a
>> question of leveraging or deprecating the use of SC as an indicator of
>> hierarchy.  Deprecating this use means that we need to move into a
>> technology specific hierarchy indicator, which is what you're saying ST
>> provides.
>>
>> The move from generic to technology-specific mechanisms, really runs
>> counter to the basic principals of GMPLS and is likely to have some
>> nasty ripple effects.  (For example do we just obsolete 6001, or do a
>> bis which allows for / requires carrying the technology-specific layer
>> identifier?)
>>
>> Lou
>>
>> On 12/6/2011 2:34 PM, Zhangfatai wrote:
>>> Hi Julien,
>>>
>>> For TDM networks, Signal Type has beed introduced in RFC4606 or
>> RFC4328 or G.709V3 drafts to address what you need.
>>>
>>> Anything is missed in routing or signaling?
>>>
>>>
>>> Thanks
>>>
>>> Fatai
>>>
>>>
>>> _______________________________________
>>> 发件人: ccamp-bounces@ietf.org [ccamp-bounces@ietf.org] 代表 Julien
>> Meuric [julien.meuric@orange.com]
>>> 发送时间: 2011年12月6日 23:31
>>> 到: John E Drake; Lou Berger
>>> Cc: CCAMP
>>> 主题: Re: [CCAMP] OSPF OTN considerations post IETF 82 (Issue 1/2)
>>>
>>> Hi John, hi Lou.
>>>
>>> On the one hand, SONET/SDH and OTN are close: it is highly tempting
>> to
>>> prolong control of the former to the latter. Nevertheless, the GMPLS
>>> deployments on SONET/SDH I am aware of only control high order
>>> containers (i.e. SDH VC-4/VC-4-nc or SONET STS-1/STS-1-nc). In that
>>> context, I do not think we can easily generalized protocol extensions
>>> from an almost single-stage control to a highly multi-stage control.
>>>
>>> On the other hand, it seems that PSC-1 to PSC-4 have not been
>>> implemented much. Reasons behind are only guesses. Mine is that
>>> upgrading implementations and deployments of MPLS-TE was not worth
>> the
>>> pain with respect to the added value of moving to the GMPLS flavor of
>>> IGPs and RSVP-TE (especially for packet-only operations). Whatever
>> the
>>> actual reason for having so few implementations, PSC-n are part of
>> the
>>> original GMPLS specification.
>>>
>>> Let me quote the section about PSC in RFC 4202: "The various levels
>> of
>>> PSC establish a hierarchy of LSPs tunneled within LSPs." This really
>>> looks like what we are doing in OTN. Yes, the discrete nature of the
>>> technology will introduce one more information into the SC field, but
>>> doing otherwise would depreciate existing GMPLS specification.
>>>
>>> Furthermore, RFC 4203 says: "When the Switching Capability field is
>> TDM,
>>> the Switching Capability specific information field includes Minimum
>> LSP
>>> Bandwidth..." In other words, even if not included in the SC field so
>>> far, one cannot really say that a value per ODUk layer would overload
>>> the ISCD definition.
>>>
>>> Thus, we have legacy vs. depreciation: my understanding of IETF work
>> is
>>> to put emphasis on consistency and avoid defining new solutions when
>>> they already exist, even if not absolutely optimized (we are not
>>> building G.709 control from scratch).
>>>
>>> My 2 cents,
>>>
>>> Julien
>>>
>>>
>>> Le 30/11/2011 22:37, John E Drake a écrit :
>>>>  Comments inline. I still think this is a terrible idea and I would
>>>>  like to see what the rest of the WG thinks.
>>>>
>>>>> -----Original Message----- From: Lou Berger
>>>>> [mailto:lberger@labn.net]
>>>>>
>>>>> John,
>>>>>
>>>>> see below
>>>>>
>>>>>
>>>>> On 11/30/2011 2:59 PM, John E Drake wrote:
>>>>>> Using Switching Capability to indicate link bandwidth seems
>>>>>> ill-considered at best, especially since this information is
>>>>>> carried in other fields, and as Daniele noted, it significantly
>>>>>> overloads to intended meaning of Switching Capability.
>>>>>
>>>>> I agree with the point on BW, but my point was related to the
>>>>> layer&hierarchy implications of the different ODUk values. I'd
>>>>> think that using values that are TDM-1 -> TDM-n should make this
>>>>> clear and remove any ambiguity related to bandwidth. It is also
>>>>> completely consistent with the base GMPLS definition, i.e., PSC-1
>>>>> -> PSC-n.
>>>>
>>>>  [JD] You are simply asserting that this is a good idea and further
>>>>  asserting that there is "ambiguity related to bandwidth', without
>>>>  providing any evidence.
>>>>
>>>>  To the best of my knowledge no one ever implemented or deployed the
>>>>  PSC-1 -> PSC-4 hierarchy, simply because no one could figure out
>> what
>>>>  it meant. To quote from you, below, "Well hopefully we have a
>> better
>>>>  understanding of the technologies involved than we had in the
>> past.".
>>>>  I.e., we should all understand that PSC-1 -> PSC-4 was a bad idea
>>>>  (tm) and move on.
>>>>
>>>>>
>>>>>> It also is inconsistent with the usage of Switching Capability in
>>>>>> SDH/SONET.
>>>>>
>>>>> Well hopefully we have a better understanding of the technologies
>>>>> involved than we had in the past.
>>>>
>>>>  [JD] I think we had a very good understanding of SDH/SONET then and
>>>>  we have a very good understanding of OTN now, and in both cases the
>>>>  authors saw no requirement to overload switching capability in the
>>>>  manner you are suggesting.
>>>>
>>>>>
>>>>>>
>>>>>> A more extensive quote from RFC4202 is the following, which
>>>>>> seems clear enough to me:
>>>>>>
>>>>>> "In the context of this document we say that a link is connected
>>>>>> to a node by an interface. In the context of GMPLS interfaces
>>>>>> may have different switching capabilities. For example an
>>>>>> interface that connects a given link to a node may not be able to
>>>>>> switch individual packets, but it may be able to switch channels
>>>>>> within an SDH payload. Interfaces at each end of a link need not
>>>>>> have the same switching capabilities. Interfaces on the same
>>>>>> node need not have the same switching capabilities."
>>>>>
>>>>> Not sure how this helps clarify anything...
>>>>
>>>>  [JD] I think it clarifies that switching capabilities is meant to
>>>>  describe how a given interface switches the information with which
>> it
>>>>  is provided. This has nothing to do with the interface's bandwidth.
>>>>
>>>>>
>>>>> Lou
>>>>>>
>>>>>>> -----Original Message----- From: Lou Berger
>>>>>>> [mailto:lberger@labn.net] Sent: Wednesday, November 30, 2011
>>>>>>> 8:43 AM To: John E Drake Cc: Daniele Ceccarelli; CCAMP Subject:
>>>>>>> Re: [CCAMP] OSPF OTN considerations post IETF 82 (Issue
>>>>> 1/2)
>>>>>>>
>>>>>>> Great. Care to substantiate your point?
>>>>>>>
>>>>>>> On 11/30/2011 11:14 AM, John E Drake wrote:
>>>>>>>> I completely disagree.
>>>>>>>>
>>>>>>>>> -----Original Message----- From: ccamp-bounces@ietf.org
>>>>>>>>> [mailto:ccamp-bounces@ietf.org] On
>>>>>>> Behalf
>>>>>>>>> Of Lou Berger Sent: Wednesday, November 30, 2011 7:22 AM
>>>>>>>>> To: Daniele Ceccarelli Cc: CCAMP Subject: Re: [CCAMP] OSPF
>>>>>>>>> OTN considerations post IETF 82 (Issue
>>>>>>> 1/2)
>>>>>>>>>
>>>>>>>>> Hi Daniele, Since I raised the point, I guess I need to
>>>>>>>>> champion it! (With chair hat off.)
>>>>>>>>>
>>>>>>>>> All,
>>>>>>>>>
>>>>>>>>> Daniele said:
>>>>>>>>>> WRT issue 1: the proposal was to indicate the bottom most
>>>>>>>>>> ODUk of
>>>>>>> the
>>>>>>>>>> muxing hiearachy in the Switching Capability field of the
>>>>>>>>>> ISCD.
>>>>>>> After
>>>>>>>>>> a quick talk with the other authors of the ID, the idea
>>>>>>>>>> was to
>>>>>>> reject
>>>>>>>>>> the proposal as it would lead to an overloading of the
>>>>>>>>>> meaning of
>>>>>>> the
>>>>>>>>>> Switching Capability field. (even if the definition of
>>>>>>>>>> PSC1-2-3-4 already overloads the meaning of the switching
>>>>>>>>>> capability field)
>>>>>>>>>
>>>>>>>>> This really goes to the interpretation of the intent of
>>>>>>>>> Switching Capability Types. So we have a few definitions:
>>>>>>>>> 3471 says "the
>>>>> type
>>>>>>> of
>>>>>>>>> switching that should be performed", 4202 says "describes
>>>>> switching
>>>>>>>>> capability of an interface." 3945 doesn't really define the
>>>>>>>>> term
>>>>> (it
>>>>>>>>> just references 4202), but does equate it with a "layer".
>>>>>>>>> While it allows for hierarchy within a "layer" it also says
>>>>>>>>> hierarchy
>>>>> occurs
>>>>>>>>> "between interface types".
>>>>>>>>>
>>>>>>>>> So I interpret Switching Capability Types to represent (a)
>>>>> different
>>>>>>>>> switching/technology layers and (b) different levels of
>>>>>>>>> hierarchy
>>>>> --
>>>>>>>>> even within a layer. I think (a) is identifiable in the
>>>>> definition
>>>>>>> of
>>>>>>>>> the original GMPLS supported technologies (i.e., PSC, L2SC,
>>>>>>>>> TDM
>>>>> LSC,
>>>>>>>>> and FSC), and (b) is identifiable in the original types
>>>>>>>>> plus the
>>>>>>> definition
>>>>>>>>> of PSC-1 through PSC-4.
>>>>>>>>>
>>>>>>>>> So how does this apply to our current OTN work?
>>>>>>>>>
>>>>>>>>> To me, the first question to ask relates to (a), and is
>>>>>>>>> should
>>>>> each
>>>>>>>>> ODUk be modeled as a separate layer?
>>>>>>>>>
>>>>>>>>> I know this has been a much debated point, and it seems to
>>>>>>>>> me that
>>>>>>> they
>>>>>>>>> are, but more for the perspective of switching layers than
>>>>>>> technology
>>>>>>>>> layers (i.e., they are clearly the same technology but are
>>>>> different
>>>>>>>>> granularity of swicthing.) So this is a yes for me.
>>>>>>>>>
>>>>>>>>> I think the second question to ask relates to (b), and is
>>>>>>>>> does
>>>>> each
>>>>>>>>> ODUk represent a different level of hierarchy?
>>>>>>>>>
>>>>>>>>> I see this as simply yes, and no different than what has
>>>>>>>>> been done
>>>>>>> more
>>>>>>>>> recently with Ethernet or, even if we do continue to model
>>>>>>>>> OTN as
>>>>> a
>>>>>>>>> single layer, no different than PSC-1 -> PSC-4.
>>>>>>>>>
>>>>>>>>> There's also a minor processing efficiency gained by this
>>>>>>>>> approach
>>>>>>> for
>>>>>>>>> nodes that support a smaller set of ODUks than are
>>>>>>>>> advertised
>>>>> within
>>>>>>> an
>>>>>>>>> IGP.
>>>>>>>>>
>>>>>>>>> Based on all this, I believe different ODUk's should use
>>>>>>>>> different Switching Types. In particular, I'm proposing:
>>>>>>>>> (1) that either the framework or info documents identify
>>>>>>>>> that a per-OTUk Switching Capability Types will be used to
>>>>>>>>> support G.709v3. (2) that
>>>>>>>>> draft-ietf-ccamp-gmpls-ospf-g709v3 define a different
>>>>>>>>> Switching Cap field value for each ODUk, and that it state
>>>>>>>>> that the value corresponding to the signal type identified
>>>>>>>>> in the #stages=0 of the ISCP be set. (Without any other
>>>>>>>>> changes to the current definition of ISCD.) (3) that
>>>>>>>>> draft-ietf-ccamp-gmpls-signaling-g709v3 be updated to match
>>>>>>>>> above.
>>>>>>>>>
>>>>>>>>> To keep thinks generic, we probably should use TDM-1
>>>>>>>>> through TDM-n
>>>>>>> as
>>>>>>>>> the new Switching Capability Types, but this is a
>>>>>>>>> secondary
>>>>>>> discussion.
>>>>>>>>>
>>>>>>>>> Comments?
>>>>>>>>>
>>>>>>>>> Lou
>>>>>>>>>
>>>>>>>>> PS While the above is an important change, it doesn't
>>>>> significantly
>>>>>>>>> impact encoding and won't take much text to make the
>>>>>>>>> actual
>>>>> change,
>>>>>>> so
>>>>>>>>> this is a discussion that can continue until Paris if we
>>>>>>>>> really
>>>>> need
>>>>>>> a
>>>>>>>>> face to face to resolve the discussion.
>>>>>>>>>
>>>>>>>>> On 11/23/2011 1:18 PM, Daniele Ceccarelli wrote:
>>>>>>>>>> Hi CCAMP,
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> During the OTN OSPF draft presentation at the IETF
>>>>>>>>>> meeting in
>>>>>>> Taipei
>>>>>>>>> two
>>>>>>>>>> comments were raised with respect to the following
>>>>>>>>>> issues:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> - Issue 1: Using different switching caps for each ODU
>>>>>>>>>> type
>>>>>>>>>>
>>>>>>>>>> - Issue 2: Type 2 (unres bandwidth for variable
>>>>>>>>>> containers) and
>>>>>>> Type
>>>>>>>>> 3
>>>>>>>>>> (MAX LSP bandwidth foe variable containers always used in
>>>>>>>>>> tandem?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> WRT issue 1: the proposal was to indicate the bottom most
>>>>>>>>>> ODUk of
>>>>>>> the
>>>>>>>>>> muxing hiearachy in the Switching Capability field of the
>>>>>>>>>> ISCD.
>>>>>>> After
>>>>>>>>> a
>>>>>>>>>> quick talk with the other authors of the ID, the idea was
>>>>>>>>>> to
>>>>> reject
>>>>>>>>> the
>>>>>>>>>> proposal as it would lead to an overloading of the
>>>>>>>>>> meaning of the Switching Capability field. (even if the
>>>>>>>>>> definition of PSC1-2-3-4 already overloads the meaning of
>>>>>>>>>> the switching capability field)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> WRT issue 2: it is analyzed in section 5.3 of the draft
>>>>>>>>>> (version
>>>>> -
>>>>>>>>> 00).
>>>>>>>>>> I'm copying it below for your convenience
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> In this example the advertisement of an ODUflex->ODU3
>>>>> hierarchy
>>>>>>> is
>>>>>>>>>>
>>>>>>>>>> shown. In case of ODUflex advertisement the MAX LSP
>>>>>>>>>> bandwidth
>>>>>>>>> needs
>>>>>>>>>>
>>>>>>>>>> to be advertised but in some cases also information about
>>>>>>>>>> the
>>>>>>>>>>
>>>>>>>>>> Unreserved bandwidth could be useful. The amount of
>>>>> Unreserved
>>>>>>>>>>
>>>>>>>>>> bandwidth does not give a clear indication of how many
>>>>>>>>>> ODUflex
>>>>>>> LSP
>>>>>>>>>>
>>>>>>>>>> can be set up either at the MAX LSP Bandwidth or at
>>>>>>>>>> different
>>>>>>>>> rates,
>>>>>>>>>>
>>>>>>>>>> as it gives no information about the spatial allocation
>>>>>>>>>> of the
>>>>>>>>> free
>>>>>>>>>>
>>>>>>>>>> TSs.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> An indication of the amount of Unreserved bandwidth could
>>>>>>>>>> be
>>>>>>>>> useful
>>>>>>>>>>
>>>>>>>>>> during the path computation process, as shown in the
>>>>>>>>>> following
>>>>>>>>>>
>>>>>>>>>> example. Supposing there are two TE-links (A and B) with
>>>>>>>>>> MAX
>>>>>>> LSP
>>>>>>>>>>
>>>>>>>>>> Bandwidth equal to 10 Gbps each. In case 50Gbps of
>>>>>>>>>> Unreserved
>>>>>>>>>>
>>>>>>>>>> Bandwidth are available on Link A, 10Gbps on Link B and
>>>>>>>>>> 3
>>>>>>> ODUflex
>>>>>>>>>>
>>>>>>>>>> LSPs of 10 GBps each, have to be restored, for sure only
>>>>>>>>>> one
>>>>> can
>>>>>>>>> be
>>>>>>>>>>
>>>>>>>>>> restored along Link B and it is probable (but not sure)
>>>>>>>>>> that
>>>>> two
>>>>>>>>> of
>>>>>>>>>>
>>>>>>>>>> them can be restored along Link A.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Early proposal was to have, in the case of variable
>>>>>>>>>> containers advertisements (i.e. ODUflex), the MAX LSP
>>>>>>>>>> bandwidth TLV (Type 3)
>>>>>>> as
>>>>>>>>> a
>>>>>>>>>> mandatory piece of information and the Unreserved
>>>>>>>>>> bandiwdth TLV
>>>>>>> (Type
>>>>>>>>> 2)
>>>>>>>>>> as an optional piece of information.
>>>>>>>>>>
>>>>>>>>>> The comment received is that optional information can
>>>>>>>>>> lead to interworking issues and the counter proposal was
>>>>>>>>>> to have both
>>>>>>> pieces
>>>>>>>>> of
>>>>>>>>>> information as mandatory and, as a consequence, merge the
>>>>>>>>>> two
>>>>> TLVs
>>>>>>>>> into
>>>>>>>>>> a single one.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> We'd like to hear the opinion of the WG on both issues
>>>>>>>>>> before
>>>>>>>>> proceeding
>>>>>>>>>> with any modification to the document.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>>
>>>>>>>>>> Daniele
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> *DANIELE CECCARELLI * *System & Technology - DU IP &
>>>>>>>>>> Broadband*
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Via L.Calda, 5 Genova, Italy Phone +390106002512 Mobile
>>>>>>>>>> +393346725750 daniele.ceccarelli@ericsson.com
>>>>>>>>>> www.ericsson.com
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> <http://www.ericsson.com/>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> This Communication is Confidential. We only send and
>>>>>>>>>> receive
>>>>> email
>>>>>>> on
>>>>>>>>>> the basis of the term set out at
>>>>> www.ericsson.com/email_disclaimer
>>>>>>>>>> <http://www.ericsson.com/email_disclaimer>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________ CCAMP
>>>>>>>>>> mailing list CCAMP@ietf.org
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/ccamp
>>>>>>>>> _______________________________________________ CCAMP
>>>>>>>>> mailing list CCAMP@ietf.org
>>>>>>>>> https://www.ietf.org/mailman/listinfo/ccamp
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>  _______________________________________________ CCAMP mailing list
>>>>  CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp
>>>>
>>>
>>> _______________________________________________
>>> CCAMP mailing list
>>> CCAMP@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ccamp