draft-ietf-l2vpn-signaling-06.txt   draft-ietf-l2vpn-signaling-07.txt 
Network Working Group E. Rosen Network Working Group E. Rosen
Internet-Draft W. Luo Internet-Draft W. Luo
Expires: March 13, 2006 B. Davie Expires: September 4, 2006 B. Davie
Cisco Systems, Inc. Cisco Systems, Inc.
V. Radoaca V. Radoaca
September 9, 2005 March 3, 2006
Provisioning, Autodiscovery, and Signaling in L2VPNs Provisioning, Autodiscovery, and Signaling in L2VPNs
draft-ietf-l2vpn-signaling-06.txt draft-ietf-l2vpn-signaling-07.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 13, 2006. This Internet-Draft will expire on September 4, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
Abstract Abstract
There are a number of different kinds of "Provider Provisioned Layer Provider Provisioned Layer 2 Virtual Private Networks (L2VPNs) may
2 VPNs" (L2VPNs). The different kinds of L2VPN may have different have different "provisioning models", i.e., models for what
"provisioning models", i.e., different models for what information information needs to be configured in what entities. Once
needs to be configured in what entities. Once configured, the configured, the provisioning information is distributed by a
provisioning information is distributed by a "discovery process". "discovery process". When the discovery process is complete, a
When the discovery process is complete, a signaling protocol is signaling protocol is automatically invoked to set up the mesh of
automatically invoked. The signaling protocol sets up the mesh of Pseudowires (PWs) that form the (virtual) backbone of the L2VPN.
Pseudowires (PWs) that form the (virtual) backbone of the L2VPN. Any
PW signaling protocol needs to have a method which allows each PW
endpoint to identify the other; thus a PW signaling protocol will
have the notion of an endpoint identifier. The semantics of the
endpoint identifiers which the signaling protocol uses for a
particular type of L2VPN are determined by the provisioning model.
This document specifies a number of L2VPN provisioning models, and This document specifies a number of L2VPN provisioning models, and
further specifies the semantic structure of the endpoint identifiers further specifies the semantic structure of the endpoint identifiers
required by each provisioning model. It discusses the way in which required by each model. It discusses the distribution of these
the endpoint identifiers are distributed by the discovery process, identifiers by the discovery process, especially when discovery is
especially when the discovery process is based upon the Border based on the Border Gateway Protocol (BGP). It then specifies how
Gateway Protocol (BGP). It then specifies how the endpoint the endpoint identifiers are carried in the two signaling protocols
identifiers are carried in the two signaling protocols that are used that are used to set up PWs, the Label Distribution Protocol (LDP)
to set up PWs, the Label Distribution Protocol (LDP) and the Layer 2 and the Layer 2 Tunneling Protocol (L2TPv3).
Tunneling Protocol (L2TPv3).
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Signaling Protocol Framework . . . . . . . . . . . . . . . . . 7 2. Signaling Protocol Framework . . . . . . . . . . . . . . . . . 7
2.1. Endpoint Identification . . . . . . . . . . . . . . . . . 7 2.1. Endpoint Identification . . . . . . . . . . . . . . . . . 7
2.2. Creating a Single Bidirectional Pseudowire . . . . . . . . 8 2.2. Creating a Single Bidirectional Pseudowire . . . . . . . . 8
2.3. Attachment Identifiers and Forwarders . . . . . . . . . . 9 2.3. Attachment Identifiers and Forwarders . . . . . . . . . . 9
3. Applications . . . . . . . . . . . . . . . . . . . . . . . . . 11 3. Applications . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1. Individual Point-to-Point Pseudowires . . . . . . . . . . 11 3.1. Individual Point-to-Point Pseudowires . . . . . . . . . . 11
3.1.1. Provisioning Models . . . . . . . . . . . . . . . . . 11 3.1.1. Provisioning Models . . . . . . . . . . . . . . . . . 11
3.1.1.1. Double Sided Provisioning . . . . . . . . . . . . 11 3.1.1.1. Double Sided Provisioning . . . . . . . . . . . . 11
3.1.1.2. Single Sided Provisioning with Discovery . . . . . 11 3.1.1.2. Single Sided Provisioning with Discovery . . . . . 11
3.1.2. Signaling . . . . . . . . . . . . . . . . . . . . . . 12 3.1.2. Signaling . . . . . . . . . . . . . . . . . . . . . . 12
3.2. Virtual Private LAN Service . . . . . . . . . . . . . . . 13 3.2. Virtual Private LAN Service . . . . . . . . . . . . . . . 13
3.2.1. Provisioning . . . . . . . . . . . . . . . . . . . . . 13 3.2.1. Provisioning . . . . . . . . . . . . . . . . . . . . . 13
3.2.2. Auto-Discovery . . . . . . . . . . . . . . . . . . . . 14 3.2.2. Auto-Discovery . . . . . . . . . . . . . . . . . . . . 14
3.2.2.1. BGP-based auto-discovery . . . . . . . . . . . . . 14 3.2.2.1. BGP-based auto-discovery . . . . . . . . . . . . . 14
3.2.3. Signaling . . . . . . . . . . . . . . . . . . . . . . 15 3.2.3. Signaling . . . . . . . . . . . . . . . . . . . . . . 16
3.2.4. Pseudowires as VPLS Attachment Circuits . . . . . . . 16 3.2.4. Pseudowires as VPLS Attachment Circuits . . . . . . . 16
3.3. Colored Pools: Full Mesh of Point-to-Point Pseudowires . . 16 3.3. Colored Pools: Full Mesh of Point-to-Point
3.3.1. Provisioning . . . . . . . . . . . . . . . . . . . . . 16 Pseudowires . . . . . . . . . . . . . . . . . . . . . . . 16
3.3.1. Provisioning . . . . . . . . . . . . . . . . . . . . . 17
3.3.2. Auto-Discovery . . . . . . . . . . . . . . . . . . . . 17 3.3.2. Auto-Discovery . . . . . . . . . . . . . . . . . . . . 17
3.3.2.1. BGP-based auto-discovery . . . . . . . . . . . . . 17 3.3.2.1. BGP-based auto-discovery . . . . . . . . . . . . . 17
3.3.3. Signaling . . . . . . . . . . . . . . . . . . . . . . 18 3.3.3. Signaling . . . . . . . . . . . . . . . . . . . . . . 19
3.4. Colored Pools: Partial Mesh . . . . . . . . . . . . . . . 19 3.4. Colored Pools: Partial Mesh . . . . . . . . . . . . . . . 20
3.5. Distributed VPLS . . . . . . . . . . . . . . . . . . . . . 20 3.5. Distributed VPLS . . . . . . . . . . . . . . . . . . . . . 20
3.5.1. Signaling . . . . . . . . . . . . . . . . . . . . . . 22 3.5.1. Signaling . . . . . . . . . . . . . . . . . . . . . . 22
3.5.2. Provisioning and Discovery . . . . . . . . . . . . . . 23 3.5.2. Provisioning and Discovery . . . . . . . . . . . . . . 24
3.5.3. Non-distributed VPLS as a sub-case . . . . . . . . . . 24 3.5.3. Non-distributed VPLS as a sub-case . . . . . . . . . . 24
3.5.4. Splicing and the Data Plane . . . . . . . . . . . . . 24 3.5.4. Splicing and the Data Plane . . . . . . . . . . . . . 24
4. Inter-AS Operation . . . . . . . . . . . . . . . . . . . . . . 25 4. Inter-AS Operation . . . . . . . . . . . . . . . . . . . . . . 26
4.1. Multihop EBGP redistribution of L2VPN NLRIs . . . . . . . 25 4.1. Multihop EBGP redistribution of L2VPN NLRIs . . . . . . . 26
4.2. EBGP redistribution of L2VPN NLRIs with Pseudowire 4.2. EBGP redistribution of L2VPN NLRIs with Multi-Segment
Switching . . . . . . . . . . . . . . . . . . . . . . . . 26 Pseudowires . . . . . . . . . . . . . . . . . . . . . . . 27
4.3. Inter-Provider Application of Dist. VPLS Signaling . . . . 27 4.3. Inter-Provider Application of Distributed VPLS
4.4. RT and RD Assignment Considerations . . . . . . . . . . . 28 Signaling . . . . . . . . . . . . . . . . . . . . . . . . 28
4.4. RT and RD Assignment Considerations . . . . . . . . . . . 29
5. Security Considerations . . . . . . . . . . . . . . . . . . . 29
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 5. Security Considerations . . . . . . . . . . . . . . . . . . . 30
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
8. Normative References . . . . . . . . . . . . . . . . . . . . . 32 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32
9. Informative References . . . . . . . . . . . . . . . . . . . . 33 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
8.1. Normative References . . . . . . . . . . . . . . . . . . . 33
8.2. Informative References . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36
Intellectual Property and Copyright Statements . . . . . . . . . . 35 Intellectual Property and Copyright Statements . . . . . . . . . . 37
1. Introduction 1. Introduction
[L2VPN-FW] describes a number of different ways in which sets of [I-D.ietf-l2vpn-l2-framework] describes a number of different ways in
pseudowires may be combined together into "Provider Provisioned Layer which sets of pseudowires may be combined together into "Provider
2 VPNs" (L2 PPVPNs, or L2VPNs), resulting in a number of different Provisioned Layer 2 VPNs" (L2 PPVPNs, or L2VPNs), resulting in a
kinds of L2VPN. Different kinds of L2VPN may have different number of different kinds of L2VPN. Different kinds of L2VPN may
"provisioning models", i.e., different models for what information have different "provisioning models", i.e., different models for what
needs to be configured in what entities. Once configured, the information needs to be configured in what entities. Once
provisioning information is distributed by a "discovery process", and configured, the provisioning information is distributed by a
once the information is discovered, the signaling protocol is "discovery process", and once the information is discovered, the
automatically invoked to set up the required pseudowires. The signaling protocol is automatically invoked to set up the required
semantics of the endpoint identifiers which the signaling protocol pseudowires. The semantics of the endpoint identifiers which the
uses for a particular type of L2VPN are determined by the signaling protocol uses for a particular type of L2VPN are determined
provisioning model. That is, different kinds of L2VPN, with by the provisioning model. That is, different kinds of L2VPN, with
different provisioning models, require different kinds of endpoint different provisioning models, require different kinds of endpoint
identifiers. This document specifies a number of PPVPN provisioning identifiers. This document specifies a number of L2VPN provisioning
models, and specifies the semantic structure of the endpoint models, and specifies the semantic structure of the endpoint
identifiers required for each provisioning model. identifiers required for each provisioning model.
Either LDP (as specified in [LDP] and extended in [PWE3-CONTROL]) or Either LDP (as specified in [RFC3036] and extended in [I-D.ietf-pwe3-
L2TP version 3 (as specified in [L2TP-BASE] and extended in [L2TP- control-protocol]) or L2TP version 3 (as specified in [RFC3931] and
L2VPN]) can be used as signaling protocols to set up and maintain extended in [I-D.ietf-l2tpext-l2vpn]) can be used as signaling
pseudowires (PWs) [PWE3-ARCH]. Any protocol which sets up protocols to set up and maintain pseudowires (PWs) [RFC3985]. Any
connections must provide a way for each endpoint of the connection to protocol which sets up connections must provide a way for each
identify the other; each PW signaling protocol thus provides a way to endpoint of the connection to identify the other; each PW signaling
identify the PW endpoints. Since each signaling protocol needs to protocol thus provides a way to identify the PW endpoints. Since
support all the different kinds of L2VPN and provisioning models, the each signaling protocol needs to support all the different kinds of
signaling protocol must have a very general way of representing L2VPN and provisioning models, the signaling protocol must have a
endpoint identifiers, and it is necessary to specify rules for very general way of representing endpoint identifiers, and it is
encoding each particular kind of endpoint identifier into the necessary to specify rules for encoding each particular kind of
relevant fields of each signaling protocol. This document specifies endpoint identifier into the relevant fields of each signaling
how to encode the endpoint identifiers of each provisioning model protocol. This document specifies how to encode the endpoint
into the LDP and L2TPv3 signaling protocols. identifiers of each provisioning model into the LDP and L2TPv3
signaling protocols.
We make free use of terminology from [L2VPN-FW], [L2VPN-TERM], and We make free use of terminology from [I-D.ietf-l2vpn-l2-framework],
[PWE3-ARCH], in particular the terms "Attachment Circuit", [RFC4026], [RFC3985], and [I-D.ietf-pwe3-ms-pw-arch], in particular
"pseudowire", "PE", "CE". the terms "Attachment Circuit", "pseudowire", "PE", "CE", and "multi-
segment pseudowire".
Section 2 provides an overview of the relevant aspects of [PWE3- Section 2 provides an overview of the relevant aspects of [I-D.ietf-
CONTROL] and [L2TP-L2VPN]. pwe3-control-protocol] and [I-D.ietf-l2tpext-l2vpn].
Section 3 details various provisioning models and relates them to the Section 3 details various provisioning models and relates them to the
signaling process and to the discovery process. The way in which the signaling process and to the discovery process. The way in which the
signaling mechanisms can be integrated with BGP-based auto-discovery signaling mechanisms can be integrated with BGP-based auto-discovery
is covered in some detail. is covered in some detail.
Section 4 explains how the procedures for discovery and signaling can Section 4 explains how the procedures for discovery and signaling can
be applied in a multi-AS environment and outlines several options for be applied in a multi-AS environment and outlines several options for
the establishment of multi-AS L2VPNs. the establishment of multi-AS L2VPNs.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 document are to be interpreted as described in [RFC2119]
2. Signaling Protocol Framework 2. Signaling Protocol Framework
2.1. Endpoint Identification 2.1. Endpoint Identification
Per [L2VPN-FW], a pseudowire can be thought of as a relationship Per [I-D.ietf-l2vpn-l2-framework], a pseudowire can be thought of as
between a pair of "Forwarders". In simple instances of VPWS, a a relationship between a pair of "Forwarders". In simple instances
Forwarder binds a pseudowire to a single Attachment Circuit, such of VPWS, a Forwarder binds a pseudowire to a single Attachment
that frames received on the one are sent on the other, and vice Circuit, such that frames received on the one are sent on the other,
versa. In VPLS, a Forwarder binds a set of pseudowires to a set of and vice versa. In VPLS, a Forwarder binds a set of pseudowires to a
Attachment Circuits; when a frame is received from any member of that set of Attachment Circuits; when a frame is received from any member
set, a MAC address table is consulted (and various 802.1d procedures of that set, a MAC address table is consulted (and various 802.1d
executed) to determine the member or members of that set on which the procedures executed) to determine the member or members of that set
frame is to be transmitted. In more complex scenarios, Forwarders on which the frame is to be transmitted. In more complex scenarios,
may bind PWs to PWs, thereby "splicing" two PWs together; this is Forwarders may bind PWs to PWs, thereby "splicing" two PWs together;
needed, e.g., to support distributed VPLS and some inter-AS this is needed, e.g., to support distributed VPLS and some inter-AS
scenarios. scenarios.
In simple VPWS, where a Forwarder binds exactly one PW to exactly one In simple VPWS, where a Forwarder binds exactly one PW to exactly one
Attachment Circuit, a Forwarder can be identified by identifying its Attachment Circuit, a Forwarder can be identified by identifying its
Attachment Circuit. In simple VPLS, a Forwarder can be identified by Attachment Circuit. In simple VPLS, a Forwarder can be identified by
identifying its PE device and its VPN. identifying its PE device and its VPN.
To set up a PW between a pair of Forwarders, the signaling protocol To set up a PW between a pair of Forwarders, the signaling protocol
must allow the Forwarder at one endpoint to identify the Forwarder at must allow the Forwarder at one endpoint to identify the Forwarder at
the other. In [PWE3-CONTROL], the term "Attachment Identifier", or the other. In [I-D.ietf-pwe3-control-protocol] the term "Attachment
"AI", is used to refer to a quantity whose purpose is to identify a Identifier", or "AI", is used to refer to a quantity whose purpose is
Forwarder. In [L2TP-L2VPN], the term "Forwarder Identifier" is used to identify a Forwarder. In [I-D.ietf-l2tpext-l2vpn], the term
for the same purpose. In the context of this document, "Attachment "Forwarder Identifier" is used for the same purpose. In the context
Identifier" and "Forwarder Identifier" are used interchangeably. of this document, "Attachment Identifier" and "Forwarder Identifier"
are used interchangeably.
[PWE3-CONTROL] specifies two FEC elements that can be used when [I-D.ietf-pwe3-control-protocol] specifies two FEC elements that can
setting up pseudowires, the PWid FEC element, and the Generalized Id be used when setting up pseudowires, the PWid FEC element, and the
FEC element. The PWid FEC element carries only one Forwarder Generalized Id FEC element. The PWid FEC element carries only one
identifier; it can be thus be used only when both forwarders have the Forwarder identifier; it can be thus be used only when both
same identifier, and when that identifier can be coded as a 32-bit forwarders have the same identifier, and when that identifier can be
quantity. The Generalized Id FEC element carries two Forwarder coded as a 32-bit quantity. The Generalized Id FEC element carries
identifiers, one for each of the two Forwarders being connected. two Forwarder identifiers, one for each of the two Forwarders being
Each identifier is known as an Attachment Identifier, and a signaling connected. Each identifier is known as an Attachment Identifier, and
message carries both a "Source Attachment Identifier" (SAI) and a a signaling message carries both a "Source Attachment Identifier"
"Target Attachment Identifier" (TAI). (SAI) and a "Target Attachment Identifier" (TAI).
The Generalized ID FEC element also provides some additional The Generalized ID FEC element also provides some additional
structuring of the identifiers. It is assumed that the SAI and TAI structuring of the identifiers. It is assumed that the SAI and TAI
will sometimes have a common part, called the "Attachment Group will sometimes have a common part, called the "Attachment Group
Identifier" (AGI), such that the SAI and TAI can each be thought of Identifier" (AGI), such that the SAI and TAI can each be thought of
as the concatenation of the AGI with an "Attachment Individual as the concatenation of the AGI with an "Attachment Individual
Identifier" (AII). So the pair of identifiers is encoded into three Identifier" (AII). So the pair of identifiers is encoded into three
fields: AGI, Source AII (SAII), and Target AII (TAII). The SAI is fields: AGI, Source AII (SAII), and Target AII (TAII). The SAI is
the concatenation of the AGI and the SAII, while the TAI is the the concatenation of the AGI and the SAII, while the TAI is the
concatenation of the AGI and the TAII. concatenation of the AGI and the TAII.
Similarly, [L2TP-L2VPN] allows using one or two Forwarder Identifiers Similarly, [I-D.ietf-l2tpext-l2vpn] allows using one or two Forwarder
to set up pseudowires. If only the target Forwarder Identifier is Identifiers to set up pseudowires. If only the target Forwarder
used in L2TP signaling messages, both the source and target Identifier is used in L2TP signaling messages, both the source and
Forwarders are assumed to have the same value. If both the source target Forwarders are assumed to have the same value. If both the
and target Forwarder Identifiers are carried in L2TP signaling source and target Forwarder Identifiers are carried in L2TP signaling
messages, each Forwarder uses a locally significant identifier value. messages, each Forwarder uses a locally significant identifier value.
The Forwarder Identifier in [L2TP-L2VPN] is an equivalent term as The Forwarder Identifier in [I-D.ietf-l2tpext-l2vpn] is an equivalent
Attachment Identifier in [PWE3-CONTROL]. A Forwarder Identifier also term to Attachment Identifier in [I-D.ietf-pwe3-control-protocol]. A
consists of an Attachment Group Identifier and an Attachment Forwarder Identifier also consists of an Attachment Group Identifier
Individual Identifier. Unlike the Generalized ID FEC element, the and an Attachment Individual Identifier. Unlike the Generalized ID
AGI and AII are carried in distinct L2TP Attribute-Value-Pairs FEC element, the AGI and AII are carried in distinct L2TP Attribute-
(AVPs). The AGI is encoded in the AGI AVP, and the SAII and TAII are Value-Pairs (AVPs). The AGI is encoded in the AGI AVP, and the SAII
encoded in the Local End ID AVP and the Remote End ID AVP and TAII are encoded in the Local End ID AVP and the Remote End ID
respectively. The source Forwarder Identifier is the concatenation AVP respectively. The source Forwarder Identifier is the
of the AGI and SAII, while the target Forwarder Identifier is the concatenation of the AGI and SAII, while the target Forwarder
concatenation of the AGI and TAII. Identifier is the concatenation of the AGI and TAII.
In applications that group sets of PWs into "Layer 2 Virtual Private In applications that group sets of PWs into "Layer 2 Virtual Private
Networks", the AGI can be thought of as a "VPN Identifier". Networks", the AGI can be thought of as a "VPN Identifier".
It should be noted that while different forwarders support different It should be noted that while different forwarders support different
applications, the type of application (e.g., VPLS vs. VPWS) cannot applications, the type of application (e.g., VPLS vs. VPWS) cannot
necessarily be inferred from the forwarders' identifiers. A router necessarily be inferred from the forwarders' identifiers. A router
receiving a signaling message with a particular TAI will have to be receiving a signaling message with a particular TAI will have to be
able to determine which of its local forwarders is identified by that able to determine which of its local forwarders is identified by that
TAI, and to determine the application provided by that forwarder. TAI, and to determine the application provided by that forwarder.
But other nodes may not be able to infer the application simply by But other nodes may not be able to infer the application simply by
inspection of the signaling messages. inspection of the signaling messages.
In this document some further structure of the AGI and AII is In this document some further structure of the AGI and AII is
proposed for certain L2VPN applications. We note that [PWE3-CONTROL] proposed for certain L2VPN applications. We note that [I-D.ietf-
defines a TLV structure for AGI and AII fields. Thus, an operator pwe3-control-protocol] defines a TLV structure for AGI and AII
who chooses to use the AII structure defined here could also make use fields. Thus, an operator who chooses to use the AII structure
of different AGI or AII types if he also wanted to use a different defined here could also make use of different AGI or AII types if he
structure for these identifiers for some other application. For also wanted to use a different structure for these identifiers for
example, the long prefix type of [AII-TYPES] could be used to enable some other application. For example, the long prefix type of
the communication of administrative information, perhaps combined [I-D.metz-aii-aggregate] could be used to enable the communication of
with information learned during autodiscovery. administrative information, perhaps combined with information learned
during autodiscovery.
2.2. Creating a Single Bidirectional Pseudowire 2.2. Creating a Single Bidirectional Pseudowire
In any form of LDP-based signaling, each PW endpoint must initiate In any form of LDP-based signaling, each PW endpoint must initiate
the creation of a unidirectional LSP. A PW is a pair of such LSPs. the creation of a unidirectional LSP. A PW is a pair of such LSPs.
In most of the PPVPN provisioning models, the two endpoints of a In most of the L2VPN provisioning models, the two endpoints of a
given PW can simultaneously initiate the signaling for it. They must given PW can simultaneously initiate the signaling for it. They must
therefore have some way of determining when a given pair of LSPs are therefore have some way of determining when a given pair of LSPs are
intended to be associated together as a single PW. intended to be associated together as a single PW.
The way in which this association is done is different for the The way in which this association is done is different for the
various different L2VPN services and provisioning models. The various different L2VPN services and provisioning models. The
details appear in later sections. details appear in later sections.
L2TP signaling inherently establishes a bidirectional session that L2TP signaling inherently establishes a bidirectional session that
carries a PW between two PW endpoints. The two endpoints can also carries a PW between two PW endpoints. The two endpoints can also
simultaneously initiate the signaling for a given PW. It is possible simultaneously initiate the signaling for a given PW. It is possible
that two PWs can be established for a pair of Forwarders. that two PWs can be established for a pair of Forwarders.
In order to avoid setting up duplicated pseudowires between two In order to avoid setting up duplicated pseudowires between two
Forwarders, each PE must be able to independently detect such a Forwarders, each PE must be able to independently detect such a
pseudowire tie. The procedures of detecting a pseudowire tie is pseudowire tie. The procedures of detecting a pseudowire tie is
described in [L2TP-L2VPN] described in [I-D.ietf-l2tpext-l2vpn]
2.3. Attachment Identifiers and Forwarders 2.3. Attachment Identifiers and Forwarders
Every Forwarder in a PE must be associated with an Attachment Every Forwarder in a PE must be associated with an Attachment
Identifier (AI), either through configuration or through some Identifier (AI), either through configuration or through some
algorithm. The Attachment Identifier must be unique in the context algorithm. The Attachment Identifier must be unique in the context
of the PE router in which the Forwarder resides. The combination <PE of the PE router in which the Forwarder resides. The combination <PE
router, AI> must be globally unique. router, AI> must be globally unique.
As specified in [PWE3-CONTROL], the Attachment Identifier may consist As specified in [I-D.ietf-pwe3-control-protocol], the Attachment
of an Attachment Group Identifier (AGI) plus an Attachment Individual Identifier may consist of an Attachment Group Identifier (AGI) plus
Identifier (AII). In the context of this document, an AGI may be an Attachment Individual Identifier (AII). In the context of this
thought of as a VPN-id, or a VLAN identifier, some attribute which is document, an AGI may be thought of as a VPN-id, or some attribute
shared by all the Attachment Circuits which are allowed to be which is shared by all the Attachment Circuits which are allowed to
connected. be connected.
It is sometimes helpful to consider a set of attachment circuits at a It is sometimes helpful to consider a set of attachment circuits at a
single PE to belong to a common "pool". For example a set of single PE to belong to a common "pool". For example a set of
attachment circuits that connect a single CE to a given PE may be attachment circuits that connect a single CE to a given PE may be
considered a pool. The use of pools is described in detail in considered a pool. The use of pools is described in detail in
Section 3.3. Section 3.3.
The details for how to construct the AGI and AII fields identifying The details for how to construct the AGI and AII fields identifying
the pseudowire endpoints in particular provisioning models are the pseudowire endpoints in particular provisioning models are
discussed later in this paper. discussed later in this document.
We can now consider an LSP for one direction of a pseudowire to be We can now consider an LSP for one direction of a pseudowire to be
identified by: identified by:
o <PE1, <AGI, AII1>, PE2, <AGI, AII2>> o <PE1, <AGI, AII1>, PE2, <AGI, AII2>>
and the LSP in the opposite direction of the pseudowire will be and the LSP in the opposite direction of the pseudowire will be
identified by: identified by:
o <PE2, <AGI, AII2>, PE1, <AGI, AII1>> o <PE2, <AGI, AII2>, PE1, <AGI, AII1>>
skipping to change at page 12, line 28 skipping to change at page 12, line 28
Double Sided Provisioning is that it enables one to move an Double Sided Provisioning is that it enables one to move an
Attachment Circuit from one PE to another without having to Attachment Circuit from one PE to another without having to
reconfigure the remote endpoint. However, compared to the approach reconfigure the remote endpoint. However, compared to the approach
described in Section 3.3 below, it imposes a greater burden on the described in Section 3.3 below, it imposes a greater burden on the
discovery mechanism, because each attachment circuit's name must be discovery mechanism, because each attachment circuit's name must be
advertised individually (i.e. there is no aggregation of AC names in advertised individually (i.e. there is no aggregation of AC names in
this simple scheme). this simple scheme).
3.1.2. Signaling 3.1.2. Signaling
The LDP-based signaling follows the procedures specified in [PWE3- The LDP-based signaling follows the procedures specified in
CONTROL]. That is, one PE (PE1) sends a Label Mapping Message to [I-D.ietf-pwe3-control-protocol]. That is, one PE (PE1) sends a
another PE (PE2) to establish an LSP in one direction. If that Label Mapping Message to another PE (PE2) to establish an LSP in one
message is processed successfully, and there is not yet an LSP for direction. If that message is processed successfully, and there is
the pseudowire in the opposite (PE1->PE2) direction, then PE2 sends a not yet an LSP for the pseudowire in the opposite (PE1->PE2)
Label Mapping Message to PE1. direction, then PE2 sends a Label Mapping Message to PE1.
In addition to the procedures of [PWE3-CONTROL], when a PE receives a In addition to the procedures of [I-D.ietf-pwe3-control-protocol],
Label Mapping Message, and the TAI identifies a particular Attachment when a PE receives a Label Mapping Message, and the TAI identifies a
Circuit which is configured to be bound to a point-to-point PW, then particular Attachment Circuit which is configured to be bound to a
the following checks must be made. point-to-point PW, then the following checks must be made.
If the Attachment Circuit is already bound to a pseudowire (including If the Attachment Circuit is already bound to a pseudowire (including
the case where only one of the two LSPs currently exists), and the the case where only one of the two LSPs currently exists), and the
remote endpoint is not PE1, then PE2 sends a Label Release message to remote endpoint is not PE1, then PE2 sends a Label Release message to
PE1, with a Status Code meaning "Attachment Circuit bound to PE1, with a Status Code meaning "Attachment Circuit bound to
different PE", and the processing of the Mapping message is complete. different PE", and the processing of the Mapping message is complete.
If the Attachment Circuit is already bound to a pseudowire (including If the Attachment Circuit is already bound to a pseudowire (including
the case where only one of the two LSPs currently exists), but the AI the case where only one of the two LSPs currently exists), but the AI
at PE1 is different than that specified in the AGI/SAII fields of the at PE1 is different than that specified in the AGI/SAII fields of the
skipping to change at page 13, line 28 skipping to change at page 13, line 28
pseudowire is bound to a Forwarder on PE1 with the AI different than pseudowire is bound to a Forwarder on PE1 with the AI different than
that specified in the SAI fields of the ICRQ message, then PE2 sends that specified in the SAI fields of the ICRQ message, then PE2 sends
a CDN message to PE1, with a Status Code meaning "Attachment Circuit a CDN message to PE1, with a Status Code meaning "Attachment Circuit
bound to different remote Attachment Circuit", and the processing of bound to different remote Attachment Circuit", and the processing of
the ICRQ message is complete. the ICRQ message is complete.
These errors could occur as the result of misconfigurations. These errors could occur as the result of misconfigurations.
3.2. Virtual Private LAN Service 3.2. Virtual Private LAN Service
In the VPLS application [L2VPN-REQ, VPLS], the Attachment Circuits In the VPLS application [I-D.ietf-l2vpn-vpls-ldp], the Attachment
can be though of as LAN interfaces which attach to "virtual LAN Circuits can be thought of as LAN interfaces which attach to "virtual
switches", or, in the terminology of [L2VPN-FW], "Virtual Switching LAN switches", or, in the terminology of [I-D.ietf-l2vpn-l2-
Instances" (VSIs). Each Forwarder is a VSI that attaches to a number framework], "Virtual Switching Instances" (VSIs). Each Forwarder is
of PWs and a number of Attachment Circuits. The VPLS service [L2VPN- a VSI that attaches to a number of PWs and a number of Attachment
REQ, VPLS] requires that a single pseudowire be created between each Circuits. The VPLS service requires that a single pseudowire be
pair of VSIs that are in the same VPLS. Each PE device may have a created between each pair of VSIs that are in the same VPLS. Each PE
multiple VSIs, where each VSI belongs to a different VPLS. device may have multiple VSIs, where each VSI belongs to a different
VPLS.
3.2.1. Provisioning 3.2.1. Provisioning
Each VPLS must have a globally unique identifier, which we call a Each VPLS must have a globally unique identifier, which we call a
VPN-id. Every VSI must be configured with the VPN-id of the VPLS to VPN-id. Every VSI must be configured with the VPN-id of the VPLS to
which it belongs. which it belongs.
Each VSI must also have a unique identifier, which we call a VSI-ID. Each VSI must also have a unique identifier, which we call a VSI-ID.
This can be formed automatically by concatenating its VPN-id with an This can be formed automatically by concatenating its VPN-id with an
IP address of its PE router. (Note that the PE address here is used IP address of its PE router. (Note that the PE address here is used
only as a form of unique identifier; a service provider could choose only as a form of unique identifier; a service provider could choose
to use some other numbering scheme if that was desired. See to use some other numbering scheme if that was desired. See
Section 4.4 for a discussion of the assignment of identifiers in the Section 4.4 for a discussion of the assignment of identifiers in the
case of multiple providers.) case of multiple providers.)
3.2.2. Auto-Discovery 3.2.2. Auto-Discovery
3.2.2.1. BGP-based auto-discovery 3.2.2.1. BGP-based auto-discovery
The framework for BGP-based auto-discovery for a generic L2VPN A framework for BGP-based auto-discovery for a generic L2VPN service
service is as described in [BGP-AUTO], section 3.2. is described in [I-D.ietf-l3vpn-bgpvpn-auto], section 3.2. In this
section we specify how BGP-based auto-discovery can be used to build
VPLS instances.
The AFI/SAFI used would be: When BGP-based autodiscovery is used for VPLS, the AFI/SAFI will be:
o An AFI specified by IANA for L2VPN. (This is the same for all o An AFI specified by IANA for L2VPN. (This is the same for all
L2VPN schemes.) L2VPN schemes.)
o A SAFI specified by IANA specifically for an L2VPN service whose o A SAFI specified by IANA specifically for an L2VPN service whose
pseudowires are set up using the procedures described in the pseudowires are set up using the procedures described in the
current document. current document.
See Section 6 for further discussion of AFI/SAFI assignment. See Section 6 for further discussion of AFI/SAFI assignment.
In order to use BGP-based auto-discovery as specified in [BGP-AUTO], In order to use BGP-based auto-discovery, there must be at least one
there must be at least one globally unique identifier associated with globally unique identifier associated with a VPLS, and each such
a VPLS, and each such identifier must be encodable as an 8-byte Route identifier must be encodable as an 8-byte Route Distinguisher (RD).
Distinguisher (RD). If the globally unique identifier for a VPLS is Any method of assigning one or more unique identifiers to a VPLS and
an RFC2685 VPN-id, it can be encoded as an RD as specified in [BGP- encoding each of them as an RD (using the encoding techniques of
AUTO]. However, any other method of assigning one or more unique [RFC4364]) will do.
identifiers to a VPLS and encoding each of them as an RD (using the
encoding techniques of [RFC2547bis]) will do. It is RECOMMENDED that a single VPN-ID be assigned to a VPLS
instance. That VPN-ID MAY be a VPN-ID as defined in [RFC2685], in
which case it SHOULD be encoded as an RD by placing the value 0x80 in
the first byte of the RD (to indicate the RD type) and the 7-byte
VPN-ID in the remaining bytes of the RD. However, any method of
assigning a unique VPN-ID to each VPLS instance and encoding that
VPN-ID in an RD MAY be used.
Each VSI needs to have a unique identifier, which can be encoded as a Each VSI needs to have a unique identifier, which can be encoded as a
BGP NLRI. This is formed by prepending the RD (from the previous BGP NLRI. This is formed by prepending the RD (from the previous
paragraph) to an IP address of the PE containing the VSI. Note that paragraph) to an IP address of the PE containing the VSI. Note that
the role of this address is simply as a readily available unique the role of this address is simply as a readily available unique
identifier for the VSIs within a VPN; it does not need to be globally identifier for the VSIs within a VPN; it does not need to be globally
routable. An alternate numbering scheme (e.g. numbering the VSIs of routable. An alternate numbering scheme (e.g. numbering the VSIs of
a single VPN from 1 to n) could be used if desired. a single VPN from 1 to n) could be used if desired.
(Note also that it is not strictly necessary for all the VSIs in the
same VPLS to have the same RD, all that is really necessary is that
the NLRI uniquely identify a VSI.)
Each VSI needs to be associated with one or more Route Target (RT) Each VSI needs to be associated with one or more Route Target (RT)
Extended Communities, as discussed in [BGP-AUTO]. These control the Extended Communities. These control the distribution of the NLRI,
distribution of the NLRI, and hence will control the formation of the and hence will control the formation of the overlay topology of
overlay topology of pseudowires that constitutes a particular VPLS. pseudowires that constitutes a particular VPLS.
Auto-discovery proceeds by having each PE distribute, via BGP, the Auto-discovery proceeds by having each PE distribute, via BGP, the
NLRI for each of its VSIs, with itself as the BGP next hop, and with NLRI for each of its VSIs, with itself as the BGP next hop, and with
the appropriate RT for each such NLRI. Typically, each PE would be a the appropriate RT for each such NLRI. Typically, each PE would be a
client of a small set of BGP route reflectors, which would client of a small set of BGP route reflectors, which would
redistribute this information to the other clients. redistribute this information to the other clients.
If a PE has a VSI with a particular RT, it can then import all the If a PE has a VSI with a particular RT, it can then import all the
NLRI which have that same RT, and from the BGP next hop attribute of NLRI which have that same RT, and from the BGP next hop attribute of
these NLRI it will learn the IP addresses of the other PE routers these NLRI it will learn the IP addresses of the other PE routers
which have VSIs with the same RT. The considerations of [RFC2547bis] which have VSIs with the same RT. The considerations of [RFC4364]
section 4.3.3 on the use of route reflectors apply. section 4.3.3 on the use of route reflectors apply.
If a particular VPLS is meant to be a single fully connected LAN, all If a particular VPLS is meant to be a single fully connected LAN, all
its VSIs will have the same RT, in which case the RT could be (though its VSIs will have the same RT, in which case the RT could be (though
it need not be) an encoding of the VPN-id. If a particular VPLS it need not be) an encoding of the VPN-id. A VSI can be placed in
consists of multiple VLANs, each VLAN must have its own unique RT. A multiple VPLSes by assigning it multiple RTs.
VSI can be placed in multiple VLANS (or even in multiple VPLSes) by
assigning it multiple RTs.
Note that hierarchical VPLS can be set up by assigning multiple RTs Note that hierarchical VPLS can be set up by assigning multiple RTs
to some of the VSIs; the RT mechanism allows one to have complete to some of the VSIs; the RT mechanism allows one to have complete
control over the pseudowire overlay which constitutes the VPLS control over the pseudowire overlay which constitutes the VPLS
topology. topology.
If Distributed VPLS (described in Section 3.5) is deployed, only the If Distributed VPLS (described in Section 3.5) is deployed, only the
N-PEs participate in BGP-based autodiscovery. This means that an N-PEs participate in BGP-based autodiscovery. This means that an
N-PE would need to advertise reachability to each of the VSIs that it N-PE would need to advertise reachability to each of the VSIs that it
supports, including those located in U-PEs to which it is connected. supports, including those located in U-PEs to which it is connected.
To create a unique identifier for each such VSI, an IP address of To create a unique identifier for each such VSI, an IP address of
each U-PE combined with the RD for the VPLS instance could be used. each U-PE combined with the RD for the VPLS instance could be used.
In summary, the BGP advertisement for a particular VSI at a given PE In summary, the BGP advertisement for a particular VSI at a given PE
will contain: will contain:
o an NLRI of AFI = L2VPN, SAFI = TBD, encoded as RD:PE_addr o an NLRI of AFI = L2VPN, SAFI = TBA, encoded as RD:PE_addr
o a BGP next hop equal to the loopback address of the PE o a BGP next hop equal to the loopback address of the PE
o an extended community attribute containing one or more RTs. o an extended community attribute containing one or more RTs.
See Section Section 6 for discussion of the AFI and SAFI values.
Note that this advertisement is quite similar to the NLRI format Note that this advertisement is quite similar to the NLRI format
defined in [BGP-VPLS], the main difference being that [BGP-VPLS] also defined in [I-D.ietf-l2vpn-vpls-bgp], the main difference being that
includes a label block in the NLRI. Interoperability between the [I-D.ietf-l2vpn-vpls-bgp] also includes a label block in the NLRI.
VPLS scheme defined here and that defined in [BGP-VPLS] is beyond the Interoperability between the VPLS scheme defined here and that
scope of this document. defined in [I-D.ietf-l2vpn-vpls-bgp] is beyond the scope of this
document.
3.2.3. Signaling 3.2.3. Signaling
It is necessary to create Attachment Identifiers which identify the It is necessary to create Attachment Identifiers which identify the
VSIs. In the preceding section, a VSI-ID was encoded as RD:PE_addr VSIs. In the preceding section, a VSI-ID was encoded as RD:PE_addr
for the purposes of autodiscovery. For signaling purposes, the same for the purposes of autodiscovery. For signaling purposes, the same
information is carried but is encoded slightly differently. information is carried but is encoded slightly differently.
Specifically, we encode the RD in the AGI field, and place the Specifically, we encode the RD in the AGI field, and place the
PE_addr (or, more generally, the VSI-ID that was advertised in BGP, PE_addr (or, more generally, the VSI-ID that was advertised in BGP,
minus the RD) in the TAII field. The combination of AGI and TAII is minus the RD) in the TAII field. The combination of AGI and TAII is
sufficient to fully specify the VSI to which this pseudowire is to be sufficient to fully specify the VSI to which this pseudowire is to be
connected, in both single AS and inter-AS environments. The SAII connected, in both single AS and inter-AS environments. The SAII
SHOULD be null. MUST be set to the PE_addr of the sending PE (or, more generally, the
VSI-ID, without the RD, of the VSI associated with this VPLS in the
sending PE), to enable signaling of the reverse half of the PW if
needed.
The structure of the AGI and AII fields for the Generalized ID FEC in The structure of the AGI and AII fields for the Generalized ID FEC in
LDP is defined in [PWE3-CONTROL]. The AGI field in this case LDP is defined in [I-D.ietf-pwe3-control-protocol]. The AGI field in
consists of a Type of 1, a length field of value 8, and the 8 bytes this case consists of a Type of 1, a length field of value 8, and the
of the RD. The TAII consists of a Type of 1, a length field of value 8 bytes of the RD. The TAII consists of a Type of 1, a length field
4, followed by the 4-byte PE address (or other 4-byte identifier). of value 4, followed by the 4-byte PE address (or other 4-byte
See Section 6 for discussion of the AGI and AII Type assignment. identifier). See Section 6 for discussion of the AGI and AII Type
assignment.
The encoding of the AGI and AII in L2TP is specified in [L2TP-L2VPN]. The encoding of the AGI and AII in L2TP is specified in [I-D.ietf-
l2tpext-l2vpn].
Note that it is not possible using this technique to set up more than Note that it is not possible using this technique to set up more than
one PW per pair of VSIs. one PW per pair of VSIs.
3.2.4. Pseudowires as VPLS Attachment Circuits 3.2.4. Pseudowires as VPLS Attachment Circuits
It is also possible using this technique to set up a PW which It is also possible using this technique to set up a PW which
attaches at one endpoint to a VSI, but at the other endpoint only to attaches at one endpoint to a VSI, but at the other endpoint only to
an Attachment Circuit. However, in this case there may be more than an Attachment Circuit. There may be more than one PW terminating on
one PW terminating on a given VSI, which must somehow be a given VSI, which must somehow be distinguished, so each PW must
distinguished, so that the SAIIs cannot be null in this case. have an SAII which is unique relative to the VSI-ID.
Rather, each such PW must have an SAII which is unique relative to
the VSI-ID.
3.3. Colored Pools: Full Mesh of Point-to-Point Pseudowires 3.3. Colored Pools: Full Mesh of Point-to-Point Pseudowires
The "Colored Pools" model of operation provides an automated way to The "Colored Pools" model of operation provides an automated way to
deliver Virtual Private Wire Service (VPWS). In this model, each PE deliver Virtual Private Wire Service (VPWS). In this model, each PE
may contain several pools of Attachment Circuits, each pool may contain several pools of Attachment Circuits, each pool
associated with a particular VPN. A PE may contain multiple pools associated with a particular VPN. A PE may contain multiple pools
per VPN, as each pool may correspond to a particular CE device. It per VPN, as each pool may correspond to a particular CE device. It
may be desired to create one pseudowire between each pair of pools may be desired to create one pseudowire between each pair of pools
that are in the same VPN; the result would be to create a full mesh that are in the same VPN; the result would be to create a full mesh
skipping to change at page 17, line 39 skipping to change at page 17, line 48
the relative pool identifier of a remote pool. Then that Attachment the relative pool identifier of a remote pool. Then that Attachment
Circuit would be bound to a particular pseudowire only if that Circuit would be bound to a particular pseudowire only if that
pseudowire's remote endpoint is the pool with that relative pool pseudowire's remote endpoint is the pool with that relative pool
identifier. With this option, the same pairs of Attachment Circuits identifier. With this option, the same pairs of Attachment Circuits
will always be bound via pseudowires. will always be bound via pseudowires.
3.3.2. Auto-Discovery 3.3.2. Auto-Discovery
3.3.2.1. BGP-based auto-discovery 3.3.2.1. BGP-based auto-discovery
The framework for BGP-based auto-discovery for a generic L2VPN A framework for BGP-based auto-discovery for a generic L2VPN service
service is described in [BGP-AUTO], section 3.2. is described in [I-D.ietf-l3vpn-bgpvpn-auto], section 3.2. In this
section we specify how BGP-based auto-discovery can be used to build
VPWS instances.
The AFI/SAFI used would be: When BGP-based autodiscovery is used for VPWS, the AFI/SAFI will be:
o An AFI specified by IANA for L2VPN. (This is the same for all o An AFI specified by IANA for L2VPN. (This is the same for all
L2VPN schemes.) L2VPN schemes.)
o A SAFI specified by IANA specifically for an L2VPN service whose o A SAFI specified by IANA specifically for an L2VPN service whose
pseudowires are set up using the procedures described in the pseudowires are set up using the procedures described in the
current document. current document.
See Section 6 for further discussion of AFI/SAFI assignment. See Section 6 for further discussion of AFI/SAFI assignment.
skipping to change at page 18, line 18 skipping to change at page 18, line 29
Distinguisher). The globally unique identifier of a pool must be Distinguisher). The globally unique identifier of a pool must be
encodable as NLRI; the color would be encoded as the RD and the pool encodable as NLRI; the color would be encoded as the RD and the pool
identifier as a four-byte quantity which is appended to the RD to identifier as a four-byte quantity which is appended to the RD to
create the NLRI. create the NLRI.
Each pool must also be associated with an RT (route target), which Each pool must also be associated with an RT (route target), which
may also be an encoding of the color. If the desired topology is a may also be an encoding of the color. If the desired topology is a
full mesh of pseudowires, all pools may have the same RT. See full mesh of pseudowires, all pools may have the same RT. See
Section 3.4 for a discussion of other topologies. Section 3.4 for a discussion of other topologies.
Auto-discovery procedures by having each PE distribute, via BGP, the Auto-discovery proceeds by having each PE distribute, via BGP, the
NLRI for each of its pools, with itself as the BGP next hop, and with NLRI for each of its pools, with itself as the BGP next hop, and with
the RT that encodes the pool's color. If a given PE has a pool with the RT that encodes the pool's color. If a given PE has a pool with
a particular color (RT), it must receive, via BGP, all NLRI with that a particular color (RT), it must receive, via BGP, all NLRI with that
same color (RT). Typically, each PE would be a client of a small set same color (RT). Typically, each PE would be a client of a small set
of BGP route reflectors, which would redistribute this information to of BGP route reflectors, which would redistribute this information to
the other clients. the other clients.
If a PE has a pool with a particular color, it can then receive all If a PE has a pool with a particular color, it can then receive all
the NLRI which have that same color, and from the BGP next hop the NLRI which have that same color, and from the BGP next hop
attribute of these NLRI will learn the IP addresses of the other PE attribute of these NLRI will learn the IP addresses of the other PE
routers which have pools switches with the same color. It also routers which have pools switches with the same color. It also
learns the unique identifier of each such remote pool, as this is learns the unique identifier of each such remote pool, as this is
encoded in the NLRI. The remote pool's relative identifier can be encoded in the NLRI. The remote pool's relative identifier can be
extracted from the NLRI and used in the signaling, as specified extracted from the NLRI and used in the signaling, as specified
below. below.
In summary, the BGP advertisement for a particular pool of attachment In summary, the BGP advertisement for a particular pool of attachment
circuits at a given PE will contain: circuits at a given PE will contain:
o an NLRI of AFI = L2VPN, SAFI = TBD, encoded as RD:pool_num; o an NLRI of AFI = L2VPN, SAFI = TBA, encoded as RD:pool_num;
o a BGP next hop equal to the loopback address of the PE; o a BGP next hop equal to the loopback address of the PE;
o an extended community attribute containing one or more RTs. o an extended community attribute containing one or more RTs.
See Section Section 6 for discussion of the AFI and SAFI values.
3.3.3. Signaling 3.3.3. Signaling
The LDP-based signaling follows the procedures specified in [PWE3- The LDP-based signaling follows the procedures specified in
CONTROL]. That is, one PE (PE1) sends a Label Mapping Message to [I-D.ietf-pwe3-control-protocol]. That is, one PE (PE1) sends a
another PE (PE2) to establish an LSP in one direction. The address Label Mapping Message to another PE (PE2) to establish an LSP in one
of PE2 is the next-hop address learned via BGP as described above. direction. The address of PE2 is the next-hop address learned via
If the message is processed successfully, and there is not yet an LSP BGP as described above. If the message is processed successfully,
for the pseudowire in the opposite (PE1->PE2) direction, then PE2 and there is not yet an LSP for the pseudowire in the opposite
sends a Label Mapping Message to PE1. Similarly, the L2TPv3-based (PE1->PE2) direction, then PE2 sends a Label Mapping Message to PE1.
signaling follows the procedures of [L2TP-BASE]. Additional details Similarly, the L2TPv3-based signaling follows the procedures of
on the use of these signaling protocols follow. [I-D.ietf-l2tpext-l2vpn]. Additional details on the use of these
signaling protocols follow.
When a PE sends a Label Mapping message or an ICRQ message to set up When a PE sends a Label Mapping message or an ICRQ message to set up
a PW between two pools, it encodes the color as the AGI, the local a PW between two pools, it encodes the color as the AGI, the local
pool's relative identifier as the SAII, and the remote pool's pool's relative identifier as the SAII, and the remote pool's
relative identifier as the TAII. relative identifier as the TAII.
The structure of the AGI and AII fields for the Generalized ID FEC in The structure of the AGI and AII fields for the Generalized ID FEC in
LDP is defined in [PWE3-CONTROL]. The AGI field in this case LDP is defined in [I-D.ietf-pwe3-control-protocol]. The AGI field in
consists of a Type of 1, a length field of value 8, and the 8 bytes this case consists of a Type of 1, a length field of value 8, and the
of the RD. The TAII consists of a Type of 1, a length field of value 8 bytes of the RD. The TAII consists of a Type of 1, a length field
4, followed by the 4-byte remote pool number. The SAII consists of a of value 4, followed by the 4-byte remote pool number. The SAII
Type of 1, a length field of value 4, followed by the 4-byte local consists of a Type of 1, a length field of value 4, followed by the
pool number. See Section 6 for discussion of the AGI and AII Type 4-byte local pool number. See Section 6 for discussion of the AGI
assignment. Note that the VPLS and VPWS procedures defined in this and AII Type assignment. Note that the VPLS and VPWS procedures
document can make use of the same AGI Type (1) and the same AII Type defined in this document can make use of the same AGI Type (1) and
(1). the same AII Type (1).
The encoding of the AGI and AII in L2TP is specified in [L2TP-L2VPN]. The encoding of the AGI and AII in L2TP is specified in [I-D.ietf-
l2tpext-l2vpn].
When PE2 receives a Label Mapping message or an ICRQ message from When PE2 receives a Label Mapping message or an ICRQ message from
PE1, and the TAI identifies to a pool, and there is already an PE1, and the TAI identifies to a pool, and there is already an
pseudowire connecting an Attachment Circuit in that pool to an pseudowire connecting an Attachment Circuit in that pool to an
Attachment Circuit at PE1, and the AI at PE1 of that pseudowire is Attachment Circuit at PE1, and the AI at PE1 of that pseudowire is
the same as the SAI of the Label Mapping or ICRQ message, then PE2 the same as the SAI of the Label Mapping or ICRQ message, then PE2
sends a Label Release or CDN message to PE1, with a Status Code sends a Label Release or CDN message to PE1, with a Status Code
meaning "Attachment Circuit already bound to remote Attachment meaning "Attachment Circuit already bound to remote Attachment
Circuit". This prevents the creation of multiple pseudowires between Circuit". This prevents the creation of multiple pseudowires between
a given pair of pools. a given pair of pools.
skipping to change at page 20, line 18 skipping to change at page 20, line 33
PW to every other pool which has X as one of its "export RTs". PW to every other pool which has X as one of its "export RTs".
The signaling messages and procedures themselves are as in section The signaling messages and procedures themselves are as in section
3.3.3. 3.3.3.
As a simple example, consider the task of building a hub-and-spoke As a simple example, consider the task of building a hub-and-spoke
topology with a single hub. One pool, the "hub" pool, is configured topology with a single hub. One pool, the "hub" pool, is configured
with an export RT of RT_hub and an import RT of RT_spoke. All other with an export RT of RT_hub and an import RT of RT_spoke. All other
pools (the spokes) are configured with an export RT of RT_spoke and pools (the spokes) are configured with an export RT of RT_spoke and
an import RT of RT_hub. Thus the Hub pool will connect to the an import RT of RT_hub. Thus the Hub pool will connect to the
spokes, and vice-versa, but the spoke pools will not connect to each spokes, and vice-versa, but the spoke pools will not connect to each
other. More complex examples are presented in section 4.2.2 of [BGP- other. More complex examples are presented in section 4.2.2 of
AUTO]. [I-D.ietf-l3vpn-bgpvpn-auto].
3.5. Distributed VPLS 3.5. Distributed VPLS
In Distributed VPLS ([L2VPN-FW], [DTLS], [LPE]), the VPLS In Distributed VPLS ([I-D.ietf-l2vpn-l2-framework]), the VPLS
functionality of a PE router is divided among two systems: a U-PE and functionality of a PE router is divided among two systems: a U-PE and
an N-PE. The U-PE sits between the user and the N-PE. VSI an N-PE. The U-PE sits between the user and the N-PE. VSI
functionality (e.g., MAC address learning and bridging) is performed functionality (e.g., MAC address learning and bridging) is performed
on the U-PE. A number of U-PEs attach to an N-PE. For each VPLS on the U-PE. A number of U-PEs attach to an N-PE. For each VPLS
supported by a U-PE, the U-PE maintains a pseudowire to each other supported by a U-PE, the U-PE maintains a pseudowire to each other
U-PE in the same VPLS. However, the U-PEs do not maintain signaling U-PE in the same VPLS. However, the U-PEs do not maintain signaling
control connections with each other. Rather, each U-PE has only a control connections with each other. Rather, each U-PE has only a
single signaling connection, to its N-PE. In essence, each U-PE-to- single signaling connection, to its N-PE. In essence, each U-PE-to-
U-PE pseudowire is composed of three pseudowires spliced together: U-PE pseudowire is composed of three pseudowires spliced together:
one from U-PE to N-PE, one from N-PE to N-PE, and one from N-PE to one from U-PE to N-PE, one from N-PE to N-PE, and one from N-PE to
U-PE. U-PE. In the terminology of [I-D.ietf-pwe3-ms-pw-arch], the N-PEs
perform the pseudowire switching function to establish multi-segment
PWs from U-PE to U-PE.
Consider for example the following topology: Consider for example the following topology:
U-PE A-----| |----U-PE C U-PE A-----| |----U-PE C
| | | |
| | | |
N-PE E--------N-PE F N-PE E--------N-PE F
| | | |
| | | |
U-PE B-----| |-----U-PE D U-PE B-----| |-----U-PE D
skipping to change at page 22, line 4 skipping to change at page 22, line 22
| | | |
N-PE E--------N-PE F N-PE E--------N-PE F
| | | |
| | | |
U-PE B-----| |-----U-PE D U-PE B-----| |-----U-PE D
B-D PW <-----><-----------><------> B-D PW <-----><-----------><------>
^ ^ ^ ^
| | | |
splicing points splicing points
One can see that distributed VPLS does not reduce the number of One can see that distributed VPLS does not reduce the number of
pseudowires per U-PE, but it does reduce the number of control pseudowires per U-PE, but it does reduce the number of control
connections per U-PE. Whether this is worthwhile depends, of course, connections per U-PE. Whether this is worthwhile depends, of course,
on what the bottleneck is. on what the bottleneck is.
3.5.1. Signaling 3.5.1. Signaling
The signaling to support Distributed VPLS can be done with the The signaling to support Distributed VPLS can be done with the
mechanisms described in this paper. However, the procedures for VPLS mechanisms described in this document. However, the procedures for
(section 3.2.3) need some additional machinery to ensure that the VPLS (section 3.2.3) need some additional machinery to ensure that
appropriate number of PWs are established between the various N-PEs the appropriate number of PWs are established between the various
and U-PEs, and among the N-PEs. N-PEs and U-PEs, and among the N-PEs.
At a given N-PE, the directly attached U-PEs in a given VPLS can be At a given N-PE, the directly attached U-PEs in a given VPLS can be
numbered from 1 to n. This number identifies the U-PE relative to a numbered from 1 to n. This number identifies the U-PE relative to a
particular VPN-id and a particular N-PE. (That is, to uniquely particular VPN-id and a particular N-PE. (That is, to uniquely
identify the U-PE, the N-PE, the VPN-id, and the U-PE number must be identify the U-PE, the N-PE, the VPN-id, and the U-PE number must be
known.) known.)
As a result of configuration/discovery, each U-PE must be given a As a result of configuration/discovery, each U-PE must be given a
list of <j, IP address> pairs. Each element in this list tells the list of <j, IP address> pairs. Each element in this list tells the
U-PE to set up j PWs to the specified IP address. When the U-PE U-PE to set up j PWs to the specified IP address. When the U-PE
skipping to change at page 23, line 33 skipping to change at page 24, line 6
considered equivalent. As long as the correct total number of PWs considered equivalent. As long as the correct total number of PWs
are established, the N-PEs can splice these PWs to appropriate U-PWs. are established, the N-PEs can splice these PWs to appropriate U-PWs.
The signaling of the correct number of PWs from N-PE to N-PE is based The signaling of the correct number of PWs from N-PE to N-PE is based
on the remote list. The remote list specifies the number of PWs to on the remote list. The remote list specifies the number of PWs to
set up, per local U-PE, to a particular remote N-PE. set up, per local U-PE, to a particular remote N-PE.
When signaling a particular PW from an N-PE to an N-PE, the AGI is When signaling a particular PW from an N-PE to an N-PE, the AGI is
set to the appropriate VPN-id. The TAII identifies the remote N-PE, set to the appropriate VPN-id. The TAII identifies the remote N-PE,
as in the non-distributed case, i.e. it contains an IP address of the as in the non-distributed case, i.e. it contains an IP address of the
remote N-PE. If there are n such PWs, they are distinguished by the remote N-PE. If there are n such PWs, they are distinguished by the
setting of the SAII, which will be a number from 1 to n inclusive. A setting of the SAII. In order to allow multiple different SAII
PW between two N-PEs is known as an "N-PW". values in a single VPLS, the sending N-PE needs to have as many VSI-
IDs as it has U-PEs. As noted above in Section 3.2.2, this may be
achieved by using an IP address of each attached U-PE, for example.
A PW between two N-PEs is known as an "N-PW".
Each U-PW must be "spliced" to an N-PW. This is based on the remote Each U-PW must be "spliced" to an N-PW. This is based on the remote
list. If the remote list contains an element <i, F>, then i U-PWs list. If the remote list contains an element <i, F>, then i U-PWs
from each local U-PE must be spliced to i N-PWs from the remote N-PE from each local U-PE must be spliced to i N-PWs from the remote N-PE
F. It does not matter which U-PWs are spliced to which N-PWs, as long F. It does not matter which U-PWs are spliced to which N-PWs, as long
as this constraint is met. as this constraint is met.
If an N-PE has more than one local U-PE for a given VPLS, it must If an N-PE has more than one local U-PE for a given VPLS, it must
also ensure that a U-PW from each such U-PE is spliced to a U-PW from also ensure that a U-PW from each such U-PE is spliced to a U-PW from
each of the other U-PEs. each of the other U-PEs.
skipping to change at page 24, line 18 skipping to change at page 24, line 42
the VPLS. This information is sufficient to enable one to compute the VPLS. This information is sufficient to enable one to compute
the local list and the remote list for each N-PE. the local list and the remote list for each N-PE.
3.5.3. Non-distributed VPLS as a sub-case 3.5.3. Non-distributed VPLS as a sub-case
A PE which is providing "non-distributed VPLS" (i.e., a PE which A PE which is providing "non-distributed VPLS" (i.e., a PE which
performs both the U-PE and N-PE functions) can interoperate with performs both the U-PE and N-PE functions) can interoperate with
N-PE/U-PE pairs that are providing distributed VPLS. The "non- N-PE/U-PE pairs that are providing distributed VPLS. The "non-
distributed PE" simply advertises, in the discovery procedure, that distributed PE" simply advertises, in the discovery procedure, that
it has one local U-PE per VPLS. And of course, the non-distributed it has one local U-PE per VPLS. And of course, the non-distributed
PE does no splicing. PE does no PW switching.
If every PE in a VPLS is providing non-distributed VPLS, and thus If every PE in a VPLS is providing non-distributed VPLS, and thus
every PE advertises itself as an N-PE with one local U-PE, the every PE advertises itself as an N-PE with one local U-PE, the
resultant signaling is exactly the same as that specified in resultant signaling is exactly the same as that specified in
Section 3.2.3 above, except that an SAII value of 1 is used instead Section 3.2.3 above.
of null. (A PE providing non-distributed VPLS should therefore treat
SAII values of 1 the same as it treats SAII values of null.)
3.5.4. Splicing and the Data Plane 3.5.4. Splicing and the Data Plane
Splicing two PWs together is quite straightforward in the MPLS data Splicing two PWs together is quite straightforward in the MPLS data
plane, as moving a packet from one PW directly to another is just a plane, as moving a packet from one PW directly to another is just a
label replace operation on the PW label. When a PW consists of two label replace operation on the PW label. When a PW consists of two
or more PWs spliced together, it is assumed that the data will go to or more PWs spliced together, it is assumed that the data will go to
the node where the splicing is being done, i.e., that the data path the node where the splicing is being done, i.e., that the data path
will pass through the nodes that participate in PW signaling. will pass through the nodes that participate in PW signaling.
Further details on splicing are discussed in [PW-SWITCH]. Further details on splicing are discussed in [I-D.ietf-pwe3-
segmented-pw].
4. Inter-AS Operation 4. Inter-AS Operation
The provisioning, autodiscovery and signaling mechanisms described The provisioning, autodiscovery and signaling mechanisms described
above can all be applied in an inter-AS environment. As in [2547bis] above can all be applied in an inter-AS environment. As in [RFC4364]
there are a number of options for inter-AS operation. there are a number of options for inter-AS operation.
4.1. Multihop EBGP redistribution of L2VPN NLRIs 4.1. Multihop EBGP redistribution of L2VPN NLRIs
This option is most like option (c) in [2547bis]. That is, we use This option is most like option (c) in [RFC4364]. That is, we use
multihop EBGP redistribution of L2VPN NLRIs between source and multihop EBGP redistribution of L2VPN NLRIs between source and
destination ASes, with EBGP redistribution of labeled IPv4 routes destination ASes, with EBGP redistribution of labeled IPv4 or IPv6
from AS to neighboring AS. routes from AS to neighboring AS.
An ASBR must maintain labeled IPv4 /32 routes to the PE routers An ASBR must maintain labeled IPv4 /32 (or IPv6 /128) routes to the
within its AS. It uses EBGP to distribute these routes to other PE routers within its AS. It uses EBGP to distribute these routes to
ASes, and sets itself as the BGP next hop for these routes. ASBRs in other ASes, and sets itself as the BGP next hop for these routes.
any transit ASes will also have to use EBGP to pass along the labeled ASBRs in any transit ASes will also have to use EBGP to pass along
/32 routes. This results in the creation of a set of label switched the labeled /32 (or /128) routes. This results in the creation of a
paths from all ingress PE routers to all egress PE routers. Now PE set of label switched paths from all ingress PE routers to all egress
routers in different ASes can establish multi-hop EBGP connections to PE routers. Now PE routers in different ASes can establish multi-hop
each other, and can exchange L2VPN NLRIs over those connections. EBGP connections to each other, and can exchange L2VPN NLRIs over
Following such exchanges a pair of PEs in different ASes could those connections. Following such exchanges a pair of PEs in
establish an LDP session to signal PWs between each other. different ASes could establish an LDP session to signal PWs between
each other.
For VPLS, the BGP advertisement and PW signaling are exactly as For VPLS, the BGP advertisement and PW signaling are exactly as
described in Section 3.2. As a result of the multihop EBGP session described in Section 3.2. As a result of the multihop EBGP session
that exists between source and destination AS, the PEs in one AS that that exists between source and destination AS, the PEs in one AS that
have VSIs of a certain VPLS will discover the PEs in another AS that have VSIs of a certain VPLS will discover the PEs in another AS that
have VSIs of the same VPLS. These PEs will then be able to establish have VSIs of the same VPLS. These PEs will then be able to establish
the appropriate PW signaling protocol session and establish the full the appropriate PW signaling protocol session and establish the full
mesh of VSI-VSI pseudowires to build the VPLS as described in Section mesh of VSI-VSI pseudowires to build the VPLS as described in Section
3.2.3. 3.2.3.
skipping to change at page 26, line 5 skipping to change at page 27, line 5
that have pools of the same color. These PEs will then be able to that have pools of the same color. These PEs will then be able to
establish the appropriate PW signaling protocol session and establish establish the appropriate PW signaling protocol session and establish
the full mesh of pseudowires as described in Section 3.2.3. A the full mesh of pseudowires as described in Section 3.2.3. A
partial mesh can similarly be established using the procedures of partial mesh can similarly be established using the procedures of
Section 3.4. Section 3.4.
As in layer 3 VPNs, building an L2VPN that spans the networks of more As in layer 3 VPNs, building an L2VPN that spans the networks of more
than one provider requires some co-ordination in the use of RTs and than one provider requires some co-ordination in the use of RTs and
RDs. This subject is discussed in more detail in Section 4.4. RDs. This subject is discussed in more detail in Section 4.4.
4.2. EBGP redistribution of L2VPN NLRIs with Pseudowire Switching 4.2. EBGP redistribution of L2VPN NLRIs with Multi-Segment Pseudowires
A possible drawback of the approach of the previous section is that A possible drawback of the approach of the previous section is that
it creates PW signaling sessions among all the PEs of a given L2VPN it creates PW signaling sessions among all the PEs of a given L2VPN
(VPLS or VPWS). This means a potentially large number of LDP or (VPLS or VPWS). This means a potentially large number of LDP or
L2TPv3 sessions will cross the AS boundary and that these session L2TPv3 sessions will cross the AS boundary and that these session
connect to many devices within an AS. In the case were the ASes connect to many devices within an AS. In the case were the ASes
belong to different providers, one might imagine that providers would belong to different providers, one might imagine that providers would
like to have fewer signaling sessions crossing the AS boundary and like to have fewer signaling sessions crossing the AS boundary and
that the entities that terminate the sessions could be restricted to that the entities that terminate the sessions could be restricted to
a smaller set of devices. Furthermore, by forcing the LDP or L2TPv3 a smaller set of devices. Furthermore, by forcing the LDP or L2TPv3
signaling sessions to terminate on a small set of ASBRs, a provider signaling sessions to terminate on a small set of ASBRs, a provider
could use standard authentication procedures on a small set of inter- could use standard authentication procedures on a small set of inter-
provider sessions. These concerns motivate the approach described provider sessions. These concerns motivate the approach described
here. here.
[PW-SWITCH] describes an approach to "switching" packets from one [I-D.ietf-pwe3-segmented-pw] describes an approach to "switching"
pseudowire to another at a particular node. This approach allows an packets from one pseudowire to another at a particular node. This
end-to-end pseudowire to be constructed out of several pseudowire approach allows an end-to-end, multi-segment pseudowire to be
segments, without maintaining an end-to-end control connection. We constructed out of several pseudowire segments, without maintaining
can use this approach to produce an inter-AS solution that more an end-to-end control connection. We can use this approach to
closely resembles option (b) in [2547bis]. produce an inter-AS solution that more closely resembles option (b)
in [RFC4364].
In this model, we use EBGP redistribution of L2VPN NLRI from AS to In this model, we use EBGP redistribution of L2VPN NLRI from AS to
neighboring AS. First, the PE routers use IBGP to redistribute L2VPN neighboring AS. First, the PE routers use IBGP to redistribute L2VPN
NLRI either to an Autonomous System Border Router (ASBR), or to a NLRI either to an Autonomous System Border Router (ASBR), or to a
route reflector of which an ASBR is a client. The ASBR then uses route reflector of which an ASBR is a client. The ASBR then uses
EBGP to redistribute those L2VPN NLRI to an ASBR in another AS, which EBGP to redistribute those L2VPN NLRI to an ASBR in another AS, which
in turn distributes them to the PE routers in that AS, or perhaps to in turn distributes them to the PE routers in that AS, or perhaps to
another ASBR which in turn distributes them, and so on. another ASBR which in turn distributes them, and so on.
In this case, a PE can learn the address of an ASBR through which it In this case, a PE can learn the address of an ASBR through which it
could reach another PE to which it wishes to establish a PW. That could reach another PE to which it wishes to establish a PW. That
is, a local PE will receive a BGP advertisement containing L2VPN NLRI is, a local PE will receive a BGP advertisement containing L2VPN NLRI
corresponding to an L2VPN instance in which the local PE has some corresponding to an L2VPN instance in which the local PE has some
attached members. The BGP next-hop for that L2VPN NLRI will be an attached members. The BGP next-hop for that L2VPN NLRI will be an
ASBR of the local AS. Then, rather than building a control ASBR of the local AS. Then, rather than building a control
connection all the way to the remote PE, it builds one only to the connection all the way to the remote PE, it builds one only to the
ASBR. A pseudowire segment can now be established from the PE to the ASBR. A pseudowire segment can now be established from the PE to the
ASBR. The ASBR in turn can establish a PW to the ASBR of the next ASBR. The ASBR in turn can establish a PW to the ASBR of the next
AS, and splice that PW to the PW from the PE as described in AS, and splice that PW to the PW from the PE as described in
Section 3.5.4 and [PW-SWITCH]. Repeating the process at each ASBR Section 3.5.4 and [I-D.ietf-pwe3-segmented-pw]. Repeating the
leads to a sequence of PW segments that, when spliced together, process at each ASBR leads to a sequence of PW segments that, when
connect the two PEs. spliced together, connect the two PEs.
Note that in the approach just described, the local PE may never Note that in the approach just described, the local PE may never
learn the IP address of the remote PE. It learns the L2VPN NLRI learn the IP address of the remote PE. It learns the L2VPN NLRI
advertised by the remote PE, which need not contain the remote PE advertised by the remote PE, which need not contain the remote PE
address, and it learns the IP address of the ASBR that is the BGP address, and it learns the IP address of the ASBR that is the BGP
next hop for that NLRI. next hop for that NLRI.
When this approach is used for VPLS, or for full-mesh VPWS, it leads When this approach is used for VPLS, or for full-mesh VPWS, it leads
to a full mesh of pseudowires among the PEs, just as in the previous to a full mesh of pseudowires among the PEs, just as in the previous
section, but it does not require a full mesh of control connections section, but it does not require a full mesh of control connections
(LDP or L2TPv3 sessions). Instead the control connections within a (LDP or L2TPv3 sessions). Instead the control connections within a
single AS run among all the PEs of that AS and the ASBRs of the AS. single AS run among all the PEs of that AS and the ASBRs of the AS.
A single control connection between the ASBRs of adjacent ASes can be A single control connection between the ASBRs of adjacent ASes can be
used to support however many AS-to-AS pseudowire segments are needed. used to support however many AS-to-AS pseudowire segments are needed.
Note that the procedures described here will result in the splicing Note that the procedures described here will result in the splicing
points being co-located with the ASBRs. It is of course possible to points (S-PEs in the terminology of [I-D.ietf-pwe3-ms-pw-arch]) being
have multiple ASBR-ASBR connections between a given pair of ASes. In co-located with the ASBRs. It is of course possible to have multiple
this case a given PE could choose among the available ASBRs based on ASBR-ASBR connections between a given pair of ASes. In this case a
a range of criteria, such as IGP metric, local configuration, etc., given PE could choose among the available ASBRs based on a range of
analogous to choosing an exit point in normal IP routing. The use of criteria, such as IGP metric, local configuration, etc., analogous to
multiple ASBRs would lead to greater resiliency (at the timescale of choosing an exit point in normal IP routing. The use of multiple
BGP routing convergence) since a PE could select a new ASBR in the ASBRs would lead to greater resiliency (at the timescale of BGP
event of the failure of the one currently in use. routing convergence) since a PE could select a new ASBR in the event
of the failure of the one currently in use.
As in layer 3 VPNs, building an L2VPN that spans the networks of more As in layer 3 VPNs, building an L2VPN that spans the networks of more
than one provider requires some co-ordination in the use of RTs and than one provider requires some co-ordination in the use of RTs and
RDs. This subject is discussed in more detail in Section 4.4. RDs. This subject is discussed in more detail in Section 4.4.
4.3. Inter-Provider Application of Dist. VPLS Signaling 4.3. Inter-Provider Application of Distributed VPLS Signaling
An alternative approach to inter-provider VPLS can be derived from An alternative approach to inter-provider VPLS can be derived from
the Distributed VPLS approach described above. Consider the the Distributed VPLS approach described above. Consider the
following topology: following topology:
PE A --- Network 1 ----- Border ----- Border ----- Network 2 --- PE B PE A --- Network 1 ----- Border ----- Border ----- Network 2 --- PE B
Router 12 Router 21 | Router 12 Router 21 |
| |
PE C PE C
skipping to change at page 28, line 27 skipping to change at page 29, line 28
A-BR12, BR12-BR21, and BR21-B. The border routers would have to A-BR12, BR12-BR21, and BR21-B. The border routers would have to
splice the corresponding segments together. splice the corresponding segments together.
This requires the PEs within a VPLS to be numbered from 1-n (relative This requires the PEs within a VPLS to be numbered from 1-n (relative
to that VPLS) within a given network. to that VPLS) within a given network.
4.4. RT and RD Assignment Considerations 4.4. RT and RD Assignment Considerations
We note that, in order for any of the inter-AS procedures described We note that, in order for any of the inter-AS procedures described
above to work correctly, the two ASes must use RTs and RDs above to work correctly, the two ASes must use RTs and RDs
consistently, just as in layer 3 VPNs [RFC2547bis]. The structure of consistently, just as in layer 3 VPNs [RFC4364]. The structure of
RTs and RDs is such that there is not a great risk of accidental RTs and RDs is such that there is not a great risk of accidental
collisions. The main challenge is that it is necessary for the collisions. The main challenge is that it is necessary for the
operator of one AS to know what RT or RTs have been chosen in another operator of one AS to know what RT or RTs have been chosen in another
AS for any VPN that has sites in both ASes. As in layer 3 VPNs, AS for any VPN that has sites in both ASes. As in layer 3 VPNs,
there are many ways to make this work, but all require some co- there are many ways to make this work, but all require some co-
operation among the providers. For example, provider A may tag all operation among the providers. For example, provider A may tag all
the NLRI for a given VPN with a single RT, say RT_A, and provider B the NLRI for a given VPN with a single RT, say RT_A, and provider B
can then configure the PEs that connect to sites of that VPN to can then configure the PEs that connect to sites of that VPN to
import NLRI that contains that RT. Provider B can choose a different import NLRI that contains that RT. Provider B can choose a different
RT, RT_B, tag all NLRI for this VPN with that RT, and then provider A RT, RT_B, tag all NLRI for this VPN with that RT, and then provider A
skipping to change at page 29, line 13 skipping to change at page 30, line 13
across the AS boundary. across the AS boundary.
5. Security Considerations 5. Security Considerations
This document describes a number of different L2VPN provisioning This document describes a number of different L2VPN provisioning
models, and specifies the endpoint identifiers that are required to models, and specifies the endpoint identifiers that are required to
support each of the provisioning models. It also specifies how those support each of the provisioning models. It also specifies how those
endpoint identifiers are mapped into fields of auto-discovery endpoint identifiers are mapped into fields of auto-discovery
protocols and signaling protocols. protocols and signaling protocols.
The security considerations related to the signaling and auto- The security considerations related to the signaling protocols are
discovery protocols are discussed in the relevant protocol discussed in the relevant protocol specifications ([RFC3036]
specifications ([BGP-AUTO], [L2TP-BASE], [L2TP-L2VPN], [LDP], [PWE3- [I-D.ietf-pwe3-control-protocol] [RFC3931] [I-D.ietf-l2tpext-l2vpn]).
CONTROL]).
The security considerations related to the particular kind of L2VPN The security considerations related to BGP-based autodiscovery,
service being supported are discussed in [L2VPN-REQS], [L2VPN-FW], including inter-AS issues, are discussed in [RFC4364].
and [VPLS].
The security consideration of inter-AS operation are similar to those The security considerations related to the particular kind of L2VPN
for inter-AS L3VPNs [2547bis]. service being supported are discussed in [I-D.ietf-l2vpn-l2-
framework], [I-D.ietf-l2vpn-requirements], and [I-D.ietf-l2vpn-vpls-
ldp].
The way in which endpoint identifiers are mapped into protocol fields The way in which endpoint identifiers are mapped into protocol fields
does not create any additional security issues. does not create any additional security issues.
6. IANA Considerations 6. IANA Considerations
This document does not require any IANA actions.
This document assumes the assignment of an AFI and a SAFI for L2VPN This document assumes the assignment of an AFI and a SAFI for L2VPN
NLRI. Both AFI and SAFI may be the same as the values assigned for NLRI. Both AFI and SAFI should be the same as the values assigned
[BGP-VPLS]. for [I-D.ietf-l2vpn-vpls-bgp].
[PWE3-IANA] defines registries for "Attachment Group Identifier (AGI) [I-D.ietf-pwe3-iana-allocation] defines registries for "Attachment
Type" and "Attachment Individual Identifier (AII) Type". Type 1 in Group Identifier (AGI) Type" and "Attachment Individual Identifier
each registry has been assigned to the AGI and AII formats defined in (AII) Type". Type 1 in each registry has been assigned to the AGI
this document. and AII formats defined in this document.
This document requires two new LDP status codes. IANA already
maintains a registry of name "STATUS CODE NAME SPACE" defined by
[RFC3036]. The following values are suggested for assignment:
0x0000002C "Attachment Circuit bound to different PE"
0x0000002D "Attachment Circuit bound to different remote Attachment
Circuit".
The document requires two new L2TP Result Codes for the CDN message.
IANA already maintains a registry of L2TP Result Code Values for the
CDN message, defined by [RFC3438]. The following values are
requested for assignment:
RC-TBD1: Attachment Circuit bound to different PE
RC-TBD2: Attachment Circuit bound to different remote Attachment
Circuit
7. Acknowledgments 7. Acknowledgments
Thanks to Dan Tappan, Ted Qian, Ali Sajassi, Skip Booth, Luca Thanks to Dan Tappan, Ted Qian, Ali Sajassi, Skip Booth, Luca
Martini, Dave McDysan and Francois LeFaucheur for their comments, Martini, Dave McDysan, Francois LeFaucheur, and Matthew Bocci for
criticisms, and helpful suggestions. their comments, criticisms, and helpful suggestions.
Thanks to Tissa Senevirathne, Hamid Ould-Brahim and Yakov Rekhter for Thanks to Tissa Senevirathne, Hamid Ould-Brahim and Yakov Rekhter for
discussing the auto-discovery issues. discussing the auto-discovery issues.
Thanks to Vach Kompella for a continuing discussion of the proper Thanks to Vach Kompella for a continuing discussion of the proper
semantics of the generalized identifiers. semantics of the generalized identifiers.
8. Normative References 8. References
[BRADNER] Bradner, S., "Key words for use in RFCs to Indicate 8.1. Normative References
Requirement Levels", BCP 14, RFC 2119, March 1997.
[MP-BGP] Bates, T., Rekhter, Y., Chandra, R. and D. Katz, [I-D.ietf-idr-bgp-ext-communities]
"Multiprotocol Extensions for BGP-4", RFC 2858, June 2000. Rekhter, Y., "BGP Extended Communities Attribute",
draft-ietf-idr-bgp-ext-communities-09 (work in progress),
July 2005.
[EXT-COMM] Sangli, S., Tappan, D. and Y. Rekhter, "BGP Extended [I-D.ietf-l2tpext-l2vpn]
Communities Attribute", Internet-Draft Luo, W., "L2VPN Extensions for L2TP",
draft-ietf-idr-bgp-ext-communities-09, July 2005. draft-ietf-l2tpext-l2vpn-07 (work in progress),
March 2006.
[L2TP-BASE] Lau et. al., "Layer Two Tunneling Protocol (Version 3)", [I-D.ietf-pwe3-control-protocol]
RFC 3931, March 2005. Martini, L., "Pseudowire Setup and Maintenance using the
Label Distribution Protocol",
draft-ietf-pwe3-control-protocol-17 (work in progress),
June 2005.
[LDP] Anderson et al., "LDP Specification", RFC 3036, Jan 2001. [I-D.ietf-pwe3-segmented-pw]
Martini, L., "Segmented Pseudo Wire",
draft-ietf-pwe3-segmented-pw-01 (work in progress),
October 2005.
[PWE3-CONTROL] "Pseudowire Setup and Maintenance using LDP", Martini, [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
et. al., draft-ietf-pwe3-control-protocol-17.txt, June 2005. Requirement Levels", BCP 14, RFC 2119, March 1997.
9. Informative References [RFC2685] Fox, B. and B. Gleeson, "Virtual Private Networks
Identifier", RFC 2685, September 1999.
[BGP-AUTO] "Using BGP as an Auto-Discovery Mechanism for Network- [RFC2858] Bates, T., Rekhter, Y., Chandra, R., and D. Katz,
based VPNs", Ould-Brahim et. al., "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000.
draft-ietf-l3vpn-bgpvpn-auto-05.txt, February 2005
[L2TP-L2VPN] "L2VPN Extensions for L2TP", Luo, [RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and
draft-ietf-l2tpext-l2vpn-05.txt, June 2005 B. Thomas, "LDP Specification", RFC 3036, January 2001.
[L2VPN-FW] "L2VPN Framework", Andersson et. al., [RFC3438] Townsley, W., "Layer Two Tunneling Protocol (L2TP)
draft-ietf-l2vpn-l2-framework-05.txt, June 2004 Internet Assigned Numbers Authority (IANA) Considerations
Update", BCP 68, RFC 3438, December 2002.
[L2VPN-REQ] "Service Requirements for Layer 2 Provider Provisioned [RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling
Virtual Private Network Services", Augustyn, Serbest, et. al., Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.
draft-ietf-l2vpn-requirements-04.txt, February 2005
[L2VPN-TERM] Andersson, Madsen, "PPVPN Terminology", RFC 4026, March [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
2005. Networks (VPNs)", RFC 4364, February 2006.
[PWE3-ARCH] Bryant, Pate, et. al., "PWE3 Architecture", RFC 3985, 8.2. Informative References
March 2005.
[PW-SWITCH] "Pseudo Wire Switching", Martini, et. al., [I-D.ietf-l2vpn-l2-framework]
draft-martini-pwe3-pw-switching-03.txt, April 2005 Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual
Private Networks (L2VPNs)",
draft-ietf-l2vpn-l2-framework-05 (work in progress),
June 2004.
[PWE3-IANA] "IANA Allocations for pseudo Wire Edge to Edge Emulation [I-D.ietf-l2vpn-requirements]
(PWE3)", Martini, draft-ietf-pwe3-iana-allocation-11.txt, June 2005 Augustyn, W. and Y. Serbest, "Service Requirements for
Layer 2 Provider Provisioned Virtual Private Networks",
draft-ietf-l2vpn-requirements-06 (work in progress),
January 2006.
[RFC2547bis], "BGP/MPLS IP VPNs", Rosen, Rekhter, et. al., [I-D.ietf-l2vpn-vpls-bgp]
draft-ietf-l3vpn-rfc2547bis-03.txt, October 2004 Kompella, K. and Y. Rekhter, "Virtual Private LAN
Service", draft-ietf-l2vpn-vpls-bgp-06 (work in progress),
December 2005.
[RFC2685] "Virtual Private Networks Identifier", Fox, Gleeson, RFC [I-D.ietf-l2vpn-vpls-ldp]
2685, September 1999 Lasserre, M. and V. Kompella, "Virtual Private LAN
Services over MPLS", draft-ietf-l2vpn-vpls-ldp-08 (work in
progress), November 2005.
[VPLS] "Virtual Private LAN Services over MPLS", Laserre, et. al., [I-D.ietf-l3vpn-bgpvpn-auto]
draft-ietf-l2vpn-vpls-ldp-06.txt, February 2005 Ould-Brahim, H., "Using BGP as an Auto-Discovery Mechanism
for Layer-3 and Layer-2 VPNs",
draft-ietf-l3vpn-bgpvpn-auto-06 (work in progress),
June 2005.
[BGP-VPLS] "Virtual Private LAN Service", Kompella et al., [I-D.ietf-pwe3-iana-allocation]
draft-ietf-l2vpn-vpls-bgp-05.txt, April 2005 Martini, L., "IANA Allocations for pseudo Wire Edge to
Edge Emulation (PWE3)", draft-ietf-pwe3-iana-allocation-15
(work in progress), November 2005.
[AII-TYPES] "AII Types for Aggregation", Metz et al., [I-D.ietf-pwe3-ms-pw-arch]
draft-metz-aii-aggregate-00.txt, July 2005 Bocci, M. and S. Bryant, "An Architecture for Multi-
Segment Pseudo Wire Emulation Edge-to-Edge",
draft-ietf-pwe3-ms-pw-arch-00 (work in progress),
January 2006.
[I-D.metz-aii-aggregate]
Metz, C., "AII Types for Aggregation",
draft-metz-aii-aggregate-01 (work in progress),
October 2005.
[RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-
Edge (PWE3) Architecture", RFC 3985, March 2005.
[RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual
Private Network (VPN) Terminology", RFC 4026, March 2005.
Authors' Addresses Authors' Addresses
Eric Rosen Eric Rosen
Cisco Systems, Inc. Cisco Systems, Inc.
1414 Mass. Ave. 1414 Mass. Ave.
Boxborough, MA 01719 Boxborough, MA 01719
USA USA
Email: erosen@cisco.com Email: erosen@cisco.com
skipping to change at page 35, line 41 skipping to change at page 37, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 107 change blocks. 
331 lines changed or deleted 404 lines changed or added

This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/