Subject: RE: BNF for GMPLS path message (was Re: draft-gray-mpls-rsvp-oif- uni-ext)

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

Lou,

	Now, if you just put the SUGESTED_LABEL 
back together with the LABEL_SET, you will have
what we had originally. 

	:-)

	What application do you have in mind for
using both a SUGESTED_LABEL and a LABEL_SET?
Semantically, there's nothing non-sensical about
having both, but the suggested applications for 
each are fairly diverse.

--
Eric Gray

> -----Original Message-----
> From: Lou Berger [mailto:[email-masked]]
> Sent: Monday, September 18, 2000 3:01 PM
> To: Adrian Farrel
> Cc: Lou Berger; [email-masked]; [email-masked]
> Subject: RE: BNF for GMPLS path message (was Re:
> draft-gray-mpls-rsvp-oif- uni-ext)
> 
> 
> At 05:20 PM 9/18/00, Adrian Farrel wrote:
> >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?
> 
> It's the same class so you can only have one.  I think the 
> generalized one 
> c-type = 5 can always be used.
> 
> >Is it also right to add <LABEL_SET> to
> ><sender descriptor> ?
> 
> Woops, not that got missed.
> 
> I think location is arguable either way, but I believe 
> outside the sender 
> description is preferable (for other message processing).  My 
> suggestion is:
> 
>         <Path Message> ::=       <Common Header> [ <INTEGRITY> ]
>                                  <SESSION> <RSVP_HOP>
>                                  <TIME_VALUES>
>                                 [ <EXPLICIT_ROUTE> ]
>                                  <LABEL_REQUEST>
>                                  <LABEL_SET>
>                                  [ <SESSION_ATTRIBUTE> ]
>                                  [ <POLICY_DATA> ... ]
>                                  <sender descriptor>
> Lou
> 
> 
> >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:23:02 -0400

>back together with the LABEL_SET, you will have

yes, but they are both needed as they serve different purposes.

>using both a SUGESTED_LABEL and a LABEL_SET?

LABEL_SET limits the label space that can be used by the downstream 
node.  If none of the labels are acceptable, the downstream node responds 
with an error.  See section 3.5 of 
draft-ashwood-generalized-mpls-signaling-00.txt for a description where 
this is anticipated to be useful.

SUGGEST_LABEL is just that, a suggestion.  If the downstream node doesn't 
like the suggestion, it can choose whichever label it considers to be 
available.  The purpose of the suggested label is to reduce hardware setup 
time in the upstream node.  See section 3.4 of the draft for more info.

>having both, but the suggested applications for

One is for latency, the other is for limited switching capabilities...

Lou