Internet DRAFT - draft-ouldbrahim-l1vpn-bgp-auto-discovery
draft-ouldbrahim-l1vpn-bgp-auto-discovery
l1vpn WG Hamid Ould-Brahim
Don Fedyk
Internet Draft Nortel
Expiration Date: September 2006
Yakov Rekhter
Juniper Networks
March 2006
BGP-based Auto-Discovery for L1VPNs
draft-ouldbrahim-l1vpn-bgp-auto-discovery-01.txt
Status of this Memo
By submitting this Internet-Draft, each author represents
that any applicable patent or other IPR claims of which he
or she is aware have been or will be disclosed, and any of which
he or she becomes aware will be disclosed, in accordance with
Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet
Engineering Task Force (IETF), its areas, and its working
groups. Note that other groups may also distribute working
documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as
"work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed
at http://www.ietf.org/shadow.html.
Abstract
The purpose of this draft is to define a BGP-based auto-
discovery mechanism for layer-1 VPNs. The auto-discovery
mechanism for l1vpns allows the provider network devices to
dynamically discover the set of PEs having ports attached to
CEs member of the same VPN. That information is necessary for
completing the signaling phase. One main objective of l1vpn
auto-discovery mechanism is to support "single-end
provisioning" model, where addition of a new port to a given
l1vpn would involve configuration changes only on the PE that
has this port and on the CE that is connected to the PE via
this port.
Ould-Brahim, Rekhter March 2006 [Page 1]
draft-ouldbrahim-l1vpn-bgp-auto-discovery-01.txt September 2006
1. Introduction
The purpose of this draft is to define a BGP-based auto-
discovery mechanism for layer-1 VPNs. The auto-discovery
mechanism for l1vpns allows the provider network devices to
dynamically discover the set of PEs having ports attached to
CEs member of the same VPN. That information is necessary for
completing the signaling phase. One main objective of l1vpn
auto-discovery mechanism is to support "single-end
provisioning" model, where addition of a new port to a given
l1vpn would involve configuration changes only on the PE that
has this port and on the CE that is connected to the PE via
this port.
The auto-discovery mechanism proceeds by having a PE advertises
to other PEs, at a minimum, its own IP address and the list of
<private address, provider address> tuples local to that PE.
Once that information is received, the remote PEs will identify
the list of VPN members they have in common with the
advertising PE, and use the information carried within the
discovery mechanism to perform address resolution during
signaling phase.
PE PE
+---------+ +--------------+
+--------+ | +------+| | +----------+ | +--------+
| VPN-A | | |VPN-A || | | VPN-A | | | VPN-A |
| CE1 |--| |PIT || BGP route | | PIT | |-| CE2 |
+--------+ | | ||<----------->| | | | +--------+
| +------+| Distribution| +----------+ |
| | | |
+--------+ | +------+| | +----------+ | +--------+
| VPN-B | | |VPN-B || -------- | | VPN-B | | | VPN-B |
| CE1 |--| |PIT ||-( GMPLS )--| | PIT | |-| CE2 |
+--------+ | | || (Backbone ) | | | | +--------+
| +------+| --------- | +----------+ |
| | | |
+--------+ | +-----+ | | +----------+ | +--------+
| VPN-C | | |VPN-C| | | | VPN-C | | | VPN-C |
| CE1 |--| |PIT | | | | PIT | |-| CE2 |
+--------+ | | | | | | | | +--------+
| +-----+ | | +----------+ |
+---------+ +--------------+
Figure 1 BGP auto-discovery for l1vpn
This version of the draft focuses on describing an auto-
discovery mechanism for the basic mode only. Details for the
Ould-Brahim et al. March 2006 [Page 2]
draft-ouldbrahim-l1vpn-bgp-auto-discovery-01.txt September 2006
enhanced mode will be described in future revised version of
this draft.
2. Procedures
In the context of l1vpns, a CE is connected to a PE via one or
more ports, where each port may consists of one or more
channels or sub-channels. Each port on a CE that connects the
CE to a PE has an identifier that is unique within that l1vpn
(but need not be unique across several l1vpn). We refer to this
identifier as the customer port identifier (CPI). Each port on
a PE has as well an identifier that is unique within that
provider network. We refer to this identifier as the provider
port identifier (PPI). Note that IP addresses used for CPIs,
PPIs could be either IPv4 or IPv6 addresses.
A PE maintains for each l1vpn configured on that PE a port
information tables (PIT) associated with each l1vpn that has at
least one port configured on a PE. A PIT contains a list of
<CPI, PPI> tuples for all the ports within its l1vpn. Note that
a PIT may as well hold routing information (for example when
CPIs are learnt using a routing protocol).
A PIT on a given PE is populated from two sources: the
information related to the CEs’ ports attached to the ports on
that PE (this information could be optionally received from the
CEs), and the information received from other PEs through the
auto-discovery mechanism. We’ll refer to the former as the
"local" information, and to the latter as the "remote"
information.
Propagation of local information to other PEs is accomplished
by using BGP multiprotocol extensions as specified in [BGP-VPN-
AUTODISCOVERY]. To restrict the flow of this information to
only the PITs within a given l1vpn, we use BGP route filtering
based on the Route Target Extended Community [BGP-COMM], as
follows.
Each PIT on a PE is configured with one or more Route Target
Communities, called "export Route Targets", that are used for
tagging the local information when it is exported into
provider’s BGP. The granularity of such tagging could be as
fine as a single <CPI, PPI> pair. In addition, each PIT on a PE
is configured with one or more Route Target Communities, called
"import Route Targets", that restrict the set of routes that
could be imported from provider’s BGP into the PIT to only the
routes that have at least of these Communities.
When a service provider adds a new l1vpn port to a particular
PE, this port is associated at provisioning time with a PIT on
that PE, and this PIT is associated (again at provisioning
time) with that l1vpn.
Ould-Brahim et al. March 2006 [Page 3]
draft-ouldbrahim-l1vpn-bgp-auto-discovery-01.txt September 2006
Note that since the protocol used to populate a PIT with remote
information is BGP, since BGP works across multiple routing
domains, it follows that the mechanisms described in this
document could support l1vpns that span multiple routing
domains.
3. Carrying l1vpn information in BGP
The <CPI, PPI> mapping is carried using the Multiprotocol
Extensions BGP [RFC2858]. [RFC2858] defines the format of two
BGP attributes, MP_REACH_NLRI and MP_UNREACH_NLRI that can be
used to announce and withdraw the announcement of reachability
information. We introduce a new a new subsequent address family
identifier (to be assigned by the IANA), and also a new NLRI
format for carrying the CPI and PPI information.
One or more <PPI, CPI> tuples could be carried in the above
mentioned BGP attributes.
The format of encoding a single <PPI, CPI> tuple is shown in
Figure 2 below:
+---------------------------------------+
| Length (1 octet) |
+---------------------------------------+
| PPI Length (1 octet) |
+---------------------------------------+
| PPI (variable) |
+---------------------------------------+
| CPI AFI (2 octets) |
+---------------------------------------+
| CPI (length) |
+---------------------------------------+
| CPI (variable) |
+---------------------------------------+
Figure 2: NLRI BGP encoding
The use and meaning of these fields are as follows:
Length:
A one octet field whose value indicates the length of
the <PPI, CPI> Information tuple in octets.
PPI Length:
A one octet field whose value indicates the length of
of the PPI field
PPI field:
A variable length field that contains the value of
Ould-Brahim et al. March 2006 [Page 4]
draft-ouldbrahim-l1vpn-bgp-auto-discovery-01.txt September 2006
the PPI (either an address or <port index,
address> tuple
CPI AFI field:
A two octets field whose value indicates address
family of the CPI.
CPI Length:
A once octet field whose value indicates the
length of the CPI field.
CPI (variable):
A variable length field that contains the CPI
value (either an address or <port index, address>
tuple.
4. Security Considerations
TBD.
5. References
[BGP-VPN-AUTODISCOVERY] Ould-Brahim, H., Rosen, E., Rekhter,
Y., "Using BGP as an Auto-Discovery Mechanism for Layer-3
and Layer-2 VPNs", draft-ietf-l3vpn-bgpvpn-auto-05.txt,
work in progress
[GVPN] Ould-Brahim, H., Rekhter, Y., et al., "Generalized VPNs
using BGP and GMPLS toolkit", work in progress, August 2005.
[BGP-COMM] Ramachandra, Tappan, et al., "BGP Extended
Communities Attribute", draft-ietf-idr-bgp-ext-communities-
08.txt, August 2005, work in progress.
[BGP-MP] Bates, Chandra, Katz, and Rekhter, "Multiprotocol
Extensions for BGP4", February 1998, RFC 2283.
[L1VPN-FRMK] Tomonori Takeda, et al., " Framework and
Requirements for Layer 1 Virtual Private Networks", draft-ietf-
l1vpn-framework-00.txt, August 2005, work in progress.
6. Author's Addresses
Hamid Ould-Brahim
Nortel
P O Box 3511 Station C
Ould-Brahim et al. March 2006 [Page 5]
draft-ouldbrahim-l1vpn-bgp-autodiscovery-01.txt October 2005
Ottawa ON K1Y 4H7 Canada
Phone: +1 (613) 765 3418
Email: hbrahim@nortel.com
Yakov Rekhter
Juniper Networks
1194 N. Mathilda Avenue
Sunnyvale, CA 94089
Email: yakov@juniper.net
Don Fedyk
Nortel
600 Technology Park
Billerica, Massachusetts
01821 U.S.A
Phone: +1 (978) 288 3041
Email: dwfedyk@nortel.com
Ould-Brahim et al. March 2006 [Page 6]
draft-ouldbrahim-l1vpn-bgp-autodiscovery-01.txt October 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope
of and Intellectual Property Rights or other rights that
might be claimed to pertain to the implementation or use of
the technology described in this document or the extent to
which any license under such rights might or might not be
available; nor does it represent that it has made any
independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents
can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and
any assurances of licenses to be made available, or the
result of an attempt made to obtain a general license or
permission for the use of such proprietary rights by
implementers or users of this specification can be obtained
from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its
attention any copyrights, patents or patent applications, or
other proprietary rights that may cover technology that may
be required to implement this standard. Please address the
information to the IETF at ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are
provided on an "AS IS" basis and THE CONTRIBUTOR, THE
ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY),
THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE
DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is
subject to the rights, licenses and restrictions contained
in BCP 78, and except as set forth therein, the authors
retain all their rights.
Ould-Brahim et al. March 2006 [Page 7]
