RE :

["LE ROUX Jean-Louis FTRD/DAC/LAN" <jeanlouis.leroux@francetelecom.com>]

Hi Adrian

Thanks for these useful comments.
Please see inline


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

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



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). 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?
>
>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.
>The definition of "unreasonable" may require some work!
>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? 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. This, I believe, does not 
>happen in open shortest path first. 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.
>
>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)?  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?
>
>   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?
>
>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.
>
>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.
>
>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. 
>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.
>
>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?
>
>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?
>
>8.1. Performances
>   Other criteria may be added in further revisions of this 
>document. I guess now is your last chance :-)
>
>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? :-)
>
>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.
>
>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.
>
>Copyright and IPR
>No IPR statement found
>Copyright needs to use the new boilerplate.
>
>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.
>