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 (jpv@cisco.com)
Raymond Zhang (raymond.zhang@bt.infonet.com)
Nabil Bitar (nabil.n.bitar@verizon.com)
Jean-Louis Le Roux (jeanlouis.leroux@orange-ft.com)
66th IETF, Montreal, July 2006
A bit of history …
•
•
“Yes” … history …
Solution first presented in draft-vasseur-inter-aste-00.txt - IETF 56 - SF - March 2003.
 Inter-AS MPLS Traffic Engineering requirements draft: draftzhang-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-pdpath-comp
draft-vasseur-pce-brpc01.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 4216
7.3. Path Optimality
5.1.3. 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 [TEREQ]) 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.
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 suboptimality) 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 4216
7.7. Support of Diversely-Routed Inter-Area TE LSPs
5.1.4. Support of Diversely Routed Inter-AS TE LSP
…
Setting up multiple inter-AS TE LSPs between a pair of
LSRs might be desirable when:
Thus, the solution MUST be able to establish diverselyrouted 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 loadbalancing 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.
(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 [MPLSRecov].
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 ?
66th IETF, Montreal, July 2006