The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2000-Sep> msg00199



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

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

  • From: Eric Gray <EGray@zaffire.com>
  • Date: Mon, 18 Sep 2000 15:24:43 -0700
  • Cc: Eric Gray <EGray@zaffire.com>, mpls@UU.NET

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:lberger@labn.net]
> Sent: Monday, September 18, 2000 3:01 PM
> To: Adrian Farrel
> Cc: Lou Berger; egray@zaffire.com; mpls@UU.NET
> 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:lberger@labn.net]
> > >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:af@datcon.co.uk
> > >>Network Convergence Group
> > >>Data Connection Ltd., Chester, UK
> > >>http://www.datcon.co.uk/
> > >>Tel: +44 (0) 1244 313440  Fax: +44 (0) 1244 312422
> > >
>