Subject: Re: draft-gray-mpls-rsvp-oif-uni-ext

From: Eric Gray <[email-masked]>
Date: Mon, 18 Sep 2000 15:19:02 -0700

Adrian,

	For the RSVP Optical UNI specification, the
PATH message MUST contain GENERALIZED_LABEL_REQUEST
(as opposed to LABEL_REQUEST).

	I believe that SUGGESTED_LABEL and LABEL_SET
should be listed in the same place (whether that's
in Sender Descriptor or not).  I am curious if many
people feel that it should be possible to include 
both a LABEL_SET and a SUGGESTED_LABEL in the same 
PATH message.

	Also, it is not clear in the generalized 
signaling draft that GENERALIZED_LABEL_REQUEST and
SUGGESTED_LABEL are mutually exclusive - though it
is possible to make this true since the format is
the same.  This would require that the (G)LSR is
able to recognize either.  It would also introduce
a small problem (relative to Lou's suggestion) as
to where each of the two belong.  It might be an
unreasonable complication to expect an implementation
to look for either a GLR in the main body of the PATH
message or a SL in the Sender Descriptor part of the
PATH message.

--
Eric Gray

> -----Original Message-----
> From: Adrian Farrel [mailto:[email-masked]]
> Sent: Monday, September 18, 2000 2:21 PM
> To: Lou Berger
> Cc: [email-masked]; [email-masked]
> Subject: RE: BNF for GMPLS path message (was Re:
> draft-gray-mpls-rsvp-oif- uni-ext)
> 
> 
> Thanks Lou,
> That makes some sense.
> 
> For <LABEL_REQUEST> should I read
> <LABEL_REQUEST> | <GENERALIZED_LABEL_REQUEST> or
> are some of the fields of GLR sufficiently 
> specific to the sender for that object to need to
> be in the sender descriptor?
> 
> Is it also right to add <LABEL_SET> to 
> <sender descriptor> ?
> 
> Adrian
> 
> >From: Lou Berger [mailto:[email-masked]]
> >Sent: Monday, September 18, 2000 9:53 PM
> >
> >Adrian,
> >         My understanding of the BNF for Path based on the 
> generalized 
> >draft is:
> >
> >
> >       <Path Message> ::=       <Common Header> [ <INTEGRITY> ]
> >                                <SESSION> <RSVP_HOP>
> >                                <TIME_VALUES>
> >                               [ <EXPLICIT_ROUTE> ]
> >                                <LABEL_REQUEST>
> >                                [ <SESSION_ATTRIBUTE> ]
> >                                [ <POLICY_DATA> ... ]
> >                                <sender descriptor>
> >
> ><sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC>
> >                     [<ADSPEC>] [<RECORD_ROUTE>]
> >                                [ <SUGGESTED_LABEL> ]
> >                               [ <UPSTREAM_LABEL> ]
> >
> >It was in the draft and was removed due to lack of parity 
> between the 
> >protocols.  Obviously it needs to be in the eventual RSVP 
> related spec.
> >
> >Lou
> >
> >At 04:26 PM 9/18/00, Adrian Farrel wrote:
> >>Hi Eric,
> >>
> >>Thanks for this draft, it pulls things together nicely and 
> >>shows how simply UNI can be performed with existing protocols.
> >>
> >>I have just a couple of questions.
> >>
> >>Is the Propagation Delay object wholly new?  Have you any 
> >>plans for what it looks like?
> >>
> >>In sections 3.4 and 5.4 (which need renumbering :-)  you use 
> >>a Notify to expedite the acknowledgement of a Tear if there 
> >>is no suitable message on which to piggy-back the Ack.  Why 
> >>did you choose this rather than an Ack message?  The Ack 
> >>message exists for exactly this purpose, while the Notify
> >>requires an Error_Spec.
> >>
> >>I believe you may have cut and pasted a typo from
> >>draft-ietf-mpls-rsvp-lsp-tunnel-06.txt.  George has fixed
> >>this in v7.  TIME_VALUES should be mandatory on Path and Resv
> >>
> >>Lastly, I'm not sure that the format you have given for the 
> >>Path is quite correct with regard to the GLR, LS and SL 
> >>objects.  Since my version of GMPLS doesn't have anything 
> >>specific to say on the subject I can only piece it together
> >>from the text...
> >>- I don't think you can have Generalized Label Request
> >>   and suggested label on the same Path message.
> >>- I think Label Set supplements both Generalized Label
> >>   Request and Suggested Label.
> >>
> >>This (and the previous point) would give
> >>
> >>  <Path Message> ::=  <Common Header> [ <INTEGRITY> ]
> >>                      <SESSION> <RSVP_HOP>
> >>                      <TIME_VALUES>
> >>                      [ <EXPLICIT ROUTE> ]
> >>                      <GENERALIZED LABEL_REQUEST> | 
> <SUGGESTED LABEL>
> >>                      [ <LABEL SET> ]
> >>                      [ <UPSTREAM LABEL> ]
> >>                      [ <SESSION_ATTRIBUTE> ]
> >>                      [ <POLICY_DATA> ... ]
> >>                      <sender descriptor>
> >>
> >>Regards,
> >>Adrian
> >>--
> >>Adrian Farrel  mailto:[email-masked]
> >>Network Convergence Group
> >>Data Connection Ltd., Chester, UK
> >>http://www.datcon.co.uk/
> >>Tel: +44 (0) 1244 313440  Fax: +44 (0) 1244 312422
> >
>

---

From: Lou Berger <[email-masked]>
Date: Mon, 18 Sep 2000 19:11:59 -0400

At 06:19 PM 9/18/00, Eric Gray wrote:
>in Sender Descriptor or not).

Why.  (I think the position of Label_set is arguable either way.  I'm just 
curious about your reasons.)

>I am curious if many

They serve *very* different purposes, so I'd phrase it the other way 
around.  Why would you not permit both?

>the same.

I think there's a mistype here.  GENERALIZED_LABEL_REQUEST and
SUGGESTED_LABEL have very different formats and server different 
purposes.  What am I missing?

Lou

>This would require that the (G)LSR is