RE: Label type to be used

John Drake <jdrake@calient.net> Fri, 26 March 2004 19:07 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 OAA08265 for <ccamp-archive@ietf.org>; Fri, 26 Mar 2004 14:07:07 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6wfb-0005iA-00 for ccamp-archive@ietf.org; Fri, 26 Mar 2004 14:07:07 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6wed-0005ad-00 for ccamp-archive@ietf.org; Fri, 26 Mar 2004 14:06:08 -0500
Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1B6wde-0005T3-00 for ccamp-archive@ietf.org; Fri, 26 Mar 2004 14:05:07 -0500
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B6wOe-000BPT-Hc for ccamp-data@psg.com; Fri, 26 Mar 2004 18:49:36 +0000
Received: from [63.102.55.206] (helo=lightwave.chromisys.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B6wOd-000BP7-Lk for ccamp@ops.ietf.org; Fri, 26 Mar 2004 18:49:35 +0000
Received: by lightwave.chromisys.com with Internet Mail Service (5.5.2653.19) id <GTZGHLSV>; Fri, 26 Mar 2004 10:49:30 -0800
Message-ID: <9D42C6E086250248810DCADA39CE7EFC017AD51F@nimbus.chromisys.com>
From: John Drake <jdrake@calient.net>
To: Kireeti Kompella <kireeti@juniper.net>, ccamp@ops.ietf.org
Subject: RE: Label type to be used
Date: Fri, 26 Mar 2004 10:49:31 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
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.1 required=5.0 tests=AWL autolearn=no version=2.60


> -----Original Message-----
> From: Kireeti Kompella [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.
> -------