RE: Working Group Last Call on draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt

["Ong, Lyndon" <Lyong@Ciena.com>]

Hi Deborah,

 

Sorry for the lateness of the comments, but the draft is quite detailed.  Some

of the questions I have are more on the thought behind the procedures than

the correctness of the procedures.

 

General Comment:

 

Not sure whether this is part of WG Last Call or not, but I certainly think it would be good

to pass this through ITU Q.12 and Q.14/15 before it is submitted to the IESG, so that the

definitions and procedures for call can be reviewed for any inconsistencies.  Hopefully we

will in that way avoid having multiple definitions or defining procedures that do not fit what

is desired for ASON.

 

I leave it to you and Adrian as to the right way to go about doing this.

 

More Detailed Comments:

 

1. Although the draft does not define a format for the Long Call ID, a format has been

defined in ITU-T Recommendation G.7713.2, and it might be worth pointing to this.

 

2. Want to be sure I understand the procedures for the Short Call ID. Since the field is labeled

"MUST be zero" in RFC 3209, there could be multiple interpretations:

-- a non-zero value will be received and discarded (zero inserted on transmission)

-- a non-zero value will be treated as an error and generate an error response

-- a non-zero value will be treated as an error and the message discarded

 

It's noted in section 7 that the only way to successfully create

an LSP through a transit node following behavior's (a) or (b) above would be to upgrade

the LSP - does this mean you could potentially have successful call setup but failure

of the associated connection setup if the transit LSP behavior is not correct?

 

3. Are there procedures for when to send a LINK_CAPABILITY object?  It seems to

be totally optional at both ends.  Is this determined by policy?

 

4. Why is the procedure in section 6.2.1 that the responding side should assume that the call is successful

if it does not receive an ack to its Notify message? 

 

5. Is refresh of the NOTIFY really necessary if there are active LSPs in the call?  Possibly the LSP refresh

could be sufficient, since this carries the short Call ID.  Is it possible that the call would be dropped while

there are still active LSPs?

 

Cheers,

 

Lyndon