RFC 4216
MPLS Inter-Autonomous System (AS) Traffic Engineering (TE) Requirements
RFC 4216: MPLS Inter-Autonomous System (AS) Traffic Engineering (TE) Requirements 🎀
okay bestie, this is RFC 4216 💖. It's an Informational document from the Network Working Group, dated November 2005 ✨. The editors are R. Zhang, Ed. from Infonet Services Corporation and J.-P. Vasseur, Ed. from Cisco Systems, Inc. 💅 It doesn't obsolete or update any other RFCs, since none are listed in its header 🦋.
Status of This Memo 📣
this memo is here to give information to the Internet community 🌸. it does not specify an Internet standard of any kind, and distribution of this memo is unlimited 🫶.
Copyright Notice 🔒
the copyright belongs to the Internet Society, as in Copyright (C) The Internet Society (2005). 💜
Abstract ✨
this doc talks about what's needed to support inter-AS MPLS Traffic Engineering (MPLS TE) 🦋. the main goal is to lay out a set of requirements and scenarios 🎯. from there you get general guidelines for defining, picking, and writing up any technical solution that meets those requirements and supports those scenarios 🔥.
Table of Contents 📚
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................3
2. Contributing Authors ............................................4
3. Definitions and Requirements Statement ..........................5
3.1. Definitions ................................................5
3.2. Objectives and Requirements of Inter-AS Traffic
Engineering ................................................7
3.2.1. Inter-AS Bandwidth Guarantees .......................7
3.2.2. Inter-AS Resource Optimization ......................8
3.2.3. Fast Recovery across ASes ...........................8
3.3. Inter-AS Traffic Engineering Requirements Statement ........9
4. Application Scenarios ...........................................9
4.1. Application Scenarios Requiring Inter-AS Bandwidth
Guarantees .................................................9
4.1.1. Scenario I - Extended or Virtual PoP (VPoP) .........9
4.1.2. Scenario II - Extended or Virtual Trunk ............11
4.1.3. Scenario III - End-to-End Inter-AS MPLS TE
from CE to CE ......................................12
4.2. Application Scenarios Requiring Inter-AS Resource
Optimization ..............................................13
4.2.1. Scenario IV - TE across multi-AS within a
Single SP ..........................................13
4.2.2. Scenario V - Transit ASes as Primary and
Redundant Transport ................................14
5. Detailed Requirements for Inter-AS MPLS Traffic Engineering ....16
5.1. Requirements within One SP Administrative Domain ..........16
5.1.1. Inter-AS MPLS TE Operations and Interoperability ...16
5.1.2. Protocol Signaling and Path Computations ...........16
5.1.3. Optimality .........................................17
5.1.4. Support of Diversely Routed Inter-AS TE LSP ........17
5.1.5. Re-Optimization ....................................18
5.1.6. Fast Recovery Support Using MPLS TE Fast Reroute ...18
5.1.7. DS-TE Support ......................................18
5.1.8. Scalability and Hierarchical LSP Support ...........19
5.1.9. Mapping of Traffic onto Inter-AS MPLS TE Tunnels ...19
5.1.10. Inter-AS MPLS TE Management .......................19
5.1.10.1. Inter-AS MPLS TE MIB Requirements ........19
5.1.10.2. Inter-AS MPLS TE Fault Management
Requirements .............................20
5.1.11. Extensibility .....................................21
5.1.12. Complexity and Risks ..............................21
5.1.13. Backward Compatibility ............................21
5.1.14. Performance .......................................21
5.2. Requirements for Inter-AS MPLS TE across Multiple SP ......22
5.2.1. Confidentiality ....................................22
5.2.2. Policy Control .....................................23
5.2.2.1. Inter-AS TE Agreement Enforcement
Polices ...................................23
5.2.2.2. Inter-AS TE Rewrite Policies ..............24
5.2.2.3. Inter-AS Traffic Policing .................24
6. Security Considerations ........................................24
7. Acknowledgements ...............................................24
8. Normative References ...........................................25
9. Informative References .........................................25
Appendix A. Brief Description of BGP-based Inter-AS Traffic
Engineering ...........................................271. Introduction ✨
okay so the MPLS Traffic Engineering (TE) mechanism in [TE-RSVP] can be used by Service Providers (SPs) to hit some of the biggest goals of network traffic engineering, which are described in [TE-OVW] 💅. those goals boil down to:
- Supporting end-to-end services that need Quality of Service (QoS) guarantees
- Performing network resource optimization
- Providing fast recovery
the catch is that this TE mechanism only works inside one Autonomous System (AS) 😭.
this doc is all about requirements for an inter-AS MPLS Traffic Engineering mechanism 🌈. the idea is that it gets the same set of goals across AS boundaries, whether that's inside a single SP's administrative domains or beyond them 🚀.
the doc also presents application scenarios where an inter-AS traffic engineering mechanism might be needed 🧚. a mechanism could be built based on the requirements here 💜. the scenarios are there to get the conversation going toward a detailed requirements list for this inter-AS Traffic Engineering mechanism 🍓.
quick side note 🙈: other ways of doing traffic engineering exist too. there's the Interior Gateway Protocol (IGP), metrics-based approaches (for use within an AS), and Border Gateway Protocol (BGP) attribute-based approaches (for use across ASes, as described in Appendix A). those give you coarser control over traffic paths. this doc is focused on an MPLS-based, fine-grained approach for inter-AS TE ✨.
this doc doesn't make any claims about whether a practical solution that meets every requirement listed here is actually possible 🫶.
1.1. Conventions Used in This Document 💜
the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC-2119] 🔥.
2. Contributing Authors 🫶
the co-authors below all helped shape the text and content of this doc 💖. (the editors' contact info is in section 9, so it isn't repeated down here 📮.)
Kenji Kumaki
KDDI Corporation
Garden Air Tower
Iidabashi, Chiyoda-ku,
Tokyo 102-8460, JAPAN
EMail : ke-kumaki@kddi.com
Paul Mabey
Qwest Communications
950 17th Street,
Denver, CO 80202, USA
EMail: pmabey@qwest.com
Nadim Constantine
Infonet Services Corporation
2160 E. Grand Ave.
El Segundo, CA 90025. USA
EMail: nadim_constantine@infonet.com
Pierre Merckx
EQUANT
1041 route des Dolines - BP 347
06906 SOPHIA ANTIPOLIS Cedex, FRANCE
EMail: pierre.merckx@equant.com
Ting Wo Chung
Bell Canada
181 Bay Street, Suite 350
Toronto, Ontario, Canada, M5J 2T3
EMail: ting_wo.chung@bell.ca
Jean-Louis Le Roux
France Telecom
2, avenue Pierre-Marzin
22307 Lannion Cedex, France
EMail: jeanlouis.leroux@francetelecom.com
Yonghwan Kim
SBC Laboratories, Inc.
4698 Willow Road
Pleasanton, CA 94588, USA
EMail: Yonghwan_Kim@labs.sbc.com3. Definitions and Requirements Statement 🔥
3.1. Definitions
okay so first up, the glossary 📖 here's the list of abbreviations and acronyms that this doc uses specifically 🎀
- SP: Service Providers, including regional or global providers 🌸
- SP Administrative Domain: a single SP administration over a network or networks, which might be one AS or multiple ASes 🧚
- IP-only networks: an SP's network where IP routing protocols like IGP/BGP are switched on 🌈
- IP/MPLS networks: an SP's network where MPLS switching capabilities and signaling controls (like the ones in [MPLS-ARCH]) are switched on, on top of the IP routing protocols 💜
- Intra-AS TE: a generic term for traffic engineering mechanisms that run over IP-only and/or IP/MPLS networks inside one AS ✨
- Inter-AS TE: a generic term for traffic engineering mechanisms that run over IP-only and/or IP/MPLS networks across one or multiple ASes. Since this document only deals with IP/MPLS networks, any mention of Inter-AS TE here means IP/MPLS networks only, and it is NOT trying to cover IP-only TE requirements 🦋
- TE LSP: an MPLS Traffic Engineering Label Switched Path 🔥
- Intra-AS MPLS TE: an MPLS Traffic Engineering mechanism where the TE Label Switched Path (LSP), the Head-end Label Switching Router (LSR), and the Tail-end LSR all live in the same AS for traffic engineering purposes 🍓
- Inter-AS MPLS TE: an MPLS Traffic Engineering mechanism where the TE LSPs, the Head-end LSR, and the Tail-end LSR do NOT all sit inside the same AS, or where the Head-end LSR and Tail-end LSR are in the same AS but the TE LSP's transit path goes across different ASes 🌸
- ASBRs: Autonomous System Border Routers, used to connect to another AS, whether it belongs to a different SP or the same one, through one or more links that interconnect ASes 🫶
- Inter-AS TE Path: a TE path that goes through multiple ASes and ASBRs, like
AS1-ASBR1-inter-AS link(s)-ASBR2-AS2... ASBRn-ASn🛤️ - Inter-AS TE Segment: a portion of the Inter-AS TE path 💅
- Inter-AS DS-TE: Diffserv-aware Inter-AS TE 👑
- CE: Customer Edge Equipment 💖
- PE: Provider Edge Equipment, which has direct connections to CEs 🎀
- P: Provider Equipment that only has backbone trunk connections 🧚
- VRF: Virtual Private Network (VPN) Routing and Forwarding Instance 🌈
- PoP: a Point of Presence, or a node in an SP's network 🦋
- SRLG: a set of links may count as a 'shared risk link group' (SRLG) if they share a resource whose failure could knock out every link in the set, as defined in [GMPLS-ROUT] 😭
- PCC: Path Computation Client, meaning any client application that asks the Path Computation Element to do a path computation ✨
- PCE: Path Computation Element, an entity (a component, an application, or a network node) that can compute a network path or route based on a network graph and apply computational constraints 💜
Please note that CE, PE, and P are used throughout this document in a generic way. Whenever those acronyms show up, it does NOT automatically mean the CE is connected to a PE in a VRF environment like the one described in [BGP-MPLSVPN] 🙈
3.2. Objectives and Requirements of Inter-AS Traffic Engineering
As mentioned in section 1 above, some SPs want to hit the same set of traffic engineering objectives that are presented in [TE-OVW], but across AS boundaries 🔥
This section looks at these requirements in each of the key related areas: 1) Inter-AS bandwidth guarantees; 2) Inter-AS resource optimization; and 3) fast recovery across ASes, which means recovering Inter-AS links/SRLGs and ASBR nodes 💅
3.2.1. Inter-AS Bandwidth Guarantees
The Diffserv IETF working group has defined a set of mechanisms in [DIFF_ARCH], [DIFF_AF], and [DIFF_EF] or [MPLS-Diff] 🌸 These mechanisms can be turned on at the edge of a Diffserv domain or across the whole thing, and they help enforce a QoS policy (or a bunch of QoS policies). Those policies can be written in terms of things like maximum one-way transit delay, inter-packet delay variation, loss rate, and so on 💖
Lots of SPs have partial or full Diffserv deployments in their networks today, either across the entire network or just minimally on the network edge across CE-PE links 🦋
When strict QoS bounds are needed, admission control inside the backbone is sometimes required on top of the current Diffserv mechanisms 👑
When the propagation delay can be bounded, performance targets like maximum one-way transit delay can be guaranteed by providing bandwidth guarantees along the Diffserv-enabled path 🌈
One typical example is providing bandwidth guarantees over an end-to-end path for VoIP traffic classified in the EF (Expedited Forwarding [DIFF_EF]) class in a Diffserv-enabled network 🎀 When the EF path stretches across multiple ASes, an inter-AS bandwidth guarantee becomes required 😭
Another case for an inter-AS bandwidth guarantee is needing to guarantee a certain amount of transit bandwidth across one or multiple ASes ✨
Several application scenarios are presented in section 4 below to further illustrate this requirement 🧚
3.2.2. Inter-AS Resource Optimization
In Service Provider (SP) networks, the BGP protocol [BGP] is deployed to exchange routing information between ASes 🌸 BGP's inter-AS capabilities can also be used for traffic engineering across AS boundaries. Appendix A gives a quick rundown of the current BGP-based inter-AS traffic engineering practices 💅
SPs have managed to survive with this coarse set of BGP-based traffic engineering tools across inter-AS links in a mostly best-effort environment 💀 Honestly, in lots of cases, plenty of bandwidth inside an SP's network and across inter-AS links means you don't need fancier inter-AS TE policies 🫶
BUT, when an SP network is deployed over multiple ASes (for example, as the number of inter-AS links grows), the complexity of the inter-AS policies and the difficulty of inter-AS TE path optimization climb until it may soon become unmanageable 😭
Another example is when inter-AS links are set up between different SP administrative domains. Nondeterministic factors like uncoordinated routing and network changes, plus sub-optimal traffic conditions, could easily lead to a messy set of inter-AS traffic engineering policies that current traffic engineering mechanisms probably wouldn't scale well for 🙈
In these situations, where resource optimization is required and/or specific routing requirements come up, the BGP-based inter-AS facilities will need to be backed up by a more granular inter-AS traffic engineering mechanism 👑
3.2.3. Fast Recovery across ASes
When services like VoIP get extended across ASes, customers often expect SPs to keep the same level of performance targets, such as packet loss and service availability, that they get within a single AS 🦋 Because of that, fast convergence in a stable fashion after link/SRLG/node failures becomes a strong requirement 🔥 This is really hard to pull off with current inter-domain techniques, especially when links or SRLGs fail between ASBRs, or when ASBR nodes themselves fail 💀
3.3. Inter-AS Traffic Engineering Requirements Statement
Just like with deploying MPLS TE in an SP's network, an inter-AS TE method is needed on top of the BGP-based traffic engineering capabilities. It has to be deployed across inter-AS links wherever resource optimization, bandwidth guarantees, and fast recovery are required 💖
This is extra critical in a Diffserv-enabled, multi-class environment, like the one described in [PSTE], where statistical performance targets must be maintained consistently over the entire path across different ASes 👑
The approach of extending the current intra-AS MPLS TE capabilities [TE-RSVP] across inter-AS links for IP/MPLS networks is being considered here, because there are already available implementations and operational experience with it 🌈
Please note that inter-AS traffic engineering over an IP-only network is left for future consideration, since there isn't enough interest in requirements like the ones for IP/MPLS networks at this time. More specifically, this document only covers the inter-AS TE requirements for packet-based IP/MPLS networks 🎀
4. Application Scenarios ✨
The following sections present a few application scenarios over IP/MPLS networks where requirements can't be addressed with the current intra-AS MPLS TE mechanism, and they bring up considerations for inter-AS MPLS traffic engineering requirements 🧚
Even though it isn't explicitly noted in the discussions that follow, fast recovery of traffic path(s) crossing multiple ASes in a stable fashion is super important when links, SRLGs, or nodes fail at AS boundaries, for all of the application scenarios presented here 🫶
4.1. Application Scenarios Requiring Inter-AS Bandwidth Guarantees
4.1.1. Scenario I - Extended or Virtual PoP (VPoP) 💖
Okay so picture this 🌸. A global service provider (SP1) wants to expand into a region where a regional service provider (SP2) already has a super dense network presence. SP1 can connect with SP2 at one or multiple points in that region. In their customer-dense areas, SP1 can use SP2's network as an extended transport by co-locating aggregation routers in SP2's PoPs 🦋.
To make sure the bandwidth SP2 provides is actually there, and to get some transparency so SP1 isn't fully impacted when SP2's capacity and network conditions change ✨, one or more inter-AS MPLS TE LSPs can be built between SP1's ASBR or PE router inside AS1 and SP1's PE routers co-located in SP2's PoPs. Here's the diagram 👇
<===========Inter-AS MPLS TE Tunnel===========>
----- -----
________|ASBR |___Inter-AS___|ASBR |________
| | RTR | Link | RTR | |
---- ----- ----- ----- -----
|SP1 |_Inter-AS_| SP2 | | SP1 |
|VPoP| Link |P/PE | |P/PE |
---- ----- ----- ----- -----
|________|ASBR |___Inter-AS___|ASBR |________|
| RTR | Link | RTR |
----- -----
<=================Inter-AS MPLS TE Tunnel======================>
+-SP1 AS1-+ +---SP2 AS2-----+ +------SP1 AS1------+In situations where end-to-end Diffserv paths must be maintained 🎀, both SPs' networks may need to provision Diffserv PHB at each hop so they can support a set of traffic classes with compatible performance targets. The stuff about SLA (Service Level Agreement) boundaries, reporting and measuring system interoperability, and support demarcations is beyond the scope of this document, so we're not going deeper into it 🙈.
If either SP1's or SP2's network is not a Diffserv-aware network, the scenario still applies to provide bandwidth guarantees 💅.
SP2, on the other hand, can choose to expand its reach beyond its servicing region over SP1's network via inter-AS MPLS TE tunnels. Mirror energy 🪞✨.
It's worth mentioning that these remote aggregation routers co-located in another SP's network are unlikely to host SP1's IGP and BGP routing planes, and will more likely maintain their own AS or be part of SP1's AS. In this case, such TE tunnels may cross several ASes, but the Head-end and Tail-end LSRs of the TE tunnel may have the same AS number, as shown in the diagram above. Main character energy 👑.
4.1.2. Scenario II - Extended or Virtual Trunk 🦋
Instead of co-locating a PE router in SP2's PoP, SP1 can also choose to aggregate customer VPN sites onto an SP2 PE router, where inter-AS TE tunnels can be built and signaled through SP2's MPLS network. Those tunnels run between the SP2 PoP (where SP1 and customer CEs are directly connected) and SP1's ASBR or PE routers inside SP1's network. This means SP1's customers connected to the SP2 PE router can get a guaranteed bandwidth service, up to the TE LSP tail-end router located in SP1's network 🎀.
In this scenario, there could be two applicable cases 🧚:
Case 1 - the inter-AS MPLS TE tunnel functions as an extended or virtual trunk aggregating SP1's CE's local-loop access circuits on SP2's MPLS network, and the bandwidth can be guaranteed to the TE LSP tail-end router located in SP1's network, as shown in the diagram below:
<====Inter-AS MPLS TE Tunnel====>
or
< ===Inter-AS MPLS TE Tunnel===============>
---- ----- ----- ----- -----
| CE |_____Local___| SP2 |___|ASBR |___Inter-AS___|ASBR |___|SP1 |
| | Loop | PE | | RTR | Link | RTR | |PE |
---- ----- ----- ----- -----
+SP1 Customer ASx+ +-----SP2 AS2---+ +-SP1 AS1-------+Case 2 - the inter-AS MPLS TE tunnel in this case functions as an extended or virtual local access link from SP1's CE on SP2's network to SP1's ASBR or PE:
<==============Inter-AS MPLS TE Tunnel==============>
or
<==============Inter-AS MPLS TE Tunnel========================>
---- ----- ----- ----- -----
| CE |____Local_____| SP2 |___|ASBR |___Inter-AS___|ASBR |___|SP1 |
| | Loop | PE | | RTR | Link | RTR | |PE |
---- ----- ----- ----- -----
+SP1 Customer ASx+ +------SP2 AS2---+ +--SP1 AS1-----+In Case 2 above, SP2 may elect to establish an aggregating or hierarchical intra-AS MPLS TE tunnel between the transiting P or PE router and SP2's ASBR router, just to reduce the number of tunnel states signaled from the SP2 PE to where SP1's CEs are connected 🧠✨.
4.1.3. Scenario III - End-to-End Inter-AS MPLS TE from CE to CE 🌈
In this scenario, as illustrated below, customers need an MPLS TE tunnel from CE1 to CE2, end-to-end, across several SPs' networks 💜.
<======================Inter-AS MPLS TE Tunnel==================>
--- ----- ----- ----- ----- ---
|CE1|_____| SP2 |___|ASBR |__Inter-AS__|ASBR |____| SP1 |_____|CE2|
| | | PE | | RTR | Link | RTR | | PE | | |
--- ----- ----- ----- ----- ---
+Cust ASx+ +---SP2 AS-----+ +-------SP1 AS-------+ +Cust ASy+The diagram below shows another example, where CE1 and CE2 are customers of SP1 with external BGP (eBGP) peering relationships established across the CE-PE links. An inter-AS MPLS TE tunnel may then be established from CE1 in ASx to CE2, which may belong to the same AS or a different AS than CE1, across SP1's network in AS2 🫶.
<===============Inter-AS MPLS TE Tunnel=====================>
--- ----- ---- ---- ----- ---
|CE1|______| SP1 |_____|SP1 |____|SP1 |____| SP1 |_________|CE2|
| | | PE1 | |P1 | |P2 | | PE2 | | |
--- ----- ---- ---- ----- ---
+-Cust ASx-+ +-------------SP1 AS2----------------+ +-Cust ASy-+The above example shows that SP1's network has a single AS. Obviously, there may be multiple ASes between CE1 and CE2, as well as in SP1's network 🌍.
In addition, where both CE1 and CE2 reside in the same AS, they will likely share the same private AS number 🔐.
However, Scenario III will not scale well if there is a greater number of inter-AS TE MPLS tunnels in some degree of partial mesh or full mesh. Therefore, it is expected that this scenario will have few deployments, unless some mechanisms, such as hierarchical intra-AS TE-LSPs, are used to reduce the number of signaling states 😭.
4.2. Application Scenarios Requiring Inter-AS Resource Optimization 🔥
The scenarios presented in this section mainly deal with inter-AS resource optimization 💅.
4.2.1. Scenario IV - TE across multi-AS within a Single SP Administrative Domain 👑
As mentioned in [TE-APP], SPs have generally admitted that the current MPLS TE mechanism provides a great deal of tactical and strategic value in areas of traffic path optimization [TE-RSVP] and rapid local repair capabilities [TE-FRR], via a set of on-line or off-line constraint-based path computation algorithms. It's giving real results 🤩.
From a service provider's perspective, another way of stating the objectives of traffic engineering is to utilize available capacity in the network for delivering customer traffic without violating performance targets, and/or to provide better QoS services via an improved network utilization, more likely operating below congestion thresholds 🌸.
It's worth noting that situations where resource provisioning is not an issue (e.g., low density in inter-AS connectivity or ample inter-AS capacity) may not require more scalable and granular TE facilities beyond BGP routing policies. That's because such policies can be rather simple, and because inter-AS resource optimization is not an absolute requirement 🙃.
However, many SPs, especially those with networks across multiple continents, as well as those with sparsely connected networks, have designed their multi-AS routing policies along or within continental or sub-continental boundaries, where the number of ASes can range from a very few to dozens. Generally, inter-continent or sub-continent capacity is very expensive 💸. Some Service Providers have multiple ASes in the same country and would like to optimize resources over their inter-region links. This would demand a more scalable degree of resource optimization, which warrants considering extending current intra-AS MPLS TE capabilities across inter-AS links 🧚.
In addition, one may only realize higher efficiency in conducting traffic optimization and path protection/restoration planning when coordinating all network resources as a whole, rather than partially 🎯. For a network which may consist of many ASes, this could be realized via the establishment of inter-AS TE LSPs, as shown in the diagram below:
<===================Inter-AS MPLS Tunnel=============>
-------- -------- --------
| |_______________| |____________| |
| SP1 |_______________| SP1 |____________| SP1 |
| AS1 |_______________| AS2 |____________| AS3 |
| | | | | |
-------- -------- --------
|| ||
|| --------- ||
||___________________| SP1 |________________||
|____________________| AS4 |_________________|
| |
---------The motivation for inter-AS MPLS TE is even more prominent in a Diffserv-enabled network, over which statistical performance targets are to be maintained from any point to any point of the network, as illustrated in the diagram below with an inter-AS DS-TE LSP 📊:
<===================Inter-AS MPLS DS-TE Tunnel=============>
---- ----- ----- ----- ----- ----
| PE |__| P |___|ASBR |___Inter-AS___|ASBR |___|P |___|PE |
| RTR| | RTR | | RTR | Link | RTR | |RTR | |RTR |
---- ----- ----- ----- ----- ----
+------------SP1 AS1---------+ +------------SP1 AS2------+For example, the inter-AS MPLS DS-TE LSP shown in the diagram above could be used to transport a set of L2 Pseudo Wires or VoIP traffic with corresponding bandwidth requirements 📞🎀.
Furthermore, fast recovery in case of ASBR-ASBR link failure or ASBR node failure is a strong requirement for such services 🚨💖.
4.2.2. Scenario V - Transit ASes as Primary and Redundant Transport 🦋
okay so Scenario V is another possible deployment case 💅 SP1 with AS1 wants to hook a regional network up to its core backbone by building an inter-AS MPLS TE tunnel over one or multiple transit ASes that belong to SP2, SP3, etc. It looks like this:
<===========Inter-AS MPLS TE Tunnel=======>
[ ] [ ] [ ]
[ ---- ---- ] [ ---- ---- ] [ ---- ---- ]
[ |P/PE|__|ASBR|]_Inter-AS_[|ASBR|.|ASBR|]_Inter-AS_[|ASBR| |P/PE|]
[ |RTR | |RTR |] Link [|RTR | |RTR |] Link [|RTR | |RTR |]
[ ---- ---- ] [ ---- ---- ] [ ---- ---- ]
[ ] [ ] [ ]
<================Inter-AS MPLS TE Tunnel=====================>
+SP1 Regional ASx+ +Transit SP2 AS2,etc...SPi ASi+ +------SP1 AS1-+This is giving Scenario I (section 4.1.1) but bigger 🌸 The "VPoP" could be expanded into a regional network of SP1. By the same token, the AS number for SP1's regional network ASx may be the same as AS1, or it may be different, no cap ✨
The inter-AS MPLS TE LSP in this case may also be used to back up an internal path, as shown below. Just know this could introduce routing complexities 🙈
<===========Inter-AS MPLS TE Tunnel=======>
+----------------------------SP1 AS1-----------------------------+
[ ]
[ ---- ---- ---- ---- ]
[ |P/PE|__|ASBR|__________Primary Intera-AS________|P | |PE |]
[ |RTR | |RTR | Link |RTR | |RTR |]
[ ---- ---- ---- ---- ]
[ | | ]
[ ---- ---- ]
[ |ASBR| |ASBR| ]
[ |RTR | |RTR | ]
[ ---- ---- ]
^ | | ^
| | | |
| | [ ] | |
| | [ ---- ---- ] | |
| |__ Inter-AS_[|ASBR|..|ASBR|]_Inter-AS_| |
| Link [|RTR | |RTR |] Link |
| [ ---- ---- ] |
| [ ] |
| |
+======Backup Inter-AS MPLS TE Tunnel======+
+Transit SP2 AS2,SP3 AS3,etc....SPi ASi+5. Detailed Requirements for Inter-AS MPLS Traffic Engineering 👑
This section is the big one 🔥 It covers detailed requirements in two main areas: 1) requirements for inter-AS MPLS TE in the same SP administrative domain, and 2) requirements for inter-AS MPLS TE across different SP administrative domains.
5.1. Requirements within One SP Administrative Domain 💜
This section presents detailed requirements for inter-AS MPLS TE within the same SP administrative domain.
5.1.1. Inter-AS MPLS TE Operations and Interoperability 🧚
The inter-AS MPLS TE solution SHOULD be consistent with the requirements discussed in [TE-REQ], and the derived solution MUST be such that it will interoperate seamlessly with the current intra-AS MPLS TE mechanism and inherit its capability sets from [TE-RSVP] 🫶
The proposed solution SHOULD allow the provisioning of a TE LSP at the Head/Tail-end with end-to-end Resource Reservation Protocol (RSVP) signaling (eventually with loose paths) traversing across the interconnected ASBRs, without further provisioning required along the transit path ✨
5.1.2. Protocol Signaling and Path Computations 🎀
One can conceive that an inter-AS MPLS TE tunnel path signaled across inter-AS links consists of a sequence of ASes, ASBRs, and inter-AS links 🌈
The proposed solution SHOULD provide the ability either to select explicitly or to auto-discover the following elements when signaling the inter-AS TE LSP path:
- a set of AS numbers as loose hops and/or
- a set of LSRs including ASBRs
It should also specify the above elements in the Explicit Route Object (ERO) and record them in the Record Route Object (RRO) of the Resv message, just to keep track of the set of ASes or ASBRs traversed by the inter-AS TE LSP 📍
In the case of establishing an inter-AS TE LSP traversing multiple ASes within the same SP networks, the solution SHOULD also allow the Head-end LSR to explicitly specify the hops across any one of the transiting ASes. The TE tunnel Head-end SHOULD also check the explicit segment to make sure that the constraints are met 🔍
In addition, the proposed solution SHOULD provide the ability to specify and signal that certain loose or explicit nodes (e.g., AS numbers, etc.) and resources are to be explicitly excluded in the inter-AS TE LSP path establishment, such as the one defined in [EXCLUDE-ROUTE] 🚫
5.1.3. Optimality 💎
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 sub-optimality), since the path may not remain optimal for the lifetime of the LSP 🥹
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:
- a single TE LSP satisfying the required set of constraints cannot be found, in which case it may require load sharing;
- 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);
- path protection (e.g., 1:1 or 1:N) as discussed in [MPLS-Recov].
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 🌸
5.1.5. Re-Optimization 🔁
Once an inter-AS TE LSP has been established, and should there be any resource or other changes inside anyone of the ASes, the solution MUST be able to re-optimize the LSP accordingly and non-disruptively. This can happen either upon expiration of a configurable timer, or upon being triggered by a network event or a manual request at the TE tunnel Head-End 🙌
The solution 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 of the ASes 🎛️
In the case of an identical set of traversed paths, the solution SHOULD provide an option for the Head-End LSRs to control whether re-optimization will occur, because there could exist a more optimal path in one of the transit ASes along the inter-AS TE LSP path 👀
Furthermore, the solution MUST provide the ability to reject re-optimization at AS boundaries 🛑
5.1.6. Fast Recovery Support Using MPLS TE Fast Reroute ⚡
There are, in general, two or more inter-AS links between multiple pairs of ASBRs for redundancy. The topological density between ASes in an SP network with multi-ASes is generally much higher 🕸️
In the event of an inter-AS link failure, rapid local protection SHOULD also be made available, and SHOULD interoperate with the current intra-AS MPLS TE fast re-route mechanism from [TE-FRR] 💫
The traffic routed onto an inter-AS TE tunnel SHOULD also be fast protected against any node failure, where the node could be internal to an AS or at the AS boundary 🛡️
5.1.7. DS-TE Support 🌷
The proposed inter-AS MPLS TE solution SHOULD satisfy the core requirements documented in [DS-TE] 📚
It is worth pointing out that the compatibility clause in section 4.1 of [DS-TE] SHOULD also be faithfully applied to the solution development 🤓
5.1.8. Scalability and Hierarchical LSP Support 📈
The proposed solution(s) MUST have a minimum impact on network scalability from both intra- and inter-AS perspectives 😤
This requirement applies to all of the following:
- IGP (impact in terms of IGP flooding, path computation, etc.)
- BGP (impact in terms of additional information carried within BGP, number of routes, flaps, overload events, etc.)
- RSVP TE (impact in terms of 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. 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 more aggregating LSP(s). One such mechanism, for example, is described in [MPLS-LSPHIE] 🧩
5.1.9. Mapping of Traffic onto Inter-AS MPLS TE Tunnels 🗺️
There SHOULD be several possibilities to map particular traffic to a particular destination onto a specific inter-AS TE LSP 💖
For example, static routing could be used if IP destination addresses are known. Another example is to utilize static routing using recursive BGP route resolution 🪄
The proposed solution SHOULD also provide the ability to "announce" the inter-AS MPLS TE tunnels as a link into the IGPs (ISIS or OSPF), with the link's cost associated with it. By doing so, PE routers that do not participate in the inter-AS TE path computation can take such links into account in their IGP-based SPF computation 🧠
5.1.10. Inter-AS MPLS TE Management ✨
5.1.10.1. Inter-AS MPLS TE MIB Requirements 📚
okay so SPs need an inter-AS TE MIB 🎀 to manage and configure inter-AS traffic engineering tunnels with their network management protocols. bestie, this new MIB SHOULD extend the existing MIBs, not reinvent them 🙅♀️ we love a glow-up, not a total rebrand ✨
the MIB should have features like:
- setting up inter-AS TE tunnels with their constraints (like resources) 💅
- collecting traffic and performance stats not just at the tunnel head-end, but at any other points along the TE tunnel 📊
- including IPv4/v6 + AS# or AS# subobjects in the ERO in the Path message 🛤️ here's what that looks like:
EXPLICIT_ROUTE class object:
address1 (loose IPv4 Prefix, /AS1)
address2 (loose IPv4 Prefix, /AS1)
AS2 (AS number)
address3 (loose IPv4 prefix, /AS3)
address4 (loose IPv4 prefix, /AS3) - destinationor
address1 (loose IPv4 Prefix, /AS1)
address2 (loose IPv4 Prefix, /AS1)
address3 (loose IPv4 Prefix, /AS2)
address4 (loose IPv4 Prefix, /AS2)
address5 (loose IPv4 prefix, /AS3)
address6 (loose IPv4 prefix, /AS3) - destination- same energy for the RRO object in the Resv message 🦋 it records sub-objects like the interface IPv4/v6 address (if not hidden), AS number, a label, a node-id (when required), etc. 💜
- inter-AS specific attributes from section 5 of this document, like inter-AS MPLS TE tunnel accounting records across each AS segment 🧾 the whole receipts era 🤭
5.1.10.2. Inter-AS MPLS TE Fault Management Requirements 🔍
okay so in an MPLS network, an SP wants to catch both control plane and data plane failures 🫠 but the tools for fault detection over LSPs haven't really been built out yet 😭 right now SPs troubleshoot these by hand, hop by hop, across the data path. if they spot an error on the data plane, they then have to check the control plane to figure out where the fault actually came from. that's a lot, bestie 💀
the proposed solution SHOULD be able to interoperate with the fault detection mechanisms of intra-AS TE 🤝 and the inter-AS TE tunnel ending addresses MAY or MAY NOT need to be known or routable across IGP areas (OSPF) or levels (IS-IS) within the transiting ASes, with working return paths 🌸
for example, [LSPPING] is being looked at as a data plane failure detection mechanism (vs. the control plane) and could be used to troubleshoot intra-AS TE LSPs 🔥 if it gets adopted, those facilities SHOULD then be extended to inter-AS TE paths too ✨
but honestly, the example above is one mechanism that DOES need a working return path, so diagnostic test packets can come back over an alternate data plane, like a global IPv4 path, in case the LSP breaks 🦋
[MPLS-TTL] explains how TTL may be processed across hierarchical MPLS networks 🧠 and a facility like that SHOULD also be extended 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 specs evolve 🌈 no locking the door on future upgrades, periodt 🚪✨
5.1.12. Complexity and Risks ⚠️
the proposed solution(s) SHOULD NOT add unnecessary complexity to the current operating network to the point where it affects stability and waters down the benefits of deploying it over SP networks 😬 nobody wants a messy network era 💀
5.1.13. Backward Compatibility 🤝
deploying inter-AS MPLS TE SHOULD NOT impact existing BGP-based traffic engineering or MPLS TE mechanisms 🫶 it should allow a smooth migration or co-existence, no drama, just vibes 💅
5.1.14. Performance 🚀
the solution SHOULD be evaluated against several performance criteria 📈 the list is giving main character energy:
- degree of path optimality of the inter-AS TE LSP path 🎯
- TE LSP setup time ⏱️
- failure and restoration time 🔁
- impact and scalability of the control plane from added overheads, etc. 🧠
- impact and scalability of the data/forwarding plane from added overheads, etc. 📦
5.2. Requirements for Inter-AS MPLS TE across Multiple SP Administrative Domains 🌐
okay bestie, the requirements for inter-AS MPLS TE across multiple SP admin domains SHOULD include everything from section 5.1 above, PLUS the extra stuff in this section 🎀 it's a whole layered look 👑
also, an SP with multi-AS networks may choose NOT to turn on the features in the next two sections when building TE tunnels across ASes in its own domain 🙃 totally valid, no pressure 🫶
5.2.1. Confidentiality 🕵️♀️
since an inter-AS TE LSP may span multiple ASes belonging to different SPs, the solution MIGHT allow hiding the set of hops the TE LSP uses within an AS 🫣 here's the picture:
[ ASBR1-----ASBR2 ]
[ ] [ ]
[ A ] [ B ]
[ AS1 ] [ AS2 ]
[ SP1 ]-----[ SP2 ]
[ ] [ ]so say there's an inter-AS TE LSP from A (inside AS1 of SP1) to B (inside AS2 of SP2) 💌 when computing the path, the set of hops within AS2 might be hidden from AS1 🙈 in that case, the solution lets A learn that the more optimal TE LSP path to B (one that follows the constraints) goes through ASBR2, without needing the detailed list of hops inside AS2 🧚
optionally, the TE LSP path cost within AS2 could be shared with A through something like PCC-PCE communication 📡 so A (the PCC) can use that info to compute an optimal path, even if AS2 doesn't hand over the computed path itself ✨ (see [PCE-COM] for PCC-PCE communication and [PCE] for the PCE-based path computation architecture 📖)
and the management requirements from section 5.1.10 above, when used across different SP admin domains, SHOULD include similar confidentiality requirements discussed here, like "hiding" intermediate hops or interface addresses and/or labels in the transiting or peering SPs 🫢 keep the secrets, keep the tea 🍵
5.2.2. Policy Control 🛂
in some cases, policy control might be needed at the AS boundaries 🚧 specifically ingress policy controls, so SPs can enforce inter-AS policies per their interconnect agreements, or modify some requested parameters carried in incoming inter-AS MPLS TE signaling requests 💁♀️
it's worth noting that this kind of policy control may also be used between ASes within a single SP 🏠
this section only talks about the elements that could form a set of ingress control policies 📝 how SPs actually set up bilateral or multilateral agreements that those policies are built on is beyond the scope of this document 🙅♀️ not our tea to spill here 🫖
5.2.2.1. Inter-AS TE Agreement Enforcement Polices 🛡️
here's the set of TE-LSP parameters in inter-AS TE Requests (RSVP Path Message) that could be enforced at the AS boundaries 🔐
- RSVP-TE session attributes: affinities and preemption priorities 🎨
- per AS or SP bandwidth admission control, so RSVP-TE messages don't request bandwidth resources over their allocation 💸
- request origins, which can be represented by the Head-End tunnel ending IP address, originating AS#, neighbor AS#, neighbor ASBR interface IP address, etc. 📍
- DS-TE TE-Class <Class-Type, Preemption> 🏷️
- FRR attribute: local protection desired bit, node protection desired bit, and bandwidth protection desired bit carried in the
- SESSION ATTRIBUTE or the FAST-REROUTE objects in the RSVP Path message as defined in [TE-FRR] 🔁
- optimization allowed or not allowed ⚖️
in some cases, a TE policy server could also be used to enforce inter-AS TE policies 🖥️ implementations SHOULD allow the use of a policy enforcement server 🙌 this could help SPs make their inter-AS TE policies scale better 📈
if a non-policy-compliant request gets signaled, the policy enforcing node SHOULD generate a RSVP Path Error message towards the Head-end LSR, saying what the cause is 🚨 and the Head-end LSR SHOULD take appropriate actions, like re-routing, once it gets that message 🛣️ no cap, that's a solid plan 💯
5.2.2.2. Inter-AS TE Rewrite Policies ✏️
sometimes SPs need to rewrite some attributes of incoming inter-AS TE signaling requests 🖊️ this could be due to a lack of resources for a particular TE-Class, non-compliant preemption, or mutual agreements 🤝 here's a non-exhaustive list of parameters that could potentially be rewritten at the AS boundaries:
- RSVP-TE session attributes: affinities and preemption priorities 🎨
- DS-TE TE-Class <Class-Type, Preemption> 🏷️
- ERO expansion requests 🧵
similarly, the rewriting node SHOULD generate a RSVP Path Error Message towards the Head-end LSR, indicating the cause in terms of the types of changes made, so the end-to-end integrity of the inter-AS TE LSP is maintained 🧷 receipts again, bestie 🧾
5.2.2.3. Inter-AS Traffic Policing 🚦
the proposed solution SHOULD also provide a set of policing mechanisms that could be configured on the inter-AS links 🛑 the goal is to make sure traffic routed through the tunnel does not exceed the bandwidth negotiated during LSP signaling 📏
for example, an ingress policer could be configured to enforce the traffic contract on the mutually agreed resource requirements of the established inter-AS TE LSP (i.e., RSVP bandwidth) on the interface where the inter-AS link connects 🔒 no overstepping, no exceptions 🙅♀️💅
6. Security Considerations 🔐💀
okay this part is SERIOUS, bestie 😤 the proposed solution(s) MUST address security issues across multiple SP administrative domains 🚨 inter-AS MPLS TE isn't expected to add specific security extensions beyond the ones in current intra-AS TE, BUT way more thought MUST go into how to establish a trusted model across AS boundaries 🧱 SPs SHOULD have a means to authenticate (such as using the RSVP INTEGRITY Object), to allow, and to possibly deny inter-AS signaling requests 🪪 and SPs SHOULD be protected from DoS attacks 🛡️ we are NOT letting the network get flooded, period 😤💥
7. Acknowledgements 🫶
we'd like to thank Yuichi Ikejiri, David Allan, Kurt Erik Lindqvist, Dave McDysan, Christian Jacquenet, Kireeti Kompella, Ed Kern, Jim Boyle, Thomas Nadeau, Yakov Rekhter, and Bert Wijnen for their suggestions and helpful comments during the discussions of this document 💖 the real MVPs 👑
8. Normative References 📚
[TE-REQ] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M.,
and J. McManus, "Requirements for Traffic Engineering
Over MPLS", RFC 2702, September 1999.
[TE-RSVP] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,
V., and G. Swallow, "RSVP-TE: Extensions to RSVP for
LSP Tunnels", RFC 3209, December 2001.
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.9. Informative References ✨
okay bestie, this is the reading list 📚 every single one of these is a real RFC or draft the authors leaned on, so i'm keeping every detail exactly as written 🫶
[MPLS-ARCH]Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. 🧚[BGP-MPLSVPN]Rosen, E. and Y. Rekhter, "BGP/MPLS IP VPNs", Work in Progress, October 2004. 🌸[DIFF_ARCH]Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Service", RFC 2475, December 1998. 💖[DIFF_AF]Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999. 🎀[DIFF_EF]Davie, B., Charny, A., Bennet, J.C., Benson, K., Le Boudec, J., Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002. ✨[MPLS-Diff]Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services", RFC 3270, May 2002. 🦋[TE-OVW]Awduche, D., Chiu, A., Elwalid, A., Widjaja, I., and X. Xiao, "Overview and Principles of Internet Traffic Engineering", RFC 3272, May 2002. 🍓[PSTE]Li, T. and Y. Rekhter, "A Provider Architecture for Differentiated Services and Traffic Engineering (PASTE)", RFC 2430, October 1998. 💜[TE-APP]Boyle, J., Gill, V., Hannan, A., Cooper, D., Awduche, D., Christian, B., and W. Lai, "Applicability Statement for Traffic Engineering with MPLS", RFC 3346, August 2002. 👑[GMPLS-ROUT]Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 🔥[BGP]Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995. 🌈[LSPPING]Kompella, K. and G. Swallow, "Detecting MPLS Data Plane Failures", Work in Progress, May 2005. 🙈[MPLS-TTL]Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks", RFC 3443, January 2003. ⭐[DS-TE]Le Faucheur, F. and W. Lai, "Requirements for Support of Differentiated Services-aware MPLS Traffic Engineering", RFC 3564, July 2003. 💅[TE-FRR]Pan, P., Swallow, G. and A. Atlas, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005. 🫶[MPLS-LSPHIE]Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, September 2005. 🎀[MPLS-Recov]Sharma, V. and F. Hellstrand, "Framework for Multi-Protocol Label Switching (MPLS)-based Recovery", RFC 3469, February 2003. 🌸[EXCLUDE-ROUTE]Lee, CY., Farrel, A., and S. De Cnodder, "Exclude Routes - Extension to RSVP-TE", Work in Progress, August 2005. 🧚[PCE]Farrel, A., Vasseur, J.-P., and J. Ash, "Path Computation Element (PCE) Architecture", Work in Progress, September 2005. 💖[PCE-COM]Vasseur, J.-P., et al., "Path Computation Element (PCE) communication Protocol (PCEP) - Version 1", Work in Progress, September 2005. 🦋
Appendix A. Brief Description of BGP-based Inter-AS Traffic Engineering ✨
okay so this appendix is the vibe check on how service providers were doing inter-AS traffic engineering with BGP back then 🫶
In today's Service Provider (SP) network, BGP is deployed to do two different jobs 💅:
- Setting up a scalable exterior routing plane that's separate from the data forwarding plane inside the SP's own administrative domain 🌸
- Swapping network reachability info with other BGP autonomous systems (ASes), which might belong to a different SP, or just be a different AS inside the same SP network 🧚
Over connections that cross AS boundaries, traffic engineering can also happen through a set of BGP capabilities, as long as you enforce BGP-based inter-AS routing policies properly. The current BGP-based inter-AS traffic engineering practices go like this:
- "Closest exit" routing, where egress traffic from one SP to another follows the path with the lowest IGP or intra-AS MPLS TE tunnel metrics to the
next-HOPof exterior routes learned from other ASes over the inter-AS links 🍓 - "BGP path attribute"-based routing selection, where the egress path is picked by interconnect (peering or transit) policies based on one or a combination of BGP path attributes, like
AS_PATH,MULTI_EXIT_DISC(MED), andLocal_Pref🔥
SPs have often run into a bunch of nondeterministic factors with the inter-AS traffic engineering methods above 😭
Those factors show up as:
- Sub-optimum traffic distribution across inter-AS links 💀
- Nondeterministic traffic condition changes caused by uncoordinated IGP routing policies or topology changes in other ASes, and uncoordinated BGP routing policy changes (MED or as-prepend, etc.) 🙈
To get some extra granularity, SPs may choose to enforce BGP inter-AS policies 👑. These policies are specific to one inter-AS link, or to a set of inter-AS links, for ingress traffic. By tagging certain sets of routes with a specific attribute when announcing them to another AS, ingress traffic from that AS gets steered to certain PoPs or to regions within the SP's network. Of course, this only works if the other AS permits automated egress policy by matching the predefined attribute on incoming routes. ✨
Editors' Addresses
the editors, with their contact details exactly as published 💌
Raymond Zhang
Infonet Services Corporation
2160 E. Grand Ave.
El Segundo, CA 90025
USA
EMail: raymond_zhang@infonet.com
J.-P. Vasseur
Cisco Systems, Inc.
300 Beaver Brook Road
Boxborough, MA 01719
USA
EMail: jpv@cisco.comFull Copyright Statement
the legal bit, but make it cute 🎀
Copyright (C) The Internet Society (2005). 🌈
This document is covered by the rights, licenses and restrictions in BCP 78. Unless that says otherwise, the authors keep all of their rights 💅.
This document and the information in it are provided "AS IS", and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 💀
Intellectual Property
who owns what, and how to ask 🔥
The IETF doesn't take a position on whether any Intellectual Property Rights or other rights that someone might claim over the technology in this document are valid or in scope. It also doesn't say whether licenses for those rights are available, and it hasn't independently gone looking for any of them 🙈. For information on how rights work for RFC documents, check BCP 78 and BCP 79 🧚.
Copies of IPR disclosures sent to the IETF Secretariat, any assurances of licenses that will be made available, and the results of any attempt to get a general license or permission to use proprietary rights, which implementers or users of this specification can ask for, are available from the IETF's online IPR repository at http://www.ietf.org/ipr 🌸.
The IETF invites anyone who's interested to tell it about any copyrights, patents or patent applications, or other proprietary rights that might cover technology needed to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org 💖.
Acknowledgement
the thank-you section 🫶
Funding for the RFC Editor function is currently provided by the Internet Society. 🌈✨
📦 where this page comes from
- ietf: rfc4216 2005-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms