Subject: RE: draft-ashwood-generalized-mpls-signaling- (was Re: Optical MP LS)

From: "Peter Ashwood-Smith" <[email-masked]>
Date: Sun, 16 Jul 2000 23:32:35 -0400

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:[email-masked]]
	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
	[email-masked]

---

From: Lou Berger <[email-masked]>
Date: Mon, 17 Jul 2000 07:21:12 -0400

One additional point that makes the different objects a requirement (at 
least for RSVP): error processing is different for the two objects.

Per the draft:
         Generalized Label Class Num = 19 [of form 0bbbbbbb]

         [...]
         In RSVP the Suggested Label uses a new class number (TBD of
         form 10bbbbbb) and the C-type of the label being suggested.
         [...]

See RFC2205 if unclear on the implication of the two forms.

Lou

At 11:32 PM 7/16/00 -0400, Peter Ashwood-Smith wrote:
>[...]
>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:[email-masked]]  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,
>
>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.
>
>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 ?
>
>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  [email-masked]