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:01:15 -0700

Lou,

	Actually, there is nothing in the generalized
signaling draft to indicate _where_ in a PATH message
SUGGESTED_LABEL or UPSTREAM_LABEL are supposed to be.
We will happily align the RSVP UNI signaling draft to
conform to the generalized signaling draft if/when it
does include this information.

	Why do you feel that they should be part of the 
Sender Descriptor?

> -----Original Message-----
> From: Lou Berger [mailto:[email-masked]]
> Sent: Monday, September 18, 2000 1:53 PM
> To: Adrian Farrel
> Cc: [email-masked]; [email-masked]
> Subject: BNF for GMPLS path message (was Re:
> draft-gray-mpls-rsvp-oif-uni-ext)
> 
> 
> 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:06:44 -0400

>SUGGESTED_LABEL or UPSTREAM_LABEL are supposed to be.

Eric,

You're right.  This should be corrected.

>does include this information.

The next rev will have it.  (Assuming I can influence the next rev ;-)

>         Why do you feel that they should be part of the

Because then it automatically gets included in other messages, in 
particular the PathErr msg.

Lou