66th IETF, Montreal, July 2006 PCE Working Group Meeting IETF-66, July 2006, Montreal A Backward Recursive PCE-based Computation (BRPC) procedure to compute shortest inter-domain Traffic Engineering Label Switched Path draft-vasseur-pce-brpc-01.txt JP Vasseur Raymond Zhang Nabil Bitar Jean-Louis Le Roux

66th IETF, Montreal, July 2006 A bit of history … “Yes” … history … Solution first presented in draft-vasseur-inter-as- te-00.txt - IETF 56 - SF - March  Inter-AS MPLS Traffic Engineering requirements draft: draft- zhang-mpls-interas-te-req-02.txt (TE WG)  Inter-AS MPLS Traffic Engineering (solution draft): draft-vasseur-inter-AS-te-00.txt (WG to be decided once inter-AS reqs draft adopted as a WG doc) Scenario 1: per-AS TE LSP Path computation Scenario 2: distributed path computation server draft-ietf-inter-domain-pd- path-comp draft-vasseur-pce-brpc- 01.txt

66th IETF, Montreal, July 2006 Where does this document fit in the charter ? This is about inter-domain TE LSP path computation, which belongs to CCAMP but using PCE discussed in the PCE WG Proposal: discuss this ID in PCE with a review of CCAMP In term of requirements … See RFC 4105 See RFC Path Optimality In the context of this requirement document, an optimal path is defined as the shortest path across multiple areas, taking into account either the IGP or TE metric [METRIC]. In other words, such a path is the path that would have been computed by making use of some CSPF algorithm in the absence of multiple IGP areas. As mentioned in Section 5.2, the solution SHOULD provide the capability to compute an optimal path dynamically, satisfying a set of specified constraints (defined in [TE- REQ]) across multiple IGP areas. Note that this requirement document does not mandate that all inter-area TE LSPs require the computation of an optimal (shortest) inter-area path Optimality The solution SHOULD allow the set-up of an inter-AS TE LSP that complies with a set of TE constraints defined in [TE-REQ]) and follows an optimal path. An optimal path is defined as a path whose end-to-end cost is minimal, based upon either an IGP or a TE metric. Note that in the case of an inter-AS path across several ASes having completely different IGP metric policies, the notion of minimal path might require IGP metric normalization. The solution SHOULD provide mechanism(s) to compute and establish an optimal end-to-end path for the inter-AS TE LSP and SHOULD also allow for reduced optimality (or sub- optimality) since the path may not remain optimal for the lifetime of the LSP.

66th IETF, Montreal, July 2006 Where does this document fit in the charter ? Support of diverse Inter-domain paths See RFC 4105 See RFC Support of Diversely-Routed Inter-Area TE LSPs … Thus, the solution MUST be able to establish diversely- routed inter-area TE LSPs when diverse paths exist. It MUST support all kinds of diversity (link, node, SRLG). The solution SHOULD allow computing an optimal placement of diversely-routed LSPs. There may be various criteria to determine an optimal placement. For instance, the placement of two diversely routed LSPs for load- balancing purposes may consist of minimizing their cumulative cost. The placement of two diversely-routed LSPs for protection purposes may consist of minimizing the cost of the primary LSP while bounding the cost or hop count of the backup LSP Support of Diversely Routed Inter-AS TE LSP Setting up multiple inter-AS TE LSPs between a pair of LSRs might be desirable when: (1) a single TE LSP satisfying the required set of constraints cannot be found, in which case it may require load sharing; (2) multiple TE paths may be required to limit the impact of a network element failure to a portion of the traffic (as an example, two VoIP gateways may load balance the traffic among a set of inter-AS TE LSPs); (3) path protection (e.g., 1:1 or 1:N) as discussed in [MPLS- Recov]. In the examples above, being able to set up diversely routed TE LSPs becomes a requirement for inter-AS TE. The solution SHOULD be able to set up a set of link/SRLG/Node diversely routed inter-AS TE LSPs.

66th IETF, Montreal, July 2006 Summary: Number of editorial changes in this new revision: Thanks to Adrian for the thorough review that led to several editorial changes New changes: … This document specifies a procedure relying on the use of multiple Path Computation Elements (PCEs) in order to compute such inter-domain shortest constraint paths along a determined sequence of domains, using a backward recursive path computation technique while preserving confidentiality across domains, which is sometimes required when domains are managed by different Service Providers... Clarification on the VSPT computation (Step i) - Inter-domain TE links has as a prerequisite the knowledge) Path computation procedure is quite stable Next revision will cover in more details the path diversity issue+ slight procedural modification to support bidirectional LSPs (GMPLS) + New Manageability section Proposed Next Steps Adopt the ID as a WG document ?