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

["Adrian Farrel" <adrian@olddog.co.uk>]

Excellent. Thanks.

A couple of points below, just to close. No need for answers.

Cheers,
Adrian

> Basically a solution must have limited impact on
> Link State Database size
> LSA/LSP flooding load
> SPF delay
>
> These parameters must be used then in an applicability statement to
> evaluate the solutions. It would be quite hard to give precise rules for
> such "limited" impact. It really depends on ISPs. One could say that
> the impact must be <= linear, with an increase lower than 10% for instance.

Great. This is really my point. We have a desire to minimize the impact on
the IGP, but an understanding that some additional information/flooding may
be acceptable and desireable.

We want to avoid dogmatic statements that say "do not" unless we absolutely mean them, and
then (of course) we must adhere to them.

> Basically we know that the leaking of dynamic TE information, in order
> to compute an optimal path, would have a major impact on IGP scalability
> and would likely suppress the advantages of IGP hierarchy.
> That's why, NO leaking of dynamic TE info across areas is a MUST
> requirement in this draft. This avoids working on solutions that ISPs
> would not want to deploy...

I accept that full leakage of all TE information in a dynamic way would almost certainly
have a major impact on IGP scalbility.

I do not accept that some carefully considered leaking of aggregated TE information on a
sparse timer basis would necessarily have such a dire impact.

This is why I want the requirements draft to tell me what impact on the IGP I am allowed
to have and leave CCAMP to derive a solution that fits that requirement. I don't think it
is right to tell CCAMP what solutions it may or may not consider.


> We want to have control on how the TE-LSP is signaled !
> If several inter-area signaling options are standardized, which is
> likely to happen (contiguous, stiching, nesting...),  it seems
> quite important for an ISP to have direct control on the option
> used to signal a given inter-area TE-LSP, and not only on the
> network functions that are provided. This is a key requirement
> expressed by all ISPs in this draft.

Well, if that is what the SPs want, who am I to argue?
It would, I suppose, be nice to understand why this is a requirement.
I am used to seeing functional options signaled (see RFC 3209).