Re: [CCAMP] Fwd: I-D Action: draft-berger-ccamp-swcaps-update-00.txt

[Daniele Ceccarelli <[e-mail]>]

Lou,

Comments to your previous replies in line and a further consideration here:

What i'm really interested in is not loosing the pieces of information that have been added to the OTN SCSI (muxing hierarchies and relationship between the various layers) and the introduction of the ILH as currently defined does not affect it, so i'm not against it. 
Nevertheless i find no reason to be in favour of it because, as John does, can't really see any advantage it introduces or any problem it solves. Could you please explain what is the rationale behind introducing it? 

Thanks,
Daniele

>-----Original Message-----
>From: Lou Berger [mailto:[e-mail]] 
>Sent: lunedì 27 febbraio 2012 18.02
>To: Daniele Ceccarelli
>Cc: CCAMP
>Subject: Re: [CCAMP] Fwd: I-D Action: 
>draft-berger-ccamp-swcaps-update-00.txt
>
>Daniele,
>	See below.
>
>
>On 2/27/2012 11:39 AM, Daniele Ceccarelli wrote:
>>  Hi Lou,
>> 
>> My replies in line.
>> 
>> Thanks,
>> Daniele
>> 
>>> -----Original Message-----
>>> From: Lou Berger [mailto:[e-mail]]
>>> Sent: lunedì 27 febbraio 2012 17.08
>>> To: Daniele Ceccarelli
>>> Cc: CCAMP
>>> Subject: Re: [CCAMP] Fwd: I-D Action: 
>>> draft-berger-ccamp-swcaps-update-00.txt
>>>
>>> Daniele,
>>> 	Thanks for the comments.  Please see responses below.
>>>
>>> On 2/27/2012 9:51 AM, Daniele Ceccarelli wrote:
>>>> Hi Lou, Julien,
>>>>
>>>> I had a look at the ID. It is a good work and definitely something 
>>>> we
>>> needed to put some order in past so to have solid bases for 
>the future.
>>>>
>>>> Please find some notes/comments/questions below:
>>>>
>>>> 1. PSC deprecation - agree
>>>>
>>>> 2. Revised Switiching Type definition - agree with a question
>>>> - "A different Switching Type SHOULD be used for each data plane 
>>>> technology even when those technologies share the same type of 
>>>> multiplexing or switching." Does this mean that e.g. SDH and OTN, 
>>>> despite sharing same type of switching SHOULD use different
>>> Switching
>>>> type?
>>>
>>> For *future* technology definitions, yes, as they may use different 
>>> SCSIs.
>> 
>> OK, it was just a confirmation. So OTN is a future technology :-)
>
>Future, as in what the working group works on *after* the new 
>approach in the draft is accepted by the working group....

OK, what i mean is that, given that SDH uses SC=100 and OTN uses SC=101, the OTN draft is already compliant to what is stated here.

>
>> 
>>>
>>>> What is not clear to me is "same type of multiplexing" could you 
>>>> please clarify?
>>>>
>>>
>>> The text currently provides the following example:
>>>  For example, Time Division Multiplexing (TDM) technologies that  
>>> have different multiplexing structures should use two different  
>>> Switching Types.
>>>
>>> Is this not sufficiently clear?  Can you suggest some 
>clarifying text 
>>> as I'm not sure what else to say?
>> 
>> What was not clear to me was whether you were referring to:
>> 1. different muxing technology between SDH and OTN 2. 
>different muxing 
>> technology within SDH or within OTN.
>> In case 2. different OTN muxing hierarchies (e.g. ODU1->ODU2 
>and ODU1->ODU3)should have a different Switching Type for each 
>muxing hierarchy.
>> I assume you were refering to case 1. and suggest the following text:
>
>So I interpret this as not liking the phrase "multiplexing structures".
> I took this term from ITU-T documents.  For example, take a 
>look at Page 8 of G.707 pr page 16 of G.709, both show 
>"Multiplexing structure", which are clearly not shared.  I 
>think it's beneficial to reuse the terminology used in the 
>definitions of the data plane, rather than try to come up with 
>something new.

It might be misleading for me, but once that it is clear that different ultiplexing structure means intertechnology structures and not intratechnology ones i agree on keeping alignment with ITU-T docs.

>
>> 
>> OLD:
>>    For example, Time Division Multiplexing (TDM) technologies that
>>    have different multiplexing structures should use two different
>>    Switching Types.
>> NEW:
>>    For example, different Time Division Multiplexing (TDM) 
>technologies
>>    should use different Switching Types.
>
>How about:
>   For example, Time Division Multiplexing (TDM) technologies that
>   have different multiplexing structures, such as SDH [G.707] and
>   OTN [G.709], should use two different Switching Types.

OK

>> 
>>>
>>>> 3. "Additionally, a different Switching Type MUST be used to
>>> indicate
>>>> different Switching Capability specific information field formats."
>>>>
>>>> - This is potentially non future proof. If we have one to
>>> one mapping
>>>> between the Switching Type and the SCSI the SCSI design MUST
>>> be future
>>>> proof, otherwise we fall back in the issue of the Min LSP 
>bandwidth 
>>>> SCSI linked to Switch Cap TDM. Maybe avoiding this 1:1 mapping but 
>>>> allowing a 1:N would prevent this problem to happening.
>>>
>>> I think you may be misinterpreting our intent.  Does the following 
>>> rephrasing cover your concern:
>>>
>>> OLD:
>>>    Additionally, a different Switching Type MUST be used to
>>>    indicate different Switching Capability specific information
>>>    field formats.
>>> NEW:
>>>    As the format of the Switching Capability specific information
>>>    field is dependent on the value of this field, a different
>>>    Switching Type value MUST be used to differentiate between 
>>> different
>>>    Switching Capability specific information field formats.
>> 
>> Perfect
>> 
>>>
>>> This doesn't mean that two technologies (and two Switching Type 
>>> value) can't share the same SCSI format.  Just that when there are 
>>> two SCSI formats, two different Switching Types must be used.  This 
>>> is already an implicit requirement in [RFC4203] and [RFC5307].
>>>
>>>>
>>>> 4. It is not clear to me how the ILH field is used. From my 
>>>> understanding there is a mapping as follows (i'm 
>considering the OTN 
>>>> as example) ODU0 --> Switch Type=OTN; ILH=1
>>>> ODU1 --> Switch Type=OTN; ILH=2
>>>> ODU2 --> Switch Type=OTN; ILH=3
>>>> ...
>>>> This would imply advertising 1 ISCD for each "signal type" 
>instead of
>>> 1 ISCD for each "muxing hierarchy" as it is now stated in 
>>> draft-ospf-g709v3. Is my understanding correct?
>>>>
>>>
>>> Given that maturity level of this (our) draft, I would not 
>>> recommend any changes to gmpls-ospf-g709v3 at this time.
>>>
>>> That said, if you want to use gmpls-ospf-g709v3 as an example, 
>>> ILH would be set to match the Signal Type of the #stages=0 TLV 
>>> carried in the ISCD/SCSI.  As I read the gmpls-ospf-g709v3, 
>>> gmpls-ospf-g709v3 already precludes the advertisement of 
>>> different Signal Type at the #stages=0 in the same ISCD, so 
>>> there would be no change in number of advertised ISCDs due to 
>>> the use of ILH field in this example.
>> 
>> Again a misunderstanding from my side, but i think it is 
>worth spending few more words to identify the meaning of the ILH.
>> 
>> A suggestion:
>> 
>> OLD:
>>    In order to support hierarchical switching within a 
>particular data
>>    plane technology in routing, this section defines a Intra-Layer
>>    Hierarchy, or ILH, field.  This field allows for 
>representation of up
>>    to 15 layers of hierarchical switching.  The ILH field is 
>carried in
>>    a portion of the previously defined reserved field of the 
>Interface
>>    Switching Capability Descriptor and has the following format:
>> 
>> NEW:
>>    In order to support hierarchical switching within a 
>particular data
>>    plane technology in routing, this section defines a Intra-Layer
>>    Hierarchy, or ILH, field.  This field allows for 
>representation of up
>>    to 15 layers of hierarchical switching.  The ILH field 
>represent the 
>>    bottom most layer of the multiplexing hierarchy and is carried in
>>    a portion of the previously defined reserved field of the 
>Interface
>>    Switching Capability Descriptor and has the following format:
>> 
>
>How about:
>  ... This field allows for
>  representation of up to 15 layers of hierarchical switching.  It,
>  for example, can represent the bottom most layer of a
>  multiplexing hierarchy.  The ILH field is carried...

Ok, but the comment on its usefulness still needs to be addressed.

>Thanks again,
>Lou
>
>>>
>>> Lou
>>>
>>>> Thanks,
>>>> Daniele
>>>>
>>>>> -----Original Message-----
>>>>> From: [e-mail] [mailto:[e-mail]] On 
>>>>> Behalf Of Lou Berger
>>>>> Sent: martedì 21 febbraio 2012 15.32
>>>>> To: CCAMP
>>>>> Subject: [CCAMP] Fwd: I-D Action:
>>>>> draft-berger-ccamp-swcaps-update-00.txt
>>>>>
>>>>> All,
>>>>> 	This draft was motivated by the OTN discussion in 
>>> December.  The 
>>>>> general issue raised by that discussion was how should we 
>(the WG) 
>>>>> assign Switching types going forward.  At the time, my 
>proposal was 
>>>>> that we should follow general precedent, i.e., per 
>hierarchy level 
>>>>> assignment ala PSC-N. The problem with this, as John and 
>the others 
>>>>> pointed out, is that there is also precedent for per 
>>> technology type 
>>>>> assignment.
>>>>> The discussion left off with my commitment to submit a 
>draft on the 
>>>>> general topic, which is the draft mentioned below.
>>>>>
>>>>> The intent of this draft is to clearly establish which 
>>> precedent will 
>>>>> be followed in the future.  Our proposal is that we follow per 
>>>>> technology type assignment, i.e., a Switching type value whenever 
>>>>> there may be a different SCSI, and remove any relationship to 
>>>>> hierarchy from this field.  We also propose to deprecate 
>>> PSC-2,3 & 4.  
>>>>> For compatibility sake, we do not propose changing any 
>>> other existing 
>>>>> Switching type values.
>>>>>
>>>>> Obviously, comments are welcome and desired.
>>>>>
>>>>> Lou (as co-author)
>>>>>
>>>>> -------- Original Message --------
>>>>> Subject: I-D Action: draft-berger-ccamp-swcaps-update-00.txt
>>>>> Date: Tue, 21 Feb 2012 06:23:55 -0800
>>>>> From: [e-mail]
>>>>> Reply-To: [e-mail]
>>>>> To: [e-mail]
>>>>>
>>>>>
>>>>> A New Internet-Draft is available from the on-line 
>Internet-Drafts 
>>>>> directories.
>>>>>
>>>>> 	Title           : Revised Definition of The GMPLS
>>>>> Switching Capability
>>>>> and Type Fields
>>>>> 	Author(s)       : Lou Berger
>>>>>                          Julien Meuric
>>>>> 	Filename        : draft-berger-ccamp-swcaps-update-00.txt
>>>>> 	Pages           : 9
>>>>> 	Date            : 2012-02-21
>>>>>
>>>>>   GMPLS provides control for multiple switching technologies, and
>>>>>   hierarchical switching within a technology.  GMPLS routing and
>>>>>   signaling use common values to indicate switching 
>technology type.
>>>>>   These values are carried in routing in the Switching Capability
>>>>>   field, and in signaling in the Switching Type field. While the
>>>>>   values using in these fields are the primary indicators of the
>>>>>   technology and hierarchy level being controlled, the values are
>>>>>   not consistently defined and used across the different
>>>>>   technologies supported by GMPLS.  This document is intended to
>>>>>   resolve the inconsistent definition and use of the Switching
>>>>>   Capability and Type fields by narrowly scoping the 
>meaning and use
>>>>>   of the fields.  This document updates any document that uses the
>>>>>   GMPLS Switching Capability and Types fields, in particular RFC
>>>>>   3471, RFC 4202, RFC 4203, and RFC 5307.
>>>>>
>>>>>
>>>>> A URL for this Internet-Draft is:
>>>>> http://www.ietf.org/internet-drafts/draft-berger-ccamp-swcaps-u
>>>>> pdate-00.txt
>>>>>
>>>>> Internet-Drafts are also available by anonymous FTP at:
>>>>> ftp://ftp.ietf.org/internet-drafts/
>>>>>
>>>>> This Internet-Draft can be retrieved at:
>>>>> ftp://ftp.ietf.org/internet-drafts/draft-berger-ccamp-swcaps-up
>>>>> date-00.txt
>>>>>
>>>>> _______________________________________________
>>>>> I-D-Announce mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/i-d-announce
>>>>> Internet-Draft directories: http://www.ietf.org/shadow.html or 
>>>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> CCAMP mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/ccamp
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>> 
>> 
>> 
>