Re: Label type to be used

dimitri papadimitriou <dpapadimitriou@psg.com> Sat, 20 March 2004 13:14 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 IAA09580 for <ccamp-archive@ietf.org>; Sat, 20 Mar 2004 08:14:49 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4gJO-00051B-00 for ccamp-archive@ietf.org; Sat, 20 Mar 2004 08:14:50 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4gIP-0004u5-00 for ccamp-archive@ietf.org; Sat, 20 Mar 2004 08:13:50 -0500
Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1B4gHR-0004n4-00 for ccamp-archive@ietf.org; Sat, 20 Mar 2004 08:12:49 -0500
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B4fxN-000IPf-EW for ccamp-data@psg.com; Sat, 20 Mar 2004 12:52:05 +0000
Received: from psg.com ([147.28.0.62]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B4fxM-000IPO-BM; Sat, 20 Mar 2004 12:52:04 +0000
Message-ID: <405C3EF3.4000206@psg.com>
Date: Sat, 20 Mar 2004 13:54:11 +0100
From: dimitri papadimitriou <dpapadimitriou@psg.com>
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Kireeti Kompella <kireeti@juniper.net>
CC: ccamp@ops.ietf.org
Subject: Re: Label type to be used
References: <20040318093213.B7263@kummer.juniper.net>
In-Reply-To: <20040318093213.B7263@kummer.juniper.net>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
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
Content-Transfer-Encoding: 7bit

hi kireeti

see in-line:

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?

yes, wouldn't be also wise to include the distinction for the
[TDM,TDM] case ?

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

port

>    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?
> 
> If we can get closure on this, I'll take up the task of modifying the
> pending RFC with the ADs.
> 
> Kireeti.
> -------
> 
> 
> .
>