RE: Label type to be used

"Pandian, Vijay" <Vijay.Pandian@sycamorenet.com> Mon, 22 March 2004 17:03 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 MAA06243 for <ccamp-archive@ietf.org>; Mon, 22 Mar 2004 12:03:29 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5Spm-00055X-00 for ccamp-archive@ietf.org; Mon, 22 Mar 2004 12:03:31 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5Son-0004w0-00 for ccamp-archive@ietf.org; Mon, 22 Mar 2004 12:02:30 -0500
Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1B5Snr-0004n9-00 for ccamp-archive@ietf.org; Mon, 22 Mar 2004 12:01:31 -0500
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B5SNg-0004PV-6l for ccamp-data@psg.com; Mon, 22 Mar 2004 16:34:28 +0000
Received: from [12.146.0.143] (helo=cabo.sycamorenet.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B5SNZ-0004OU-2G for ccamp@ops.ietf.org; Mon, 22 Mar 2004 16:34:21 +0000
Received: by cabo.sycamorenet.com with Internet Mail Service (5.5.2653.19) id <H2A6THPZ>; Mon, 22 Mar 2004 11:37:38 -0500
Message-ID: <5533E74FC0108E41A8217C0899CA56CF081CB5@mach5.sycamorenet.com>
From: "Pandian, Vijay" <Vijay.Pandian@sycamorenet.com>
To: 'Kireeti Kompella' <kireeti@juniper.net>, ccamp@ops.ietf.org
Subject: RE: Label type to be used
Date: Mon, 22 Mar 2004 11:37:36 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
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,

Comments inline...

Regards,

Vijay

> -----Original Message-----
> From: Kireeti Kompella [mailto:kireeti@juniper.net]
> Sent: Thursday, March 18, 2004 12:58 PM
> 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?

Yes, but we need one more change.
Why is it for [TDM, LSC] the label is lambda? Shouldn't this be port as
well?

> b) in your implementation today, what do expect the label to represent
>    i) in the case of [PSC, LSC]?

Not applicable

>    ii) in the case of [PSC, TDM] with a fully transparent signal?

Port

> c) if you implement as the draft says, would it be a hardship 
> to change
>    this?

No

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