draft-ietf-ccamp-inter-domain-framework-03.txt   draft-ietf-ccamp-inter-domain-framework-04.txt 
Network Working Group Adrian Farrel Network Working Group Adrian Farrel
IETF Internet Draft Olddog Consulting IETF Internet Draft Olddog Consulting
Proposed Status: Informational Proposed Status: Informational
Expires: December 2005 Jean-Philippe Vasseur Expires: January 2006 Jean-Philippe Vasseur
Cisco Systems, Inc. Cisco Systems, Inc.
Arthi Ayyangar Arthi Ayyangar
Juniper Networks Juniper Networks
June 2005 July 2005
A Framework for Inter-Domain MPLS Traffic Engineering 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 Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at line 77 skipping to change at line 77
3. Path Computation Techniques ................................ 6 3. Path Computation Techniques ................................ 6
3.1. Management Configuration ............................... 7 3.1. Management Configuration ............................... 7
3.2. Head End Computation ................................... 7 3.2. Head End Computation ................................... 7
3.2.1. Multi-Domain Visibility Computation ................ 7 3.2.1. Multi-Domain Visibility Computation ................ 7
3.2.2. Partial Visibility Computation ..................... 7 3.2.2. Partial Visibility Computation ..................... 7
3.2.3. Local Domain Visibility Computation ................ 8 3.2.3. Local Domain Visibility Computation ................ 8
3.3. Domain Boundary Computation ............................ 8 3.3. Domain Boundary Computation ............................ 8
3.4. Path Computation Element ............................... 9 3.4. Path Computation Element ............................... 9
3.4.1. Multi-Domain Visibility Computation ................ 9 3.4.1. Multi-Domain Visibility Computation ................ 9
3.4.2. Path Computation Use of PCE When Preserving 3.4.2. Path Computation Use of PCE When Preserving
Confidentiality .................................... 9 Confidentiality ................................... 10
3.4.3. Per-Domain Computation Servers .................... 10 3.4.3. Per-Domain Computation Servers .................... 10
3.5. Optimal Path Computation .............................. 10 3.5. Optimal Path Computation .............................. 10
4. Distributing Reachability and TE Information .............. 10 4. Distributing Reachability and TE Information .............. 11
5. Comments on Advanced Functions ............................ 11 5. Comments on Advanced Functions ............................ 12
5.1. LSP Re-Optimization ................................... 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.3. LSP Repair ............................................ 13
5.4. Fast Reroute .......................................... 13 5.4. Fast Reroute .......................................... 14
5.5. Comments on Path Diversity ............................ 14 5.5. Comments on Path Diversity ............................ 15
5.6. Domain-Specific Constraints ........................... 15 5.6. Domain-Specific Constraints ........................... 15
5.7. Policy Control ........................................ 16 5.7. Policy Control ........................................ 16
5.8. Inter-domain OAM ...................................... 16 5.8. Inter-domain OAM ...................................... 16
5.9. Point-to-Multipoint ................................... 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 6. Security Considerations ................................... 17
7. IANA Considerations ....................................... 17 7. IANA Considerations ....................................... 17
8. Acknowledgements .......................................... 17 8. Acknowledgements .......................................... 17
9. Intellectual Property Considerations ...................... 17 9. Intellectual Property Considerations ...................... 17
10. Normative References ..................................... 18 10. Normative References ..................................... 18
11. Informational References ................................. 18 11. Informational References ................................. 18
12. Authors' Addresses ....................................... 19 12. Authors' Addresses ....................................... 20
13. Full Copyright Statement ................................. 20 13. Full Copyright Statement ................................. 20
1. Introduction 1. Introduction
The Traffic Engineering Working Group has developed requirements for The Traffic Engineering Working Group has developed requirements for
inter-area and inter-AS MPLS Traffic Engineering in [INTER-AREA] and inter-area and inter-AS MPLS Traffic Engineering in [INTER-AREA] and
[INTER-AS]. [INTER-AS].
Various proposals have subsequently been made to address some or all Various proposals have subsequently been made to address some or all
of these requirements through extensions to the RSVP-TE and IGP of these requirements through extensions to the RSVP-TE and IGP
skipping to change at line 400 skipping to change at line 400
If the LSR at the domain boundary has only partial visibility (using 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 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 the next domain boundary, and will supply further domain/domain
boundary information if not already present in the ERO. boundary information if not already present in the ERO.
If the LSR at the domain boundary has only local visibility into the 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 immediate domain it will simply add information to the ERO to carry
the Path message as far as the next domain boundary. 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 3.4. Path Computation Element
The computation techniques in sections 3.2 and 3.3 rely on topology The computation techniques in sections 3.2 and 3.3 rely on topology
and TE information being distributed to the ingress LSR and those and TE information being distributed to the ingress LSR and those
LSRs at domain boundaries. These LSRs are responsible for computing LSRs at domain boundaries. These LSRs are responsible for computing
paths. Note that there may be scaling concerns with distributing the paths. Note that there may be scaling concerns with distributing the
required information - see section 4. required information - see section 4.
An alternative technique places the responsibility for path An alternative technique places the responsibility for path
computation with a Path Computation Element (PCE) [PCE]. There may be computation with a Path Computation Element (PCE) [PCE]. There may be
skipping to change at line 903 skipping to change at line 928
progress. progress.
[FRR] Ping Pan, et al, "Fast Reroute Extensions to RSVP-TE [FRR] Ping Pan, et al, "Fast Reroute Extensions to RSVP-TE
for LSP Tunnels", draft-ietf-mpls-rsvp-lsp-fastreroute, for LSP Tunnels", draft-ietf-mpls-rsvp-lsp-fastreroute,
work in progress. work in progress.
[GMPLS-AS] Otani, T., Kumaki, K., and Okamoto, S., "GMPLS Inter-AS [GMPLS-AS] Otani, T., Kumaki, K., and Okamoto, S., "GMPLS Inter-AS
Traffic Engineering Requirements", Traffic Engineering Requirements",
draft-otani-ccamp-interas-GMPLS-TE, work in progress. 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 [HIER] Kompella K., Rekhter Y., "LSP Hierarchy with
Generalized MPLS TE", draft-ietf-mpls-lsp-hierarchy, Generalized MPLS TE", draft-ietf-mpls-lsp-hierarchy,
work in progress. work in progress.
[INTER-AREA] Le Roux, Vasseur et Boyle, "Requirements for support of [INTER-AREA] Le Roux, Vasseur et Boyle, "Requirements for support of
Inter-Area and Inter-AS MPLS Traffic Engineering", Inter-Area and Inter-AS MPLS Traffic Engineering",
draft-ietf-tewg-interarea-mpls-te-req, work in draft-ietf-tewg-interarea-mpls-te-req, work in
progress. progress.
[INTER-AS] Zhang, R., Vasseur, JP. et al, "MPLS Inter-AS Traffic [INTER-AS] Zhang, R., Vasseur, JP. et al, "MPLS Inter-AS Traffic
 End of changes. 

This html diff was produced by rfcdiff 1.24, available from http://www.levkowetz.com/ietf/tools/rfcdiff/