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

From: "Mack-Crane, T. Benjamin" <[email-masked]>
Date: Mon, 19 Jun 2006 01:49:10 -0500

Hi,

I looked over this draft over the weekend and I have some comments and
questions.

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?

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

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.

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

5)       The call control mechanism defined appears to support only IPv4
or IPv6 addressed endpoints from a single address space.  Is this
correct?

Regards,

Ben

________________________________

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Brungard, Deborah A, ALABS
Sent: Monday, June 05, 2006 5:10 PM
To: [email-masked]
Cc: Adrian Farrel; Brungard, Deborah A, ALABS
Subject: Working Group Last Call on
draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt

All,

As discussed at the last CCAMP meeting, the authors of this draft would
like the draft to be considered for WG Last Call. Although it appears to
be a 00 draft, the material was previously in
draft-ietf-ccamp-gmpls-te-ason-03.txt. At least one implementation
exists.

This email begins a two week Working Group Last Call on the draft:

ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-rsvp-te-call-00
.txt

The last call will complete on June 19th at 9PM EST.

Comments should be addressed to the mailing list or, if anonymity is
preferred, to me. On a point of procedure, as both Adrian and myself are
co-authors, anyone who has an issue with this draft going to WG Last
Call should contact one of our ADs, Ross ([email-masked]) or Bill
([email-masked]).

Thanks,

Deborah

 t

============================================================
The information contained in this message may be privileged
and confidential and protected from disclosure. If the reader
of this message is not the intended recipient, or an employee
or agent responsible for delivering this message to the
intended recipient, you are hereby notified that any reproduction,
dissemination or distribution of this communication is strictly
prohibited. If you have received this communication in error,
please notify us immediately by replying to the message and
deleting it from your computer. Thank you. Tellabs
============================================================

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 19 Jun 2006 14:18:59 +0100

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.

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

> 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