Subject: Label type to be used

From: Kireeti Kompella <[email-masked]>
Date: Thu, 18 Mar 2004 09:58:23 -0800 (PST)

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.
-------

---

From: Anca Zamfir <[email-masked]>
Date: Thu, 18 Mar 2004 13:30:05 -0500

Hi,
Does "label represents a port" means port label must be used in signaling? 
Or a label (from the respective LSP domain) that takes the whole port 
resource should be used? For example, in the [PSC, TDM] I think that 
signaling should still use a TDM label. Is this interpretation correct?
Thanks,
/anca

---

From: [email-masked]
Date: Thu, 18 Mar 2004 20:03:27 +0100

anca,

VC/STS signal:
- Label Request per GMPLS-SONET-SDH
- Label per GMPLS-SONET-SDH

Section/RS or Line/MS transparent STS-1/STM-0/STS-
3*N/STM-N (N=1, 4, 16, 64, 256) signal:
- Label Request per GMPLS-SONET-SDH
- Label per RFC 3471 Section 3.2 => port (represents
   the section/RS or line/MS)

Fully transparent signal:
- Label Request per RFC 3471 Section 3.1
- Label per RFC 3471 Section 3.2 => port (represents
   whole signal)

note: transparent =/= photonic (that LSC implies)

so your second assumption seems to be the right one

---

Anca Zamfir wrote:

> Hi,
> Does "label represents a port" means port label must be used in 
> signaling? Or a label (from the respective LSP domain) that takes the 
> whole port resource should be used? For example, in the [PSC, TDM] I 
> think that signaling should still use a TDM label. Is this 
> interpretation correct?
> Thanks,
> /anca
> 

-- 
Papadimitriou Dimitri
E-mail : [email-masked]
E-mail : [email-masked]
Webpage: http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491

---

From: [email-masked]
Date: Thu, 18 Mar 2004 20:12:19 +0100

oops... pushed too fast

 > note: transparent =/= photonic (that LSC implies)

add: "Transparency is not applied at the interfaces with
the initiating and terminating LSRs, but is only applied
between intermediate LSRs."

---

From: Kireeti Kompella <[email-masked]>
Date: Thu, 18 Mar 2004 11:19:33 -0800 (PST)

Hi Anca,

> signaling should still use a TDM label. Is this interpretation correct?

"represents a port" means port label should be used.

If you look at GMPLS-SONET-SDH, last para of section 2:

   The traffic parameters and label encoding defined in [RFC3471]
   Section 3.2 MUST be used for fully transparent STS-1/STM-0/STS-
                                ^^^^^^^^^^^^^^^^^

If you use traffic params from 3471/3473, you *cannot* use an SUKLM
label.  However, section 3.2 of 3471 covers lots of label types (port,
lambda, ATM/FR), so that reference is not very helpful, except to say
that the label is not SUKLM.

Kireeti.
-------

---

From: Anca Zamfir <[email-masked]>
Date: Thu, 18 Mar 2004 16:08:03 -0500

Dimitri, Kireeti,
Thanks for the clarifications. The changes proposed look ok.

>a) do you agree with the above change?

yes

>    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

n/a

thanks,
/anca

---

From: Ashok Narayanan <[email-masked]>
Date: Thu, 18 Mar 2004 16:27:33 -0500

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

-- 

--- 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)

---

From: Lou Berger <[email-masked]>
Date: Thu, 18 Mar 2004 16:43:11 -0500

>architecture to me. Why is this not preferred?

Ashok,

Beyond the original rational for the current definition, this is not 
consistent with GMPLS-SONET-SDH, which is in the RFC editor queue, 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).

Lou

---

From: Ashok Narayanan <[email-masked]>
Date: Thu, 18 Mar 2004 18:38:53 -0500

On Thu, Mar 18, 2004 at 04:43:11PM -0500, Lou Berger wrote:
> 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 

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

-- 

--- Asok the Intern ----------------------------------------
Ashok Narayanan

---

From: Ashok Narayanan <[email-masked]>
Date: Thu, 18 Mar 2004 18:47:18 -0500

I erroneously sent out some wrong text in my previous email which can
be ignored as noise:

> Plus TDM switches now
> SONET/SDH TSpecs when in fact there was really no need for it. 

Meanwhile I have another question. We changed the label type of 
[PSC, LSC] from "lambda" to "port"; and I guess the reason for that is
that a PSC device really isn't going to know about wavelengths. If my
understanding is correct, then [TDM, LSC] should also really be a port
label. Why isn't it?

-Ashok

> If the

-- 

--- Asok the Intern ----------------------------------------
Ashok Narayanan

---

From: dimitri papadimitriou <[email-masked]>
Date: Sat, 20 Mar 2004 13:54:11 +0100

hi kireeti

see in-line:

> a) do you agree with the above change?

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

port

port

> .

---

From: Kireeti Kompella <[email-masked]>
Date: Sat, 20 Mar 2004 18:03:51 -0800 (PST)

Hi Dimitri,

> yes, wouldn't be also wise to include the distinction for the

Could you clarify?

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

Thanks for your responses.

Kireeti.
-------

---

From: dimitri papadimitriou <[email-masked]>
Date: Sun, 21 Mar 2004 14:21:13 +0100

Hi kireeti

 >       [PSC, TDM] - non-transparent signal: label represents a TDM time

the suggestion is also indicate the distinction for [TDM,TDM]:
         [TDM, TDM] - fully transparent signal: label represents a port
                      ("transparency" is defined in [GMPLS-SONET-SDH])
         [TDM, TDM] - non-transparent signal: label represents a TDM time
                      slot [GMPLS-SONET-SDH]
 >       [PSC, TDM] - non-transparent signal: label represents a TDM time

thanks,
- dimitri.

---

From: Kireeti Kompella <[email-masked]>
Date: Sun, 21 Mar 2004 10:16:13 -0800 (PST)

On Sun, 21 Mar 2004, dimitri papadimitriou wrote:

Hi Dimitri,

>  >       [PSC, TDM] - non-transparent signal: label represents a TDM time

Okay.  Makes sense.  Questions for all:

1) do you agree with this change?
2) if you implement GMPLS for [TDM, TDM] links, do you use port labels
   or SUKLM labels for the fully transparent case?
   - if SUKLM, would it be a hardship to change this?

Please respond by Sun Mar 28th, 5pm PST.

Thanks!
Kireeti.
-------

---

From: Lou Berger <[email-masked]>
Date: Mon, 22 Mar 2004 09:38:01 -0500

>Please respond by Sun Mar 28th, 5pm PST.

Kireeti,
         I think Dimitri's clarification reflects the current state of the 
documents.  So is *not* a change, but makes more explicit what is already 
in the documents.  There are implementations that do exactly this today.

Changing to SUKLM, per your item 2, implies an update to 
[GMPLS-SONET-SDH].  Also, more importantly, (at least to me) is it implies 
that a link's switching type or label type may need change based on a 
neighbor's switching type!  Consider transport equipment that support 
SONET/SDH framing, but not sub-channel switching.  Item 2 implies that a 
SUKLM label would be used when the neighbor is a TDM switch, and a port 
label is used when a neighbor is a router.  This seems wrong to me.

An alternative is to advertise such interfaces as LSC all the time.  I 
don't think such advertisements are implied today, but the text could be 
change.  An even better alternative is to introduce a new switching 
capability between TDM and LSC that is used for interfaces that only 
support a single transparent service on the interface.  I like this 
alternative, but it is a bit late to make such a change...

Lou

---

From: Ben Mack-Crane <[email-masked]>
Date: Tue, 23 Mar 2004 10:14:50 -0600

Hi,

The original text seems to have a sensible pattern.
The proposed changed text does not.

In reviewing the discussion so far, it seems to me the best solution
is to leave the text as is, understanding that switches capable of
handling both TDM channelized switching as well as fully transparent
(port or lambda) switching advertise multiple switching types.

The tuples shown in the text under discussion do not appear in routing,
and labels are not a concern of routing, so rather than confuse
things further, it is best to leave the text as is.

Answers to the specific questions are in-line below.

Regards,
Ben

>a) do you agree with the above change?
No.

>   i) in the case of [PSC, LSC]?
Lambda.

>   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
Yes.

>pending RFC with the ADs.

-----------------------------------------
============================================================
The information contained in this message may be privileged 
and confidential and protected from disclosure.  If the 
reader of this message is not the intended recipient, or an 
employee or agent responsible for delivering this message to 
the intended recipient, you are hereby notified that any 
reproduction, dissemination or distribution of this 
communication is strictly prohibited. If you have received 
this communication in error, please notify us immediately by 
replying to the message and deleting it from your computer.

Thank you.
Tellabs
============================================================

---

From: Kireeti Kompella <[email-masked]>
Date: Tue, 23 Mar 2004 11:42:22 -0800 (PST)

Hi Ben,

> The proposed changed text does not.

Your responses below don't bear out your comment above: your
implementation uses port labels for [PSC, TDM/transparent], but the
original text says to use SUKLM.

The sensibility of the pattern is also questionable; an equally
sensible pattern is to use port labels for [x, TDM/transparent].

> (port or lambda) switching advertise multiple switching types.

I'm not sure how you reached the conclusion that the best solution is
to leave the text as is.  So far, there's been uniform agreement to
change the text, with Ashok counted as an abstention ("I won't really
object").

The main point, though, is to come to a meaningful position that also
jives with current implementations -- ultimately, standards are to
enable interoperable implementations.

<snipped>

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

Noted.

Kireeti.
-------

---

From: Arthi Ayyangar <[email-masked]>
Date: Tue, 23 Mar 2004 12:06:02 -0800 (PST)

Kireeti,

I have also included your original questions for [PSC,LSC] and [PSC,TDM]
in this mail. Please see my answers inline.

thanks,
-arthi

> 1) do you agree with this change?
--------> Yes for the above changes. Yes for the proposed changes to
[PSC, LSC] case as well.

>    - if SUKLM, would it be a hardship to change this?
------> N/A.

  3) 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.

> 4) if you implement as the draft says, would it be a hardship to change
>    this?
-------> N/A.

---

From: Ben Mack-Crane <[email-masked]>
Date: Tue, 23 Mar 2004 14:20:55 -0600

Hi Kireeti,

See in-line.

Regards,
Ben

>sensible pattern is to use port labels for [x, TDM/transparent].
If an interface supports transparent switching, it would fit the
type [x, FSC], and thus use a port label for transparent LSP requests.
So both [x, TDM] and [x, FSC] would fit the advertisement provided by
a TDM port that supports both TDM channelized switching and transparent
switching.  One would use SUKLM label in the first case and a port label
in the second (as indicated in the GMPLS-SONET-SDH draft, and in the
current text in the routing draft).

At least this is the way I understand the current docs.

>enable interoperable implementations.
I thought my interpretation did match current implementations (as far
as I can tell from the discussion to date).

Thank you.
Tellabs

---

From: Ashok Narayanan <[email-masked]>
Date: Tue, 23 Mar 2004 15:34:39 -0500

> current text in the routing draft).

My understanding of how transparent switching works on a TDM switch is
not where it really should be to jump into this discussion, but what
the heck....

If you request a fully transparent TDM signal, that still implies that
it is a TDM signal, right? Could you connect a GigE port to a TDM
switch and request a OC-48 worth of fully transparent signal to
another GigE port on the other side? I believe the answer is no; and
in that case the switch can't truly advertise this link as FSC.

-Ashok

-- 

--- Asok the Intern ----------------------------------------
Ashok Narayanan