[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,
I apologize for responding on the last day, but my schedule kept me from
looking at this sooner.
Some responses in-line.
Regards,
Ben
> -----Original Message-----
> From: Adrian Farrel [mailto:adrian@olddog.co.uk]
> Sent: Monday, June 19, 2006 9:19 AM
> To: Mack-Crane, T. Benjamin; Brungard, Deborah A, ALABS;
> ccamp@ops.ietf.org
> Subject: 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.
OK. I was just commenting, as an outsider, on the relatively confusing
semantics of the result.
>
> 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.
It is not clear how the form of initiation of a call affects the
information available about the egress link. In part this may be
affected by whether the ingress node is inside or outside the network
(IGP) boundary. It would seem that the situation at the egress would
have something to do with this as well. It is unclear where the egress
trail termination point is expected to be, e.g. inside or outside the
network boundary, and, if inside, at the near or far side of the egress
node's matrix.
This may just be me having trouble parsing the text, which is why I
thought a picture would help (e.g. showing the ingress/egress nodes,
location of trail terminations, location of network boundary or
reference points, like UNI or NNI or unsignaled interface, etc.). I
can't propose text or figures because I am unsure what point is being
made 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").
>
> 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.
A call is defined as "an agreement between endpoints" and any connection
entails an agreement to be connected (as a connection request can be
rejected by the egress endpoint). In the case of "connection setup
without a call" the terms of the agreement are implicit or commonly
understood. For example, primary and secondary LSPs belong to the same
call, but do not require a separate call setup. It is not such a
stretch to think that some common cases may benefit from carrying call
request information in the connection request rather than requiring an
additional protocol exchange to do this. On the other hand, ...(see
below)
>
> 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.
One could start with the general case, and only optimize later if clear
benefits can be realized. So I understand your point here.
>
> >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?
Networks don't worry me, but it is useful to support address
independence in operator networks. I'm not sure where my understanding
went wrong (separate address spaces and/or other than IP addressed
endpoints). I suppose that's an exercise for the reader.
>
> Thanks,
> Adrian
============================================================
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
============================================================