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

From: "Mack-Crane, T. Benjamin" <[email-masked]>
Date: Wed, 19 Jul 2006 13:37:14 -0500

Hi Adrian,

See in-line.

Regards,
Ben

> -----Original Message-----
> From: Adrian Farrel [mailto:[email-masked]]
> Sent: Wednesday, July 19, 2006 8:26 AM
> To: Mack-Crane, T. Benjamin
> Cc: [email-masked]; 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
============================================================

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 20 Jul 2006 19:55:29 +0100

Hi Ben,

>>>> than words.
>>>> finding confusing, it would be helpful if you asked specific
>>>> questions or proposed text.
>>>
>>> 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).
>>
>> 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.
>>
> 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.

Thank you for your courteous and professional comments.

You appear to be making two comments in this paragraph.
1. The problem statement for the I-D is not sufficiently clear.
2. The requirements for (and use of) the Link Capabilities
   object are not clear.

As I said before, it remains a very hard conversation if you simply say "I 
don't understand". I can try to rephrase the text for you, but this does not 
necessarily get us any closer. Asking specific questions is a much more 
efficient way of establishing what is missing from the draft and allowing us 
to rephrase it as necessary. Alternatively we may discover that someone's 
understanding (yours or ours) is misplaced, and we can act accordingly.

With respect to the problem statement for the I-D. We can break it down into 
pieces.

- Definition of a call.
   I hope the definition provided in Section 1 is clear.
   It borrows heavily from the phraseology used within the ITU-T,
   and cites ASON as an example.
   Section 4 goes into even more detail and is (hopefully) complete.
- Requirements to support calls.
   This is a little harder to pin down. What we assumed was
   that if the definition of a call could stand on its own, then
   it could be taken for granted that there was a need to support
   calls. Perhaps this is a mistake, do you think we need to add
   further description of why calls should be supported in
   GMPLS?
- What the document does.
   This is, I think, quite clear. The first sentence of the Introduction
   says it all...
   This document defines protocol procedures and extensions to
   support Calls within Generalized MPLS (GMPLS).

We should also try to examine the detailed requirements listed in section 3. 
The requirements here are stated as bald facts without supporting evidence. 
In my opinion, this is usual in this type of document, but I wonder if this 
is the cause of some of your concern. Are there some requirements listed 
here that leave you wondering why they are requirements?

With regard to the purpose and use of the Link Capabilities object, this is 
driven mainly by the material in section 4.3. The requirement is, as the 
text says, to allow the ingress of a connection to know information about 
the final link that the connection will traverse, so that it can tune the 
connection request to have a better chance of success and to make best use 
of the network and link resources.

As you'll see from reading the section, the Call may be a mechanism for 
exchanging information about the final link, but it is not the only 
mechanism, and in some scenarios the Call does not need to carry the 
information because it is already available. Thus, the Link Capability 
object, introduced in section 4.3, is available for use during Call setup, 
but is not mandatory.

Now, I realise that all I have done here is restate and rephrase the text in 
the I-D in an attempt to help clarify things to you. Perhaps we can now take 
this process forward by understanding more clearly what it is you want 
clarified so that we can work on the text. But I repeat that simply saying 
that you have difficulty understanding the problem statement won't get us 
anywhere. What don't you understand? What are your questions?

Thanks,
Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 20 Jul 2006 19:55:29 +0100

Hi Ben,

- Definition of a call.

Thanks,
Adrian