The MPLS WG Archive

["Robert Rennison" <robren@laurelnetworks.com>]

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