Re: MPLS Inter-area TE requirement draft

[Jim Boyle <jboyle@pdnets.com>]

Jean Philippe and Jean Louis,

I have read the draft of you and your 6 co-authors, I am happy that you
now also agree that inter-area is important to consider (especially if
inter-as is!).  With 7 authors, including 2 editors, I am a bit amused
that your references section seems out of sorts, you or your co-editor may
want to cross-check them.  You may also want to take a look at the RFC
editor's policy on Author overload:

	http://www.rfc-editor.org/policy.html#policy.authlist

But some of the non-referenced references do actually hint at some of my
concerns with the work that may lead out of inter-area and inter-as
requirements.  As examples [BANDWIDTH-PROTECTION], [PATH-COMP],
[OSPF-TE-CAP], [LOOSE-PATH-REOPT], [NODE-ID] and [INTER-AS-TE-LINK].
Specifically, I worry about loosely bounded extensions, some of which may
seriously limit practical scalability of use (or ease of
operation/understanding).

I would like to work to bring our drafts together, however first I think
there is a crucial difference between them, something perhaps that some
list comment may shed light on.

In mine, edge to edge optimality yields to scalability.  Solutions that
come to mind include standard crankback approaches.  LSPs are likely to
be greedy within each region.  In yours, it appears that scalability
yields to optimality, or as another level of complexity, this is one
possible mode.  Your path computation servers would seem one approach
here, as these "straddle" and can bridge at least two areas, however this
would seem to involve a round of coordination with the head end, and once
an LSP goes across the second area into a third (Such as an edge to edge
LSP would likely do), there is again a limited visibility that must be
dealt with.

Am I off here?  I'm interested to here some feedback from the members of
the WG if they feel scalability or optimality is more crucial, or if it
is widely felt that they may harmoniously coexist without trade-off.

regards,

Jim