Re: Label type to be used

[Ashok Narayanan <ashokn@cisco.com>]

On Thu, Mar 18, 2004 at 04:43:11PM -0500, Lou Berger wrote:
> At 04:27 PM 3/18/2004 -0500, Ashok Narayanan wrote:
> 
> >Personally, I do not agree with this change. I would rather see the
> >other side of this discrepancy fixed i.e. GMPLS-SONET-SDH should
> >specify the use of SUKLM label and SONET TSpec for all [PSC, TDM]
> >links irrespective of transparency. This seems like a more natural
> >architecture to me. Why is this not preferred?
> >
> >-Ashok
> 
> Ashok,
> 
> Beyond the original rational for the current definition, this is not 
> consistent with GMPLS-SONET-SDH, which is in the RFC editor queue, 

Both drafts are in the queue; one is not consistent with the
other. Seem symmetric to me.

> and does 
> not match many implementations (at least all we've tested against.)
> 
> Kireeti's change is consistent with the other documents (and the reality of 
> many implementations).

That's not bad; I could say that especially at this late time we could
live with it. But it seems messy. It's a very nice hierarchical model
to say that label type and TSpec type is dictated by switching type (pair). 
But this exception makes things not so clean. Plus TDM switches now
have to handle both SUKLM and port labels, and both Intserv and
SONET/SDH TSpecs when in fact there was really no need for it. If the
signal is truly transparent then a TSpec reflecting all the slots on
the link, and a SUKLM label reflecting STS-1, is functionally
identical to a port label and an Intserv tspec (probably the SONET
TSpec is a more accurate description of the link). 

Anyway, I won't really object to the change if nobody else does.

-Ashok

> 
> Lou
> 
> >On Thu, Mar 18, 2004 at 09:58:23AM -0800, Kireeti Kompella wrote:
> >> 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.
> >> -------
> >
> >--
> >
> >
> >--- Asok the Intern ----------------------------------------
> >Ashok Narayanan
> >IOS Network Protocols, Cisco Systems
> >1414 Mass Ave, Boxborough MA 01719
> >Ph: 978-936-1608.  Fax: 978-936-2218 (Attn: Ashok Narayanan)

-- 



--- Asok the Intern ----------------------------------------
Ashok Narayanan
IOS Network Protocols, Cisco Systems
1414 Mass Ave, Boxborough MA 01719
Ph: 978-936-1608.  Fax: 978-936-2218 (Attn: Ashok Narayanan)