Label type to be used

[Kireeti Kompella <kireeti@juniper.net>]

Hi,

Arthi and Lou pointed out the following typos in the GMPLS routing doc
(draft-ietf-ccamp-gmpls-routing-09.txt) which is now in the RFC
Editor's queue:

In section 2.4.7 is the following table defining the type of label
for various combinations of switching types:

      [PSC, PSC] - label is carried in the "shim" header [RFC3032]
      [TDM, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH]
      [LSC, LSC] - label represents a lambda
      [FSC, FSC] - label represents a port on an OXC
      [PSC, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH]
      [PSC, LSC] - label represents a lambda
      [PSC, FSC] - label represents a port
      [TDM, LSC] - label represents a lambda
      [TDM, FSC] - label represents a port
      [LSC, FSC] - label represents a port

The one at issue is [PSC, LSC]; above it says that the label
represents a lambda; and in the case of [PSC, TDM] with a fully
transparent signal, the above indicates the label represents a TDM
time slot.  The proposal is to change this to:

      [PSC, PSC] - label is carried in the "shim" header [RFC3032]
      [TDM, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH]
      [LSC, LSC] - label represents a lambda
      [FSC, FSC] - label represents a port on an OXC
      [PSC, TDM] - fully transparent signal: label represents a port
                   ("transparency" is defined in [GMPLS-SONET-SDH])
      [PSC, TDM] - non-transparent signal: label represents a TDM time
                   slot [GMPLS-SONET-SDH]
      [PSC, LSC] - label represents a port
      [PSC, FSC] - label represents a port
      [TDM, LSC] - label represents a lambda
      [TDM, FSC] - label represents a port
      [LSC, FSC] - label represents a port

Please respond by Friday 3/26, 5pm PST with comments on:

a) do you agree with the above change?
b) in your implementation today, what do expect the label to represent
   i) in the case of [PSC, LSC]?
   ii) in the case of [PSC, TDM] with a fully transparent signal?
c) if you implement as the draft says, would it be a hardship to change
   this?

If we can get closure on this, I'll take up the task of modifying the
pending RFC with the ADs.

Kireeti.
-------