RFC 6368

Internal BGP as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)

📅 published September 2011, from ietf

RFC 6368 💖 Internal BGP as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)

Okay bestie, here's the whole vibe up top 🎀 This is RFC 6368, an Internet Standards Track document from September 2011 ✨ It's an IETF (Internet Engineering Task Force) product. The authors are P. Marques and R. Raszuk from NTT MCL, K. Patel from Cisco Systems, and K. Kumaki and T. Yamagata from KDDI Corporation 🫶 The ISSN is 2070-1721. The header doesn't list anything it obsoletes or updates, so there's nothing extra to chase 🦋

Abstract 🌸

So the abstract says this doc defines protocol extensions and procedures for BGP Provider/Customer Edge router iteration in BGP/MPLS IP VPNs 💅 The big goal is making the BGP/MPLS IP VPN transparent to the customer network, as far as routing information is concerned ✨

Status of This Memo 📜

This is an Internet Standards Track document 🔥 It's a product of the IETF, so it represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG) 👑 For more on Internet Standards, check Section 2 of RFC 5741 🙈 Info about the current status, errata, and how to give feedback lives at http://www.rfc-editor.org/info/rfc6368 🧚

The copyright line is Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. 💜

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as in effect on the date of publication. Read those carefully, because they explain your rights and restrictions 🫠 Code Components extracted from this doc must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions. They're provided without warranty, as described in the Simplified BSD License 💀

Table of Contents 📚

1. Introduction ....................................................2
2. Requirements Language ...........................................3
3. IP VPN as a Route Server ........................................3
4. Path Attributes .................................................5
5. BGP Customer Route Attributes ...................................6
6. Next-Hop Handling ...............................................7
7. Exchanging Routes between Different VPN Customer Networks .......8
8. Deployment Considerations ......................................10
9. Security Considerations ........................................12
10. IANA Considerations ...........................................12
11. Acknowledgments ...............................................12
12. References ....................................................13
   12.1. Normative References .....................................13
   12.2. Informative References ...................................13

1. Introduction 🧚

Okay so in current deployments, when BGP is the Provider/Customer Edge routing protocol, these peering sessions are usually set up as external peering between the VPN provider autonomous system (AS) and the customer network autonomous system 🫠 At every External BGP boundary, BGP path attributes [RFC4271] get modified per standard BGP rules. That includes prepending the AS_PATH attribute with the autonomous-system number of the originating Customer Edge (CE) router and the autonomous-system number(s) of the Provider Edge (PE) router(s) 🍓

To keep those routes from getting rejected by AS_PATH loop detection, a PE router advertising a route it got from a remote PE often remaps the customer network autonomous-system number to its own 🔥 Otherwise, the customer network can use different autonomous-system numbers at different sites, or configure their CE routers to accept routes containing their own AS number 🙈

This works really well when there are no BGP routing exchanges between the client network and other networks. But it has drawbacks for customer networks that use BGP internally for purposes other than interaction between CE and PE routers 💀

To make the BGP/MPLS VPN usage as transparent as possible to any external interaction, it's desirable to define a mechanism where PE-CE routers can exchange BGP routes by means other than External BGP ✨

You can think of a BGP/MPLS VPN as a provider-managed backbone service interconnecting several customer-managed sites 💅 It's not universal, but it's a good starting point 🎀

Regardless of VPN service, networks often use a hierarchical design with either BGP route reflection [RFC4456] or confederations [RFC5065]. This document assumes the IP VPN service interacts with the customer network following a similar model 🫶

2. Requirements Language 📝

Here's the requirement-word rulebook 🤓 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 [RFC2119].

3. IP VPN as a Route Server 🌈

Okay so in a typical backbone/area hierarchical design, routers that attach an area (or site) to the core use BGP route reflection (or confederations) to distribute routes between the top-level core Internal BGP (iBGP) mesh and the local area iBGP cluster 🌸

To get equivalent functionality on a network using a provider-provisioned backbone, you can treat the VPN as the equivalent of an Internal BGP Route Server that multiplexes information from N VPN attachment points 💜

A route learned by any of the PEs in the IP VPN is available to all other PEs that import the Route Target used to identify the customer network. Basically, this is conceptually like a centralized route server 🧚

In a PE router, PE-received routes are not advertised back to other PEs 🙈 This split-horizon technique is what prevents routing loops in an IP VPN environment 💅 It's also consistent with how a top-level mesh of route reflectors (RRs) behaves.

To complete the Route Server model, you need to transparently carry the Internal BGP path attributes of customer network routes through the BGP/MPLS VPN core ✨ That's done with a new BGP path attribute, described below, which lets the customer network attributes get saved and restored at the BGP/MPLS VPN boundaries 🦋

When a route is advertised from PE to CE as an iBGP route, the CE won't advertise it further unless it's itself configured as a route reflector (or has an External BGP session) 💀 That's because of the default BGP behavior of not advertising iBGP routes back to iBGP peers. This behavior is not modified 🧠

On a BGP/MPLS VPN PE, a CE-received route MUST be advertised to other VPN PEs that import the Route Targets associated with the route 🔥 This is independent of whether the CE route was received as an external or internal route. However, a CE-received route is not re-advertised back to other CEs unless route reflection is explicitly configured 👑 That's the equivalent of disabling client-to-client reflection in BGP route reflection implementations.

When reflection is configured on the PE router, with local CE routers as clients, there's no need to internally mesh the multiple CEs that may exist in the site 🫶

This Route Server model can also support a confederation-style abstraction to CE devices. We're choosing not to describe the procedures for that mode in detail right now 🙃 Confederations are considered less common than route reflection in enterprise environments 🍓

4. Path Attributes 🎀

This diagram shows the BGP path attribute stack processing next to the existing BGP/MPLS IP VPN [RFC4364] route processing procedures 🌈

             --> push path attributes --> vrf-export --> BGP/MPLS IP VPN
   VRF route                                             PE-PE route
                                                         advertisement
             <--  pop path attributes <--  vrf-import <--

BGP path attributes received from a customer network get pushed into the stack, before the Export Route Targets are added to the BGP path attributes 💖 Going the other way, the stack is popped following the Import Target processing step that identifies the VPN Routing and Forwarding (VRF) table where a PE-received route is accepted ✨

When the advertising PE does a "push" at the "vrf-export" processing stage, it SHOULD initialize the attributes of the BGP IP VPN route advertisement as it would for a locally originated route from the respective VRF context 🦋

When a PE-received route is imported into a VRF, its IGP metric (as far as BGP path selection is concerned) SHOULD be the metric to the remote PE address, expressed in terms of the service provider metric domain 🧚

For VRF route selection performed at the PE, between routes received from local CEs and remote PEs, customer network IGP metrics SHOULD always be considered higher (and thus least preferred) than local site metrics 👑

When backdoor links are present, this would tend to direct traffic between two sites through the backdoor link for BGP routes originated by a remote site 💀 BGP already has policy mechanisms, such as the LOCAL_PREF attribute, to deal with this type of situation 🫠

When a given CE is connected to more than one PE, it won't advertise a route it receives from a PE to another PE unless it's configured as a route reflector, because of the standard BGP route advertisement rules 🙈

When a CE reflects a PE-received route to another PE, the fact that the original attributes of a route are preserved across the VPN prevents routing loops from forming due to mutual redistribution between the two networks 💅

5. BGP Customer Route Attributes ✨

Okay bestie, so customer routes come with their own BGP path attributes, and we need those to survive the trip through the provider's network totally intact 🫶. This document adds a brand-new attribute to make that happen. Meet ATTR_SET (type code 128) 💖. It's an optional transitive attribute that carries a set of BGP path attributes. An attribute set (ATTR_SET) can hold any BGP attribute that can show up in a BGP UPDATE message, except for the MP_REACH and MP_UNREACH attributes. 🙈

Here's how the encoding looks 🎀:

                   +------------------------------+
                   | Attr Flags (O|T) Code = 128  |
                   +------------------------------+
                   | Attr. Length (1 or 2 octets) |
                   +------------------------------+
                   | Origin AS (4 octets)         |
                   +------------------------------+
                   | Path Attributes (variable)   |
                   +------------------------------+

The Attribute Flags are encoded according to RFC 4271 [RFC4271]. The Extended Length bit decides whether the Attribute Length is one or two octets. 🦋

The attribute value is a 4-octet "Origin AS" value, followed by a variable-length field that follows the BGP UPDATE message path attribute encoding rules. So the total length of this attribute is 4 plus the total length of the encoded attributes. 🌸

A PE router uses the ATTR_SET attribute to stash the original set of BGP attributes it gets from a CE. When a PE router advertises a PE-received route to a CE, it pulls the path attributes right back out of the ATTR_SET attribute. 💅

Basically, the BGP path attributes get "pushed" into this attribute when the route comes in through the VPN, and it works like a stack 🥞. Then they get "popped" back out when the route goes in the PE-to-CE direction. Main character energy for sure ✨.

Using this mechanism keeps the customer network isolated from the attributes used inside the provider network, and vice versa 👑. Attributes like the route reflection cluster list are kept separate too, so the cluster identifiers from the customer network won't get considered by the customer's route reflectors, and the other way around. Iconic. 🧚

The Origin autonomous-system number is there to stop a route that starts in one autonomous system's iBGP from leaking into a different autonomous system without proper AS_PATH manipulation 🔥. It SHOULD contain the autonomous-system number of the customer network that originates the given set of attributes. The value is a 32-bit unsigned integer in network byte order, and that's true whether or not the originating PE supports 4-octet AS numbers [RFC4893] 💜.

The AS_PATH and AGGREGATOR attributes inside an ATTR_SET attribute MUST be encoded using 4-octet AS numbers [RFC4893], no matter what the receiving BGP speaker advertised as its capabilities 🌈. BGP speakers that support the extensions in this document MUST also support RFC 4893 [RFC4893]. Why? To get rid of any ambiguity between 2-octet and 4-octet AS_PATH attribute encoding. Literally no room for confusion 🙈.

The NEXT_HOP attribute SHOULD NOT be included in an ATTR_SET. If it is there anyway, the receiving PE SHOULD ignore it 🍓. Future uses of the ATTR_SET attribute MAY define meaningful semantics for an included NEXT_HOP attribute ⭐.

Now, the ATTR_SET attribute SHALL be considered malformed if any of these apply 💀:

  • Its length is less than 4 octets.
  • The original path attributes carried in the variable-length attribute data include the MP_REACH or MP_UNREACH attribute.
  • The included attributes are malformed themselves.

And if an UPDATE message has a malformed ATTR_SET attribute, it SHALL be handled like this 😭. If its Partial flag is set and its Neighbor-Complete flag is clear, the UPDATE is treated as a route withdraw, as discussed in [OPT-TRANS-BGP]. Otherwise (so the Partial flag is clear, or Neighbor-Complete is set), the procedures of the BGP-4 base specification [RFC4271] MUST be followed with respect to an Optional Attribute Error. No cap, this part is strict 💅.

6. Next-Hop Handling 🦋

Okay, so when BGP/MPLS VPNs aren't in use, the NEXT_HOP attribute in iBGP routes carries the address of the border router that advertised the route into the domain 🌸. The IGP distance to that NEXT_HOP is a huge deal when BGP picks the best route 👀.

But here's the tea: when a BGP/MPLS VPN service is used to interconnect different sites, the customer network runs a different IGP domain. So the metrics between the provider network and the customer network just aren't comparable 💔.

Still, the most important part of a metric is the inter-area metric, and the customer network is the one who knows that number. The intra-area metric is usually negligible, so it's not the main drama 🧚.

Route reflection, for example, needs metrics configured so that inter-cluster or inter-area metrics are always bigger than intra-cluster metrics 📏. That's just how it has to be ✨.

So the approach this document takes is to rewrite the NEXT_HOP attribute at the VRF import/export boundary 🎀. PE routers take the PE-PE IGP distance, calculated by the customer network's IGP, into account when they pick between routes advertised from different PEs. Smart. 👑

The best part of this method? The customer network can run independent IGPs at each site. Lowkey my favourite thing in this whole doc 🫶.

7. Exchanging Routes between Different VPN Customer Networks 💅

Alright, in the traditional model, External BGP sessions are used between the BGP/MPLS VPN PE and CE. In that setup, the PE router identifies itself as belonging to the customer network autonomous system 🥰.

But if you want Internal BGP sessions, the PE router has to identify itself as belonging to the customer AS instead 🔥. To be more specific, the VRF that connects to that customer site gets assigned to the customer AS, not the VPN provider AS. Big switch, honestly ✨.

The Origin AS element in the ATTR_SET path attribute tells you the AS number of the originating VRF 🧚. A receiving PE uses this AS number to identify route exchanges between VRFs in different ASes. It's giving detective work 🔍.

Now, in scenarios like what people call an "extranet" VPN, routes MAY be advertised to both internal and external VPN attachments that belong to different autonomous systems 🌈. Picture this 🎀:

                          +-----+                 +-----+
                          | PE1 |-----------------| PE2 |
                          +-----+                 +-----+
                         /       \                   |
                  +-----+         +-----+         +-----+
                  | CE1 |         | CE2 |         | CE3 |
                  +-----+         +-----+         +-----+
                    AS 1            AS 2            AS 1

So take the example above, where the (PE1, CE1) and (PE2, CE3) sessions are iBGP. In BGP/MPLS VPNs, a route received from CE1 might get distributed to the VRFs for the attachment points of CE2 and CE3 💖.

The goal in a scenario like this is to show the internal peer (CE3) a BGP advertisement with the same BGP path attributes that came from CE1. And to show the external peer (CE2), the advertisement should look like AS 1 and AS 2 have an External BGP session between them 🦋. Both happy, no drama 🫶.

To get there, these rules apply 📜:

When a VPN route that carries the ATTR_SET attribute gets imported into a destination VRF, a PE router MUST check that the "Origin AS" number in the ATTR_SET attribute matches the autonomous system associated with the VRF 🔍.

If the autonomous-system numbers do match, the route is imported into the VRF with the attributes in the ATTR_SET attribute. But if they don't match, the set of attributes for the route SHALL be built like this 🥞:

  1. The path attributes are set to the attributes contained in the ATTR_SET attribute.
  2. iBGP-specific attributes are discarded (LOCAL_PREF, ORIGINATOR, CLUSTER_LIST, etc).
  3. The "Origin AS" number contained in the ATTR_SET attribute is prepended to the AS_PATH, following the rules that would apply to an External BGP peering between the source and destination ASes.
  4. If the autonomous system associated with the VRF is the same as the VPN provider autonomous system, and the AS_PATH attribute of the VPN route is not empty, it SHALL be prepended to the AS_PATH attribute of the VRF route.

When advertising the VRF route to an External BGP peer, a PE router SHALL apply steps 1 to 4 above, and then prepend its own autonomous-system number to the AS_PATH attribute 🌸. For example, say the route started in a VRF that supports Internal BGP peering and the ATTR_SET attribute, and it gets advertised to a CE that's set up in the traditional External BGP mode. Then the originator AS, the VPN AS_PATH segment, and the customer network AS all get prepended to the AS_PATH. Math that actually works 🧮.

And when a route without the ATTR_SET attribute gets imported into a VRF that's configured in a different autonomous system, a PE router MUST prepend the VPN provider AS number to the AS_PATH 🌈.

One last thing, and it's a big one 👑: in every case where a route with the ATTR_SET attribute is imported, the attributes on the VPN route, other than NEXT_HOP, get ignored. That goes for route selection in the VRF Adj-RIB-In and for route advertisement to a CE router 🙈. In other words, the information in the ATTR_SET attribute overrides the VPN route attributes on "vrf-import". Periodt 💅✨.

8. Deployment Considerations ✨

okay bestie, so here's the deal 💅 it is RECOMMENDED that different VRFs of the same VPN (think: different PE routers) that are set up with iBGP PE-CE peering sessions use different Route Distinguisher (RD) values 🎀. otherwise, if the same RD gets used, the BGP IP VPN infrastructure might pick just ONE BGP customer path for a given IP Network Layer Reachability Information (NLRI) 😭 and it won't have access to the detailed path info stored in the ATTR_SET attribute. not cute!

remember how we said the model here is a "Route Server"? the IP VPN hands the customer network ALL the BGP paths the CEs know about 🦋. which basically means you need unique RDs per VRF. it's giving consistency ✨

the whole goal of this extension is to keep the customer network isolated from the BGP path attribute stuff the IP VPN does, and also keep the service provider network isolated from any attributes the customer slips in 💖. for example, BGP communities can be used to influence how the IP VPN infrastructure behaves 👀. with this extension, the service provider network can carry those attributes along transparently without messing with its own operations. main character energy for the provider network 👑

another moment of "wait, that's a problem" 🙈: what if the same service provider AS number is used for both Internet service AND the IP VPN service? in that case it's pretty common for a VPN customer route to contain the provider's AS number 🌸. the IP VPN should still work transparently here, same as in every other case 🫶

this protocol extension is designed so that each PE VRF acts like a router in the configured AS 🧚. before this, VRFs only operated in the provider network's AS. the VPN backbone connects VRFs in the same AS, and it also connects VRFs across different ASes (subject to the appropriate policies) 🌈. when VRFs are in the same AS, the VPN backbone works as a top-level route reflection mesh 💜. when they're in different ASes, the provider network sets up an implicit peering relationship between the ASes that originate and import a specific route 🍓

this extension also works when the VPN backbone spans multiple ASes 🦋. when the Inter-AS operation follows option b) or c) from Section 10 of [RFC4364], the provider networks can influence the route attributes and route selection of VPN routes while still giving the customer AS a transparent service ✨. either Internal BGP connectivity or extranets can be provided to the customer AS 💅

⚠️ bestie, this part is important: when VPN provider networks interconnect via option a), there is NO way to give a fully transparent service 😭. by definition, option a) means each autonomous-system border router (ASBR) has a VRF tied to the customer VPN that's configured to operate in the respective provider AS. those ASBR VRFs then talk to their peer provider ASes via External BGP 🔥

still, it IS possible to have all the customer VRFs within one provider network configured in the same customer AS 🎀. that customer AS will then peer with the provider AS implicitly at the ASBR, and the ASBR will explicitly peer with a second provider AS 🦋. but this is NOT a scenario where transparency to the customer AS is possible 🙈

9. Security Considerations 🔐

okay this section is SO important, so let's look at it from two angles: the IP VPN provider and the IP VPN customer 💖

from the IP VPN provider's perspective, this mechanism makes sure there's separation between the BGP path attributes the CE router advertises and the BGP attributes used inside the provider network 🛡️. so it can potentially improve security 🫶

now, this is mostly implementation dependent, BUT right now a CE device CAN inject BGP attributes (extended communities, for example) that have meaning on the IP VPN provider network 😱, unless the PE is explicitly configured to disable that 🚫

with the rules for the ATTR_SET path attribute, any attribute received from a CE gets pushed onto the stack before the route is advertised to other PEs 📚

just like with any other field based on values from an external system, an implementation MUST consider input validation and resource management issues 🙏

wait, I said MUST? yep, let's be clear about it: an implementation must consider the issues of input validation and resource management. no shade, just facts 💅

from the VPN customer network's perspective, it's our opinion that there's no change to the security profile of PE-CE interaction ✨. an iBGP session lets the PE specify extra attributes that aren't allowed on an External BGP session (LOCAL_PREF, for example) 👀, but this doesn't significantly change the fact that the VPN customer has to trust its service provider to give it correct routing information 🥺

10. IANA Considerations 📋

this document defines a new BGP path attribute that lives in a registry managed by IANA 🎀. IANA has updated its BGP Path Attributes registry with the value specified above (128) for the ATTR_SET path attribute 🌸

11. Acknowledgments 🫶

the authors want to thank Stephane Litkowski and Bruno Decraene for their comments 💖

12. References 📚

12.1. Normative References

[RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC4271]   Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
            Border Gateway Protocol 4 (BGP-4)", RFC 4271,
            January 2006.

[RFC4364]   Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
            Networks (VPNs)", RFC 4364, February 2006.

[RFC4456]   Bates, T., Chen, E., and R. Chandra, "BGP Route
            Reflection: An Alternative to Full Mesh Internal BGP
            (IBGP)", RFC 4456, April 2006.

[RFC4893]   Vohra, Q. and E. Chen, "BGP Support for Four-octet AS
            Number Space", RFC 4893, May 2007.

[RFC5065]   Traina, P., McPherson, D., and J. Scudder, "Autonomous
            System Confederations for BGP", RFC 5065, August 2007.

12.2. Informative References

[OPT-TRANS-BGP]
            Scudder, J. and E. Chen, "Error Handling for Optional
            Transitive BGP Attributes", Work in Progress,
            September 2010.

Authors' Addresses 📮

Pedro Marques

EMail: pedro.r.marques@gmail.com


Robert Raszuk
NTT MCL
101 S. Ellsworth Avenue Suite 350
San Mateo, CA  94401
US

EMail: robert@raszuk.net


Keyur Patel
Cisco Systems
170 W. Tasman Dr.
San Jose, CA  95134
US

EMail: keyupate@cisco.com


Kenji Kumaki
KDDI Corporation
Garden Air Tower
Iidabashi
Chiyoda-ku, Tokyo  102-8460
Japan

EMail: ke-kumaki@kddi.com


Tomohiro Yamagata
KDDI Corporation
Garden Air Tower
Iidabashi
Chiyoda-ku, Tokyo  102-8460
Japan

EMail: to-yamagata@kddi.com
📦 where this page comes from