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

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

Hi Dimitri,

Thanks for your responses.  I meant AS=Applicability Statement. 

As far as the Association Object, I understand from the definition
that this is serving a different purpose, however a separate object
(different from the Association Object) could still have some
advantage compared to using an existing field in the Session object.

Was not sure what you meant by call blocking based on informational
data - does this mean that you want to avoid the possibility that
a call will be rejected based on Link_Capability by making it
always flexible as to whether it is sent?

Thanks,

Lyndon

-----Original Message-----
From: Dimitri.Papadimitriou@alcatel.be
[mailto:Dimitri.Papadimitriou@alcatel.be] 
Sent: Saturday, June 17, 2006 2:32 AM
To: Ong, Lyndon
Cc: Adrian Farrel; ccamp@ops.ietf.org; owner-ccamp@ops.ietf.org
Subject: RE: Working Group Last Call on
draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt

lyndon - see in-inline

Again, thank you for your detailed response.  I had the following
thoughts:

-- regarding the format for Long Call ID, if there is to be an AS on the
use of the draft, a reference to G.7713.2 would be good.
A reference in the draft itself might be simpler, though.  References to
other Call ID formats could also be added, if desired.

[dp] - what do you mean by "is to be an AS on the use..."

-- on the issue of the Session Object processing, I see your thinking as
to why an implementation should not zero out the Short Call ID subfield,
but the draft itself notes that some implementations interpret RFC 3209
to mean the field is zeroed out due to the labeling of the field "MUST
be zero" in 3209.

Why not use a separate object for the Call ID, along the lines of the
Association object?  That would separate processing of the Call ID from
the Session object, and might fit the ASON model better by separating
Call information from LSP information.

[dp] already discussed see

<https://ops.ietf.org/lists/ccamp/ccamp.2006/msg00209.html>

answer:

"association object associates by definition LSPs (using per-sender node
identifier and address) on the other side a call creates an association
between end-points by which subsequent LSPs may be made (call ids are
unique within the context of the pair of addresses that are the call
source and destination)"

-- on the LINK_CAPABILITY object, I may have missed it in the text, but
I did not see a way for a source node to request the destination node to
send its LINK_CAPABILITY back, that would be useful. 

[dp] it is a local policy decision, in both ways - leaves flexibility
and does not create additional call blocking on informational data from
the protocol perspective 

Also, shouldn't the object be forwarded if not recognized, and not
discarded?

[dp] you refer to the class-num, because when the notify message travels
end-to-end a non-supporting receiver just discard it; keep in mind that
the dest address of the notify message is a routable egress node address

-- One new question: "Simultaneous call and connection establishment
(sometimes called piggybacking) is not supported" in section 5.1 - does
this mean it may be supported in future, or is not considered possible
or desirable?

[dp] the latter v 

Cheers,

Lyndon