--- 1/draft-ietf-ccamp-inter-domain-framework-03.txt 2006-02-04 22:57:10.000000000 +0100 +++ 2/draft-ietf-ccamp-inter-domain-framework-04.txt 2006-02-04 22:57:10.000000000 +0100 @@ -1,25 +1,25 @@ Network Working Group Adrian Farrel IETF Internet Draft Olddog Consulting Proposed Status: Informational -Expires: December 2005 Jean-Philippe Vasseur +Expires: January 2006 Jean-Philippe Vasseur Cisco Systems, Inc. Arthi Ayyangar Juniper Networks - June 2005 + July 2005 A Framework for Inter-Domain MPLS Traffic Engineering - draft-ietf-ccamp-inter-domain-framework-03.txt + draft-ietf-ccamp-inter-domain-framework-04.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -67,42 +67,42 @@ 3. Path Computation Techniques ................................ 6 3.1. Management Configuration ............................... 7 3.2. Head End Computation ................................... 7 3.2.1. Multi-Domain Visibility Computation ................ 7 3.2.2. Partial Visibility Computation ..................... 7 3.2.3. Local Domain Visibility Computation ................ 8 3.3. Domain Boundary Computation ............................ 8 3.4. Path Computation Element ............................... 9 3.4.1. Multi-Domain Visibility Computation ................ 9 3.4.2. Path Computation Use of PCE When Preserving - Confidentiality .................................... 9 + Confidentiality ................................... 10 3.4.3. Per-Domain Computation Servers .................... 10 3.5. Optimal Path Computation .............................. 10 - 4. Distributing Reachability and TE Information .............. 10 - 5. Comments on Advanced Functions ............................ 11 + 4. Distributing Reachability and TE Information .............. 11 + 5. Comments on Advanced Functions ............................ 12 5.1. LSP Re-Optimization ................................... 12 - 5.2. LSP Setup Failure ..................................... 12 + 5.2. LSP Setup Failure ..................................... 13 5.3. LSP Repair ............................................ 13 - 5.4. Fast Reroute .......................................... 13 - 5.5. Comments on Path Diversity ............................ 14 + 5.4. Fast Reroute .......................................... 14 + 5.5. Comments on Path Diversity ............................ 15 5.6. Domain-Specific Constraints ........................... 15 5.7. Policy Control ........................................ 16 5.8. Inter-domain OAM ...................................... 16 5.9. Point-to-Multipoint ................................... 16 - 5.10. Applicability to Non-Packet Technologies ............. 16 + 5.10. Applicability to Non-Packet Technologies ............. 17 6. Security Considerations ................................... 17 7. IANA Considerations ....................................... 17 8. Acknowledgements .......................................... 17 9. Intellectual Property Considerations ...................... 17 10. Normative References ..................................... 18 11. Informational References ................................. 18 - 12. Authors' Addresses ....................................... 19 + 12. Authors' Addresses ....................................... 20 13. Full Copyright Statement ................................. 20 1. Introduction The Traffic Engineering Working Group has developed requirements for inter-area and inter-AS MPLS Traffic Engineering in [INTER-AREA] and [INTER-AS]. Various proposals have subsequently been made to address some or all of these requirements through extensions to the RSVP-TE and IGP @@ -390,20 +390,45 @@ If the LSR at the domain boundary has only partial visibility (using the definitions of section 3.2.2) it will fill in the path as far as the next domain boundary, and will supply further domain/domain boundary information if not already present in the ERO. If the LSR at the domain boundary has only local visibility into the immediate domain it will simply add information to the ERO to carry the Path message as far as the next domain boundary. + Domain boundary path computations are performed independently from + each other. Domain boundary LSRs may have different computation + capabilities, run different path computation algorithms, apply + different sets of constraints and optimization criteria, and so + forth, which might result in path segment quality which is + unpredictable to and out of the control of the ingress LSR. A + solution to this issue lies in enhancing the informaiton signaled + during LSP setup to include a larger set of constraints and to + include the paths of related LSPs (such as diverse protected LSPs) + as described in [GMPLS-E2E]. + + It is also the case that paths generated on domain boundaries may + produce loops. Specifically, the paths computed may loop back into a + domain that has already been crossed by the LSP. This may, or may not + be a problem, and might even be desirable, but could also give rise + to real loops. This can be avoided by using the recorded route (RRO) + to provide exclusions within the path computation algorithm, but in + the case of lack of trust between domains it may be necessary for the + RRO to indicate the previously visited domains. Even this solution is + not available where the RRO is not available on a Path message. Note + that when an RRO is used to provide exclusions, and a loop-free path + is found to be not available by the computation at a downstream + border node, crankback [CRANKBACK] may enable an upstream border node + to select an alternate path. + 3.4. Path Computation Element The computation techniques in sections 3.2 and 3.3 rely on topology and TE information being distributed to the ingress LSR and those LSRs at domain boundaries. These LSRs are responsible for computing paths. Note that there may be scaling concerns with distributing the required information - see section 4. An alternative technique places the responsibility for path computation with a Path Computation Element (PCE) [PCE]. There may be @@ -893,20 +918,26 @@ progress. [FRR] Ping Pan, et al, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", draft-ietf-mpls-rsvp-lsp-fastreroute, work in progress. [GMPLS-AS] Otani, T., Kumaki, K., and Okamoto, S., "GMPLS Inter-AS Traffic Engineering Requirements", draft-otani-ccamp-interas-GMPLS-TE, work in progress. + [GMPLS-E2E] Lang, J.P., Rekhter, Y., Papadimitriou, D., Editors, + "RSVP-TE Extensions in support of End-to-End + GMPLS-based Recovery", + draft-lang-ccamp-gmpls-recovery-e2e-signaling, work in + progress. + [HIER] Kompella K., Rekhter Y., "LSP Hierarchy with Generalized MPLS TE", draft-ietf-mpls-lsp-hierarchy, work in progress. [INTER-AREA] Le Roux, Vasseur et Boyle, "Requirements for support of Inter-Area and Inter-AS MPLS Traffic Engineering", draft-ietf-tewg-interarea-mpls-te-req, work in progress. [INTER-AS] Zhang, R., Vasseur, JP. et al, "MPLS Inter-AS Traffic