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

From: Eric Gray <[email-masked]>
Date: Mon, 18 Sep 2000 16:16:55 -0700

Adrian,

	We will align with the use of TIME_VALUES in
the latest version of RSVP-TE in the next iteration
of this draft.

	On use of the Ack message (as opposed to the
Notify message), Jonathan Lang already pointed this
out.  We will be simply omitting the reference, since
we already state that the messages are Ack'd IAW Lou's
Refresh Reduction draft.  But thanks for reminding me. :-)

	Yes, the propagation delay object is - as far as
I know - wholly new.  It comes from Optical UNI signaling 
requirements (draft-bala-mpls-optical-uni-signaling-00).
As for what it looks like, it should be straight-forward 
since the description is:

"6.3.2  Service-Related
   ...
   5. Propagation delay: This specifies the maximum acceptable
      propagation delay in milliseconds.  Defaults to infinity."

We will be working with the folks doing the corresponding
CR-LDP UNI signaling draft to come up with a reasonably
consistent format - give that it should be simple.

--
Eric Gray

> -----Original Message-----
> From: Adrian Farrel [mailto:[email-masked]]
> Sent: Monday, September 18, 2000 1:27 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: draft-gray-mpls-rsvp-oif-uni-ext
> 
> 
> 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
>