RE: Label type to be used

Lou Berger <lberger@movaz.com> Fri, 26 March 2004 19:35 UTC

Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10181 for <ccamp-archive@ietf.org>; Fri, 26 Mar 2004 14:35:34 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6x78-0000Zd-00 for ccamp-archive@ietf.org; Fri, 26 Mar 2004 14:35:34 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6x5y-0000O5-00 for ccamp-archive@ietf.org; Fri, 26 Mar 2004 14:34:24 -0500
Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1B6x4k-00009N-00 for ccamp-archive@ietf.org; Fri, 26 Mar 2004 14:33:06 -0500
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B6wpf-000FDo-Hc for ccamp-data@psg.com; Fri, 26 Mar 2004 19:17:31 +0000
Received: from [65.205.166.188] (helo=jera.movaz.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B6wpe-000FDW-D0 for ccamp@ops.ietf.org; Fri, 26 Mar 2004 19:17:30 +0000
Received: from lb-laptop.movaz.com (kenaz.atlanta.movaz.com [172.16.8.184]) by jera.movaz.com (Postfix) with ESMTP id 13091C6A; Fri, 26 Mar 2004 14:17:29 -0500 (EST)
Message-Id: <6.0.3.0.2.20040326135558.035aad58@mo-ex1>
X-Sender: lb@mo-ex1
X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0
Date: Fri, 26 Mar 2004 14:17:27 -0500
To: Kireeti Kompella <kireeti@juniper.net>
From: Lou Berger <lberger@movaz.com>
Subject: RE: Label type to be used
Cc: ccamp@ops.ietf.org, John Drake <jdrake@calient.net>
In-Reply-To: <9D42C6E086250248810DCADA39CE7EFC017AD51F@nimbus.chromisys. com>
References: <9D42C6E086250248810DCADA39CE7EFC017AD51F@nimbus.chromisys.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Sender: owner-ccamp@ops.ietf.org
Precedence: bulk
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60

Kireeti,
         I think John's points on (a) and (c) are reasonable.  I think the 
only changes needed to the draft-ietf-ccamp-gmpls-routing-09.txt to make 
this clear are:

    2.4.4. Lambda-Switch Capable

    If an interface is of type LSC, it means that the node receiving data
    over this interface can recognize and switch individual lambdas
    within the interface.  An interface that allows only one lambda per
    interface, and switches just that lambda is of type LSC.
 >  This includes interfaces that only support fully transparent SONET/SDH
 >   signals, as defined in [GMPLS-SONET-SDH].

and
        [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/port
        [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/port
        [PSC, FSC] - label represents a port
 >      [TDM, LSC] - label represents a lambda/port
        [TDM, FSC] - label represents a port
        [LSC, FSC] - label represents a port

Lou

PS This matches all but one implementation we've interoperated with.

At 01:49 PM 3/26/2004 -0500, John Drake wrote:


> > -----Original Message-----
> > From: Kireeti Kompella 
> [<mailto:kireeti@juniper.net>mailto:kireeti@juniper.net]
> > Sent: Thursday, March 18, 2004 9:58 AM
> > To: ccamp@ops.ietf.org
> > Subject: Label type to be used
> >
> > 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?
>[John Drake]
>
>I don't have a problem with the [PSC, LSC] change but I don't
>understand the distinction between transparent and non-transparent
>TDM as it pertains to GMPLS routing.  As I indicated in a previous
>e-mail, I think the transparent TDM case should be handled with a
>switching type of LSC and an encoding type of SDH/SONET, and I think
>that this should be specified in the SDH/SONET I-D, where the distinction
>between transparent and non-transparent TDM is defined, rather than in
>this document.
>
> > b) in your implementation today, what do expect the label to represent
> >    i) in the case of [PSC, LSC]?
>[John Drake]
>
>Port/lambda
>
> >    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?
>[John Drake]
>
>N/A.  Labels for SDH/SONET are defined in the SDH/SONET I-D and it's pretty
>clear about which types of labels are in the transparent and non-transparent
>TDM cases.
>
> >
> > If we can get closure on this, I'll take up the task of modifying the
> > pending RFC with the ADs.
> >
> > Kireeti.
> > -------