draft-ietf-tewg-interas-mpls-te-req-03.txt   draft-ietf-tewg-interas-mpls-te-req-04.txt 
IETF Internet Draft Raymond Zhang, Editor IETF Internet Draft Raymond Zhang, Editor
Internet Engineering Task Force Infonet Services Corporation Internet Engineering Task Force Infonet Services Corporation
Document: JP Vasseur, Co-Editor Document: JP Vasseur, Co-Editor
draft-ietf-tewg-interas-mpls-te-req-03.txt CISCO Systems, Inc draft-ietf-tewg-interas-mpls-te-req-04.txt CISCO Systems, Inc
December 2003 January 2004
Expires: June 2004 Expires: July 2004
MPLS Inter-AS Traffic Engineering requirements MPLS Inter-AS Traffic Engineering requirements
draft-ietf-tewg-interas-mpls-te-req-03.txt draft-ietf-tewg-interas-mpls-te-req-04.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are Working all provisions of Section 10 of RFC2026. Internet-Drafts are Working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
skipping to change at page 4, line 5 skipping to change at page 3, line 53
criteria for any technical solution(s) meeting these requirements. criteria for any technical solution(s) meeting these requirements.
Please note that there are other means of traffic engineering Please note that there are other means of traffic engineering
including IGP metrics based (for use within an AS) and BGP attribute including IGP metrics based (for use within an AS) and BGP attribute
based (for use across ASes; see Appendix A) traffic engineering based (for use across ASes; see Appendix A) traffic engineering
mechanisms. However, these means offer coarser control of traffic mechanisms. However, these means offer coarser control of traffic
paths, and do not readily offer bandwidth guarantees or fast paths, and do not readily offer bandwidth guarantees or fast
restoration, and therefore will not be discussed further in this restoration, and therefore will not be discussed further in this
document. document.
This document doesn't make any claims with respect to whether it is
possible to have a practical solution that meets all the
requirements listed in this document.
2. Contributing Authors 2. Contributing Authors
This document was the collective work of several. The text and This document was the collective work of several. The text and
content of this document was contributed by the editors and the content of this document was contributed by the editors and the
co-authors listed below (The contact information for the editors co-authors listed below (The contact information for the editors
appears in section 9, and is not repeated below.): appears in section 9, and is not repeated below.):
Kenji Kumaki Kenji Kumaki
KDDI Corporation KDDI Corporation
Garden Air Tower Garden Air Tower
skipping to change at page 16, line 30 skipping to change at page 16, line 30
Once an inter-AS TE LSP has been established and should there be any Once an inter-AS TE LSP has been established and should there be any
resource or other changes inside anyone of transiting ASes, the resource or other changes inside anyone of transiting ASes, the
solution MUST be able to re-optimize the LSP accordingly and solution MUST be able to re-optimize the LSP accordingly and
non-disruptively, either upon expiration of a configurable timer or non-disruptively, either upon expiration of a configurable timer or
triggered by a network event or a manual request at the TE tunnel triggered by a network event or a manual request at the TE tunnel
Head-end. Head-end.
The solution SHOULD provide an option for the Head-End LSRs to The solution SHOULD provide an option for the Head-End LSRs to
control if re-optimizing or not should there exist a more optimal control if re-optimizing or not should there exist a more optimal
path in one of the transit ASes along the inter-AS TE LSP path. path in one of the transit ASes.
In the case of an identical set of traversed path, the solution In the case of an identical set of traversed path, the solution
SHOULD provide an option for the Head-End LSRs to control if SHOULD provide an option for the Head-End LSRs to control if
re-optimizing or not should there exist a more optimal path in one re-optimizing or not should there exist a more optimal path in one
of the transit ASes along the inter-AS TE LSP path. of the transit ASes along the inter-AS TE LSP path.
Furthermore, the solution MUST provide the ability to reject Furthermore, the solution MUST provide the ability to reject
re-optimizatization at AS boundaries. re-optimizatization at AS boundaries.
5.1.6. Fast Recovery support using MPLS TE Fast Reroute 5.1.6. Fast Recovery support using MPLS TE Fast Reroute
skipping to change at page 17, line 22 skipping to change at page 17, line 22
4.1 of [DS-TE] SHOULD also be faithfully applied in the development 4.1 of [DS-TE] SHOULD also be faithfully applied in the development
of the solutions. of the solutions.
5.1.8. Scalability and Hierarchical LSP Support 5.1.8. Scalability and Hierarchical LSP Support
The proposed solution(s) MUST have minimum impact on the network The proposed solution(s) MUST have minimum impact on the network
scalability from both intra and inter-AS perspectives. scalability from both intra and inter-AS perspectives.
This requirement applies to all of the following: This requirement applies to all of the following:
- IGP (impact in terms of IGP flooding, CSPF, etc.). - IGP (impact in terms of IGP flooding, Path computation, etc.).
- BGP (impact in terms of additional information carried within - BGP (impact in terms of additional information carried within
BGP, number of routes, flaps, overload events, etc.). BGP, number of routes, flaps, overload events, etc.).
- RSVP TE (message rate, number of retained states, ,etc.). - RSVP TE (message rate, number of retained states, ,etc.).
It is also conceivable that there would potentially be scalability It is also conceivable that there would potentially be scalability
issues as the number of required inter-AS MPLS TE tunnels increases. issues as the number of required inter-AS MPLS TE tunnels increases.
In order to reduce the number of tunnel states to be maintained by In order to reduce the number of tunnel states to be maintained by
each transiting PoP, the proposed solution SHOULD allow TE LSP each transiting PoP, the proposed solution SHOULD allow TE LSP
aggregation such that individual tunnels can be carried onto one or aggregation such that individual tunnels can be carried onto one or
more aggregating LSP(s). One such mechanism, for example is more aggregating LSP(s). One such mechanism, for example is
skipping to change at page 22, line 31 skipping to change at page 22, line 31
section 5, then it MUST be explicitly documented section 5, then it MUST be explicitly documented
6.2. Performance 6.2. Performance
The solution SHOULD be evaluated taking into account various The solution SHOULD be evaluated taking into account various
performance criteria: performance criteria:
- Degree of path optimality of the inter-AS TE LSP path - Degree of path optimality of the inter-AS TE LSP path
- TE LSP setup time. - TE LSP setup time.
- Fail and restoration time - Fail and restoration time
- Impact and scalability of the control plane due to added
overheads, etc.
Other criteria might be added as this draft will evolve. Other criteria might be added as this draft will evolve.
7. Security Considerations 7. Security Considerations
The proposed solution(s) MUST address security issues across The proposed solution(s) MUST address security issues across
multiple SP administrative domains. Although inter-AS MPLS TE is multiple SP administrative domains. Although inter-AS MPLS TE is
not expected to add specific security extensions beyond those of not expected to add specific security extensions beyond those of
current intra-AS TE, greater considerations MUST be given in terms current intra-AS TE, greater considerations MUST be given in terms
of how to establish a trusted model across AS boundaries. SPs of how to establish a trusted model across AS boundaries. SPs
 End of changes. 

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