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

["LE ROUX Jean-Louis FTRD/DAC/LAN" <[e-mail]>]

Hi Adrian

Thanks for these useful comments.
Previous mail was a partial answer.
Please see inline for the complete answer.


>
>Hi,
>
>Thanks for this draft. Lots of good material and plenty to think about.
>
>I'm reviewing this with a CCAMP co-chair hat on. My
>perspective is very much that this draft will be handed over 
>to CCAMP as input and constraints to the process of developing 
>protocol extensions to deliver MPLS TE in an inter-area scenario.
>
>Thus most of my questions/issues are requests for
>clarification and are not debates on technical issues.
>
>Cheers,
>Adrian
>
>Abstract
>   This document lists a detailed set of functional
>requirements for the
>   support of inter-area MPLS Traffic Engineering (inter-area MPLS TE)
>   which could serve as a guideline to develop the required set of
>   protocol extensions.
>It is not clear to me whether these are requirements or 
>whether this draft is a general set of guidelines. Of course, 
>CCAMP will be bound by the former, and MAY ignore the latter.

They are requirements...
Agree that the abstract is confusing.
 We will rephrase as follows "This document lists a detailed set of
functional requirements for the support of inter-area MPLS Traffic
Engineering (inter-area MPLS TE). It is intended that solutions that
specify procedures for inter-area MPLS-TE  satisfy these
requirements..."


>
>Current limitations
>You make some fairly strong statements such as in 5.1...
>   However, MPLS-TE mechanisms are currently limited to a single IGP
>   area.
>I don't think this is clear at all. I don't see any
>limitations, for example, in MPLS-TE signalling in this 
>respect. It would be helpful to break down "MPLS-TE" into its 
>functional components and then it will be easy to show which 
>components are limited to a single IGP and which not. This is 
>more than the trivial point which it may appear since this 
>analysis is what will drive the solution

Basically limitations rely essentially on the routing (IGP) and path
computation components. 
You are right, we need to clarify this section.
Note that this is already partially mentionned in 5.1: "However, MPLS-TE
mechanisms are currently limited to a single IGP 
   area. This is basically due to the fact that hierarchy limits 
   topology visibility of head-end LSRs to their IGP area, and 
   consequently head-end LSRs can no longer run a CSPF algorithm to 
   compute the shortest constrained path to the tail-end"


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


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

>Perhaps you could relax the 
>requirement to adhere to FRR so as to allow the head-end to 
>supply the information for the bypass tunnel? In other words, 
>perhaps you could state the functional requirement not the 
>implementation?


>
>5.3.1. Preserve the IGP hierarchy concept
>The reason given in this section is chiefly scalability. How 
>does this section differ from the next section? It seems to be 
>a subset. But aren't hierarchies a solution to the scalability 
>requirement, not a requirement of themselves?

Basically the IGP hierachy concept MUST be preserved (ie containement of
routing information).
Hierachy is useful for various reasons, including scalability, but not
only scalability.
This is not entirely correlated, there may be inter-area solutions that
preserve IGP hierachy but are not scalable.
Preserving hierachy is necessary but not sufficient to ensure
scalability.
Basically we want a solution allowing to compute inter-area TE-LSP paths
while preserving IGP hierachy and scalability.

Section 5.3.2 adress scalability of both IGP AND RSVP.

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

>The definition of "unreasonable" may require some work!

Right...

>I think you are going to have to bite the bullet on 
>scalability since you have already stated that the reason that 
>areas exist is chiefly because of scalability issues. 
>If, for 
>example, the maximum operational size of an area was reduced 
>by the addition of inter-area TE function, would that be 
>unacceptable?

IMHO, the addition of inter-area TE funcion MUST not compromize the
maximum operational size
of an area.

 >Note also that 8.1 (4) seems to adopt a far more 
>relaxed attitude to this question. 

>Ingress and egress in the 
>same area. I think there is an important issue that we need to 
>check everyone is comfortable with. In section 6...
>   In some cases, it might also be possible to have an 
>inter-area TE LSP
>   from R0 to R5 transiting via the backbone area (or any other levels
>   with IS-IS). Basically, there may be cases where there is no longer
>   enough resources on any intra area path R0-to-R5, while there is a
>   feasible inter-area path through the backbone area.
>So we are going to specifically allow a routing scenario where 
>we may leave and re-enter an area. 

Right

>This, I believe, does not 
>happen in open shortest path first. 

Right, but here we want to do TE. One goal of MPLS-TE is to setup
constraint based paths regardless of the 
IP path isn't it ?

>Just wanted to be clear 
>that everyone agrees to this. (see also 7.8)
>
>7.1. Inter-area MPLS TE operations and interoperability
>Is it a requirement that we protect non-head-end, non-ABR LSRs 
>from knowledge of inter-area function? This seems to be what 
>8.3 says. This raises a big issue for FRR (or any other form 
>of) protection of an ABR.

Of course the PLR must support inter-area functions
Will clarify



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


>There may be *functional* reasons why one 
>signalling method is preferred, but in that case, surely the 
>head-end should specify the functions/service level that it wants.

>
>7.4. Inter-Area MPLS-TE Routing
>   As already mentioned in 5.3, IGP hierarchy does not allow the Head-
>   End LSR computing an end-to-end optimal path. Additional mechanisms
>   are required to compute an optimal path. These additional mechanisms
>   MUST not alter the IGP hierarchy principles.
>   One solution could consist of extending the IGP for the leaking of
>   summarized TE information across areas, but this would not scale: An
>   ABR would have to compute and advertise summarized TE data for each
>   potential destination and a large set of constraints combinations
>   which would ineluctability have undesirable consequences in term of
>   amount of flooded information and ABR CSPF computations.
>   Thus, in order to maintain containment of routing information and
>   preserve the overall IGP scalability, the solution MUST preclude the
>   leaking across area of any TE link information summarized 
>or not. Whatever your views on the likelihood of a successful 
>aggregation algorithm being developed, it seems to me that you 
>are deliberately curtailing the solution space rather than 
>stating the requirements. Could you limit yourself to scaling 
>requirements rather than state how these requirements must be met?

I will answer this point in a separate email


>
>   Conversely, this does not preclude the leaking of non topology
>   related information, that are not taken into account during path
>   selection, such as static TE Node information like TE router ids or
>   TE node capabilities.
>Are TE node capabilities not topology related? They certainly 
>affect how you choose a path. Perhaps you are trying to 
>distinguish between dynamic and static information?

Yes we are disinghuishing between static and dynamic TE information.
Will clarify this section.


>
>7.5. Inter-Area MPLS-TE Path computation
>   In case a solution supports more than one method, it SHOULD 
>allow the
>   operator to select by configuration, and on a per-LSP basis, the
>   desired option.
>Again, you want to be able to control the way in which a 
>service is provided at a downstream ABR rather than specify 
>the service. I am uneasy with this and see interop problems 
>without a gain in function.

IMHO this is important for an ISP to exactly control, by configuration
at Head-End, the way the path is computed


>
>7.7. Support of diversely routed inter-area TE LSPs
>   Moreover, the solution SHOULD not require
>   extra-load in signalling and routing in order to reach that
>   objective.
>Why do you say this and not...
>   Moreover, the solution SHOULD not require extra
>   load in processing at the head-end LSR, nor extra load
>   in communication with an offline path computation
>   server.
>It seems to me that if (for example) it was necessary to 
>signal fifty additional bytes in a signalling message in order 
>to achieve diverse paths, this would be entirely acceptable. 
>Actually, the whole of this section describes computation of 
>diverse paths rather than establishment of diverse paths. The 
>service that we want to achieve is clearly one where diverse 
>paths are established: computation of such paths (rather than 
>derivation) is surely just one way of facilitating the service.

You are right, we will update this section as you suggest

>
>7.9. Reoptimization of inter-area TE LSP
>Just for the record, make-before-break is only "nearly 
>non-disruptive". "Minimally disruptive" might be a good 
>phrase. This is true even in packet networks since the first 
>packet on the new LSP may overtake the last on the old path. 

Right, will clarify

>TE link across Area 0?
>
>7.14. Auto-discovery of TE meshes
>Perhaps you could add a reference for this section.
>I note that in this particular case, dynamic inter-area IGP 
>information is allowed. Curious to know how you decide where 
>to draw the line.

TE mesh is basically a static TE information, and we allow advertisement
of static TE info

>
>7.15. Inter-area MPLS TE fault management requirements
>Is there a requirement here for hierarchical LSP-PING since 
>you allow hierarchies across Area 0?

Yes, will add this requirement

>
>7.16. Inter-area MPLS-TE and routing
>To be clear, you are precluding the use of IGP shortcuts where 
>the head and tail of an LSP are in separate areas?

Bascially we are precluding the use of IGP shortcuts and also the
advertisement of a TE-LSP as a link into the IGP
Will clarify that in next revision

>
>8.1. Performances
>   Other criteria may be added in further revisions of this 
>document. I guess now is your last chance :-)

Right, we will update this section in next revision


>
>8.2. Complexity and risks
>   The proposed solution(s) SHOULD not introduce unnecessary complexity
>   to the current operating network to such a degree that it would
>   affect the stability and diminish the benefits of deploying such
>   solution over SP networks.
>But we are allowed to introduce unnecessary complexity to a 
>lesser degree? :-)

Definitely no... will rephrase


>
>9. Security Considerations
>This section seems awfully light. There is at least a new 
>policy point (the ABR) that may be responsible for security. 
>It is also possible to consider that the limited visibility 
>from one area to another is a security feature (even if it was 
>not designed as such) and so there is something to be said on 
>that topic.
>

IGP hiearchy are not defined and not used today by ISPs to improve
security,
And thus I'm not sure to understand what could be added in this section.

>References
>I wonder if all of your normative references need to be 
>normative. This is likely to hold up the publication as an RFC 
>for a long time.

Right, will update.

>
>Copyright and IPR
>No IPR statement found
>Copyright needs to use the new boilerplate.

OK

>
>Typos.
>Could someone have a good go through the draft to clean up the 
>typos and non-ASCII characters. This will make it easier to 
>read an use.
>

OK


Again, thanks a lot Adrian for these highly relevant comments

Best Regards

JL