{"draft":"draft-ietf-ospf-2547-dnbit-04","doc_id":"RFC4576","title":"Using a Link State Advertisement (LSA) Options Bit to Prevent Looping in BGP\/MPLS IP Virtual Private Networks (VPNs)","authors":["E. Rosen","P. Psenak","P. Pillay-Esnault"],"format":["ASCII","HTML"],"page_count":"7","pub_status":"PROPOSED STANDARD","status":"PROPOSED STANDARD","source":"Open Shortest Path First IGP","abstract":"This document specifies a procedure that deals with a particular\r\nissue that may arise when a Service Provider (SP) provides \"BGP\/MPLS\r\nIP VPN\" service to a customer and the customer uses OSPFv2 to\r\nadvertise its routes to the SP.  In this situation, a Customer Edge\r\n(CE) Router and a Provider Edge (PE) Router are OSPF peers, and\r\ncustomer routes are sent via OSPFv2 from the CE to the PE.  The\r\ncustomer routes are converted into BGP routes, and BGP carries them\r\nacross the backbone to other PE routers.  The routes are then\r\nconverted back to OSPF routes sent via OSPF to other CE routers.  As a\r\nresult of this conversion, some of the information needed to prevent\r\nloops may be lost.  A procedure is needed to ensure that once a route\r\nis sent from a PE to a CE, the route will be ignored by any PE that\r\nreceives it back from a CE.  This document specifies the necessary\r\nprocedure, using one of the options bits in the LSA (Link State\r\nAdvertisements) to indicate that an LSA has already been forwarded by\r\na PE and should be ignored by any other PEs that see it.  [STANDARDS-TRACK]","pub_date":"June 2006","keywords":["service provider","sp","provider edge","pe","OSPF"],"obsoletes":[],"obsoleted_by":[],"updates":[],"updated_by":[],"see_also":[],"doi":"10.17487\/RFC4576","errata_url":"https:\/\/www.rfc-editor.org\/errata\/rfc4576"}