Requirements for Inter-Area MPLS Traffic Engineering
RFC 4105

Note: This ballot was opened for revision 03 and is now closed.

(Bert Wijnen) Yes

(Harald Alvestrand) No Objection

Comment (2004-09-16 for -)
No email
send info
Reviewed by Mary Barnes, Gen-ART

(Steven Bellovin) No Objection

Comment (2004-09-11 for -)
No email
send info
There are some undefined acronyms -- I was puzzled by SRLG, and I think there are more.

(Margaret Cullen) No Objection

(Scott Hollenbeck) No Objection

(Russ Housley) No Objection

Comment (2004-09-14 for -)
No email
send info
  s/7.15. nter-area/7.15. Inter-area/
  Section 9 says: "Inter-area MPLS-TE does not raise any new security issue,
  beyond those of intra-area MPLS-TE."  It would be helpful is a pointer
  was provided to the place where the already known issues are discussed.

(David Kessens) No Objection

(Alex Zinin) No Objection

Comment (2004-09-16 for -)
No email
send info
> 4.2.3. Fast recovery within an area
>    As quality sensitive applications are deployed, one of the key 
>    requirements is to provide fast recovery mechanisms, allowing to 
>    guarantee traffic recovery on the order of tens of msecs, in case of 
>    network element failure. Note that this cannot be achieved by relying 
>    only on IGP rerouting.  

The last statement is not entirely correct. We are working on IP FRR in
RTGWG. I would change it to say "only on classical IGP rerouting".

> 5.3.2. Preserve Scalability
>    Being able to achieve the requirements listed in this document MUST 
>    be performed while preserving the IGP scalability, which is of the 
>    utmost importance. The hierarchy preservation objective addressed in 
>    the above section is actually an element to preserve IGP scalability.
>    The solution MUST also not increase IGP load which could compromise
                               +"unreasonably" to match below?
>    IGP scalability. 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. 

> 7.2. Inter-Area TE-LSP signalling
>    The solution MUST allow for the signalling of inter-area TE-LSPs, 
>    using RSVP-TE. 
>    The proposed solution MUST allow the head-end LSR to explicitly 
>    specify a set of LSRs, including ABRs, by means of strict or loose 
>    hops for the inter-area TE LSP.  
>    In addition, the proposed solution SHOULD also provide the ability to  
>    specify and signal certain resources to be explicitly excluded in the 
>    inter-area TE LSP path establishment.  

May it also be necessary to signal other constrains such as BW or admin groups?

> 7.4. Inter-Area MPLS-TE Routing
>    As already mentioned in 5.1, 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. 
>    Particularly, 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 Topology related  information even 
>    in a summarized form. 

If this is what the WG converged on--fine, but I want to make sure you
understand that this precludes at least one form of a hierarchical approach
where cross-area TE tunnels are pre-engineered and announced to other areas as
topological info. Depending on how tunnel and physical topologies compare, it
may or may not be useful.

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

> 7.8. Intra/Inter-area Path selection policy
>    For inter-area TE LSPs whose head-end and tail-end LSRs reside in the 
>    same IGP area, there may be intra-area and inter-area feasible paths. 
>    In case the shortest path is an inter-area path, an operator may 
>    either want to avoid, as far as possible, crossing area and thus 
>    prefer selecting a sub-optimal intra-area path, or conversely may 
>    prefer to use a shortest path, even if it crosses areas. 
>    Thus, the solution MUST allow to enable/disable IGP area crossing, on 
>    a per-LSP basis, for TE LSPs whose head-end and tail-end reside in 
>    the same IGP area.  

Observation: note that the above is rather an implementation req, rather
than one for the solution.

> 7.14. Auto-discovery of TE meshes
>    Because the number of LSRs participating in some TE mesh might be 

Where's a "TE mesh" defined?

> 8. Evaluation criteria
> 8.1. Performances  
>    The solution SHOULD clearly be evaluated with respects to the 
>    following criteria:  

Don't think 2119 lingo is appropriate here. How about "will be evaluated"?

>    (1) Optimality of the computed inter-area TE LSP paths.

In what terms?

>    (2) Optimality of the computed backup paths protecting against  
>        the failure of an ABR, capability to share bandwidth among backup  
>        tunnels protecting independent facilities.


>    (3) Inter-area TE LSP set up time. 

expressed how?

>    (4) RSVP-TE and IGP scalability (state impact, number of messages,    
>        message size)