The MPLS WG Archive

["Peter Ashwood-Smith" <petera@nortelnetworks.com>]

Title: RE: draft-ashwood-generalized-mpls-signaling- (was Re: Optical MPLS)

I think that's a typo. You should not have a generalized and normal label in a "RESV/Mapping" because it is ambiguous.

The suggested label is the mechanism for "hinting" as you say to the downstream neighbor as to a preferred label.

As to using a new object for the suggested label. Its just cleaner. The object has the same format, it just has a different type/ctype. Personally I prefer to avoid the use of context to imply meaning where possible. In this case it was trivial to make it concrete so we did.

Peter

-----Original Message-----
From:   Robert Rennison [SMTP:robren@laurelnetworks.com]
Sent:   Sunday, July 16, 2000 2:57 PM
To:     Lou Berger
Cc:     Chatterjee, Shash; MPLS Mailing-list (E-mail)
Subject:        RE: draft-ashwood-generalized-mpls-signaling- (was Re: Optical MPLS)

Lou,

I believe that any confusion is  caused by the following  statement in
section
3.2.2.

"The presence of both a generalized and normal label object in a
Path/REQUEST message is a protocol error and should be treated as a
malformed message by the recipient."

This explicitly states that only the presence of _both_ the
generalized and normal label object is a Path/REQUEST message is an error.

This did seem like an odd statement, why would you worry about both of
the label and generalized label being in the Path/REQUEST message.

I therefore inferred that the generalized label could be used in
the Path/REQUEST message to hint to the downstream node the upstreams
preference, in essence the functionality you have with the separate object
called the Suggested Label.

I am curious, why did you specify a new TLV, the suggested label, which is
identical to that of the generalized label, instead of
merely allowing the generalized label to be sent in the downstream direction
to achieve this functionality. Error handling procedures perhaps ?

There is precedent in other signaling protocols for overloading of the
generalized label TLV,
 consider the mechanism in ATM signaling, whereby the user side
of a Q.2931 link was allowed to include the connid info element in the
initial
SETUP message. This was also the technique used in non-facility associated
signalling.

Regards.

Rob

---------------
Robert Rennison

Laurel Networks
Ph:  (724) 933-7330
Fax: (724) 933-3377
robren@laurelnetworks.com