Hi all,
I agree that there is no need to overload Switching Cap.
Thanks
Fatai
-----Original Message----- From: [email protected]
[mailto:[email protected]] 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
[email protected]
-----Messaggio originale----- Da: [email protected]
[mailto:[email protected]] 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:[email protected]] 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:[email protected]] 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: [email protected]
>>>>> [mailto:[email protected]] 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 [email protected]
>>>>>> 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
[email protected] https://www.ietf.org/mailman/listinfo/ccamp
