Search RFCs

RFC Editor

File formats:

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 listlsr@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 particularissue that may arise when a Service Provider (SP) provides "BGP/MPLSIP VPN" service to a customer and the customer uses OSPFv2 toadvertise its routes to the SP. In this situation, a Customer Edge(CE) Router and a Provider Edge (PE) Router are OSPF peers, andcustomer routes are sent via OSPFv2 from the CE to the PE. Thecustomer routes are converted into BGP routes, and BGP carries themacross the backbone to other PE routers. The routes are thenconverted back to OSPF routes sent via OSPF to other CE routers. As aresult of this conversion, some of the information needed to preventloops may be lost. A procedure is needed to ensure that once a routeis sent from a PE to a CE, the route will be ignored by any PE thatreceives it back from a CE. This document specifies the necessaryprocedure, using one of the options bits in the LSA (Link StateAdvertisements) to indicate that an LSA has already been forwarded bya PE and should be ignored by any other PEs that see it. [STANDARDS-TRACK]

For the definition ofStatus,seeRFC 2026.

For the definition ofStream, seeRFC 8729.