RFC 7611

BGP ACCEPT_OWN Community Attribute

📅 published August 2015, from ietf

RFC 7611: BGP ACCEPT_OWN Community Attribute 🎀

okay bestie, this one is all about BGP route reflectors and VPN routes 🦋

Internet Engineering Task Force (IETF) J. Uttaro, AT&T. Request for Comments: 7611. Category: Standards Track. Authors: P. Mohapatra (Sproute Networks), D. Smith (Cisco Systems), R. Raszuk (Mirantis Inc.), and J. Scudder (Juniper Networks). ISSN: 2070-1721. Date: August 2015.

The header doesn't list anything this RFC obsoletes or updates, so it stands on its own 💅

Abstract

so the idea is this 🌸 Sometimes a BGP route reflector needs to be able to change the Route Target (RT) list on a VPN route it passes along. That lets the route reflector decide how a route from one VPN Routing and Forwarding table (VRF) gets imported into other VRFs. This works great as long as the exporting VRF is not on the same Provider Edge (PE) router as the importing VRF(s). Because of how BGP works, though, it breaks when both are on the same PE. This document changes BGP so the trick works when the VRFs share a PE, and so it can be used the same way across a whole autonomous system ✨

Status of This Memo

This is an Internet Standards Track document. 🫶

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). You can read more about Internet Standards in Section 2 of RFC 5741 📚

Info about the current status of this document, any errata, and how to give feedback can be found at http://www.rfc-editor.org/info/rfc7611.

Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. 🔒

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the date this document was published. Please read these carefully, because they spell out your rights and restrictions for this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License ⚖️

Table of Contents

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
  1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
2.  ACCEPT_OWN Community  . . . . . . . . . . . . . . . . . . . .   3
  2.1.  Route Acceptance  . . . . . . . . . . . . . . . . . . . .   3
  2.2.  Propagating ACCEPT_OWN between Address Families . . . . .   4
  2.3.  Configuration Control . . . . . . . . . . . . . . . . . .   4
3.  Decision Process  . . . . . . . . . . . . . . . . . . . . . .   4
4.  Deployment Considerations . . . . . . . . . . . . . . . . . .   5
5.  Other Applications  . . . . . . . . . . . . . . . . . . . . .   5
6.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
  8.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
  8.2.  Informative References  . . . . . . . . . . . . . . . . .   6
Appendix A.  Local Extranet Application (Non-normative) . . . . .   7
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   8
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1. Introduction 🌈

In some setups, a BGP speaker keeps several VRFs going at once [RFC4364]. Sometimes it's desirable for a route reflector to be able to change the RT list on a VPN route that it distributes. That way the route reflector can control how a route that started in one VRF gets imported into other VRFs. Sure, you could do this control directly on the originator, but in an autonomous system with tons of border routers and really complicated BGP policies, that gets operationally messy 🙈

The route reflector modifying the RT list works well as long as the exporting VRF isn't on the same PE as the importing VRF(s). Due to BGP constraints, though, it doesn't work when they're on the same PE. That's because, according to the BGP specification [RFC4271], a BGP speaker rejects received prefix advertisements that it originated itself. In an autonomous system with route reflectors, the route reflector attaches the ORIGINATOR_ID attribute to UPDATE messages. So if one of those prefix advertisements makes its way back to the originator, the originator can just reject it by checking ORIGINATOR_ID 🔍 The BGP specification also says a route should not be accepted from a peer when its NEXT_HOP attribute matches the receiver's own IP address.

This document proposes a tweak to BGP's behavior by defining a new community [RFC1997] value. That lets the RT list modification trick by the route reflector be used the standard way across an entire autonomous system, whether or not the VRFs are on the same PE or on different ones 💖

1.1. Requirements Language

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]. 📝

2. ACCEPT_OWN Community 👑

This memo defines ACCEPT_OWN, a brand-new well-known BGP community in the First Come First Served [RFC5226] range. IANA assigns it the value 0xFFFF0001. Processing of the ACCEPT_OWN community SHOULD be controlled by configuration. The functionality SHOULD default to being disabled, as Section 2.3 explains in more detail ✨

2.1. Route Acceptance

this is the part where the router gets to be a little bit extra 🦋

A router MAY accept a route whose ORIGINATOR_ID or NEXT_HOP value matches that of the receiving speaker, but only if all of the following are true:

  • Processing of the ACCEPT_OWN community is enabled by configuration.
  • The route in question carries the ACCEPT_OWN community.
  • The route in question originated from a source VRF on the router. The source VRF is a VRF on the router whose configured Route Distinguisher is equal to the Route Distinguisher carried in the route.
  • The route in question is targeted to one or more destination VRFs on the router (as determined by inspecting the Route Target(s)).
  • At least one destination VRF is different from the source VRF.

A route MUST NOT ever be accepted back into its source VRF, even if it carries one or more RTs that match that VRF. 🚫 No exceptions, bestie.

2.2. Propagating ACCEPT_OWN between Address Families

The ACCEPT_OWN community controls propagation of routes that can be linked to a source VRF by checking their Route Distinguisher, and to a target VRF by checking their Route Target list. VPN routes with a Subsequent Address Family Identifier (SAFI) of 128 are one example 🌸 So ACCEPT_OWN SHOULD NOT be attached to any routes that can't be linked to a source VRF. That also means that when routes are propagated into a VRF, the ACCEPT_OWN community SHOULD NOT be propagated. And if a route carrying the ACCEPT_OWN community shows up in an address family that doesn't let the source VRF be looked up, the ACCEPT_OWN community MUST be discarded. An OPTIONAL message may be logged in this case 📋

2.3. Configuration Control

ACCEPT_OWN handling SHOULD be controlled by configuration. If it is controlled by configuration, it MUST default to being disabled. When ACCEPT_OWN is disabled by configuration (whether explicitly or by default), the router MUST NOT apply the special route acceptance rules from Section 2.1. The router SHOULD still apply the propagation rules from Section 2.2 💅

8.1. Normative References

okay so the normative refs are the must-reads, bestie 📚✨ you can't really build this without them:

8.2. Informative References

these ones are more like bonus reading 🧠💅

Appendix A. Local Extranet Application (Non-normative) 🦋

okay this appendix is the coolest bit, no cap 🔥 it's not normative, meaning it's just an example, but it shows the ACCEPT_OWN community doing something iconic: auto-configuring extranets inside MPLS VPN networks ✨

one of the applications for the BGP well-known community in this document is auto-configuration of extranets within MPLS VPN networks. picture this topology:

CE1 --------+
            |
           (VRF 1, RD 1, RT 1)
                    PE1 ................... RR
           (VRF 2, RD 2, RT 2)
            |
CE2 --------+

                   Figure 1: Extranet Application

so here's the tea ☕ PE1 gets a prefix X from CE1. prefix X gets installed in VRF 1 and advertised to the route reflector (RR) with Route Distinguisher (RD) 1 and Route Target (RT) 1, as configured on PE1. the goal is to import prefix X into VRF 2 and advertise it to CE2, so CE1/VRF1 and CE2/VRF2 can have extranet VPN connectivity 🌸

the catch? current BGP mechanisms for MPLS VPNs [RFC4364] make you change the import RT value and/or the import policy for VRF 2 on PE1. ngl that's a whole chore in a network with tons of border routers and complicated BGP policies 😭

enter the new ACCEPT_OWN community value 💜 now the route reflector can just re-advertise prefix X back to PE1 with RT 2 appended. PE1 will accept prefix X even though its ORIGINATOR_ID or NEXT_HOP value matches it, import it into VRF 2 because RT 2 is in the route's Extended Community path attribute, and then figure out the right adjacency rewrite within VRF 1 based on the RD value and the prefix. the presence of RT 1 in that same attribute just gets ignored, since RT 1 belongs to the source VRF 1 🧚

the same thing needs to happen in the reverse direction (VRF 1 learning a route from VRF 2) so you get an extranet VPN built strictly through the route reflector, without changing PE1's BGP policy in any way. iconic, right? 👑

one thing to remember: a router doing this extranet trick can accept a route with its own ORIGINATOR_ID or NEXT_HOP value ONLY if the VRF where the router originated the route is different from the VRF where it accepts the re-advertised route 🙈

Acknowledgments 🫶

the authors would like to thank Yakov Rekhter, Jim Guichard, Clarence Filsfils, John Mullooly, Jeff Haas, Pranav Mehta, and Tamas Mondal for their valuable comments and suggestions 💖 and the decision process changes were suggested by Pranav Mehta to solve the remote extranet problem. main character energy, Pranav 👑

Authors' Addresses 🌈

the crew behind this RFC, with their addresses exactly as they appear:

James Uttaro
AT&T
200 S. Laurel Avenue
Middletown, NJ  07748
United States
Email: uttaro@att.com
Pradosh Mohapatra
Sproute Networks
Email: mpradosh@yahoo.com
David J. Smith
Cisco Systems
111 Wood Avenue South
Iselin, NJ  08830
United States
Email: djsmith@cisco.com
Robert Raszuk
Mirantis Inc.
615 National Ave. #100
Mountain View, CA  94043
United States
Email: robert@raszuk.net
John Scudder
Juniper Networks
1194 N. Mathilda Ave.
Sunnyvale, CA  94089
United States
Email: jgs@juniper.net

that's the whole spec, bestie! 🎀 you did it ✨💅

📦 where this page comes from