RFC 4576

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

File formats:
icon for text file icon for PDF icon for HTML icon for inline errata
Status:
PROPOSED STANDARD
Authors:
E. Rosen
P. Psenak
P. Pillay-Esnault
Stream:
IETF
Source:
ospf (rtg)

Cite this RFC: TXT  |  XML  |   BibTeX

DOI:  https://doi.org/10.17487/RFC4576

Discuss this RFC: Send questions or comments to the mailing list lsr@ietf.org

Other actions: View Errata  |  Submit Errata  |  Find IPR Disclosures from the IETF  |  View History of RFC 4576


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. [STANDARDS-TRACK]


For the definition of Status, see RFC 2026.

For the definition of Stream, see RFC 8729.




Advanced Search