Using a Link State Advertisement (LSA) Options Bit to Prevent Looping in BGP/MPLS IP Virtual Private Networks (VPNs)
RFC 4576
Document | Type | RFC - Proposed Standard (June 2006; No errata) | |
---|---|---|---|
Authors | Padma Pillay-Esnault , Eric Rosen , Peter Psenak | ||
Last updated | 2015-10-14 | ||
Stream | Internet Engineering Task Force (IETF) | ||
Formats | plain text html pdf htmlized (tools) htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 4576 (Proposed Standard) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Alex Zinin | ||
Send notices to | Rohit Dube <rohit@utstar.com> |
Network Working Group E. Rosen Request for Comments: 4576 P. Psenak Category: Standards Track P. Pillay-Esnault Cisco Systems, Inc. June 2006 Using a Link State Advertisement (LSA) Options Bit to Prevent Looping in BGP/MPLS IP Virtual Private Networks (VPNs) Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to 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 Notice Copyright (C) The Internet Society (2006). Abstract This document specifies a procedure that deals with a particular issue that may arise when a Service Provider (SP) provides "BGP/MPLS IP VPN" service to a customer and the customer uses OSPFv2 to advertise its routes to the SP. In this situation, a Customer Edge (CE) Router and a Provider Edge (PE) Router are OSPF peers, and customer routes are sent via OSPFv2 from the CE to the PE. The customer routes are converted into BGP routes, and BGP carries them across the backbone to other PE routers. The routes are then converted back to OSPF routes sent via OSPF to other CE routers. As a result of this conversion, some of the information needed to prevent loops may be lost. A procedure is needed to ensure that once a route is sent from a PE to a CE, the route will be ignored by any PE that receives it back from a CE. This document specifies the necessary procedure, using one of the options bits in the LSA (Link State Advertisements) to indicate that an LSA has already been forwarded by a PE and should be ignored by any other PEs that see it. Rosen, et al. Standards Track [Page 1] RFC 4576 Prevent Looping in BGP/MPLS IP VPNs June 2006 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 a method by which a Service Provider (SP) can use its IP backbone to provide an "IP VPN" service to customers. In that sort of service, a customer's edge devices (CE devices) are connected to the provider's edge routers (PE routers). Each CE device is in a single Virtual Private Network (VPN). Each PE device may attach to multiple CEs of the same or of different VPNs. A VPN thus consists of a set of "network segments" connected by the SP's backbone. A CE exchanges routes with a PE, using a routing protocol to which the customer and the SP jointly agree. The PE runs that routing protocol's decision process (i.e., it performs the routing computation) to determine the set of IP address prefixes for which the following two conditions hold: - 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 that attach to a particular VPN redistribute routes to these address prefixes into BGP, so that they can use BGP to distribute the VPN's routes to each other. BGP carries these routes in the "VPN-IPv4 address family", so that they are distinct from ordinary Internet routes. The VPN-IPv4 address family also extends the IP addresses on the left so that 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. Thus, routes from different VPNs can be carried by a single BGP instance and can be stored in a common BGP table without fear of conflict. If a PE router receives a particular VPN-IPv4 route via BGP, and if that PE is attached to a CE in the VPN to which the route belongs, then BGP's decision process may install that route in the BGP route table. If so, the PE translates the route back into an IP route and Rosen, et al. Standards Track [Page 2] RFC 4576 Prevent Looping in BGP/MPLS IP VPNs June 2006 redistributes it to the routing protocol that is running on the link to that CE.Show full document text