[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 Ben,
Welcome to the debate.
I looked over this draft over the weekend and I have some
comments and questions.
Many thanks.
Responses in line.
1) It is hard to understand why a new feature (call control)
is being designed as an extension to a notification message.
The resulting protocol design obscures the function of the
protocol and creates special case processing that may lead
to problems. Is there a reason that new message types were
not specified for call request and response?
Strong words!
Actually we did discuss defining a new message following the model of
G.7713.3, but we decided that the scope of the Notify message already
includes end-to-end communication, negotiation and notification, and that
this was consequently within scope of the Notify message.
Speaking as an author of this work, it is a little frustrating to have you
wait until the last day of the working group last call to comment in this
way on a protocol process that has been around the working group for a
considerable time. In my view (speaking as an author) I don't think that WG
last call should be used in this way.
2) Given the stated intent of maintaining strict independence
between call and connection control, were other (existing) call
control protocols considered (rather than beginning a new call
control protocol specification)?
Yes. Very much so.
But, the title of the I-D is "Generalized MPLS (GMPLS) RSVP-TE Signaling
Extensions in support of Calls" so obviously this draft wouldn't discuss
that sort of thing.
If you have other proposals for handling calls through other protocols, I'm
sure that you could write an applicability I-D in CCAMP if no modifications
to the protocol are required, or take your proposals for changes to the WG
that owns the proposed protocol.
3) The network models being used in section 4.3 and section 7 are
not clear. In particular the relationships between the call
controllers, network boundaries, ingress/egress nodes, and
ingress/egress links are not clear. Figures would be very helpful here.
Figures are always helpful, and usually (but not always) better than words.
In order to be sure to clarify the network models that you are finding
confusing, it would be helpful if you asked specific questions or proposed
text.
4) Simultaneous Call and connection establishment can
be very handy in the common case of a call with a single
connection. This model should be supported (and in fact
it is in the case of so called "connection setup without a
call").
Two points:
a. "Connection setup without a call" cannot, by any stretch of the
imagination, be considered to be "simultaneous call and connection
establishment". How could it? If there is no call established, the call
cannot be established simultaneous to anything.
b. Simultaneous Call and Connection setup could have some uses on single hop
connections where (as you say) there is a single connection per call. But
this seemed to be a very limited subset of requirements.
- What about supporting more than one conneciton per call? This must always
be available within the solution.
- What about connecitons that span more than one hope? This, too, must
always be available within the solution.
Following the oft-quoted (and reasonable) design premise that you do not
optimise for special cases, we have built a solution that can handle all of
the required network configurations yet fits within the defined
requirements.
RFC 4158 is pretty clear on the requirements that call and connection
separation is required, while (if I recall the reference correctly) G.7713
says that solutions can choose to use simultaneous call and connection setup
or not. We chose "not" because of the clear architectural benefits.
5) The call control mechanism defined appears to support
only IPv4 or IPv6 addressed endpoints from a single address
space. Is this correct?
I don't think so. Can you give an example of a network that is worrying
you?
Thanks,
Adrian