draft-ietf-bess-vpls-multihoming-01.txt   draft-ietf-bess-vpls-multihoming-02.txt 
Network Working Group B. Kothari Network Working Group B. Kothari
Internet-Draft Gainspeed Internet-Draft Augtera Networks
Updates: 4761 (if approved) K. Kompella Updates: 4761 (if approved) K. Kompella
Intended status: Standards Track Juniper Networks Intended status: Standards Track Juniper Networks
Expires: July 9, 2016 W. Henderickx Expires: March 16, 2019 W. Henderickx
Nokia
F. Balus F. Balus
Alcatel-Lucent Cisco
J. Uttaro J. Uttaro
AT&T AT&T
S. Palislamovic Sep 12, 2018
Alcatel-Lucent
W. Lin
Juniper Networks
January 6, 2016
BGP based Multi-homing in Virtual Private LAN Service BGP based Multi-homing in Virtual Private LAN Service
draft-ietf-bess-vpls-multihoming-01.txt draft-ietf-bess-vpls-multihoming-02.txt
Abstract Abstract
Virtual Private LAN Service (VPLS) is a Layer 2 Virtual Private Virtual Private LAN Service (VPLS) is a Layer 2 Virtual Private
Network (VPN) that gives its customers the appearance that their Network (VPN) that gives its customers the appearance that their
sites are connected via a Local Area Network (LAN). It is often sites are connected via a Local Area Network (LAN). It is often
required for the Service Provider (SP) to give the customer redundant required for the Service Provider (SP) to give the customer redundant
connectivity to some sites, often called "multi-homing". This memo connectivity to some sites, often called "multi-homing". This memo
shows how BGP-based multi-homing can be offered in the context of LDP shows how BGP-based multi-homing can be offered in the context of LDP
and BGP VPLS solutions. and BGP VPLS solutions.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 9, 2016. This Internet-Draft will expire on March 16, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
skipping to change at page 2, line 36 skipping to change at page 2, line 31
2.1. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. VPLS Multi-homing Considerations . . . . . . . . . . . . 5 2.2. VPLS Multi-homing Considerations . . . . . . . . . . . . 5
3. Multi-homing Operation . . . . . . . . . . . . . . . . . . . 6 3. Multi-homing Operation . . . . . . . . . . . . . . . . . . . 6
3.1. Customer Edge (CE) NLRI . . . . . . . . . . . . . . . . . 6 3.1. Customer Edge (CE) NLRI . . . . . . . . . . . . . . . . . 6
3.2. Deployment Considerations . . . . . . . . . . . . . . . . 7 3.2. Deployment Considerations . . . . . . . . . . . . . . . . 7
3.3. Designated Forwarder Election . . . . . . . . . . . . . . 8 3.3. Designated Forwarder Election . . . . . . . . . . . . . . 8
3.3.1. Attributes . . . . . . . . . . . . . . . . . . . . . 8 3.3.1. Attributes . . . . . . . . . . . . . . . . . . . . . 8
3.3.2. Variables Used . . . . . . . . . . . . . . . . . . . 9 3.3.2. Variables Used . . . . . . . . . . . . . . . . . . . 9
3.3.3. Election Procedures . . . . . . . . . . . . . . . . . 11 3.3.3. Election Procedures . . . . . . . . . . . . . . . . . 11
3.4. DF Election on PEs . . . . . . . . . . . . . . . . . . . 12 3.4. DF Election on PEs . . . . . . . . . . . . . . . . . . . 12
3.5. Pseudowire and Site-ID Binding Properties . . . . . . . . 13
4. Multi-AS VPLS . . . . . . . . . . . . . . . . . . . . . . . . 13 4. Multi-AS VPLS . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1. Route Origin Extended Community . . . . . . . . . . . . . 13 4.1. Route Origin Extended Community . . . . . . . . . . . . . 13
4.2. VPLS Preference . . . . . . . . . . . . . . . . . . . . . 13 4.2. VPLS Preference . . . . . . . . . . . . . . . . . . . . . 13
4.3. Use of BGP attributes in Inter-AS Methods . . . . . . . . 14 4.3. Use of BGP attributes in Inter-AS Methods . . . . . . . . 14
4.3.1. Inter-AS Method (b): EBGP Redistribution of VPLS 4.3.1. Inter-AS Method (b): EBGP Redistribution of VPLS
Information between ASBRs . . . . . . . . . . . . . . 14 Information between ASBRs . . . . . . . . . . . . . . 15
4.3.2. Inter-AS Method (c): Multi-Hop EBGP Redistribution of 4.3.2. Inter-AS Method (c): Multi-Hop EBGP Redistribution of
VPLS Information between ASes . . . . . . . . . 16 VPLS Information between ASes . . . . . . . . . 16
5. MAC Flush Operations . . . . . . . . . . . . . . . . . . . . 16 5. MAC Flush Operations . . . . . . . . . . . . . . . . . . . . 16
5.1. MAC Flush Indicators . . . . . . . . . . . . . . . . . . 16 5.1. MAC Flush Indicators . . . . . . . . . . . . . . . . . . 16
5.2. Minimizing the effects of fast link transitions . . . . . 17 5.2. Minimizing the effects of fast link transitions . . . . . 17
6. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 17 6. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 17
6.1. BGP based VPLS . . . . . . . . . . . . . . . . . . . . . 17 6.1. BGP based VPLS . . . . . . . . . . . . . . . . . . . . . 18
6.2. LDP VPLS with BGP Auto-discovery . . . . . . . . . . . . 18 6.2. LDP VPLS with BGP Auto-discovery . . . . . . . . . . . . 18
7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 9. Contributing Authors . . . . . . . . . . . . . . . . . . . . 18
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
10.1. Normative References . . . . . . . . . . . . . . . . . . 19 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
10.2. Informative References . . . . . . . . . . . . . . . . . 19 11.1. Normative References . . . . . . . . . . . . . . . . . . 19
11.2. Informative References . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
Virtual Private LAN Service (VPLS) is a Layer 2 Virtual Private Virtual Private LAN Service (VPLS) is a Layer 2 Virtual Private
Network (VPN) that gives its customers the appearance that their Network (VPN) that gives its customers the appearance that their
sites are connected via a Local Area Network (LAN). It is often sites are connected via a Local Area Network (LAN). It is often
required for a Service Provider (SP) to give the customer redundant required for a Service Provider (SP) to give the customer redundant
connectivity to one or more sites, often called "multi-homing". connectivity to one or more sites, often called "multi-homing".
[RFC4761] explains how VPLS can be offered using BGP for auto- [RFC4761] explains how VPLS can be offered using BGP for auto-
skipping to change at page 3, line 28 skipping to change at page 3, line 26
multi-homing can be achieved in this context. [RFC6074] explains how multi-homing can be achieved in this context. [RFC6074] explains how
VPLS can be offered using BGP for auto-discovery (BGP-AD) and VPLS can be offered using BGP for auto-discovery (BGP-AD) and
[RFC4762] explains how VPLS can be offered using LDP for signaling. [RFC4762] explains how VPLS can be offered using LDP for signaling.
This document provides a BGP-based multi-homing solution applicable This document provides a BGP-based multi-homing solution applicable
to both BGP and LDP VPLS technologies. Note that BGP MH can be used to both BGP and LDP VPLS technologies. Note that BGP MH can be used
for LDP VPLS without the use of the BGP-AD solution. for LDP VPLS without the use of the BGP-AD solution.
Section 2 lays out some of the scenarios for multi-homing, other ways Section 2 lays out some of the scenarios for multi-homing, other ways
that this can be achieved, and some of the expectations of BGP-based that this can be achieved, and some of the expectations of BGP-based
multi-homing. Section 3 defines the components of BGP-based multi- multi-homing. Section 3 defines the components of BGP-based multi-
homing, and the procedures required to achieve this. Section 7 may homing, and the procedures required to achieve this.
someday discuss security considerations.
1.1. General Terminology 1.1. General Terminology
Some general terminology is defined here; most is from [RFC4761], Some general terminology is defined here; most is from [RFC4761],
[RFC4762] or [RFC4364]. Terminology specific to this memo is [RFC4762] or [RFC4364]. Terminology specific to this memo is
introduced as needed in later sections. introduced as needed in later sections.
A "Customer Edge" (CE) device, typically located on customer A "Customer Edge" (CE) device, typically located on customer
premises, connects to a "Provider Edge" (PE) device, which is owned premises, connects to a "Provider Edge" (PE) device, which is owned
and operated by the SP. A "Provider" (P) device is also owned and and operated by the SP. A "Provider" (P) device is also owned and
operated by the SP, but has no direct customer connections. A "VPLS operated by the SP, but has no direct customer connections. A "VPLS
Edge" (VE) device is a PE that offers VPLS services. Edge" (VE) device is a PE that offers VPLS services.
A VPLS domain represents a bridging domain per customer. A Route A VPLS domain represents a bridging domain per customer. A Route
Target community as described in [RFC4360] is typically used to Target community as described in [RFC4360] is typically used to
identify all the PE routers participating in a particular VPLS identify all the PE routers participating in a particular VPLS
domain. A VPLS site is a grouping of ports on a PE that belong to domain. A VPLS site is a grouping of ports on a PE that belong to
the same VPLS domain. The terms "VPLS instance" and "VPLS domain" the same VPLS domain. The terms "VPLS instance" and "VPLS domain"
are used interchangeably in this document. are used interchangeably in this document.
A VPLS site connected to only one PE is called as single-homed VPLS A VPLS site is a grouping of ports on a PE that belong to the same
site. The terms "VPLS site" and "CE site" are used interchangeably VPLS domain. The terms "VPLS instance" and "VPLS domain" are used
in this document. interchangeably in this document.
A VPLS site connected to multiple PEs is called as multi-homed site. If the CE devices that connect to a VPLS site's ports have
connectivity to any other PE device then the VPLS site is called a
multi-homed VPLS site. Otherwise, it is called a single-homed VPLS
site. The ports are partitioned between VPLS sites such that each
port is in no more than one VPLS site. The terms "VPLS site" and "CE
site" are used interchangeably in this document.
A BGP VPLS NLRI for the base VPLS instance that has non-zero VE block A BGP VPLS NLRI for the base VPLS instance that has non-zero VE block
offset, VE block size and label base is called as VE NLRI in this offset, VE block size and label base is called as VE NLRI in this
document. Each VPLS instance is uniquely identified by a VE-ID. VE- document. Each VPLS instance is uniquely identified by a VE-ID. VE-
ID is carried in the BGP VPLS NLRI as specified in section 3.2.2 in ID is carried in the BGP VPLS NLRI as specified in section 3.2.2 in
[RFC4761]. [RFC4761].
A VPLS NLRI with value zero for the VE block offset, VE block size A VPLS NLRI with value zero for the VE block offset, VE block size
and label base is called as CE NLRI in this document. and label base is called as CE NLRI in this document.
Section Section 3.1 defines CE NLRI and provides more detail. Section Section 3.1 defines CE NLRI and provides more detail.
skipping to change at page 7, line 23 skipping to change at page 7, line 23
be distinct even if the advertisements have the same VE-ID, which can be distinct even if the advertisements have the same VE-ID, which can
occur in case of multi-homing. This allows standard BGP path occur in case of multi-homing. This allows standard BGP path
selection rules to be applied to VPLS advertisements. selection rules to be applied to VPLS advertisements.
Each VPLS PE must advertise a unique VE-ID with non-zero VE Block Each VPLS PE must advertise a unique VE-ID with non-zero VE Block
Offset, VE Block Size and Label Base values in the BGP NLRI. VE-ID Offset, VE Block Size and Label Base values in the BGP NLRI. VE-ID
is associated with the base VPLS instance and the NLRI associated is associated with the base VPLS instance and the NLRI associated
with it must be used for creating PWs among VPLS PEs. Any single- with it must be used for creating PWs among VPLS PEs. Any single-
homed customer sites connected to the VPLS instance do not require homed customer sites connected to the VPLS instance do not require
any special addressing. However, an administrator (SP operator) can any special addressing. However, an administrator (SP operator) can
chose to have a CE-ID for a single-homed site as well. Any multi- choose to have a CE-ID for a single-homed site as well. Any multi-
homed customer sites connected to the VPLS instance require special homed customer sites connected to the VPLS instance require special
addressing, which is achieved by use of CE-ID. A set of customer addressing, which is achieved by use of CE-ID. A set of customer
sites are distinguished as multi-homed if they all have the same CE- sites are distinguished as multi-homed if they all have the same CE-
ID. The following examples illustrate the use of VE-ID and CE-ID. ID. The following examples illustrate the use of VE-ID and CE-ID.
Figure 1 shows a customer site, CE1, multi-homed to two VPLS PEs, PE1 Figure 1 shows a customer site, CE1, multi-homed to two VPLS PEs, PE1
and PE2. In order for all VPLS PEs to set up PWs to each other, each and PE2. In order for all VPLS PEs to set up PWs to each other, each
VPLS PE must be configured with a unique VE-ID for its base VPLS VPLS PE must be configured with a unique VE-ID for its base VPLS
instance. In addition, in order for all VPLS PEs within the same instance. In addition, in order for all VPLS PEs within the same
VPLS domain to elect one of the multi-homed PEs as the designated VPLS domain to elect one of the multi-homed PEs as the designated
skipping to change at page 7, line 48 skipping to change at page 7, line 48
advertisements for CE1 are identified as candidates for designated advertisements for CE1 are identified as candidates for designated
forwarder selection due to the same CE-ID. Thus, same CE-ID MUST be forwarder selection due to the same CE-ID. Thus, same CE-ID MUST be
assigned on all VPLS PEs that are multi-homed to the same customer assigned on all VPLS PEs that are multi-homed to the same customer
site. site.
Figure 2 shows two customer sites, CE1 and CE4, connected to PE1 with Figure 2 shows two customer sites, CE1 and CE4, connected to PE1 with
CE1 multi-homed to PE1 and PE2. Similar to Figure 1 provisioning CE1 multi-homed to PE1 and PE2. Similar to Figure 1 provisioning
model, each VPLS PE must be configured with a unique VE-ID for it model, each VPLS PE must be configured with a unique VE-ID for it
base VPLS instance. CE1 which is multi-homed to PE1 and PE2 requires base VPLS instance. CE1 which is multi-homed to PE1 and PE2 requires
configuration of CE-ID and both PE1 and PE2 MUST be provisioned with configuration of CE-ID and both PE1 and PE2 MUST be provisioned with
the same CE-ID for CE1. CE2, CE3 and CE4 are single-homed sites and the same CE-ID for CE1. CE2 and CE3 are single-homed sites and do
do not require special addressing. However, an operator can chose to not require special addressing. However, an operator must configure
configure a CE-ID for CE4 on PE1. By doing so, remote PEs can a CE-ID for CE4 on PE1. By doing so, remote PEs can determine that
determine that PE1 has two VPLS sites, CE1 and CE4. If both CE1 and PE1 has two VPLS sites, CE1 and CE4. If both CE1 and CE4
CE4 connectivity to PE1 is down, remote PEs can chose not to send connectivity to PE1 is down, remote PEs can choose based on D bit in
multicast traffic to PE1 as there are no VPLS sites reachable via VE NLRI not to send multicast traffic to PE1 as there are no VPLS
PE1. If CE4 was not assigned a unique CE-ID, remote PEs have no way sites reachable via PE1. If CE4 was not assigned a unique CE-ID,
to know if there are other VPLS sites attached and hence, would remote PEs have no way to know if there are other VPLS sites attached
always send multicast traffic to PE1. While CE2 and CE3 can also be and hence, would always send multicast traffic to PE1. While CE2 and
configured with unique CE-IDs, there is no advantage in doing so as CE3 can also be configured with unique CE-IDs, there is no advantage
both PE3 and PE4 have exactly one VPLS site. in doing so as both PE3 and PE4 have exactly one VPLS site.
Note that a CE-ID=0 is invalid and a PE should discard such an Note that a CE-ID=0 is invalid and a PE should discard such an
advertisement. advertisement.
Use of multiple VE-IDs per VPLS instance for either multi-homing Use of multiple VE-IDs per VPLS instance for either multi-homing
operation or for any other purpose is outside the scope of this operation or for any other purpose is outside the scope of this
document. However, for interoperability with existing deployments document. However, for interoperability with existing deployments
that use multiple VE-IDs, Section 6.1 provides more detail. that use multiple VE-IDs, Section 6.1 provides more detail.
3.3. Designated Forwarder Election 3.3. Designated Forwarder Election
skipping to change at page 9, line 42 skipping to change at page 9, line 42
A state transition from one to zero for the F bit can be used by A state transition from one to zero for the F bit can be used by
a remote PE to flush all the MACs learned from the PE that is a remote PE to flush all the MACs learned from the PE that is
transitioning from designated forwarder to non-designated transitioning from designated forwarder to non-designated
forwarder. Refer to Section 5 for more details on the use case. forwarder. Refer to Section 5 for more details on the use case.
3.3.2. Variables Used 3.3.2. Variables Used
3.3.2.1. RD 3.3.2.1. RD
RD is simply set to the Route Distinguisher field in the NLRI part of RD is simply set to the Route Distinguisher field in the NLRI part of
ADV. ADV. Actual process of assigning Route Distinguisher values must
guarantee its uniqueness per PE node. Therefore, two multi-homed PEs
offering the same VPLS service to a common set of CEs MUST allocate
different RD values for this site respectively.
3.3.2.2. SITE-ID 3.3.2.2. SITE-ID
SITE-ID is simply set to the VE-ID field in the NLRI part of the ADV. SITE-ID is simply set to the VE-ID field in the NLRI part of the ADV.
Note that no distinction is made whether VE-ID is for a multi-homed Note that no distinction is made whether VE-ID is for a multi-homed
site or not. site or not.
3.3.2.3. VBO 3.3.2.3. VBO
skipping to change at page 12, line 49 skipping to change at page 12, line 49
DF election algorithm MUST be run by all multi-homed VPLS PEs. In DF election algorithm MUST be run by all multi-homed VPLS PEs. In
addition, all other PEs SHOULD also run the DF election algorithm. addition, all other PEs SHOULD also run the DF election algorithm.
As a result of the DF election, multi-homed PEs that lose the DF As a result of the DF election, multi-homed PEs that lose the DF
election for a SITE-ID MUST put the ACs associated with the SITE-ID election for a SITE-ID MUST put the ACs associated with the SITE-ID
in non-forwarding state. in non-forwarding state.
DF election result on the egress PEs can be used in traffic DF election result on the egress PEs can be used in traffic
forwarding decision. Figure 2 shows two customer sites, CE1 and CE4, forwarding decision. Figure 2 shows two customer sites, CE1 and CE4,
connected to PE1 with CE1 multi-homed to PE1 and PE2. If PE1 is the connected to PE1 with CE1 multi-homed to PE1 and PE2. If PE1 is the
designated forwarder for CE1, based on the DF election result, PE3 designated forwarder for CE1, based on the DF election result, PE3
can chose to not send unknown unicast and multicast traffic to PE2 as can choose to not send unknown unicast and multicast traffic to PE2
PE2 is not the designated forwarder for any customer site and it has as PE2 is not the designated forwarder for any customer site and it
no other single homed sites connected to it. has no other single homed sites connected to it.
3.5. Pseudowire and Site-ID Binding Properties
For the use case where a single PE provides connectivity to a set of
CEs from which some on multi-homed and others are not, only single
pseudowire MAY be established. For example, if PE1 provides VPLS
service to CE1 and CE4 which are both part of the same VPLS domain,
but different sites, and CE1 is multi-homed, but CE4 is not (as
described in figure 2), PE3 would establish only single pseudowire
toward PE1. A design needs to ensure that regardless of PE1's
forwarding state in respect to DF or non-DF for multi-homed CE1, PE3s
access to CE4 is established. Since label allocation and pseudowire
established is tied to site-ID, we need to ensure that proper
pseudowire bindings are established.
For set of given advertisements with the common DOM but with
different Site-ID values, a VPLS PE speaker SHOULD instantiate and
bind the pseudowire based on advertisement with the lowest Site-ID
value. Otherwise, binding would be completely random and during DF
changes for multi-homed site, non-multi-homed CE might suffer traffic
loss.
4. Multi-AS VPLS 4. Multi-AS VPLS
This section describes multi-homing in an inter-AS context. This section describes multi-homing in an inter-AS context.
4.1. Route Origin Extended Community 4.1. Route Origin Extended Community
Due to lack of information about the PEs that originate the VPLS Due to lack of information about the PEs that originate the VPLS
NLRIs in inter-AS operations, Route Origin Extended Community NLRIs in inter-AS operations, Route Origin Extended Community
[RFC4360] is used to carry the source PE's IP address. [RFC4360] is used to carry the source PE's IP address.
skipping to change at page 18, line 40 skipping to change at page 18, line 46
7. Security Considerations 7. Security Considerations
No new security issues are introduced beyond those that are described No new security issues are introduced beyond those that are described
in [RFC4761] and [RFC4762]. in [RFC4761] and [RFC4762].
8. IANA Considerations 8. IANA Considerations
At this time, this memo includes no request to IANA. At this time, this memo includes no request to IANA.
9. Acknowledgments 9. Contributing Authors
The authos would also like to thank Senad Palislamovic and Wen Lin
for their contribution to the development of this document.
Senad Palislamovic
Nokia
Email: senad.palislamovic@nokia.com
Wen Lin
Juniper Networks
Email: wlin@juniper.net
10. Acknowledgments
The authors would like to thank Yakov Rekhter, Nischal Sheth, Mitali The authors would like to thank Yakov Rekhter, Nischal Sheth, Mitali
Singh, Ian Cowburn and Jonathan Hardwick for their insightful Singh, Ian Cowburn and Jonathan Hardwick for their insightful
comments and probing questions. comments and probing questions.
10. References 11. References
10.1. Normative References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private
LAN Service (VPLS) Using BGP for Auto-Discovery and LAN Service (VPLS) Using BGP for Auto-Discovery and
Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007,
<http://www.rfc-editor.org/info/rfc4761>. <https://www.rfc-editor.org/info/rfc4761>.
[RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo, [RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo,
"Provisioning, Auto-Discovery, and Signaling in Layer 2 "Provisioning, Auto-Discovery, and Signaling in Layer 2
Virtual Private Networks (L2VPNs)", RFC 6074, Virtual Private Networks (L2VPNs)", RFC 6074,
DOI 10.17487/RFC6074, January 2011, DOI 10.17487/RFC6074, January 2011,
<http://www.rfc-editor.org/info/rfc6074>. <https://www.rfc-editor.org/info/rfc6074>.
10.2. Informative References 11.2. Informative References
[I-D.kothari-l2vpn-auto-site-id] [I-D.kothari-l2vpn-auto-site-id]
Kothari, B., Kompella, K., and T. IV, "Automatic Kothari, B., Kompella, K., and T. IV, "Automatic
Generation of Site IDs for Virtual Private LAN Service", Generation of Site IDs for Virtual Private LAN Service",
draft-kothari-l2vpn-auto-site-id-01 (work in progress), draft-kothari-l2vpn-auto-site-id-01 (work in progress),
October 2008. October 2008.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/info/rfc4271>.
[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, Communities Attribute", RFC 4360, DOI 10.17487/RFC4360,
February 2006, <http://www.rfc-editor.org/info/rfc4360>. February 2006, <https://www.rfc-editor.org/info/rfc4360>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
2006, <http://www.rfc-editor.org/info/rfc4364>. 2006, <https://www.rfc-editor.org/info/rfc4364>.
[RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private [RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private
LAN Service (VPLS) Using Label Distribution Protocol (LDP) LAN Service (VPLS) Using Label Distribution Protocol (LDP)
Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007,
<http://www.rfc-editor.org/info/rfc4762>. <https://www.rfc-editor.org/info/rfc4762>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006,
<http://www.rfc-editor.org/info/rfc4271>.
Authors' Addresses Authors' Addresses
Bhupesh Kothari Bhupesh Kothari
Gainspeed Augtera Networks
295 Santa Ana Court
Sunnyvale, CA 94085
US
Email: bhupesh@gainspeed.com Email: bhupesh@anvaya.net
Kireeti Kompella Kireeti Kompella
Juniper Networks Juniper Networks
1194 N. Mathilda Ave. 1194 N. Mathilda Ave.
Sunnyvale, CA 94089 Sunnyvale, CA 94089
US US
Email: kireeti.kompella@gmail.com Email: kireeti.kompella@gmail.com
Wim Henderickx Wim Henderickx
Alcatel-Lucent Nokia
Email: wim.henderickx@alcatel-lucent.be Email: wim.henderickx@nokia.com
Florin Balus Florin Balus
Alcatel-Lucent Cisco
Email: florin.balus@alcatel-lucent.com Email: fbalus@gmail.com
James Uttaro James Uttaro
AT&T AT&T
200 S. Laurel Avenue 200 S. Laurel Avenue
Middletown, NJ 07748 Middletown, NJ 07748
US US
Email: uttaro@att.com Email: uttaro@att.com
Senad Palislamovic
Alcatel-Lucent
Email: senad.palislamovic@alcatel-lucent.com
Wen Lin
Juniper Networks
Email: wlin@juniper.net
 End of changes. 37 change blocks. 
65 lines changed or deleted 104 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/