Last call comments: draft-ietf-tewg-interarea-mpls-te-req-01.txt

Hi Jean-Louis et al,

I have reviewed the above draft quite carefully, and it is
a very useful document. Nice work!

There are several comments I have as part of last call, I'm
giving these below as technical and editorial, to make discussion
easier.

Thanks,
-Vishal
********************************************************************8

Technical
-----------

1. Sec. 1, Introduction.
"The set of MPLS traffic engineering tools," is probably better worded
as "The set of MPLs traffic engineering components," as the
phrase "MPLS traffic engineering tools" is liable to be confused
with planning and traffic engineering tools/software (a la
Netscope, NPAT, SPGuru, MATE, etc.).

2. In the same section, how are the components useful for
aggregated traffic measurement?
Is it because, OSPF-TE and IS-IS TE may be used to convey
parameters like aggregate link utilization? What else is
included here?

3. It would be good to have terms like "traffic engineering components",
"traffic engineering mechanisms" and "traffic
engineering tools" defined in the terminology section to
clear distinguish between them, and avoid confusion when
reading and interpreting this document.

4. Sec. 4.1.3, para 1, not sure what "traffic sensitive
applications" means. It might be better worded as "performance
sensitive applications" or "quality sensitive applications."

5. Sec. 4.2, option 3, it would be nice to have a phrase
explaining why this is different than LSP hierarchy.

6. Sec. 6, para 4, "pseudo wire connections" should really be
just "pseudo wires"

7. Sec. 7.2, I tend to agree with Adrian that (ideally) it
would seem it should be enough for the head-end to signal
the function/service it wants and not the underlying method
used by nodes further in path to provide that service.
If, as you mention, this is a requirement expressed by
many SPs, it would be good to understand why it is so, and
for the document to explain a bit about it.

8. Sec. 7.3 on path optimality talks only of the optimality
of a single path computed in isolation. What is the definition
of optimality to be applied for computing diverse paths?
(Sec. 7.7 later does not specifically discuss this aspect either.)
If one used CSPF in sequence to compute two diverse paths
(as this section would imply) then the computation may fail, even
though a set of optimal diverse paths exists (as acknowledged in
Sec. 7.7 ahead).

9. Sec. 7.4 "Inter-area MPLS TE Routing" I would like to
underscore Adrian's point on specifying the scaling requirements
themselves (with respect to areas, amount of flooded info. etc.)
rather than the realization of those requirements (by not adding
any info. to the LSAs, for example).

If solutions can meet the scaling requirements by adding a bit of
info. to the IGP, I think this should be allowed, otherwise
there is really not much that could be achieved using current
mechanisms (since no modifications to them seem permissible, and
we already established that these, as they exist, do not provide
for adequate inter-area MPLS TE).

BTW, one of the points made in this regard in these
email thread was about the use of path computation servers,
which can supposedly compute optimal paths without any impact on
the IGP.

I think this argument isn't quite complete, since it hides the
signaling extensions required for these as well as the
scalability impact of recursive PCE-type schemes (btw, this was a
question that came up in independent discussions with JP in the
context of the ARO and PCE schemes, and is still under discussion).

10. Sec. 7.6, the figure O(N^2) makes the assumption that
each of the N ARBs at the border of the neighboring areas is
connected to each other ABR. No?
In reality, the number of crankback's may be significantly less
therefore.

11. Sec. 7.7, I guess it would be useful to qualify what is
considered "extra-load" in signaling and routing here.
Is that to be interpreted as _absolutely no change_ to
current signaling and routing protocol objects?
Clearly, that doesn't seem feasible, if inter-area routing/TE
is to be achieved, so something more specific is implied, which
would be good to spell out.

BTW, also tend to agree with Adrian's point that this section
seems to be describing the computation of diverse paths rather
than the establishment of diverse paths, which would seem to
be the requirement.

12. Sec. 7.9, what is meant by "inter-area head end LSR"?
An LSR that is the head-end of an inter-area LSP (that is, an
LSP traversing multiple areas)?

13. Sec. 8.2, not sure that is providing a real measurable
evaluation criterion. If it is to be kept, some specifics
should probably be given.


Editorial
-----------

Below phrases between _xxxx_ are added, and between <xxxx> are
to be removed.

1. Sec. 1, Introduction, ", that supports ..." --> "which supports ..."

2. Sec. 4, para 1, line 4, "This section is intended to help
_in_ defining ..."

3. Sec. 4.1.1 --> "Intra-area _resource_ optimization"

4. Sec, 4.1.1. line 1 --> "MPLS-TE can be used within an area to redirect
paths of aggregated flows away from over-utilized resources within a
network."

5. Sec. 4.1.1., para 2 -->
"In this way, MPLS-TE allows for greater control _over_ how traffic
demands _are routed over_ <utilize> a network topology, and _utilize
a network's resources_"

5. Sec. 4.1.1., para 2 --> "As mentioned in Section 1, uses
   to date have been limited to <within> a single IGP area."

6. Sec. 4.2, option 4, what are the numbers (2) and (3) in brackets?

7. Sec. 5.1, para 6, "one possible approach could consist _of_ deploying
..."

8. Sec. 5.2, I am not sure why there is a small subsection itself titled
"Requirements for inter-area MPLS TE", when the entire document is about
this subject? Is the intent here to motivate the need for inter-area MPLS
TE?
If so, maybe it should say "Motivations for inter-area MPLS TE"?

These a few of the ones that I caught. In general, I feel the document
would benefit from a thorough editorial review of writing, that would
help to eliminate some awkward constructions and redudancy in several
places.