[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,


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.


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.



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