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

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

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.

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

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.