Re: MPLS Inter-area TE requirement draft

Hi Jim,

At 06:30 PM 12/30/2003 -0800, Jim Boyle wrote:


>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!).

Apparently you keep trying to maintain some level of confusion. Read the 
minutes of previous IETF. We never said that inter-area TE was not an 
important item at all but rather that the requirements were different from 
Inter-AS TE (hence the existence of two separate ID), and that Inter-AS TE 
was more urgent in light of the planned deployments.

>  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

As you know, the draft is not is its final form and will be aligned with 
the IETF policy of course. Thanks for the reminder.

>But some of the non-referenced references do actually hint at some of my
>concerns with the work

Please let us know of any references that should be added, no problem.

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

This is a requirement draft, not a solution draft. The requirement to be 
able to compute an optimal end to end path is clearly stated in the draft 
indeed, since it turns out to be a requirement for several SPs. You seem to 
draw the conclusion that scalability yields to optimality which is 
absolutely not an assumption of this requirement draft. Moreover, such a 
debate will obviously take place when discussing the solution in CCAMP, 
here is a *requirement* draft.

Note that the requirement for a scalable solution is clearly highlighted in 
the present draft:

5.1.    Objectives to preserve IGP/RSVP scalability

Being able to achieve the requirements listed in this document MUST be
performed while preserving the IGP scalability, which is of the utmost
importance. Hence, the set of mechanisms defined to meet those
requirements MUST not require IGP extra-load which could compromise the
IGP scalability. In particular, a solution satisfying those
requirements MUST require for the IGP to carry some unreasonable amount
of extra information and MUST not significantly increase the frequency
of IGP flooding. Likewise, the solution MUST also preserve the
scalability of RSVP TE ([RSVP-TE]). Moreover, the solution MUST
preserve the concept of IGP hierarchy (no TE link information flooded
across areas).

>  or as another level of complexity, this is one
>possible mode.  Your path computation servers would seem one approach
>here,

Again, we're not supposed to discuss about the solution here but the 
requirement.

>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.

Do you know any solution without trade-off ? Obviously not ... but I guess 
that the pros and cons of each solution addressing the requirements will be 
discussed in the solution draft.

Thanks.

JP.

>regards,
>
>Jim