draft-ietf-tewg-interas-mpls-te-req-02.txt   draft-ietf-tewg-interas-mpls-te-req-03.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-02.txt CISCO Systems, Inc draft-ietf-tewg-interas-mpls-te-req-03.txt CISCO Systems, Inc
November 2003 December 2003
Expires: May 2004 Expires: June 2004
MPLS Inter-AS Traffic Engineering requirements MPLS Inter-AS Traffic Engineering requirements
draft-ietf-tewg-interas-mpls-te-req-02.txt draft-ietf-tewg-interas-mpls-te-req-03.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 2, line 26 skipping to change at page 2, line 26
1. Introduction.......................................................3 1. Introduction.......................................................3
2. Contributing Authors...............................................4 2. Contributing Authors...............................................4
3. Definitions and Requirements Statement.............................5 3. Definitions and Requirements Statement.............................5
3.1. Definitions......................................................5 3.1. Definitions......................................................5
3.2. Objectives and Requirements of Inter-AS Traffic Engineering......6 3.2. Objectives and Requirements of Inter-AS Traffic Engineering......6
3.2.1. Inter-AS Bandwidth Guarantees..................................6 3.2.1. Inter-AS Bandwidth Guarantees..................................6
3.2.2. Inter-AS Resource Optimization.................................7 3.2.2. Inter-AS Resource Optimization.................................7
3.2.3. Fast Recovery across ASes......................................8 3.2.3. Fast Recovery across ASes......................................8
3.3. Inter-AS Traffic Engineering Requirements Statement..............8 3.3. Inter-AS Traffic Engineering Requirements Statement..............8
4. Application Scenarios..............................................8 4. Application Scenarios..............................................8
4.1. Application Scenarios Requiring Inter-AS Bandwidth Guarantees....8 4.1. Application Scenarios Requiring Inter-AS Bandwidth Guarantees....9
4.1.1. Scenario I - Extended or Virtual PoP...........................9 4.1.1. Scenario I - Extended or Virtual PoP...........................9
4.1.2. Scenario II - Extended or Virtual Trunk.......................10 4.1.2. Scenario II - Extended or Virtual Trunk.......................10
4.1.3. Scenario III - End-to-end Inter-AS MPLS TE From CE to CE......11 4.1.3. Scenario III - End-to-end Inter-AS MPLS TE From CE to CE......11
4.2. Application Scenarios Requiring Inter-AS Resource Optimization..12 4.2. Application Scenarios Requiring Inter-AS Resource Optimization..12
4.2.1. Scenario IV - TE across multi-AS within a Single SP 4.2.1. Scenario IV - TE across multi-AS within a Single SP
Administrative Domain.........................................12 Administrative Domain.........................................12
4.2.2. Scenario V - Transit ASes as Primary and Redundant Transport..13 4.2.2. Scenario V - Transit ASes as Primary and Redundant Transport..13
5. Detailed Requirements for Inter-AS MPLS Traffic Engnineering......14 5. Detailed Requirements for Inter-AS MPLS Traffic Engnineering......14
5.1. Requirements within one SP Administrative Domain................14 5.1. Requirements within one SP Administrative Domain................14
5.1.1. Inter-AS MPLS TE Operations and Interoperability..............14 5.1.1. Inter-AS MPLS TE Operations and Interoperability..............14
5.1.2. Protocol Signaling and Path Computations......................15 5.1.2. Protocol Signaling and Path Computations......................15
5.1.3. Optimality....................................................15 5.1.3. Optimality....................................................15
5.1.4. Support of diversely routed inter-AS TE LSP...................16 5.1.4. Support of diversely routed inter-AS TE LSP...................15
5.1.5. Re-optimization...............................................16 5.1.5. Re-optimization...............................................16
5.1.6. Fast Recovery support using MPLS TE Fast Reroute..............16 5.1.6. Fast Recovery support using MPLS TE Fast Reroute..............16
5.1.7. DS-TE Support.................................................17 5.1.7. DS-TE Support.................................................17
5.1.8. Hierarchical LSP Support......................................17 5.1.8. Scalability and Hierarchical LSP Support......................17
5.1.9. Mapping of traffic onto Inter-AS MPLS TE Tunnels..............17 5.1.9. Mapping of traffic onto Inter-AS MPLS TE Tunnels..............17
5.1.10. Inter-AS MPLS TE Management..................................17 5.1.10. Inter-AS MPLS TE Management..................................18
5.1.10.1. Inter-AS MPLS TE MIB Requirements..........................17 5.1.10.1. Inter-AS MPLS TE MIB Requirements..........................18
5.1.10.2. Inter-AS MPLS TE Fault Management Requirements.............18 5.1.10.2. Inter-AS MPLS TE Fault Management Requirements.............18
5.1.11. Extensibility................................................19
5.1.12. Complexity and Risks.........................................19
5.1.13. Backward Compatibility.......................................19
5.2. Requirements for Inter-AS MPLS TE across Multiple SP 5.2. Requirements for Inter-AS MPLS TE across Multiple SP
Administrative Domains..........................................19 Administrative Domains..........................................19
5.2.1. Confidentiality...............................................19 5.2.1. Confidentiality...............................................19
5.2.2. Policy Control................................................20 5.2.2. Policy Control................................................20
5.2.2.1. Inter-AS TE Agreement Enforcement Polices...................20 5.2.2.1. Inter-AS TE Agreement Enforcement Polices...................20
5.2.2.2. Inter-AS TE Rewrite Policies................................21 5.2.2.2. Inter-AS TE Rewrite Policies................................21
5.2.2.3 Inter-AS Traffic Policing....................................21
6. Evaluation Criteria...............................................21 5.2.2.3 Inter-AS Traffic Policing....................................21
6.1. Detailed Requirement Satisfactions..............................21 6. Evaluation Criteria...............................................22
6.2. Scalability and Extensibility...................................21 6.1. Detailed Requirement Satisfactions..............................22
6.3. Complexity and Risks............................................22 6.2. Performance.....................................................22
6.4. Performance.....................................................22
6.5. Backward Compatibility..........................................22
7. Security Considerations...........................................22 7. Security Considerations...........................................22
8. Acknowledgement...................................................21 8. Acknowledgement...................................................22
9. Editor's Addresses................................................23 9. Editor's Addresses................................................23
10. Normative References.............................................23 10. Normative References.............................................23
11. Informative References...........................................24 11. Informative References...........................................24
12. Full Copyright Statement.........................................25 12. Full Copyright Statement.........................................25
Appendix A. Brief Description of BGP based Inter-AS Traffic Appendix A. Brief Description of BGP based Inter-AS Traffic
Engineering..............................................26 Engineering..............................................26
1. Introduction 1. Introduction
The MPLS Traffic Engineering mechanism documented in [TE-RSVP] may The MPLS Traffic Engineering mechanism documented in [TE-RSVP] may
skipping to change at page 6, line 11 skipping to change at page 6, line 11
ASBR Routers: Border routers used to connect to another AS of a ASBR Routers: Border routers used to connect to another AS of a
different or the same Service Provider via one or more different or the same Service Provider via one or more
links inter-connecting between ASes. links inter-connecting between ASes.
Inter-AS TE Path: An TE path traversing multiple ASes and ASBRs, Inter-AS TE Path: An TE path traversing multiple ASes and ASBRs,
e.g. AS1-ASBR1-inter-AS link(s)-ASBR2-AS2... e.g. AS1-ASBR1-inter-AS link(s)-ASBR2-AS2...
ASBRn-ASn. ASBRn-ASn.
Inter-AS TE Segment: A portion of the Inter-AS TE path. Inter-AS TE Segment: A portion of the Inter-AS TE path.
PCS: Path Computation Server (e.g. an LSR or an off-line tool)
PCC: Path Computation Client (e.g. an LSR)
CE: Customer Edge Equipment CE: Customer Edge Equipment
PE: Provider Edge Equipment that has direct connections to CEs. PE: Provider Edge Equipment that has direct connections to CEs.
P: Provider Equipment that has backbone trunk connections only. P: Provider Equipment that has backbone trunk connections only.
VRF: Virtual Private Network (VPN) Routing and Forwarding Instance. VRF: Virtual Private Network (VPN) Routing and Forwarding Instance.
PoP: Point of presence or a node in SP's network. PoP: Point of presence or a node in SP's network.
skipping to change at page 14, line 52 skipping to change at page 14, line 52
This section presents detailed requirements for inter-AS MPLS TE This section presents detailed requirements for inter-AS MPLS TE
within the same SP administrative domain. within the same SP administrative domain.
5.1.1. Inter-AS MPLS TE Operations and Interoperability 5.1.1. Inter-AS MPLS TE Operations and Interoperability
The inter-AS MPLS TE solution SHOULD be consistent with requirements The inter-AS MPLS TE solution SHOULD be consistent with requirements
discussed in [TE-REQ] and the derived solution MUST be such that discussed in [TE-REQ] and the derived solution MUST be such that
it will interoperate seamlessly with current intra-AS MPLS TE it will interoperate seamlessly with current intra-AS MPLS TE
mechanism and inherit its capability sets from [TE-RSVP]. mechanism and inherit its capability sets from [TE-RSVP].
The proposed solution MUST allow to provision at the Head/Tail end The proposed solution SHOULD allow to provision at the Head/Tail end
with end-to-end RSVP signaling (eventually with loose paths) with end-to-end RSVP signaling (eventually with loose paths)
traversing across the interconnected ASBRs, without further traversing across the interconnected ASBRs, without further
provisioning required along the transit path. provisioning required along the transit path.
5.1.2. Protocol Signaling and Path Computations 5.1.2. Protocol Signaling and Path Computations
One can conceive that an inter-AS MPLS TE tunnel path signaled One can conceive that an inter-AS MPLS TE tunnel path signaled
across inter-AS links consists of a sequence of intra-AS segments. across inter-AS links consists of a sequence of intra-AS segments.
The proposed solution SHOULD provide the ability to either The proposed solution SHOULD provide the ability to either
explicitly select or auto-discover the following elements explicitly select or auto-discover the following elements
when signaling the inter-AS TE LSP path: when signaling the inter-AS TE LSP path:
- a set of AS numbers as loose HoPs - a set of AS numbers as loose HoPs
- a set of ASBR LSRs - a set of LSRs including ASBRs
and to specify the above elements in the ERO and record them in the and to specify the above elements in the ERO and record them in the
RRO of the Resv message just to keep track of the set of ASes or RRO of the Resv message just to keep track of the set of ASes or
ASBRs traversed by the inter-As TE LSP. ASBRs traversed by the inter-As TE LSP.
For example, one may provide a manual description of all or some of
the hops (loose routing) the TE LSP must traverse, allowing to keep
the information related to the intra-AS resources confidential while
still leaving intra-AS routing decisions to local operators. The
solution may allow the Head-end LSR to compute the TE LSP
path up to the next entry point in the next hop AS.
In the case of establishing inter-AS TE LSP traversing multiple ASes In the case of establishing inter-AS TE LSP traversing multiple ASes
within the same SP networks, the solution SHOULD also allow the within the same SP networks, the solution SHOULD also allow the
Headend LSR to explicitly specify the hops across anyone of Headend LSR to explicitly specify the hops across anyone of
the transiting ASes and the TE tunnel headhend SHOULD also check the transiting ASes and the TE tunnel headhend SHOULD also check
the explicit segment to make sure that the constrainsts are met. the explicit segment to make sure that the constrainsts are met.
In another example, an automated way of setting up the TE LSP
without any static configuration on the Head-End LSR. In that case,
it might require a discovery mechanism of some PCS using IGP
extensions (as defined in [OSPF-TE-CAP], for example), as well as
some signaling protocol extension to request the computation of an
inter-AS TE LSP to a PCS(s) such as one defined in [PATH-COMP].
In addition, The proposed solution SHOULD also provide the ability In addition, The proposed solution SHOULD also provide the ability
to specify and signal that certain loose or explicit nodes and to specify and signal that certain loose or explicit nodes (e.g. AS
resources to be explicitly excluded in the inter-AS TE LSP path numbers, etc.) and resources to be explicitly excluded in the
establishment, such as one defined in [EXCLUDE-ROUTE] for instance. inter-AS TE LSP path establishment, such as one defined in
[EXCLUDE-ROUTE] for instance.
5.1.3 Optimality 5.1.3 Optimality
The solution SHOULD allow the set up of an inter-AS TE LSP that 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 complies with a set of TE constraints defined in [TE-REQ]) and
follow an optimal path. follow an optimal path.
An optimal path is defined as a path whose end-to-end cost is 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 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 the case of an inter-AS path across several ASes having completely
different IGP metric policies, the notion of minimal path might different IGP metric policies, the notion of minimal path might
require IGP metric normalization, for example. require IGP metric normalization, for example.
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 suboptimality since the path may not remain
optimal for the life-time of the LSP
5.1.4 Support of diversely routed inter-AS TE LSP 5.1.4 Support of diversely routed inter-AS TE LSP
In some cases it might be desirable to set up multiple inter-AS TE In some cases it might be desirable to set up multiple inter-AS TE
LSPs between a pair of LSRs, when: LSPs between a pair of LSRs, when:
(1) A single TE LSP satisfying the required set of constraints (1) A single TE LSP satisfying the required set of constraints
cannot be found, in which case it may require load splitting. cannot be found, in which case it may require load splitting.
(2) Multiple TE paths may be required to limit the impact of a (2) Multiple TE paths may be required to limit the impact of a
network element failure to a portion of the traffic. As an network element failure to a portion of the traffic. As an
skipping to change at page 16, line 36 skipping to change at page 16, line 28
5.1.5. Re-optimization 5.1.5. Re-optimization
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 support the ability for intermediate nodes to The solution SHOULD provide an option for the Head-End LSRs to
signal the respective Head-End LSRs of the existence of a more control if re-optimizing or not should there exist a more optimal
optimal path. path in one of the transit ASes along the inter-AS TE LSP path.
The solution SHOULD also be such that an inter-AS TE LSP is In the case of an identical set of traversed path, the solution
re-signaled again (via make before break) if and only if a more SHOULD provide an option for the Head-End LSRs to control if
optimal path exists. re-optimizing or not should there exist a more optimal path in one
of the transit ASes along the inter-AS TE LSP path.
Furthermore the solution SHOULD provide the ability of manually Furthermore, the solution MUST provide the ability to reject
rejecting re-optimization 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
There are in general two or more inter-AS links between multiple There are in general two or more inter-AS links between multiple
pair of ASBRs for redundancy. The topological density between ASes pair of ASBRs for redundancy. The topological density between ASes
in a SP network with multi-ASes is generally much higher. In the in a SP network with multi-ASes is generally much higher. In the
event of an inter-AS link failure, rapid local protection SHOULD event of an inter-AS link failure, rapid local protection SHOULD
also be made available and interoperate with current intra-AS MPLS also be made available and interoperate with current intra-AS MPLS
TE fast re-route mechanism from [TE-FRR]. TE fast re-route mechanism from [TE-FRR].
skipping to change at page 17, line 19 skipping to change at page 17, line 15
5.1.7. DS-TE Support 5.1.7. DS-TE Support
The proposed inter-AS MPLS TE solution SHOULD also satisfy core The proposed inter-AS MPLS TE solution SHOULD also satisfy core
requirements documented in [DS-TE] and interoperate seamlessly with requirements documented in [DS-TE] and interoperate seamlessly with
current intra-AS MPLS DS-TE mechanism [DSTE-PROT]. current intra-AS MPLS DS-TE mechanism [DSTE-PROT].
It is worth pointing out that the compatibility clause in section It is worth pointing out that the compatibility clause in section
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. Hierarchical LSP Support 5.1.8. Scalability and Hierarchical LSP Support
It is conceivable that there would potentially be scalability issues The proposed solution(s) MUST have minimum impact on the network
as the number of required inter-AS MPLS TE tunnels increases. In scalability from both intra and inter-AS perspectives.
order to reduce the number of tunnel states to be maintained by each
transiting PoP, the proposed solution SHOULD allow TE LSP This requirement applies to all of the following:
- IGP (impact in terms of IGP flooding, CSPF, etc.).
- BGP (impact in terms of additional information carried within
BGP, number of routes, flaps, overload events, etc.).
- RSVP TE (message rate, number of retained states, ,etc.).
It is also conceivable that there would potentially be scalability
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
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
described in [MPLS-LSPHIE]. described in [MPLS-LSPHIE].
5.1.9. Mapping of traffic onto Inter-AS MPLS TE Tunnels 5.1.9. Mapping of traffic onto Inter-AS MPLS TE Tunnels
There SHOULD be several possibilities to map a particular traffic There SHOULD be several possibilities to map a particular traffic
to a particular destination onto a specific inter-AS TE LSP. to a particular destination onto a specific inter-AS TE LSP.
For example, static routing could be used if IP destination For example, static routing could be used if IP destination
skipping to change at page 19, line 14 skipping to change at page 19, line 19
The above example, however depicts one such mechanism that does The above example, however depicts one such mechanism that does
require a working return path such that diagnostic test packets can require a working return path such that diagnostic test packets can
return via an alternate data plane, such as a global IPv4 path in return via an alternate data plane, such as a global IPv4 path in
the event that the LSP is broken. the event that the LSP is broken.
[MPLS-TTL] presents how TTL may be processed across a hierarchical [MPLS-TTL] presents how TTL may be processed across a hierarchical
MPLS networks and such a facility as this SHOULD also be extended MPLS networks and such a facility as this SHOULD also be extended
to inter-AS TE links. to inter-AS TE links.
5.1.11. Extensibility
The solution(s) MUST allow extensions as both inter-AS MPLS TE and
current intra-AS MPLS TE specifications evolve.
5.1.12. Complexity and Risks
The proposed solution(s) SHOULD not introduce unnecessary complexity
to the current operating network to such a degree that it would
affect the stability and diminish the benefits of deploying such a
solution over SP networks.
5.1.13. Backward Compatibility
The deployment of inter-AS MPLS TE SHOULD not have impact on
existing BGP-based traffic engineering or MPLS TE mechanisms to
allow for a smooth migration or co-existence.
5.2. Requirements for Inter-AS MPLS TE across Multiple SP 5.2. Requirements for Inter-AS MPLS TE across Multiple SP
Administrative Domains. Administrative Domains.
The requirements for inter-AS MPLS TE across multiple SP admin The requirements for inter-AS MPLS TE across multiple SP admin
domains SHOULD include all requirements discussed in section 5.1 domains SHOULD include all requirements discussed in section 5.1
above in addition to what are presented in this section here. above in addition to what are presented in this section here.
Please note that the SP with multi-AS networks may choose not to Please note that the SP with multi-AS networks may choose not to
turn on the features discussed in the following two sections when turn on the features discussed in the following two sections when
building TE tunnels across ASes in its own domain. building TE tunnels across ASes in its own domain.
skipping to change at page 20, line 47 skipping to change at page 21, line 20
desired bit and bandwidth protection desired bit carried in the desired bit and bandwidth protection desired bit carried in the
SESSION SESSION
- ATTRIBUTE or the FAST-REROUTE objects in the RSVP Path message - ATTRIBUTE or the FAST-REROUTE objects in the RSVP Path message
as defined in [TE-FRR]. as defined in [TE-FRR].
- Optimization allowed or not. - Optimization allowed or not.
In some cases, a TE policy server could also be used for the In some cases, a TE policy server could also be used for the
enforcement of inter-AS TE policies. This requirement could allow enforcement of inter-AS TE policies. This requirement could allow
SPs to make the inter-AS TE policies scale better. SPs to make the inter-AS TE policies scale better.
The signaling of a non policy compliant request MUST trigger the The signaling of a non policy compliant request SHOULD trigger the
generation of a RSVP Path Error message by the policy enforcing generation of a RSVP Path Error message by the policy enforcing
node towards the Head-end LSR, indicating the cause. The node towards the Head-end LSR, indicating the cause. The
Head-end LSR SHOULD take appropriate actions, such as re-route, upon Head-end LSR SHOULD take appropriate actions, such as re-route, upon
receipt of such a message. receipt of such a message.
5.2.2.2. Inter-AS TE Rewrite Policies 5.2.2.2. Inter-AS TE Rewrite Policies
In some situations, SPs may need to rewrite some attributes of the In some situations, SPs may need to rewrite some attributes of the
incoming inter-AS TE signaling requests due to for example, a lack incoming inter-AS TE signaling requests due to for example, a lack
of resources for a particular TE-Class, non compliant preemption, of resources for a particular TE-Class, non compliant preemption,
upon mutual agreements. The following lists a set of parameters upon mutual agreements. The following lists a set of parameters
that can potentially be rewritten at the AS boundaries: that can potentially be rewritten at the AS boundaries:
- RSVP-TE session attributes: affinities and preemption - RSVP-TE session attributes: affinities and preemption
priorities priorities
- DS-TE TE-Class <Class-Type, Preemption>. - DS-TE TE-Class <Class-Type, Preemption>.
- ERO expansion requests - ERO expansion requests
Simimarly, the re-writing node MUST generate a RSVP Path Error Simimarly, the re-writing node SHOULD generate a RSVP Path Error
Message towards the Head-end LSR indicating the cause in terms Message towards the Head-end LSR indicating the cause in terms
of types of changes made so as to maintain the end-to-end integrity of types of changes made so as to maintain the end-to-end integrity
of inter-AS TE LSP. of inter-AS TE LSP.
5.2.2.3 Inter-AS Traffic Policing 5.2.2.3 Inter-AS Traffic Policing
The proposed solution SHOULD also provide a set of policing The proposed solution SHOULD also provide a set of policing
mechanisms which could be configured on the inter-AS links, mechanisms which could be configured on the inter-AS links,
to ensure that traffic routed through the tunnel does not exceed to ensure that traffic routed through the tunnel does not exceed
the bandwidth negotiated during LSP signaling. the bandwidth negotiated during LSP signaling.
skipping to change at page 21, line 50 skipping to change at page 22, line 20
This section provides general guidelines, which could be applied in This section provides general guidelines, which could be applied in
the selection of an optimum solution. the selection of an optimum solution.
6.1. Detailed Requirement Satisfactions 6.1. Detailed Requirement Satisfactions
The proposed solution SHOULD include at least all of the The proposed solution SHOULD include at least all of the
Application Scenarios presented in section 4 above. It MUST meet all Application Scenarios presented in section 4 above. It MUST meet all
the requirements described in section 5 each time a MUST is the requirements described in section 5 each time a MUST is
specified. specified.
6.2. Scalability and Extensibility If a solution can fulfill just a subset of those requirements in
section 5, then it MUST be explicitly documented
The proposed solution(s) MUST have minimum impact on the network
scalability from both intra and inter-AS perspectives.
This requirement applies to both of the following:
- IGP (impact in terms of IGP flooding, SPF, etc.).
- BGP (impact in terms of additional information carried within
BGP, number of routes, flaps, overload events, etc.).
- RSVP TE (message rate, number of retained states, ,etc.).
In addition, the solution(s) MUST allow extensions as both inter-AS
MPLS TE and current intra-AS MPLS TE specifications evolve.
6.3. Complexity and Risks
The proposed solution (s) SHOULD not introduce unnecessary
complexity to the current operating network to such a degree that it
would affect the stability and diminish the benefits of deploying
such solution over SP networks.
6.4. 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
Other criteria might be added as this draft will evolve. Other criteria might be added as this draft will evolve.
6.5. Backward Compatibility
The deployment of inter-AS MPLS TE SHOULD not have impact on
existing BGP-based traffic engineering or MPLS TE mechanisms to
allow for a smooth migration or co-existence.
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
SHOULD have a means to authenticating, such as using RSVP INTEGRITY SHOULD have a means to authenticating, such as using RSVP INTEGRITY
object, allowing and possibly denying inter-AS signaling requests object, allowing and possibly denying inter-AS signaling requests
and SHOULD be protected from DoS attacks. and SHOULD be protected from DoS attacks.
8. Acknowledgement 8. Acknowledgement
We would like to thank Yuichi Ikejiri, David Allan, Kurt Erik We would like to thank Yuichi Ikejiri, David Allan, Kurt Erik
Lindqvist, Dave McDysan, Christian Jacquenet, Kireeti Kompella, Lindqvist, Dave McDysan, Christian Jacquenet, Kireeti Kompella,
Ed Kern, Jim Boyle and Thomas Nadeauor for their suggestions and Ed Kern, Jim Boyle, Thomas Nadeauor and Yakov Rekhter for their
helpful comments during the discussions of this draft. suggestions and helpful comments during the discussions of this
draft.
9. Editor's Addresses 9. Editor's Addresses
Raymond Zhang Raymond Zhang
Infonet Services Corporation Infonet Services Corporation
2160 E. Grand Ave. 2160 E. Grand Ave.
El Segundo, CA 90025 El Segundo, CA 90025
USA USA
Email: raymond_zhang@infonet.com Email: raymond_zhang@infonet.com
skipping to change at line 1311 skipping to change at line 1306
etc.) etc.)
In addition, to achieve some degrees of granularity, SPs may choose In addition, to achieve some degrees of granularity, SPs may choose
to enforce BGP inter-AS policies that are specific to one or a set to enforce BGP inter-AS policies that are specific to one or a set
of inter-AS links for ingress traffic destined to certain PoPs or of inter-AS links for ingress traffic destined to certain PoPs or
regions within SP's network from another AS by tagging certain sets regions within SP's network from another AS by tagging certain sets
of routes with a specific attribute when announcing to another AS. of routes with a specific attribute when announcing to another AS.
This of course goes under the assumption that the other AS permits This of course goes under the assumption that the other AS permits
automated egress policy by matching the predefined attribute from automated egress policy by matching the predefined attribute from
incoming routes. incoming routes.
<x-flowed>
</x-flowed>
 End of changes. 

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