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

[Dimitri.Papadimitriou@alcatel.be]

lyndon - some hints:

1: not ASON specific; hence such pointer in the applicability doc

2: not sure to understand the question -what is this a) or b) that you're 
referring to - for the first sub-item see section 6.2.2 for the second see 
section 8.2
 
3: during call setup & as described in section 6.7

4: this "a la ResvConf" process is recommended, if the problem persist 
(meaning "empty" call) apply 6.6.5 procedure upon local policy 

5: recommended (and much simple) - note: 6.6.4 ensures no problem can 
arise

-d.





"Ong, Lyndon" <Lyong@Ciena.com>
Sent by: owner-ccamp@ops.ietf.org
15/06/2006 17:52
 
        To:     "Brungard, Deborah A, ALABS" <dbrungard@att.com>, 
<ccamp@ops.ietf.org>
        cc:     "Adrian Farrel" <adrian@olddog.co.uk>
        Subject:        RE: Working Group Last Call on 
draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt


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