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

["Ong, Lyndon" <[e-mail]>]

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