RFC 4576

Using a Link State Advertisement (LSA) Options Bit to Prevent Looping in BGP/MPLS IP Virtual Private Networks (VPNs)

📅 published June 2006, from ietf

Okay bestie, this is RFC 4576 🎀 It's a Standards Track doc from the Network Working Group, dated June 2006, written by E. Rosen, P. Psenak, and P. Pillay-Esnault, all three from Cisco Systems, Inc. 💅 It doesn't say it obsoletes or updates anything, so it's its own main character 👑

Status of This Memo ✨

This document specifies an Internet standards track protocol for the Internet community, and asks for discussion and suggestions for improvements. Check the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

Copyright (C) The Internet Society (2006).

Abstract 🦋

This doc lays out a procedure for a sticky situation that can pop up when a Service Provider (SP) gives a customer "BGP/MPLS IP VPN" service and that customer uses OSPFv2 to advertise its routes to the SP 🫶 Here's the setup: a Customer Edge (CE) Router and a Provider Edge (PE) Router are OSPF peers, and customer routes get sent over OSPFv2 from the CE to the PE. Those routes get turned into BGP routes, BGP carries them across the backbone to other PE routers, and then they get turned back into OSPF routes and sent over OSPF to other CE routers. Because everything is converting back and forth, some of the info needed to prevent loops can get lost 🙈

So we need a procedure that makes sure once a route goes from a PE to a CE, any PE that gets it back from a CE will ignore it. This doc uses one of the options bits in the LSA (Link State Advertisements) to say "this LSA has already been forwarded by a PE, so any other PEs that see it should ignore it" 🔥

Table of Contents 🧚

   1. Introduction ....................................................2
   2. Specification of Requirements ...................................3
   3. Information Loss and Loops ......................................3
   4. Using the LSA Options to Prevent Loops ..........................4
   5. Security Considerations .........................................5
   6. Acknowledgements ................................................5
   7. Normative References ............................................6

1. Introduction 💜

[VPN] describes how an SP can use its IP backbone to give customers an "IP VPN" service. In that setup, a customer's edge devices (CE devices) hook up to the provider's edge routers (PE routers). Each CE device lives in a single Virtual Private Network (VPN), but each PE device can attach to several CEs, from the same VPN or different ones. So a VPN is basically a set of "network segments" connected by the SP's backbone 🍓

A CE swaps routes with a PE using a routing protocol that the customer and the SP both agreed on. The PE runs that protocol's decision process (aka it does the routing computation) to figure out the set of IP address prefixes where both of these are true:

  • Each address prefix in the set can be reached via that CE.
  • The path from that CE to each such address prefix does not include the SP backbone (i.e., it does not include any PE routers).

The PE routers attached to a particular VPN redistribute routes to these address prefixes into BGP, so they can share the VPN's routes with each other. BGP carries these routes in the "VPN-IPv4 address family", which keeps them separate from ordinary Internet routes. That family also extends the IP addresses on the left, so address prefixes from two different VPNs are always distinct to BGP, even if both VPNs use the same piece of the private RFC 1918 address space. That means routes from different VPNs can ride along in one BGP instance and sit in one BGP table with no fear of conflict ✨

If a PE gets a particular VPN-IPv4 route via BGP, and that PE is attached to a CE in the VPN the route belongs to, BGP's decision process may install that route in the BGP route table. If it does, the PE translates the route back into an IP route and redistributes it to the routing protocol running on the link to that CE.

This is the "peer model" 💅 CE routers peer with PE routers, but CE routers at different sites do not peer with each other.

If a VPN uses OSPFv2 as its internal routing protocol, that doesn't automatically mean its CE routers use OSPFv2 to peer with the PE routers. Each site in a VPN can use OSPFv2 as its intra-site routing protocol while using BGP or RIP (for example) to distribute routes to a PE router. However, it's honestly super convenient to use OSPFv2 intra-site on the PE-CE link too, and [VPN] explicitly allows this. In that case, a PE runs a separate instance of OSPFv2 for each VPN attached to it, so the PE will generally have multiple VPN-specific OSPFv2 routing tables 🎀

When OSPFv2 is used on a PE-CE link that belongs to a particular VPN, the PE router must redistribute certain routes that have been installed in the BGP routing table into that VPN's OSPFv2 instance. Likewise, a PE router must redistribute routes that have been installed in the VPN-specific OSPF routing tables into BGP. The procedures for this are in [VPN-OSPF] 🧠

The routes that get redistributed from BGP into OSPFv2 are advertised in LSAs that the PE originates. The PE acts as an OSPF border router, advertising some of these routes in AS-external LSAs and some in summary LSAs, as specified in [VPN-OSPF].

Finally, when a PE gets an LSA from a CE router, it runs the OSPF routing computation. Any route that gets installed in the OSPF routing table must be translated into a VPN-IPv4 route and then redistributed into BGP. BGP then distributes these routes to the other PE routers 🦋

2. Specification of Requirements 📜

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.

3. Information Loss and Loops 😭

A PE, say PE1, may learn a route to a particular VPN-IPv4 address prefix via BGP. That can cause it to generate a summary LSA or an AS-external LSA in which it reports that address prefix. This LSA may then be distributed to a particular CE, say CE1. The LSA may then be distributed throughout a particular OSPF area, reaching another CE, say CE2. CE2 may then distribute the LSA to another PE, say PE2.

As the previous section said, PE2 must run the OSPF routing computation to figure out whether a particular address prefix, reported in an LSA from CE2, is reachable from CE2 via a path that does not include any PE router. Unfortunately, there is no standard way to do this 💀 The OSPFv2 LSAs don't necessarily carry the info PE2 needs to tell that the path to address prefix X in a particular LSA from CE2 is actually a path that includes, say, PE1. If PE2 then leaks X into BGP as a VPN-IPv4 route, PE2 is violating one of the constraints for loop-freedom in BGP; viz., that routes learned from a particular BGP domain are not redistributed back into that BGP domain. This could cause a routing loop to be created 🙈

So we need a way for an LSA to carry the info that a particular address prefix has been learned from a PE router. Any PE router that receives an LSA with this info would leave that info out of its OSPF routing computation, so it wouldn't leak the info back into BGP 🔥

When a PE generates an AS-external LSA, it could use a distinct tag value to indicate that the LSA is carrying info about an address prefix whose path includes a PE router. However, this method isn't available when the PE generates a Summary LSA. Per [VPN-OSPF], each PE router must function as an OSPF area 0 router. If the PE-CE link is an area 0 link, then the PE can receive, over that link, a summary LSA that originated at another PE router. Thus, we need some way of marking a summary LSA to indicate that it's carrying info about a path via a PE router 🎀

4. Using the LSA Options to Prevent Loops 🔐

The high-order bit of the LSA Options field (a previously unused bit) is used to solve the problem described in the previous section. We refer to this bit as the DN bit. When a type 3, 5, or 7 LSA is sent from a PE to a CE, the DN bit MUST be set. The DN bit MUST be clear in all other LSA types.

                  +-------------------------------------+
                  | DN | * | DC | EA | N/P | MC | E | * |
                  +-------------------------------------+

                         Options Field with DN Bit
                          (RFC 2328, Section A.2)

When the PE receives, from a CE router, a type 3, 5, or 7 LSA with the DN bit set, the information from that LSA MUST NOT be used during the OSPF route calculation. As a result, the LSA is not translated into a BGP route. The DN bit MUST be ignored in all other LSA types 🫶

This prevents routes learned via BGP from being redistributed to BGP. (This restriction is analogous to the usual OSPF restriction that inter-area routes learned from area 0 are not passed back to area 0.) 💖

Note that the DN bit has no other effect on LSA handling. In particular, an LSA with the DN bit set will be put in the topological database, aged, flooded, etc., just as if DN were not set ✨

Authors' Addresses 🎀

okay bestie, here are the three people who wrote this one, with their addresses so you can reach them 💌

Eric C. Rosen
Cisco Systems, Inc.
1414 Massachusetts Avenue
Boxborough, MA 01719

EMail: erosen@cisco.com


Peter Psenak
Cisco Systems
BA Business Center, 9th Floor
Plynarenska 1
Bratislava 82109
Slovakia

EMail: ppsenak@cisco.com


Padma Pillay-Esnault
Cisco Systems
3750 Cisco Way
San Jose, CA 95134

EMail: ppe@cisco.com

Copyright (C) The Internet Society (2006). 🌸

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. So the authors still own their rights, but BCP 78 has the fine print 📜

This document and the information contained herein are provided on an "AS IS" basis 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 🦋

okay so the IETF doesn't take a side on whether any IPR claims are valid or how far they reach, and it doesn't say whether licenses would be available either. It also doesn't claim it went looking for any of those rights itself 🙈 If you want the procedures for rights in RFC documents, check BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat, plus any assurances of licenses that might be made available (or the results of trying to get a general license or permission for implementers or users to use those proprietary rights), can be found in the IETF's online IPR repository at http://www.ietf.org/ipr 💜

The IETF also invites anyone who knows about copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard to let them know. Send that info to the IETF at ietf-ipr@ietf.org ✨

Acknowledgement 🌈

Funding for the RFC Editor function comes from the IETF Administrative Support Activity (IASA). Thank you IASA, you're literally keeping the lights on 🧚

📦 where this page comes from