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

[Lou Berger <[e-mail]>]

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
> 
> 
> _______________________________________
> 发件人: [e-mail] [[e-mail]] 代表 Julien Meuric [[e-mail]]
> 发送时间: 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:[e-mail]]
>>>
>>> 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:[e-mail]] 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: [e-mail]
>>>>>>> [mailto:[e-mail]] 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 [phone] Mobile
>>>>>>>> [phone] [e-mail]
>>>>>>>> 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 [e-mail]
>>>>>>>> https://www.ietf.org/mailman/listinfo/ccamp
>>>>>>> _______________________________________________ CCAMP
>>>>>>> mailing list [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/ccamp
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>>
>>>>
>>  _______________________________________________ CCAMP mailing list
>>  [e-mail] https://www.ietf.org/mailman/listinfo/ccamp
>>
> 
> _______________________________________________
> CCAMP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ccamp