draft-ietf-l2vpn-signaling-04.txt   draft-ietf-l2vpn-signaling-05.txt 
Network Working Group E. Rosen Network Working Group E. Rosen
Internet-Draft W. Luo Internet-Draft W. Luo
Expires: January 19, 2006 B. Davie Expires: February 19, 2006 B. Davie
Cisco Systems, Inc. Cisco Systems, Inc.
V. Radoaca V. Radoaca
Nortel Networks August 18, 2005
July 18, 2005
Provisioning Models and Endpoint Identifiers in L2VPN Signaling Provisioning, Autodiscovery, and Signaling in L2VPNs
draft-ietf-l2vpn-signaling-04.txt draft-ietf-l2vpn-signaling-05.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 37 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 January 19, 2006. This Internet-Draft will expire on February 19, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
Abstract Abstract
There are a number of different kinds of "Provider Provisioned Layer There are a number of different kinds of "Provider Provisioned Layer
2 VPNs" (L2VPNs). The different kinds of L2VPN may have different 2 VPNs" (L2VPNs). The different kinds of L2VPN may have different
"provisioning models", i.e., different models for what information "provisioning models", i.e., different models for what information
skipping to change at page 3, line 10 skipping to change at page 3, line 10
Gateway Protocol (BGP). It then specifies how the endpoint Gateway Protocol (BGP). It then specifies how the endpoint
identifiers are carried in the two signaling protocols that are used identifiers are carried in the two signaling protocols that are used
to set up PWs, the Label Distribution Protocol (LDP) and the Layer 2 to set up PWs, the Label Distribution Protocol (LDP) 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 VCs . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . 13 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 . . . . . . . . . . . . . . . . . . . . . . 15
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 VCs . . . . . . 16 3.3. Colored Pools: Full Mesh of Point-to-Point Pseudowires . . 16
3.3.1 Provisioning . . . . . . . . . . . . . . . . . . . . . 16 3.3.1. Provisioning . . . . . . . . . . . . . . . . . . . . . 16
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 . . . . . . . . . . . . . . . . . . . . . . 18
3.4 Colored Pools: Partial Mesh . . . . . . . . . . . . . . . 19 3.4. Colored Pools: Partial Mesh . . . . . . . . . . . . . . . 19
3.5 Distributed VPLS . . . . . . . . . . . . . . . . . . . . . 19 3.5. Distributed VPLS . . . . . . . . . . . . . . . . . . . . . 20
3.5.1 Signaling . . . . . . . . . . . . . . . . . . . . . . 21 3.5.1. Signaling . . . . . . . . . . . . . . . . . . . . . . 22
3.5.2 Provisioning and Discovery . . . . . . . . . . . . . . 23 3.5.2. Provisioning and Discovery . . . . . . . . . . . . . . 23
3.5.3 Non-distributed VPLS as a sub-case . . . . . . . . . . 23 3.5.3. Non-distributed VPLS as a sub-case . . . . . . . . . . 24
3.5.4 Splicing and the Data Plane . . . . . . . . . . . . . 23 3.5.4. Splicing and the Data Plane . . . . . . . . . . . . . 24
4. Inter-AS Operation . . . . . . . . . . . . . . . . . . . . . . 25 4. Inter-AS Operation . . . . . . . . . . . . . . . . . . . . . . 25
4.1 Multihop EBGP redistribution of L2VPN NLRIs . . . . . . . 25 4.1. Multihop EBGP redistribution of L2VPN NLRIs . . . . . . . 25
4.2 EBGP redistribution of L2VPN NLRIs with Pseudowire 4.2. EBGP redistribution of L2VPN NLRIs with Pseudowire
Switching . . . . . . . . . . . . . . . . . . . . . . . . 25 Switching . . . . . . . . . . . . . . . . . . . . . . . . 26
4.3 Inter-Provider Application of Dist. VPLS Signaling . . . . 27 4.3. Inter-Provider Application of Dist. VPLS Signaling . . . . 27
4.4. RT and RD Assignment Considerations . . . . . . . . . . . 28
5. Security Considerations . . . . . . . . . . . . . . . . . . . 29 5. Security Considerations . . . . . . . . . . . . . . . . . . . 29
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31
8. Normative References . . . . . . . . . . . . . . . . . . . . . 32 8. Normative References . . . . . . . . . . . . . . . . . . . . . 32
9. Informative References . . . . . . . . . . . . . . . . . . . . 33 9. Informative References . . . . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 33
Intellectual Property and Copyright Statements . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34
Intellectual Property and Copyright Statements . . . . . . . . . . 35
1. Introduction 1. Introduction
[L2VPN-FW] describes a number of different ways in which sets of [L2VPN-FW] describes a number of different ways in which sets of
pseudowires may be combined together into "Provider Provisioned Layer pseudowires may be combined together into "Provider Provisioned Layer
2 VPNs" (L2 PPVPNs, or L2VPNs), resulting in a number of different 2 VPNs" (L2 PPVPNs, or L2VPNs), resulting in a number of different
kinds of L2VPN. Different kinds of L2VPN may have different kinds of L2VPN. Different kinds of L2VPN may have different
"provisioning models", i.e., different models for what information "provisioning models", i.e., different models for what information
needs to be configured in what entities. Once configured, the needs to be configured in what entities. Once configured, the
provisioning information is distributed by a "discovery process", and provisioning information is distributed by a "discovery process", and
skipping to change at page 5, line 47 skipping to change at page 5, line 47
into the LDP and L2TPv3 signaling protocols. 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 [L2VPN-FW], [L2VPN-TERM], and
[PWE3-ARCH], in particular the terms "Attachment Circuit", [PWE3-ARCH], in particular the terms "Attachment Circuit",
"pseudowire", "PE", "CE". "pseudowire", "PE", "CE".
Section 2 provides an overview of the relevant aspects of [PWE3- Section 2 provides an overview of the relevant aspects of [PWE3-
CONTROL] and [L2TP-L2VPN]. CONTROL] and [L2TP-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. signaling process and to the discovery process. The way in which the
signaling mechanisms can be integrated with BGP-based auto-discovery
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.
We do not specify an auto-discovery procedure in this draft, but we
do specify the information which needs to be obtained via auto-
discovery in order for the signaling procedures to begin. The way in
which the signaling mechanisms can be integrated with BGP-based auto-
discovery is covered in some detail.
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 RFC 2119
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 [L2VPN-FW], a pseudowire can be thought of as a relationship
between a pair of "Forwarders". In simple instances of VPWS, a between a pair of "Forwarders". In simple instances of VPWS, a
Forwarder binds a pseudowire to a single Attachment Circuit, such Forwarder binds a pseudowire to a single Attachment Circuit, such
that frames received on the one are sent on the other, and vice that frames received on the one are sent on the other, and vice
versa. In VPLS, a Forwarder binds a set of pseudowires to a set of versa. In VPLS, a Forwarder binds a set of pseudowires to a set of
Attachment Circuits; when a frame is received from any member of that Attachment Circuits; when a frame is received from any member of that
set, a MAC address table is consulted (and various 802.1d procedures set, a MAC address table is consulted (and various 802.1d procedures
executed) to determine the member or members of that set on which the executed) to determine the member or members of that set on which the
frame is to be transmitted. In more complex scenarios, Forwarders frame is to be transmitted. In more complex scenarios, Forwarders
skipping to change at page 8, line 38 skipping to change at page 8, line 38
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 an operator proposed for certain L2VPN applications. We note that [PWE3-CONTROL]
who chooses to use the AII structure defined here would not be at defines a TLV structure for AGI and AII fields. Thus, an operator
liberty to use a completely different structure for these identifiers who chooses to use the AII structure defined here could also make use
for some other application. For example, it would be unwise to use of different AGI or AII types if he also wanted to use a different
ASCII strings for AII values when setting up individual pseudowires structure for these identifiers for some other application. For
and at the same time to use the <RT:PE_address> structure for AII example, the long prefix type of [AII-TYPES] could be used to enable
values in VPLS signaling. the communication of 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 PPVPN 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
skipping to change at page 9, line 21 skipping to change at page 9, line 22
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 [L2TP-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.
It is frequently convenient to a set of Forwarders as being members As specified in [PWE3-CONTROL], the Attachment Identifier may consist
of a particular "group", where PWs may only be set up among members of an Attachment Group Identifier (AGI) plus an Attachment Individual
of a group. In such cases, it is convenient to identify the Identifier (AII). In the context of this document, an AGI may be
Forwarders relative to the group, so that an Attachment Identifier thought of as a VPN-id, or a VLAN identifier, some attribute which is
would consist of an Attachment Group Identifier (AGI) plus an shared by all the Attachment Circuits which are allowed to be
Attachment Individual Identifier (AII).
IT MUST BE UNDERSTOOD THAT THIS NOTION OF "GROUP" HAS NOTHING
WHATSOEVER TO DO WITH THE "GROUP ID" THAT IS PART OF THE PWID FEC IN
[PWE3-CONTROL].
An Attachment Group Identifier may be thought of as a VPN-id, or
a VLAN identifier, some attribute which is shared by all the
Attachment Circuits (or pools thereof) which are allowed to be
connected. connected.
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
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
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 paper.
We can now consider an LSP to be identified by: We can now consider an LSP for one direction of a pseudowire to be
identified by:
o <PE1, <AGI, AII1>, PE2, <AGI, AII2>> o <PE1, <AGI, AII1>, PE2, <AGI, AII2>>
and the LSP in the opposite direction will be identified by: and the LSP in the opposite direction of the pseudowire will be
identified by:
o <PE2, <AGI, AII2>, PE1, <AGI, AII1>> o <PE2, <AGI, AII2>, PE1, <AGI, AII1>>
A pseudowire is a pair of such LSPs. In the case of using L2TP A pseudowire is a pair of such LSPs. In the case of using L2TP
signaling, these refer to the two directions of an L2TP session. signaling, these refer to the two directions of an L2TP session.
When a signaling message is sent from PE1 to PE2, and PE1 needs to When a signaling message is sent from PE1 to PE2, and PE1 needs to
refer to an Attachment Identifier which has been configured on refer to an Attachment Identifier which has been configured on one of
one of its own Attachment Circuits (or pools), the Attachment its own Attachment Circuits (or pools), the Attachment Identifier is
Identifier is called a "Source Attachment Identifier". If PE1 called a "Source Attachment Identifier". If PE1 needs to refer to an
needs to refer to an Attachment Identifier which has been Attachment Identifier which has been configured on one of PE2's
configured on one of PE2's Attachment Circuits (or pools), the Attachment Circuits (or pools), the Attachment Identifier is called a
Attachment Identifier is called a "Target Attachment Identifier". "Target Attachment Identifier". (So an SAI at one endpoint is a TAI
(So an SAI at one endpoint is a TAI at the remote endpoint, and vice at the remote endpoint, and vice versa.)
versa.)
In the signaling protocol, we define encodings for the following In the signaling protocol, we define encodings for the following
three fields: three fields:
o Attachment Group Identifier (AGI) o Attachment Group Identifier (AGI)
o Source Attachment Individual Identifier (SAII) o Source Attachment Individual Identifier (SAII)
o Target Attachment Individual Identifier (TAII) o Target Attachment Individual Identifier (TAII)
If the AGI is non-null, then the SAI consists of the AGI together If the AGI is non-null, then the SAI consists of the AGI together
with the SAII, and the TAI consists of the TAII together with the with the SAII, and the TAI consists of the TAII together with the
AGI. If the AGI is null, then the SAII and TAII are the SAI and TAI AGI. If the AGI is null, then the SAII and TAII are the SAI and TAI
respectively. respectively.
The intention is that the PE which receives an LDP Label Mapping The intention is that the PE which receives an LDP Label Mapping
message or an L2TP Incoming Call Request (ICRQ) message containing a message or an L2TP Incoming Call Request (ICRQ) message containing a
TAI will be able to map that TAI uniquely to one of its Attachment TAI will be able to map that TAI uniquely to one of its Attachment
Circuits (or pools). The way in which a PE maps a TAI to an Circuits (or pools). The way in which a PE maps a TAI to an
Attachment Circuit (or pool) should be a local matter. So as far as Attachment Circuit (or pool) should be a local matter (including the
the signaling procedures are concerned, the TAI is really just an choice of whether to use some or all of the bytes in the TAI for the
arbitrary string of bytes, a "cookie". mapping). So as far as the signaling procedures are concerned, the
TAI is really just an arbitrary string of bytes, a "cookie".
3. Applications 3. Applications
In this section, we specify the way in which the pseudowire signaling In this section, we specify the way in which the pseudowire signaling
using the notion of source and target Forwarder is applied for a using the notion of source and target Forwarder is applied for a
number of different applications. For some of the applications, we number of different applications. For some of the applications, we
specify the way in which different provisioning models can be used. specify the way in which different provisioning models can be used.
However, this is not meant to be an exhaustive list of the However, this is not meant to be an exhaustive list of the
applications, or an exhaustive list of the provisioning models that applications, or an exhaustive list of the provisioning models that
can be applied to each application. can be applied to each application.
3.1 Individual Point-to-Point VCs 3.1. Individual Point-to-Point Pseudowires
The signaling specified in this document can be used to set up The signaling specified in this document can be used to set up
individually provisioned point-to-point pseudowires. In this individually provisioned point-to-point pseudowires. In this
application, each Forwarder binds a single PW to a single Attachment application, each Forwarder binds a single PW to a single Attachment
Circuit. Each PE must be provisioned with the necessary set of Circuit. Each PE must be provisioned with the necessary set of
Attachment Circuits, and then certain parameters must be provisioned Attachment Circuits, and then certain parameters must be provisioned
for each Attachment Circuit. for each Attachment Circuit.
3.1.1 Provisioning Models 3.1.1. Provisioning Models
3.1.1.1 Double Sided Provisioning 3.1.1.1. Double Sided Provisioning
In this model, the Attachment Circuit must be provisioned with a In this model, the Attachment Circuit must be provisioned with a
local name, a remote PE address, and a remote name. During local name, a remote PE address, and a remote name. During
signaling, the local name is sent as the SAII, the remote name as the signaling, the local name is sent as the SAII, the remote name as the
TAII, and the AGI is null. If two Attachment Circuits are to be TAII, and the AGI is null. If two Attachment Circuits are to be
connected by a PW, the local name of each must be the remote name of connected by a PW, the local name of each must be the remote name of
the other. the other.
Note that if the local name and the remote name are the same, the Note that if the local name and the remote name are the same, the
PWid FEC element can be used instead of the Generalized ID FEC PWid FEC element can be used instead of the Generalized ID FEC
element in the LDP based signaling. element in the LDP based signaling.
With L2TP signaling, the local name is sent in Local End ID AVP, the With L2TP signaling, the local name is sent in Local End ID AVP, the
remote name in Remote End ID AVP. The AGI AVP is optional. If remote name in Remote End ID AVP. The AGI AVP is optional. If
present, it contains a zero-length AGI value. If the local name and present, it contains a zero-length AGI value. If the local name and
the remote name are the same, Local End ID AVP can be omitted from the remote name are the same, Local End ID AVP can be omitted from
L2TP signaling messages. L2TP signaling messages.
3.1.1.2 Single Sided Provisioning with Discovery 3.1.1.2. Single Sided Provisioning with Discovery
In this model, each Attachment Circuit must be provisioned with a In this model, each Attachment Circuit must be provisioned with a
local name. The local name consists of a VPN-id (signaled as the local name. The local name consists of a VPN-id (signaled as the
AGI) and an Attachment Individual Identifier which is unique relative AGI) and an Attachment Individual Identifier which is unique relative
to the AGI. If two Attachment circuits are to be connected by a PW, to the AGI. If two Attachment circuits are to be connected by a PW,
only one of them needs to be provisioned with a remote name (which of only one of them needs to be provisioned with a remote name (which of
course is the local name of the other Attachment Circuit). Neither course is the local name of the other Attachment Circuit). Neither
needs to be provisioned with the address of the remote PE, but both needs to be provisioned with the address of the remote PE, but both
must have the same VPN-id. must have the same VPN-id.
As part of an auto-discovery procedure, each PE advertises its As part of an auto-discovery procedure, each PE advertises its
<VPN-id, local AII> pairs. Each PE compares its local <VPN-id, <VPN-id, local AII> pairs. Each PE compares its local <VPN-id,
remote AII> pairs with the <VPN-id, local AII> pairs advertised by remote AII> pairs with the <VPN-id, local AII> pairs advertised by
the other PEs. If PE1 has a local <VPN-id, remote AII> pair with the other PEs. If PE1 has a local <VPN-id, remote AII> pair with
value <V, fred>, and PE2 has a local <VPN-id, local AII> pair with value <V, fred>, and PE2 has a local <VPN-id, local AII> pair with
value <V, fred>, PE1 will thus be able to discover that it needs to value <V, fred>, PE1 will thus be able to discover that it needs to
connect to PE2. When signaling, it will use "fred" as the TAII, and connect to PE2. When signaling, it will use "fred" as the TAII, and
will use V as he AGI. PE1's local name for the Attachment Circuit is will use V as the AGI. PE1's local name for the Attachment Circuit
sent as the SAII. is sent as the SAII.
The primary benefit of this provisioning model when compared to The primary benefit of this provisioning model when compared to
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 [PWE3-
CONTROL]. That is, one PE (PE1) sends a Label Mapping Message to CONTROL]. That is, one PE (PE1) sends a Label Mapping Message to
another PE (PE2) to establish a pseudowire in one direction. If that another PE (PE2) to establish an LSP in one direction. If that
message is processed successfully, and there is not yet a pseudowire message is processed successfully, and there is not yet an LSP for
in the opposite (PE1->PE2) direction, then PE2 sends a Label Mapping the pseudowire in the opposite (PE1->PE2) direction, then PE2 sends a
Message to PE1. Label Mapping Message to PE1.
In addition to the procedures of [PWE3-CONTROL], when a PE receives a In addition to the procedures of [PWE3-CONTROL], when a PE receives a
Label Mapping Message, and the TAI identifies a particular Attachment Label Mapping Message, and the TAI identifies a particular Attachment
Circuit which is configured to be bound to a point-to-point PW, then Circuit which is configured to be bound to a point-to-point PW, then
the following checks must be made. 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
skipping to change at page 13, line 26 skipping to change at page 13, line 26
If the Attachment Circuit is already bound to a pseudowire, but the If the Attachment Circuit is already bound to a pseudowire, but the
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 [L2VPN-REQ, VPLS], the Attachment Circuits
can be though of as LAN interfaces which attach to "virtual LAN can be though of as LAN interfaces which attach to "virtual LAN
switches", or, in the terminology of [L2VPN-FW], "Virtual Switching switches", or, in the terminology of [L2VPN-FW], "Virtual Switching
Instances" (VSIs). Each Forwarder is a VSI that attaches to a number Instances" (VSIs). Each Forwarder is a VSI that attaches to a number
of PWs and a number of Attachment Circuits. The VPLS service [L2VPN- of PWs and a number of Attachment Circuits. The VPLS service [L2VPN-
REQ, VPLS] requires that a single pseudowire be created between each REQ, VPLS] requires that a single pseudowire be created between each
pair of VSIs that are in the same VPLS. Each PE device may have a pair of VSIs that are in the same VPLS. Each PE device may have a
multiple VSIs, where each VSI belongs to a different VPLS. 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, but this can be formed Each VSI must also have a unique identifier, which we call a VSI-ID.
automatically by concatenating its VPN-id with the IP address of its This can be formed automatically by concatenating its VPN-id with an
PE router. (Note that the PE address here is used only as a form of IP address of its PE router. (Note that the PE address here is used
unique identifier; a service provider could choose to use some other only as a form of unique identifier; a service provider could choose
numbering scheme if that was desired.) to use some other numbering scheme if that was desired. See
Section 4 for a discussion of VSI-ID assignment in the 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 VPLS service is as The framework for BGP-based auto-discovery for a generic L2VPN
specified in [BGP-AUTO], section 3.2. service is as described in [BGP-AUTO], section 3.2.
The AFI/SAFI used would be: The AFI/SAFI used would 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 An SAFI specified by IANA specifically for an L2VPN (VPLS or VPWS) o A SAFI specified by IANA specifically for an L2VPN service whose
service whose pseudowires are set up using the procedures pseudowires are set up using the procedures described in the
described in the current document. current document.
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 as specified in [BGP-AUTO],
the globally unique identifier associated with a VPLS must be the globally unique identifier associated with a VPLS must be
encodable as an 8-byte Route Distinguisher (RD). If the globally encodable as an 8-byte Route Distinguisher (RD). If the globally
unique identifier for a VPLS is an RFC2685 VPN-id, it can be encoded unique identifier for a VPLS is an RFC2685 VPN-id, it can be encoded
as an RD as specified in [BGP-AUTO]. However, any other method of as an RD as specified in [BGP-AUTO]. However, any other method of
assigning a unique identifier to a VPLS and encoding it as an RD assigning a unique identifier to a VPLS and encoding it as an RD
(using the encoding techniques of [RFC2547bis]) will do. (using the encoding techniques of [RFC2547bis]) will do.
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 virtual LAN paragraph) to an IP address of the PE containing the VSI. Note that
switch. Note that the role of this address is simply as a readily the role of this address is simply as a readily available unique
available unique identifier for the VSIs within a VPN; it does not identifier for the VSIs within a VPN; it does not need to be globally
need to be globally routable. An alternate numbering scheme (e.g. routable. An alternate numbering scheme (e.g. numbering the VSIs of
numbering the VSIs of a single VPN from 1 to n) could be used if a single VPN from 1 to n) could be used if desired.
desired.
(Note also that it is not strictly necessary for all the VSIs in the (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 same VPLS to have the same RD, all that is really necessary is that
the NLRI uniquely identify a virtual LAN switch.) 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, as discussed in [BGP-AUTO]. These control the
distribution of the NLRI, and hence will control the formation of the distribution of the NLRI, and hence will control the formation of the
overlay topology of pseudowires that constitutes a particular VPLS. overlay topology of 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 receive 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 will learn the IP addresses of the other PE routers which these NLRI it will learn the IP addresses of the other PE routers
have VSIs with the same RT. The considerations of [RFC2547bis] which have VSIs with the same RT. The considerations of [RFC2547bis]
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. If a particular VPLS
consists of multiple VLANs, each VLAN must have its own unique RT. A consists of multiple VLANs, each VLAN must have its own unique RT. A
VSI can be placed in multiple VLANS (or even in multiple VPLSes) by VSI can be placed in multiple VLANS (or even in multiple VPLSes) by
assigning it multiple RTs. 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 virtual LAN switches; the RT mechanism allows one to to some of the VSIs; the RT mechanism allows one to have complete
have complete control over the pseudowire overlay which constitutes control over the pseudowire overlay which constitutes the VPLS
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 = TBD, 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.
3.2.3 Signaling Note that this advertisement is quite similar to the NLRI format
defined in [BGP-VPLS], the main difference being that [BGP-VPLS] also
includes a label block in the NLRI. Interoperability between the
VPLS scheme defined here and that defined in [BGP-VPLS] is beyond the
scope of this document.
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. Noting information is carried but is encoded slightly differently. Noting
that the RD is effectively a VPN identifier, we therefore encode the that the RD is effectively a VPN identifier, we therefore encode the
RD in the AGI field, and place the PE_addr in the TAII field. The RD in the AGI field, and place the PE_addr (or, more generally, the
SAII can be null. VSI-ID that was advertised in BGP, 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 connected, in both single AS
and inter-AS environments. The SAII SHOULD be null.
The AGI field therefore consists of a length field of value 8, The structure of the AGI and AII fields for the Generalized ID FEC in
followed by the 8 bytes of the RD. The TAII consists of a length LDP is defined in [PWE3-CONTROL]. The AGI field in this case
field of value 4 followed by the 4-byte PE address. consists of a Type of 1, a length field of value 8, and the 8 bytes
of the RD. The TAII consists of a Type of 1, a length field of value
4, followed by the 4-byte PE address (or other 4-byte 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].
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. However, in this case there may be more than
one PW between a pair of PEs, so that AIIs cannot be null. Rather, one PW terminating on a given VSI, which must somehow be
each such PW must have AII which is unique relative to the VPN-id. distinguished, so that the SAIIs cannot be null in this case.
This value would be carried in both the SAII and the TAII field of Rather, each such PW must have an SAII which is unique relative to
the signaling messages. the VSI-ID.
3.3 Colored Pools: Full Mesh of Point-to-Point VCs 3.3. Colored Pools: Full Mesh of Point-to-Point Pseudowires
In the "Colored Pools" model of operation, each PE may contain The "Colored Pools" model of operation provides an automated way to
several pools of Attachment Circuits, each pool associated with a deliver Virtual Private Wire Service (VPWS). In this model, each PE
particular VPN. A PE may contain multiple pools per VPN, as each may contain several pools of Attachment Circuits, each pool
pool may correspond to a particular CE device. It may be desired to associated with a particular VPN. A PE may contain multiple pools
create one pseudowire between each pair of pools that are in the same per VPN, as each pool may correspond to a particular CE device. It
VPN; the result would be to create a full mesh of CE-CE VCs for each may be desired to create one pseudowire between each pair of pools
VPN. that are in the same VPN; the result would be to create a full mesh
of CE-CE VCs for each VPN.
3.3.1 Provisioning 3.3.1. Provisioning
Each pool is configured, and associated with: Each pool is configured, and associated with:
o a set of Attachment Circuits; o a set of Attachment Circuits;
o a "color", which can be thought of as a VPN-id of some sort; o a "color", which can be thought of as a VPN-id of some sort;
o a relative pool identifier, which is unique relative to the color. o a relative pool identifier, which is unique relative to the color.
[Note: depending on the technology used for Attachment Circuits, it [Note: depending on the technology used for Attachment Circuits, it
may or may not be necessary to provision these circuits as well. For may or may not be necessary to provision these circuits as well. For
example, if the ACs are frame relay circuits, there may be some example, if the ACs are frame relay circuits, there may be some
separate provisioning system to set up such circuits. Alternatively, separate provisioning system to set up such circuits. Alternatively,
"provisioning" an AC may be as simple as allocating an unused VLAN ID "provisioning" an AC may be as simple as allocating an unused VLAN ID
on an interface. This issue is independent of the procedures on an interface, and communicating the choice to the customer. These
described in this document.] issues are independent of the procedures described in this document.]
The pool identifier, and color, taken together, constitute a globally The pool identifier, and color, taken together, constitute a globally
unique identifier for the pool. Thus if there are n pools of a given unique identifier for the pool. Thus if there are n pools of a given
color, their pool identifiers can be (though they do not need to be) color, their pool identifiers can be (though they do not need to be)
the numbers 1-n. the numbers 1-n.
The semantics are that a pseudowire will be created between every The semantics are that a pseudowire will be created between every
pair of pools that have the same color, where each such pseudowire pair of pools that have the same color, where each such pseudowire
will be bound to one Attachment Circuit from each of the two pools. will be bound to one Attachment Circuit from each of the two pools.
skipping to change at page 17, line 17 skipping to change at page 17, line 34
the way the colors are assigned to the pools. To create a full mesh, the way the colors are assigned to the pools. To create a full mesh,
the "color" would just be a VPN-id. the "color" would just be a VPN-id.
Optionally, a particular Attachment Circuit may be configured with Optionally, a particular Attachment Circuit may be configured with
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 colored pool service The framework for BGP-based auto-discovery for a generic L2VPN
is as specified in [BGP-AUTO], section 3.2. service is described in [BGP-AUTO], section 3.2.
The AFI/SAFI used would be: The AFI/SAFI used would 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 An SAFI specified by IANA specifically for an L2VPN (VPLS or VPWS) o A SAFI specified by IANA specifically for an L2VPN service whose
service whose pseudowires are set up using the procedures pseudowires are set up using the procedures described in the
described in the current document. current document.
See Section 6 for further discussion of AFI/SAFI assignment.
In order to use BGP-based auto-discovery, the color associated with a In order to use BGP-based auto-discovery, the color associated with a
colored pool must be encodable as both an RT (Route Target) and an RD colored pool must be encodable as both an RT (Route Target) and an RD
(Route Distinguisher). The globally unique identifier of a pool must (Route Distinguisher). The globally unique identifier of a pool must
be encodable as NLRI; the color would be encoded as the RD and the be 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 pool identifier as a four-byte quantity which is appended to the RD
to create the NLRI. to create the NLRI.
Auto-discovery procedures by having each PE distribute, via BGP, the Auto-discovery procedures 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
skipping to change at page 18, line 17 skipping to change at page 18, line 36
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 = TBD, 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.
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 [PWE3-
CONTROL]. That is, one PE (PE1) sends a Label Mapping Message to CONTROL]. That is, one PE (PE1) sends a Label Mapping Message to
another PE (PE2) to establish a pseudowire in one direction. If that another PE (PE2) to establish an LSP in one direction. The address
message is processed successfully, and there is not yet a pseudowire of PE2 is the next-hop address learned via BGP as described above.
in the opposite (PE1->PE2) direction, then PE2 sends a Label Mapping If the message is processed successfully, and there is not yet an LSP
Message to PE1. Similarly, the L2TPv3-based signaling follows the for the pseudowire in the opposite (PE1->PE2) direction, then PE2
procedures of [L2TP-BASE]. Additional details on the use of these sends a Label Mapping Message to PE1. Similarly, the L2TPv3-based
signaling protocols follow. signaling follows the procedures of [L2TP-BASE]. 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
LDP is defined in [PWE3-CONTROL]. The AGI field in this case
consists of a Type of 1, a length field of value 8, and the 8 bytes
of the RD. The TAII consists of a Type of 1, a length field of value
4, followed by the 4-byte remote pool number. The SAII consists of a
Type of 1, a length field of value 4, followed by the 4-byte local
pool number. See Section 6 for discussion of the AGI and AII Type
assignment. Note that the VPLS and VPWS procedures defined in this
document can make use of the same AGI Type (1) and the same AII Type
(1).
The encoding of the AGI and AII in L2TP is specified in [L2TP-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.
Note that the signaling itself only identifies the remote pool to Note that the signaling itself only identifies the remote pool to
which the pseudowire is to lead, not the remote Attachment Circuit which the pseudowire is to lead, not the remote Attachment Circuit
which is to be bound to the the pseudowire. However, the remote PE which is to be bound to the the pseudowire. However, the remote PE
may examine the SAII field to determine which Attachment Circuit may examine the SAII field to determine which Attachment Circuit
should be bound to the pseudowire. should be bound to the pseudowire.
3.4 Colored Pools: Partial Mesh 3.4. Colored Pools: Partial Mesh
The procedures for creating a partial mesh of pseudowires among a set The procedures for creating a partial mesh of pseudowires among a set
of colored pools are substantially the same as those for creating a of colored pools are substantially the same as those for creating a
full mesh, with the following exceptions: full mesh, with the following exceptions:
o Each pool is optionally configured with a set of "import RTs" and o Each pool is optionally configured with a set of "import RTs" and
"export RTs"; "export RTs";
o During BGP-based auto-discovery, the pool color is still encoded o During BGP-based auto-discovery, the pool color is still encoded
in the RD, but if the pool is configured with a set of "export in the RD, but if the pool is configured with a set of "export
RTs", these are are encoded in the RTs of the BGP Update messages, RTs", these are are encoded in the RTs of the BGP Update messages,
INSTEAD of the color; INSTEAD of the color;
o If a pool has a particular "import RT" value X, it will create a o If a pool has a particular "import RT" value X, it will create a
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. One pool, the "hub" pool, is configured with an export RT topology with a single hub. One pool, the "hub" pool, is configured
of RT_hub and an import RT of RT_spoke. All other pools (the spokes) with an export RT of RT_hub and an import RT of RT_spoke. All other
are configured with an export RT of RT_spoke and an import RT of pools (the spokes) are configured with an export RT of RT_spoke and
RT_hub. Thus the Hub pool will connect to the spokes, and vice- an import RT of RT_hub. Thus the Hub pool will connect to the
versa, but the spoke pools will not connect to each other. 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-
AUTO].
3.5 Distributed VPLS 3.5. Distributed VPLS
In Distributed VPLS ([L2VPN-FW], [DTLS], [LPE]), the VPLS In Distributed VPLS ([L2VPN-FW], [DTLS], [LPE]), 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-
skipping to change at page 21, line 28 skipping to change at page 22, line 5
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 paper. However, the procedures for VPLS
(section 3.2.3) need some additional machinery to ensure that the (section 3.2.3) need some additional machinery to ensure that the
appropriate number of PWs are established between the various N-PEs appropriate number of PWs are established between the various N-PEs
and U-PEs, and among the 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
skipping to change at page 23, line 16 skipping to change at page 23, line 38
setting of the SAII, which will be a number from 1 to n inclusive. A setting of the SAII, which will be a number from 1 to n inclusive. A
PW between two N-PEs is known as an "N-PW". 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 also ensure that a U-PW from each such U-PE is spliced to a U-PW from
from each of the other U-PEs. each of the other U-PEs.
3.5.2 Provisioning and Discovery 3.5.2. Provisioning and Discovery
Every N-PE must be provisioned with the set of VPLS instances it Every N-PE must be provisioned with the set of VPLS instances it
supports, a VPN-id for each one, and a list of local U-PEs for each supports, a VPN-id for each one, and a list of local U-PEs for each
such VPLS. As part of the discovery procedure, the N-PE advertises such VPLS. As part of the discovery procedure, the N-PE advertises
the number of U-PEs for each VPLS. See Section 3.2.2 for details. the number of U-PEs for each VPLS. See Section 3.2.2 for details.
Auto-discovery (e.g., BGP-based) can be used to discover all the Auto-discovery (e.g., BGP-based) can be used to discover all the
other N-PEs in the VPLS, and for each, the number of U-PEs local to other N-PEs in the VPLS, and for each, the number of U-PEs local to
that N-PE. From this, one can compute the total number of U-PEs in that N-PE. From this, one can compute the total number of U-PEs in
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 splicing.
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 section resultant signaling is exactly the same as that specified in
3.2.3 above, except that an SAII value of 1 is used instead of null. Section 3.2.3 above, except that an SAII value of 1 is used instead
(A PE providing non-distributed VPLS should therefore treat SAII of null. (A PE providing non-distributed VPLS should therefore treat
values of 1 the same as it treats SAII values of null.) 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 [PW-SWITCH].
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 [2547bis]
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 [2547bis]. 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 routes
from AS to neighboring AS. from AS to neighboring AS.
An ASBR must maintain labeled IPv4 /32 routes to the PE routers An ASBR must maintain labeled IPv4 /32 routes to the PE routers
within its AS. It uses EBGP to distribute these routes to other within its AS. It uses EBGP to distribute these routes to other
ASes. ASBRs in any transit ASes will also have to use EBGP to pass ASes, and sets itself as the BGP next hop for these routes. ASBRs in
along the labeled /32 routes. This results in the creation of a any transit ASes will also have to use EBGP to pass along the labeled
label switched path from the ingress PE router to the egress PE /32 routes. This results in the creation of a set of label switched
router. Now PE routers in different ASes can establish multi-hop paths from all ingress PE routers to all egress PE routers. Now PE
EBGP connections to each other, and can exchange L2VPN NLRIs over routers in different ASes can establish multi-hop EBGP connections to
those connections. Following such exchanges a pair of PEs in each other, and can exchange L2VPN NLRIs over those connections.
different ASes could establish an LDP session to signal PWs between Following such exchanges a pair of PEs in different ASes could
each other. 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.
For VPWS, the BGP advertisement and PW signaling are exactly as For VPWS, the BGP advertisement and PW signaling are exactly as
described in Section 3.3. As a result of the multihop EBGP session described in Section 3.3. 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 pools of a certain color (VPN) will discover PEs in another AS have pools of a certain color (VPN) will discover PEs in another AS
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.
4.2 EBGP redistribution of L2VPN NLRIs with Pseudowire Switching 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
RDs. This subject is discussed in more detail in Section 4.4.
4.2. EBGP redistribution of L2VPN NLRIs with Pseudowire Switching
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. These concerns motivate the approach a smaller set of devices. Furthermore, by forcing the LDP or L2TPv3
described here. signaling sessions to terminate on a small set of ASBRs, a provider
could use standard authentication procedures on a small set of inter-
provider sessions. These concerns motivate the approach described
here.
[PW-SWITCH] describes an approach to "switching" packets from one [PW-SWITCH] describes an approach to "switching" packets from one
pseudowire to another at a particular node. This approach allows an pseudowire to another at a particular node. This approach allows an
end-to-end pseudowire to be constructed out of several pseudowire end-to-end pseudowire to be constructed out of several pseudowire
segments, without maintaining an end-to-end control connection. We segments, without maintaining an end-to-end control connection. We
can use this approach to produce an inter-AS solution that more can use this approach to produce an inter-AS solution that more
closely resembles option (b) in [2547bis]. closely resembles option (b) in [2547bis].
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
skipping to change at page 26, line 36 skipping to change at page 26, line 45
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 use "PW switching" to splice that PW to the PW from the PE. AS, and splice that PW to the PW from the PE as described in
Repeating the process at each ASBR leads to a sequence of PW segments Section 3.5.4 and [PW-SWITCH]. Repeating the process at each ASBR
that, when spliced together, connect the two PEs. leads to a sequence of PW segments that, when spliced together,
connect the two PEs.
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
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
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 produce 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 being co-located with the ASBRs. It is of course possible to
have multiple ASBR-ASBR connections between a given pair of ASes. In have multiple ASBR-ASBR connections between a given pair of ASes. In
this case a given PE could choose among the available ASBRs based on this case a given PE could choose among the available ASBRs based on
a range of criteria, such as IGP metric, local configuration, etc., a range of criteria, such as IGP metric, local configuration, etc.,
analogous to choosing an exit point in normal IP routing. The use of analogous to choosing an exit point in normal IP routing. The use of
multiple ASBRs would lead to greater resiliency (at the timescale of multiple ASBRs would lead to greater resiliency (at the timescale of
BGP routing convergence) since a PE could select a new ASBR in the BGP routing convergence) since a PE could select a new ASBR in the
event of the failure of the one currently in use. event of the failure of the one currently in use.
We note that, in order for this approach to work correctly, the two As in layer 3 VPNs, building an L2VPN that spans the networks of more
ASes must use RTs and RDs consistently, just as in layer 3 VPNs than one provider requires some co-ordination in the use of RTs and
[RFC2547bis]. The structure of RTs and RDs is such that there is not RDs. This subject is discussed in more detail in Section 4.4.
a great risk of accidental 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 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-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 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 RT, RT_B, tag all NLRI for this VPN with that RT, and
then provider A can import NLRI with that RT at the appropriate PEs.
However this does require both providers to communicate their choice
of RTs for each VPN. Alternatively both providers could agree to use
a common RT for a given VPN. In any case communication of RTs
between the providers is essential.
4.3 Inter-Provider Application of Dist. VPLS Signaling 4.3. Inter-Provider Application of Dist. 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
where A, B, and C are PEs in a common VPLS, but Networks 1 and 2 are where A, B, and C are PEs in a common VPLS, but Networks 1 and 2 are
networks of different Service Providers. Border Router 12 is networks of different Service Providers. Border Router 12 is Network
Network 1's border router to network 2, and Border Router 21 is 1's border router to network 2, and Border Router 21 is Network 2's
Network 2's border router to Network 1. We suppose further that the border router to Network 1. We suppose further that the PEs are not
PEs are not "distributed", i.e, that each provides both the U-PE and "distributed", i.e, that each provides both the U-PE and N-PE
N-PE functions. functions.
In this topology, one needs two inter-provider pseudowires: A-B and In this topology, one needs two inter-provider pseudowires: A-B and
A-C. A-C.
Suppose a Service Provider decides, for whatever reason, that it does Suppose a Service Provider decides, for whatever reason, that it does
not want each of its PEs to have a control connection to any PEs in not want each of its PEs to have a control connection to any PEs in
the other network. Rather, it wants the inter-provider control the other network. Rather, it wants the inter-provider control
connections to run only between the two border routers. connections to run only between the two border routers.
This can be achieved using the techniques of section 3.5, where the This can be achieved using the techniques of section 3.5, where the
skipping to change at page 29, line 5 skipping to change at page 28, line 23
BR12; PEs B and C would be have like U-PEs which are locally attached BR12; PEs B and C would be have like U-PEs which are locally attached
to BR21; and the two BRs would behave like N-PEs. to BR21; and the two BRs would behave like N-PEs.
As a result, the PW from A to B would consist of three segments: As a result, the PW from A to B would consist of three segments:
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
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
consistently, just as in layer 3 VPNs [RFC2547bis]. The structure of
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
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,
there are many ways to make this work, but all require some co-
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
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
RT, RT_B, tag all NLRI for this VPN with that RT, and then provider A
can import NLRI with that RT at the appropriate PEs. However this
does require both providers to communicate their choice of RTs for
each VPN. Alternatively both providers could agree to use a common
RT for a given VPN. In any case communication of RTs between the
providers is essential. As in layer 3 VPNs, providers may configure
RT filtering to ensure that only coordinated RT values are allowed
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 and auto-
discovery protocols are discussed in the relevant protocol discovery protocols are discussed in the relevant protocol
skipping to change at page 30, line 7 skipping to change at page 30, line 7
and [VPLS]. and [VPLS].
The security consideration of inter-AS operation are similar to those The security consideration of inter-AS operation are similar to those
for inter-AS L3VPNs [2547bis]. for inter-AS L3VPNs [2547bis].
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 requires IANA to assign an AFI and a SAFI. The AFI This document requires the assignment of an AFI and a SAFI for L2VPN
could be the same as that assigned for [BGP-VPLS]. The SAFI should NLRI. Both AFI and SAFI may be the same as the values assigned for
be assigned specifically for this draft. [BGP-VPLS].
[PWE3-IANA] defines registries for AGI types and AII types. This
document defines a specific format for the AGI and the AII, and
proposes the assignment of one value in each registry. The value 1
is assigned in each case, representing the first available value in
the IETF Consensus Range.
7. Acknowledgments 7. Acknowledgments
Thanks to Dan Tappan, Ted Qian, Ali Sajassi, Skip Booth, Luca Martini Thanks to Dan Tappan, Ted Qian, Ali Sajassi, Skip Booth, Luca
and Francois LeFaucheur for their comments, criticisms, and helpful Martini, Dave McDysan and Francois LeFaucheur for their comments,
suggestions. 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. Normative References
[BRADNER] Bradner, S., "Key words for use in RFCs to Indicate [BRADNER] Bradner, S., "Key words for use in RFCs to Indicate
skipping to change at page 33, line 30 skipping to change at page 33, line 30
[L2VPN-TERM] Andersson, Madsen, "PPVPN Terminology", RFC 4026, March [L2VPN-TERM] Andersson, Madsen, "PPVPN Terminology", RFC 4026, March
2005. 2005.
[PWE3-ARCH] Bryant, Pate, et. al., "PWE3 Architecture", RFC 3985, [PWE3-ARCH] Bryant, Pate, et. al., "PWE3 Architecture", RFC 3985,
March 2005. March 2005.
[PW-SWITCH] "Pseudo Wire Switching", Martini, et. al., [PW-SWITCH] "Pseudo Wire Switching", Martini, et. al.,
draft-martini-pwe3-pw-switching-03.txt, April 2005 draft-martini-pwe3-pw-switching-03.txt, April 2005
[PWE3-IANA] "IANA Allocations for pseudo Wire Edge to Edge Emulation
(PWE3)", Martini, draft-ietf-pwe3-iana-allocation-11.txt, June 2005
[RFC2547bis], "BGP/MPLS IP VPNs", Rosen, Rekhter, et. al., [RFC2547bis], "BGP/MPLS IP VPNs", Rosen, Rekhter, et. al.,
draft-ietf-l3vpn-rfc2547bis-03.txt, October 2004 draft-ietf-l3vpn-rfc2547bis-03.txt, October 2004
[RFC2685] "Virtual Private Networks Identifier", Fox, Gleeson, [RFC2685] "Virtual Private Networks Identifier", Fox, Gleeson,
September 1999 September 1999
[VPLS] "Virtual Private LAN Services over MPLS", Laserre, et. al., [VPLS] "Virtual Private LAN Services over MPLS", Laserre, et. al.,
draft-ietf-l2vpn-vpls-ldp-06.txt, February 2005 draft-ietf-l2vpn-vpls-ldp-06.txt, February 2005
[BGP-VPLS] "Virtual Private LAN Service", Kompella et al.,
draft-ietf-l2vpn-vpls-bgp-05.txt, April 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
Wei Luo Wei Luo
Cisco Systems, Inc. Cisco Systems, Inc.
170 W Tasman Dr. 170 W Tasman Dr.
San Jose, CA 95134 San Jose, CA 95134
USA USA
Email: luo@cisco.com Email: luo@cisco.com
Bruce Davie Bruce Davie
Cisco Systems, Inc. Cisco Systems, Inc.
skipping to change at page 34, line 21 skipping to change at page 34, line 32
Bruce Davie Bruce Davie
Cisco Systems, Inc. Cisco Systems, Inc.
1414 Mass. Ave. 1414 Mass. Ave.
Boxborough, MA 01719 Boxborough, MA 01719
USA USA
Email: bsd@cisco.com Email: bsd@cisco.com
Vasile Radoaca Vasile Radoaca
Nortel Networks
600 Technology Park
Billerica, MA 01821
USA
Phone: +1 978 288 6097 Email: radoaca@hotmail.com
Email: vasile@nortelnetworks.com
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
 End of changes. 

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