Re: MPLS Inter-area TE requirement draft

[Jean Philippe Vasseur <jvasseur@cisco.com>]

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