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

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

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

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.

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

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

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

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