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

[[e-mail]]

A new Request for Comments is now available in online RFC libraries.

        
        RFC 4576

        Title:      Using a Link State Advertisement 
                    (LSA) Options Bit to Prevent Looping 
                    in BGP/MPLS IP Virtual Private Networks 
                    (VPNs) 
        Author:     E. Rosen, P. Psenak,
                    P. Pillay-Esnault
        Status:     Standards Track
        Date:       June 2006
        Mailbox:    [e-mail], 
                    [e-mail], 
                    [e-mail]
        Pages:      7
        Characters: 15149
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-ospf-2547-dnbit-04.txt

        URL:        http://www.rfc-editor.org/rfc/rfc4576.txt

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]

This document is a product of the Open Shortest Path First IGP
Working Group of the IETF.

This is now a Proposed Standard Protocol.

STANDARDS TRACK: 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.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [e-mail].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [e-mail].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [e-mail] with the message body 

help: ways_to_get_rfcs. For example:

        To: [e-mail]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
[e-mail].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...



_______________________________________________
IETF-Announce mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ietf-announce