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

From: "LE ROUX Jean-Louis FTRD/DAC/LAN" <[email-masked]>
Date: Wed, 26 May 2004 15:44:15 +0200

Hi Adrian,

Please see inline for additonal comments/answers

Cheers,

JL

>-----Message d'origine-----
>De : Adrian Farrel [mailto:[email-masked]] 
>Envoyé : mardi 25 mai 2004 12:32
>À : LE ROUX Jean-Louis FTRD/DAC/LAN
>Cc : [email-masked]; [email-masked]
>Objet : Re: Last call for draft-ietf-tewg-interarea-mpls-te-req-01.txt 
>
>
>Hey Jean-Louis,
>
>Thanks. Good responses.
>
>A couple of follow-ups...
>
>Cheers,
>Adrian
>
>
>>>Inter-area fast recovery
>>>Is this draft requiring that there should be fast recovery 
>techniques 
>>>that span area boundaries, or is it requiring that Fast 
>Reroute should 
>>>be functional across area boundaries? (see also 7.10.2)
>>
>>Fast Recovery across areas is a generic requirement.
>>A simple solution is to support FRR, and thus, support of FRR across 
>>area boundaries is defined as a specific requirement.
>
>OK. I just wanted to be clear, because (as below) FRR across 
>an area boundary is a particular problem.
>
>>>It seems that FRR places a requirement on the
>>>last LSR before the ABR to be able to compute an inter-area 
>path (and 
>>>possibly to know about diversity constraints - i.e. the path of some 
>>>other LSP).
>>
>>No, we simply mention in 7.10.2: "the
>>  solution SHOULD allow computing and setting up a backup tunnel
>>  following an optimal path that offers bandwidth guarantees during
>>   failure along with other potential constraints (like bounded
>>  propagation delay increase along the backup path)"
>>
>> This definitely does not point out that such backup computation must 
>> be done by the last LSR before the ABR.
>
>OK.
>My point was that it is usually the PLR that is responsible 
>for having computed and established the bypass tunnel.

There are currently several approaches defined for intra-area backup path determination:
	-1: Manual configuration on the PLR.
	-2: Online computation on the PLR.
	-3: Computation by a PCE, that can be an offline tool or the protected LSR itself (see http://www.watersprings.org/pub/id/draft-vasseur-mpls-backup-computation-02.txt)
	-4: Use of Backup ERO (BERO) signaled to PLRs by the Head-End.

IMO 1, 2 and 3 (offline) are currently deployed by ISPs, and I'm not so sure that 2 can be considered as THE usual case.

Nervermind, this draft does not favor any approach for inter-area backup path selection.
Any of these four approaches, or others, may be used, provided that it respect scalability requirements (sig and rtg).

The only mandated point, as regards fast reroute, is the support of [FAST-REROUTE]. This reference
only addresses the signaling aspects of FRR and not the backup computation aspects.

Will clarify that in next revision.

> This is 
>fine when the PLR, MP and bypass tunnel lie in the same area. 
>But when the ABR fails, the PLR is the "last LSR before the 
>ABR". This will require that the PLR and MP are indifferent 
>areas. Thus there is a requirement that the PLR is able to 
>compute inter-area paths.

True when using option 2 above. Thus this requirement will be a SHOULD.

>
>I wanted to understand whether it is a requirement to use this 
>form of FRR, or whether it would be acceptable (for example) 
>for the protection path to be computed by the ingress and 
>supplied to the PLR through signaling.

As mentioned above backup computation by the PLR is not a MUST requirement, any option would be acceptable provided 
that it respect other requirements

>
>>>5.3.2. Preserve Scalability
>>>   The solution MUST also not increase IGP load which could 
>compromise
>>>   IGP scalability.
>>>Just to be clear, no increase in IGP load of any sort is 
>allowed under 
>>>any circumstances? Because you go on to say...
>>>   In particular, a solution satisfying those
>>>   requirements MUST not require for the IGP to carry some 
>unreasonable
>>>   amount of extra information and MUST not unreasonably increase the
>>>   IGP flooding frequency.
>>>Which implies that additional data and flooding is allowed.
>>
>>Yes, provided that there is no impact on IPG scalability
>
>Well, I don't want to be picky, but...  :-)
>*Any* increase even in the amount of static flooded data 
>impacts on IGP scalablity. 
>So, if we are going to be governed 
>by rules on IGP scalability, we must be consistent and 
>understand the rules.

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.

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

>
>> IMHO, the addition of inter-area TE funcion MUST not compromize the 
>> maximum operational size of an area.
>
>So, that really means adding absolutely no information to any 
>LSAs at all. Because an increase in that information implies 
>an increase in stored data which implies a reduction in the 
>maximum operational size of the area.

It depends on what do we mean by "compromize" :-) See above
All in all, I'm not so sure that memory footprint is always the bottleneck in the maximum operational size of an IGP area...
One may consider the SPF time, that depends on the number of links and nodes in the area, as the bottleneck that limits the maximum size of an IGP area.
In such case the advertisement of additional static TE information not used during path computation, such as TE meshes for instance, 
would definitely not impact the SPF delay, and thus the maximum operational size of an area. 

>
>>>7.2. Inter-Area TE-LSP signalling
>>>   If multiple signalling methods are proposed in the solution, the
>>>   head-end LSR MUST have the ability to signal the required 
>or desired
>>>   method on a per-LSP basis.
>>>To be clear...
>>>The head-end is to be given the ability to cause an LSP 
>setup to fail 
>>>if the signalling technique is not to its liking regardless of the 
>>>service provided. The head-end is to be allowed to select only a 
>>>single method, but to require or desire that method. Am I missing 
>>>something, or is this a recipe for interoperability issues? For 
>>>example, if the head-end specifies that end-to-end 
>signalling MUST be 
>>>used but only supplies a loose hop for the transit of Area 0, why 
>>>would it care how the signalling across Area 0 is achieved (such as
>>>through an FA)?
>>
>>It would care about the signaling used at transit for several 
>reasons: 
>>FRR performances, optimality, head-end control of reoptimization...
>>IMHO this is important for an ISP to control, by configuration at
>>Head-End, the signaling method.
>
>Weeeeell,
>The things you have listed are functional requirements not 
>implementation requirements. That is, the head-end is free to 
>request/demand certain functions from the network, but I still 
>don't understand why it would want/need to control how those 
>functions are provided.

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.

>
>>>9. Security Considerations
>>>This section seems awfully light.
>> And thus I'm not sure to understand what could be added in this 
>> section.
>
>OK. Well, I leave it with you. You might want to consult an 
>IETF "security expert" just so that the draft doesn't get 
>bounced by the IESG.

OK

Again thanks a lot for your help in finalizing this work.

Cheers,

JL

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 26 May 2004 20:08:28 +0100

Excellent. Thanks.

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

Cheers,
Adrian

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

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

---

From: Tony Li <[email-masked]>
Date: Wed, 26 May 2004 13:36:48 -0700

> is right to tell CCAMP what solutions it may or may not consider.

Operator hat on:

I would very much like to see it be a requirement that no information 
is leaked
without specific configuration.  Further, I would very much like to see
implementations give us reasonable granularity (and reasonable 
abstraction) in
what we choose to leak.

As an example, I would like to be able to leak detailed topology 
information from
my IS-IS L2 database down into an L1 area.  I would NOT want to leak 
bandwidth
information.  I would want to leak an abstraction of another L1 area 
down into an
L1 area, but I would definitely want that to be an abstraction, NOT the 
full
database.

I am not interested in perfect optimality.  I am interested in what can 
be
achieved with a limited amount of overhead.  It is very clear that 
there cannot be
any improvements without some impact on IGP scalability.  If nothing 
else, every
byte in an LSA/LSP counts towards router memory consumption.  Thus, we 
have a
tradeoff that we need to make and perfect optimality is not a 
reasonable goal in
light of limited scalability.  Good returns can be had by leaking 
information
that is topologically "close by" and abstracting distant information.  
If
necessary, this can be supplemented by path manipulation along the way.

Regards,
Tony