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

From: Lou Berger <[email-masked]>
Date: Tue, 21 Feb 2012 09:31:42 -0500

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: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

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-update-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-update-00.txt

_______________________________________________
I-D-Announce mailing list
[email-masked]
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

---

From: Daniele Ceccarelli <[email-masked]>
Date: Mon, 27 Feb 2012 15:51:19 +0100

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? What is not clear to me is "same type of multiplexing" could you please clarify? 
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.
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?

Thanks,
Daniele

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] 
>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 
>A New Internet-Draft is available from the on-line 
>Internet-Drafts directories.
>
>Internet-Draft directories: http://www.ietf.org/shadow.html or 
>ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
>
>
>CCAMP mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ccamp
>

---

From: Lou Berger <[email-masked]>
Date: Mon, 27 Feb 2012 11:08:14 -0500

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.
> - "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.

> 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?

> 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.

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)
> 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.

Lou

---

From: Daniele Ceccarelli <[email-masked]>
Date: Mon, 27 Feb 2012 17:39:30 +0100

Hi Lou,

My replies in line.

Thanks,
Daniele

>From: Lou Berger [mailto:[email-masked]] 
>Sent: lunedì 27 febbraio 2012 17.08
>To: Daniele Ceccarelli
>Cc: CCAMP
>Subject: Re: [CCAMP] Fwd: I-D Action: 

OK, it was just a confirmation. So OTN is a future technology :-)

>
>> What is not clear to me is "same type of multiplexing" could you 
>> please clarify?
>>
>
>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:

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.

>> 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:

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].
>
>>
>> as example) ODU0 --> Switch Type=OTN; ILH=1
>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:

>>> From: [email-masked] [mailto:[email-masked]] On 
>>> Behalf Of Lou Berger
>December.  The 
>>> 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.
>>>
>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.
>>>

---

From: Lou Berger <[email-masked]>
Date: Mon, 27 Feb 2012 12:01:56 -0500

Daniele,
	See below.

> 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....

> 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.

>    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.

>    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...

Thanks again,
Lou

---

From: John E Drake <[email-masked]>
Date: Mon, 27 Feb 2012 13:26:34 -0800

Snipped, comments inline

> due to the use of ILH field in this example.

[JD]  This is the same problem I have had all along.  Viz, you are explicitly equating trunk bandwidth with layer boundaries.  

I have yet to hear anyone articulate why this is necessary or useful, and even if it were necessary or useful, advertising an explicit field is duplicative because we *already* advertise trunk bandwidth, and hence in this formulation, layer boundaries.  If an implementation were to decide that having an explicit field was necessary or useful, it could easily be included in their internal data structures without cluttering the advertisements.

As an aside, PSC 1-4 did not do this.  Instead, PSC 1-4 was an entirely logical concept, which meant that the network designer could place the layer boundaries wherever they wished.

Thanks,

John

---

From: Lou Berger <[email-masked]>
Date: Mon, 27 Feb 2012 17:24:26 -0500

On 2/27/2012 4:26 PM, John E Drake wrote:
> [JD]  This is the same problem I have had all along.  Viz, you are
> explicitly equating trunk bandwidth with layer boundaries.
> 
> I have yet to hear anyone articulate why this is necessary or useful,
> and even if it were necessary or useful, advertising an explicit
> field is duplicative because we *already* advertise trunk bandwidth,
> and hence in this formulation, layer boundaries.  If an
> implementation were to decide that having an explicit field was
> necessary or useful, it could easily be included in their internal
> data structures without cluttering the advertisements.
> 
> As an aside, PSC 1-4 did not do this.  Instead, PSC 1-4 was an
> entirely logical concept, which meant that the network designer could
> place the layer boundaries wherever they wished.
> 

John,

Yes.  MPLS and label stacking are wonderfully flexible technologies.
Unfortunately, SDH and OTN are not as flexible and there is a fixed
multiplexing structure.  (See page pgs 16 & 17 of G.709, there are only
a finite number of mappings down to the physical layer.)

ILH *could* be used to represent this, or it could *not*.  This is a
discussion for the future as all the draft says at this point is:

   The mapping of ILH values to specific
   levels of hierarchy within a data plane technology is specific to
   each switching technology and is therefore outside the scope of this
   document.

and I previously said, "I would not recommend any changes to
gmpls-ospf-g709v3 at this time."  So we really can leave this argument
until such time as someone makes a proposal on using ILH with OTN...

Lou

---

From: John E Drake <[email-masked]>
Date: Mon, 27 Feb 2012 15:51:26 -0800

Snipped, comments inline

> a finite number of mappings down to the physical layer.)

[JD] You didn't actually answer any of my points but rather just re-asserted that a layer indicator is needed and that layers correspond to trunk bandwidths.  I continue to find both assertions questionable as we didn't need a layer indicator in SDH/SONET and people far more knowledgeable than either you or I have said it is unnecessary in OTN.

To put it another way, if a TE advertisement contained a layer indicator, what *exactly* would you differently in your processing of such an advertisement?

>    each switching technology and is therefore outside the scope of this

[JD]  This presupposes that a mapping of ILH values to specific levels of hierarchy is either necessary or useful.  

> until such time as someone makes a proposal on using ILH with OTN...

[JD] Your email to which I initially responded proposed *exactly* this.  If no one knows how ILH is to be used, why are we introducing it?

---

From: [email-masked]
Date: Tue, 28 Feb 2012 17:46:06 +0800

Hi Lou, John

I am confused with the introduction of ILH also, try to figure out it 
based on the exact example (like OTN, which is the hot topic discussed 
recently).

Below is my understanding provided for discussion, please do not hesitate 
to let me know if it is wrong.

(1) The ISCD of the ODUK/OTUK is not changed except that the added ILH 
field and moving the Max LSP Bandwidth per priority as a TLV into the SCSI 
TLV?

(2) The ISCD of the ODUj is reflected by the ILH (for example 1 ODU1/2 
ODU2/3 ODU3/4 ODU4/ 8 ODU0/ 9 ODU2e/10 ODUflex CBR...) and the TLV 
carrying the unreserved bandwidth looks like?
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Reserved     | Num of stages |T|S| TSG | Res |   Priority    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Stage#1    |      ...      |   Stage#N     |    Padding    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Unres ODUj at Prio 0      |     Unres ODUj at Prio 1      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Unres ODUj at Prio 2      |     Unres ODUj at Prio 3      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Unres ODUj at Prio 4      |     Unres ODUj at Prio 5      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Unres ODUj at Prio 6      |     Unres ODUj at Prio 7      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Notes: 
(1) The structure is copied from the draft 
http://tools.ietf.org/id/draft-ietf-ccamp-gmpls-ospf-g709v3-01.txt with no 
sigal type there.

(2) For the trunk ODUK, both Max and Unreserved TLV SHOULD be carried with 
the same ISCD header.

(3）The IACD is changed like?

Consider an interface which support OTN and SDH switching,or OTN and 
packet switching.
The VC-4 frames/GFP frames can be mapped directly into ODU0, but ODU1 is 
forbidden (local polices).
In this case, the Lower ILH will be useful.
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Upper SC      | Upper Encoding| Reserved            |Upper ILH|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Lower SC      | Lower Encoding| Reserved           |Lower ILH |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Notes: the other parts is snipped here. and the XRO 

Best regards

Fei

John E Drake <[email-masked]> 
发件人:  [email-masked]
2012-02-28 07:51

收件人
Lou Berger <[email-masked]>
抄送
CCAMP <[email-masked]>
主题
Re: [CCAMP] Fwd: I-D Action: draft-berger-ccamp-swcaps-update-00.txt

Snipped, comments inline

> a finite number of mappings down to the physical layer.)

[JD] You didn't actually answer any of my points but rather just 
re-asserted that a layer indicator is needed and that layers correspond to 
trunk bandwidths.  I continue to find both assertions questionable as we 
didn't need a layer indicator in SDH/SONET and people far more 
knowledgeable than either you or I have said it is unnecessary in OTN.

To put it another way, if a TE advertisement contained a layer indicator, 
what *exactly* would you differently in your processing of such an 
advertisement?

>    each switching technology and is therefore outside the scope of this

[JD]  This presupposes that a mapping of ILH values to specific levels of 
hierarchy is either necessary or useful. 

> until such time as someone makes a proposal on using ILH with OTN...

[JD] Your email to which I initially responded proposed *exactly* this. If 
no one knows how ILH is to be used, why are we introducing it?

---

From: Daniele Ceccarelli <[email-masked]>
Date: Tue, 28 Feb 2012 12:10:46 +0100

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

>Sent: lunedì 27 febbraio 2012 18.02
>To: Daniele Ceccarelli
>Cc: CCAMP
>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.

>> 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 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.

>   OTN [G.709], should use two different Switching Types.

OK

>>> 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].
>>>
>>>>
>> 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:

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

---

From: Lou Berger <[email-masked]>
Date: Tue, 28 Feb 2012 07:25:53 -0500

John,

On 2/27/2012 6:51 PM, John E Drake wrote:
>>  So we really can leave this argument
> [JD] Your email to which I initially responded proposed *exactly* this.  

You seemed to have missed the point of my mail.  Daniele asked if
introduction to ILH would require to the OTN SCSI format.  My response
was no, and I tried to illustrate why.  My mistake for providing too
much information.  Again, the key points from my response to him:

from 2/27/2012 11:08 AM, Lou Berger wrote:
> Given that maturity level of this (our) draft, I would not recommend
> any changes to gmpls-ospf-g709v3 at this time.

and

> so there would be no change in number of advertised ISCDs

and

On 2/27/2012 5:24 PM, Lou Berger wrote:
>    each switching technology and is therefore outside the scope of
>    this document.
>

Just to be clear, I'll say it again.  I'm not proposing the use of ILH
for OTN at this time.

(Might I do so in the future? Possibly, but I really don't know what
form such a proposal would take as the the use and definition of ILH is
still a work in progress.  I'm not yet sure such a proposal makes sense
for OTN, from a technical perspective, and it certainly doesn't make
sense at this point from a procedural perspective.)

Lou

---

From: Lou Berger <[email-masked]>
Date: Tue, 28 Feb 2012 07:38:14 -0500

Fei,

	Per my last message.  The introduction of ILH does not require, or
proposal, any change to the WG OTN documents.  (Although it does imply
the use of a new Switching Type for OTNv3 -- which is already in the
drafts.)

If someone wants to propose changes to the OTN drafts based on ILH,
that's fine, but such a proposal is *not* in our draft.

Lou

On 2/28/2012 4:46 AM, [email-masked] wrote:
> Below is my understanding provided for discussion, please do not
> hesitate to let me know if it is wrong.
> 
> field and moving the Max LSP Bandwidth per priority as a TLV into the
> SCSI TLV?
> 
> http://tools.ietf.org/id/draft-ietf-ccamp-gmpls-ospf-g709v3-01.txt with
> no sigal type there.
> 
> (2) For the trunk ODUK, both Max and Unreserved TLV SHOULD be carried
> with the same ISCD header.
> 
> *John E Drake <[email-masked]>*
> re-asserted that a layer indicator is needed and that layers correspond
> to trunk bandwidths.  I continue to find both assertions questionable as
> we didn't need a layer indicator in SDH/SONET and people far more
> To put it another way, if a TE advertisement contained a layer
> indicator, what *exactly* would you differently in your processing of
> such an advertisement?
> 
>>
> [JD]  This presupposes that a mapping of ILH values to specific levels
> of hierarchy is either necessary or useful.  
> 
>>
>  If no one knows how ILH is to be used, why are we introducing it?
> 
>>
>> Lou
>>
>>
>> > Thanks,
>> >
>> > John
>>
>> >
>> >
>> >
>> >

---

From: Lou Berger <[email-masked]>
Date: Tue, 28 Feb 2012 08:27:30 -0500

On 2/28/2012 6:10 AM, Daniele Ceccarelli wrote:
>...
> Could you please explain what is the rationale
> behind introducing it?
> ...

Daniele,

Now this is a good question!

The ILH field is motivated by the WG goal of identifying and defining
common control plane mechanisms for different data plane technologies.
This draft says it this way:

   Multiple switching technologies support forms of hierarchical
   switching within a particular data plane technology.  As discussed
   above, GMPLS routing originally envisioned support for such cases for
   packet networks using PSC-2, 3, 4.  In other cases, GMPLS defined
   support using technology specific mechanisms, for example Signal Type
   was defined for SONET/SDH, see [RFC4606].  Given that one of the
   objectives of GMPLS is to generalize control plane protocols, it is
   reasonable to define a method for supporting hierarchical switching
   within a particular data plane technology that is not specific to any
   particular technology.

>From the advent of GMPLS, there has been general agreement that there
may be hierarchical switching within a particular data plane technology.
 What hasn't been figured out is the best way to represent this in a
common format.  This draft documents what we think is general agreement;
that the use of the routing Switching Cap field is the wrong place.

So what is the benefit of a generic/common representation of
intra-technology hierarchy?

>From my perspective, i.e. not speaking for Julien, it is that it enables
a function that is common across multiple technologies to be implemented
in a technology agnostic fashion -- which is, of course, on the
fundamental precepts of CCAMP and GMPLS.

Some example benefits include that it enables per-hierarchy level
topologies to be constructed by (routing) implementations *without*
parsing the SCSI.  Additionally, on equipment that doesn't support a
particular technology/hierarchy combination, processing of
advertisements for such non-supported combinations can be minimized.  As
an implementor, I also like the code & testing benefits of having common
mechanisms/implementation for equivalent per-technology functions.  I
also can see some potential operations benefits, but these certainly
will be implementation dependent.

These benefits seem sufficient to warrant looking into the mechanisms in
more detail to determine if the benefit is worth the cost of the
introduction of a new generic mechanism.  We also recognize, as has been
discussed multiple times before in the WG, there is the common tendency
of those focused on a new technology to want to solve generic problems
in a technology-specific fashion and it's the WG's job to identify when
this is happening and when it's appropriate to define new generic
mechanisms.

As we say in the document, we think that the introduction of ILH is an
open-discussion and certainly look for more/WG input.

Lou

---

From: John E Drake <[email-masked]>
Date: Tue, 28 Feb 2012 07:56:41 -0800

Comments inline

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Lou Berger
> Sent: Tuesday, February 28, 2012 5:28 AM
> To: Daniele Ceccarelli
> Cc: CCAMP
> Subject: Re: [CCAMP] Fwd: I-D Action: draft-berger-ccamp-swcaps-update-
> 00.txt
> 

[JD]  The problem with the above statement is that the term 'hierarchical switching' is not defined. 

> fundamental precepts of CCAMP and GMPLS.

[JD]  The problem with the above statement is that the term 'a function' is not defined.  

> parsing the SCSI.

[JD]  If you don't parse the SCSI, how do you place it in your TE database?

> Additionally, on equipment that doesn't support a
> advertisements for such non-supported combinations can be minimized.

[JD]  How exactly? 

> As

[JD] A common mechanism in support of what exactly?  Also, even though there a single proposed field, the values in it will be technology specific.