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)
|
|
Last updated |
|
2015-10-14
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
pdf
html
bibtex
|
| Stream |
WG state
|
|
(None)
|
|
Document shepherd |
|
No shepherd assigned
|
| IESG |
IESG state |
|
RFC 4576 (Proposed Standard)
|
|
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
Show full document text