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

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

hi Dimitri,

Yes, I recall the plan that Adrian and you presented, of a two
draft approach to the signaling issues.  Is there a schedule
for the second (applicability) draft?

Thanks,

Lyndon 

-----Original Message-----
From: Dimitri.Papadimitriou@alcatel.be
[mailto:Dimitri.Papadimitriou@alcatel.be] 
Sent: Friday, June 16, 2006 11:07 AM
To: Ong, Lyndon
Cc: Adrian Farrel; ccamp@ops.ietf.org; Brungard, Deborah A, ALABS;
owner-ccamp@ops.ietf.org
Subject: RE: Working Group Last Call on
draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt

lyndon -

- did you read them attentively ? -

if yes, you will see that the first question you asked on the list is
not to be addressed as part of this process but when the protocol
operations are going to be detailed as part of a document that will
describe ASON signaling using GMPLS RSVP-TE (as discussed during IETF 63
& 64)







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


Hi Dimitri,

I appreciate the hints as well, but Adrian has given a more detailed
email response before I had the chance to look up the cross-references
from your email :o)

Sorry about the "a)" and "b)" - forgot to label the dashed items in the
email with letters.

Cheers,

Lyndon 

-----Original Message-----
From: Dimitri.Papadimitriou@alcatel.be
[mailto:Dimitri.Papadimitriou@alcatel.be] 
Sent: Thursday, June 15, 2006 10:44 AM
To: Ong, Lyndon
Cc: Adrian Farrel; ccamp@ops.ietf.org; Brungard, Deborah A, ALABS;
owner-ccamp@ops.ietf.org
Subject: RE: Working Group Last Call on
draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt

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