[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Hi Adrian,

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.

-- 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.

-- 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.  Also, shouldn't
the object be forwarded if not recognized, and not discarded?

-- 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?


Cheers,

Lyndon