Subject: Re: last call comments

From: Jonathan Sadler <[email-masked]>
Date: Mon, 21 Aug 2000 10:08:39 -0500

Tom -

The Generalized MPLS draft being worked on in the MPLS wg includes
definition of a variable label size, as well as labels that are 32-bits
in length (ie. SDH, SONET, and Optical labels -- see Sec 3.2.1)  While
the TLV formats for ATM and FR could be dropped, the TLV format for MPLS
will be required if Generalized MPLS is to be supported.

It seems that some of these label formats defined in the GSMPv3 spec
intersect with the label formats being defined as a part of the
Generalized MPLS work.  It seems the best would be to take the SONET/SDH
definitions and merge them with the sub-DS1 formats proposed in GSMP v3.

Jonathan Sadler

[email-masked] wrote:
--- 8< snip >8 ---
> pg15: tlv labels for atm, fr and mpls. i don't think it
> makes sense to support two different encodings for these
> labels. this poses a complexity burden on the spec and on
> implementations and doesn't seem to have any associated
> benefit. if there is a need for two different encodings
> then it is not apparent.
> 
> as far as i can see, none of the label types supported have
> variable length value (i.e. the v in tlv) fields so is seems
> unnecessary to distinguish between short and tlv labels. and
> since the length field is redundant, a uniform label
> encoding using type discriminators would appear to suffice.
> 
> so i think we should go for: 1) only tlv labels, or 2) a
> uniform encoding without a length field, or 3) drop the tlv
> versions of atm, fr and mpls.

--- 8< snip >8 ---

> pg18 and throughout the spec: the ds3/e3/... labels are
> inadequately defined. it is completely unclear to me what a
> channel id is and i cannot understand how the time slots
> field is encoded. it seems that reference must be made to
> the sandards that specify the multiplex structure of these
> signals and the semantics of the fields specified in the
> gsmp be related unambiguously to those standards.
> 
> also, since we are doing channelised ds1, ds3 etc it seems
> only reasonable to also do channelised sts3 and stm1. the
> deployment of channelised sts3 and stm1 in access networks
> is very is widespread and increasing rapidly.

---

From: "tom worster" <[email-masked]>
Date: Mon, 21 Aug 2000 13:03:31 -0400

From: [email-masked] [mailto:[email-masked]]On Behalf Of
Jonathan Sadler
> will be required if Generalized MPLS is to be supported.

if variable length labels are required then tlvs make sense.
but with that decided we need to make up our minds if atm,
fr and basic mpls labels should be encoded in tlvs or in
the short format. i don't much care which but it doesn't
make any sense to specify both encodings.

> definitions and merge them with the sub-DS1 formats proposed 

in principle that would be the best approach. but i think the
timing is bad. gsmp closed last call on friday and generalised
mpls signalling is new and not exactly stable.

a workable compromise might be to remove the tdm labels from
gsmp v3 into a separate draft, put out gsmpv3 as is and then 
handle the tdm-label draft according to what goes down in 
generalised mpls. since the label type will be ianaised there 
shouldn't be much difficulty.

any thoughts on that approach?

c u
fsb

---

From: "Avri Doria" <[email-masked]>
Date: Tue, 22 Aug 2000 14:59:47 -0700

Hi,

I actually think it does make sense to do both.
In the first instance, retaining the short form makes sense for
backward compatibility, and for those using just ATM, FR or MPLS
labels who don't need the variable length capability.

On the other hand, for someone whose switch handles several
interface types, including some that have fixed length and some that
have variable length, it makes sense to be able to use just one 
kind of label in their implementation.  

What  doesn't necessarily make sense is to require any particular 
switch to support both methods.  This needs to be handled by adding 
a phrase indicating the switches must adopt at least one of the two 
label types.

Regards
a.

-- 

Avri Doria
+1 401 663 5024

---

From: Balaji Srinivasan <[email-masked]>
Date: Tue, 22 Aug 2000 15:23:00 -0700 (PDT)

>a phrase indicating the switches must adopt at least one of the two 

If we do this then the controller must be able to discover this from the
switch (via the switch configuration message or some such.) 
balaji

---

From: "tom worster" <[email-masked]>
Date: Thu, 24 Aug 2000 12:21:50 -0400

Balaji Srinivasan
> switch (via the switch configuration message or some such.) 

that's right. but there is no need for this much complexity.

i see these options:

1) use short form, fixed length for all labels. this is no good since
there is a need for variable length labels.

2) use tlv form for all labels. this will work. it is the cleanest
solution.

3) use short for atm/fr/mpls and tlv for the rest. this will work.

4) require switch support for both forms. this will also work.

5) allow switch to support either or both. this is broken -- unless
we add something like the discovery you mentioned to fix it.

so i think we should choose between 2), 3), and 4). i don't much 
like 4) because it seems nonsensical to require two message formats 
for the same thing -- which was my original last call comment. but
i'm willing to go along with any of these three.

c u
fsb

---

From: Jaroslaw Sydir <[email-masked]>
Date: Thu, 24 Aug 2000 10:22:45 -0700

My preference is for choice 2. 

Jerry

---

From: Balaji Srinivasan <[email-masked]>
Date: Thu, 24 Aug 2000 10:35:59 -0700 (PDT)

>2) use tlv form for all labels. this will work. it is the cleanest

Hi Everyone
I think this is the best solution...
balaji

---

From: Clint Bishard <[email-masked]>
Date: Fri, 25 Aug 2000 00:37:23 -0500

It appears that option 2 is the cleanest solution.  Particularly given the
statements that backwards compatibility has already been lost due to the
other changes.

Clint

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
tom worster
Sent: Thursday, August 24, 2000 11:22 AM
To: [email-masked]
Subject: RE: last call comments

i see these options:

c u
fsb

---

From: "Kenneth Sundell" <[email-masked]>
Date: Fri, 25 Aug 2000 10:13:50 +0200

folks,
is there anyone that objects to option 2 as described below?

ken

--
Kenneth Sundell
Routing Architecture Lab, Nortel Networks Sweden
phone: +46 8 5088-3538, mobile +46 70 665-7838