[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE : Last call for draft-ietf-tewg-interarea-mpls-te-req-01.txt
Hi Adrian,
Please see inline for additonal comments/answers
Cheers,
JL
>-----Message d'origine-----
>De : Adrian Farrel [mailto:adrian@olddog.co.uk]
>Envoyé : mardi 25 mai 2004 12:32
>À : LE ROUX Jean-Louis FTRD/DAC/LAN
>Cc : te-wg@ops.ietf.org; ccamp@ops.ietf.org
>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