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

["Mack-Crane, T. Benjamin" <Ben.Mack-Crane@tellabs.com>]

Hi Adrian,

See in-line.

Regards,
Ben

> -----Original Message-----
> From: Adrian Farrel [mailto:adrian@olddog.co.uk]
> Sent: Wednesday, July 19, 2006 8:26 AM
> To: Mack-Crane, T. Benjamin
> Cc: ccamp@ops.ietf.org; Brungard, Deborah A, ALABS
> Subject: Re: Working Group Last Call on
draft-ietf-ccamp-gmpls-rsvp-te-
> call-00.txt
> 
> Ben,
> 
> Sorry for the delay while travelling, etc.
> 
> > Hi Adrian,
> >
> > There were also these comments which have not been fully addressed
> > afaik:
> >
> >>> 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
> >> roposed 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.
> 
> You have latched on to an important point. The information about the
> egress
> link might not be generally available within the TED particularly when
the
> egress node is outside the TE domain (although we should observe some
of
> the
> recent discussions about OSPF and BGP extensions for advertising PE-CE
> link
> TE capabilities).
> 
> And, in fact, this is an important purpose of the Call, and why the
Link
> Capability object exists. The Link Capability object may be used
> when the tail-end is within or outside the the TE domain, and so we
> support
> the egress (and correspondingly the ingress) being inside or outside
the
> TE
> domain. This follows quite naturally from RFC 4208.
> 
> We could add a statement that the ingress and egress may be inside or
> outside the TE domain if this will make you more comfortable.

It is, I think, obvious that the ingress and egress may be inside or
outside a TE domain.  What is not so obvious is the need for the Link
Capability object, i.e. exactly what problem it is solving.  On reading
the draft, this was not at all clear to me.  Unfortunately I had
sufficient difficulty understanding the problem statement that I did not
immediately question the need for the object (hoping that clarification
of the problem would shed light on this).  However, if the policy in
CCAMP is that revising the text is not necessary as long as the intended
meaning is clear to the authors... then perhaps there is nothing to be
added (or subtracted;-) at this point.

> 
> >> >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.
> >
> > I would be interested to know how to correctly understand the draft.
> > That is, what addressing other than IPv4/6 is supported, and how
> > multiple address spaces are supported.
> 
> Hmmm. Perhaps an issue of punctuation in your original question?
> 
> Yes: we only support IPv4 or IPv6 addresses.
> No: we don't require the use of a single address space, as discussed
in
> RFC
> 4208.

OK, thanks for clarifying.

> 
> Hope that answers for you.
> 
> Regards,
> 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
============================================================