draft-ietf-l2vpn-signaling-07.txt   draft-ietf-l2vpn-signaling-08.txt 
Network Working Group E. Rosen Network Working Group E. Rosen
Internet-Draft W. Luo Internet-Draft W. Luo
Expires: September 4, 2006 B. Davie Expires: November 4, 2006 B. Davie
Cisco Systems, Inc. Cisco Systems, Inc.
V. Radoaca V. Radoaca
March 3, 2006 May 3, 2006
Provisioning, Autodiscovery, and Signaling in L2VPNs Provisioning, Autodiscovery, and Signaling in L2VPNs
draft-ietf-l2vpn-signaling-07.txt draft-ietf-l2vpn-signaling-08.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 September 4, 2006. This Internet-Draft will expire on November 4, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
Provider Provisioned Layer 2 Virtual Private Networks (L2VPNs) may Provider Provisioned Layer 2 Virtual Private Networks (L2VPNs) may
have different "provisioning models", i.e., models for what have different "provisioning models", i.e., models for what
information needs to be configured in what entities. Once information needs to be configured in what entities. Once
skipping to change at page 3, line 27 skipping to change at page 3, line 27
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 . . . . . . . . . . . . . . . . . . . . . . 16 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 3.3. Colored Pools: Full Mesh of Point-to-Point
Pseudowires . . . . . . . . . . . . . . . . . . . . . . . 16 Pseudowires . . . . . . . . . . . . . . . . . . . . . . . 17
3.3.1. Provisioning . . . . . . . . . . . . . . . . . . . . . 17 3.3.1. Provisioning . . . . . . . . . . . . . . . . . . . . . 17
3.3.2. Auto-Discovery . . . . . . . . . . . . . . . . . . . . 17 3.3.2. Auto-Discovery . . . . . . . . . . . . . . . . . . . . 18
3.3.2.1. BGP-based auto-discovery . . . . . . . . . . . . . 17 3.3.2.1. BGP-based auto-discovery . . . . . . . . . . . . . 18
3.3.3. Signaling . . . . . . . . . . . . . . . . . . . . . . 19 3.3.3. Signaling . . . . . . . . . . . . . . . . . . . . . . 19
3.4. Colored Pools: Partial Mesh . . . . . . . . . . . . . . . 20 3.4. Colored Pools: Partial Mesh . . . . . . . . . . . . . . . 20
3.5. Distributed VPLS . . . . . . . . . . . . . . . . . . . . . 20 3.5. Distributed VPLS . . . . . . . . . . . . . . . . . . . . . 21
3.5.1. Signaling . . . . . . . . . . . . . . . . . . . . . . 22 3.5.1. Signaling . . . . . . . . . . . . . . . . . . . . . . 23
3.5.2. Provisioning and Discovery . . . . . . . . . . . . . . 24 3.5.2. Provisioning and Discovery . . . . . . . . . . . . . . 25
3.5.3. Non-distributed VPLS as a sub-case . . . . . . . . . . 24 3.5.3. Non-distributed VPLS as a sub-case . . . . . . . . . . 25
3.5.4. Splicing and the Data Plane . . . . . . . . . . . . . 24 3.5.4. Splicing and the Data Plane . . . . . . . . . . . . . 25
4. Inter-AS Operation . . . . . . . . . . . . . . . . . . . . . . 26 4. Inter-AS Operation . . . . . . . . . . . . . . . . . . . . . . 27
4.1. Multihop EBGP redistribution of L2VPN NLRIs . . . . . . . 26 4.1. Multihop EBGP redistribution of L2VPN NLRIs . . . . . . . 27
4.2. EBGP redistribution of L2VPN NLRIs with Multi-Segment 4.2. EBGP redistribution of L2VPN NLRIs with Multi-Segment
Pseudowires . . . . . . . . . . . . . . . . . . . . . . . 27 Pseudowires . . . . . . . . . . . . . . . . . . . . . . . 28
4.3. Inter-Provider Application of Distributed VPLS 4.3. Inter-Provider Application of Distributed VPLS
Signaling . . . . . . . . . . . . . . . . . . . . . . . . 28 Signaling . . . . . . . . . . . . . . . . . . . . . . . . 29
4.4. RT and RD Assignment Considerations . . . . . . . . . . . 29 4.4. RT and RD Assignment Considerations . . . . . . . . . . . 30
5. Security Considerations . . . . . . . . . . . . . . . . . . . 30 5. Security Considerations . . . . . . . . . . . . . . . . . . . 32
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35
8.1. Normative References . . . . . . . . . . . . . . . . . . . 33 8.1. Normative References . . . . . . . . . . . . . . . . . . . 35
8.2. Informative References . . . . . . . . . . . . . . . . . . 34 8.2. Informative References . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38
Intellectual Property and Copyright Statements . . . . . . . . . . 37 Intellectual Property and Copyright Statements . . . . . . . . . . 39
1. Introduction 1. Introduction
[I-D.ietf-l2vpn-l2-framework] describes a number of different ways in [I-D.ietf-l2vpn-l2-framework] describes a number of different ways in
which sets of pseudowires may be combined together into "Provider which sets of pseudowires may be combined together into "Provider
Provisioned Layer 2 VPNs" (L2 PPVPNs, or L2VPNs), resulting in a Provisioned Layer 2 VPNs" (L2 PPVPNs, or L2VPNs), resulting in a
number of different kinds of L2VPN. Different kinds of L2VPN may number of different kinds of L2VPN. Different kinds of L2VPN may
have different "provisioning models", i.e., different models for what have different "provisioning models", i.e., different models for what
information needs to be configured in what entities. Once information needs to be configured in what entities. Once
configured, the provisioning information is distributed by a configured, the provisioning information is distributed by a
skipping to change at page 13, line 40 skipping to change at page 13, line 40
LAN switches", or, in the terminology of [I-D.ietf-l2vpn-l2- LAN switches", or, in the terminology of [I-D.ietf-l2vpn-l2-
framework], "Virtual Switching Instances" (VSIs). Each Forwarder is framework], "Virtual Switching Instances" (VSIs). Each Forwarder is
a VSI that attaches to a number of PWs and a number of Attachment a VSI that attaches to a number of PWs and a number of Attachment
Circuits. The VPLS service requires that a single pseudowire be Circuits. The VPLS service requires that a single pseudowire be
created between each pair of VSIs that are in the same VPLS. Each PE created between each pair of VSIs that are in the same VPLS. Each PE
device may have multiple VSIs, where each VSI belongs to a different device may have multiple VSIs, where each VSI belongs to a different
VPLS. 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 in [I-D.ietf-
VPN-id. Every VSI must be configured with the VPN-id of the VPLS to l2vpn-vpls-ldp] is referred to as the VPLS identifier (or VPLS-id).
which it belongs. Every VSI must be configured with the VPLS-id of the VPLS to 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 VPLS-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, as long as
Section 4.4 for a discussion of the assignment of identifiers in the each VSI is assigned an identifier that is unique within the VPLS
case of multiple providers.) instance. See Section 4.4 for a discussion of the assignment of
identifiers 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
A framework for BGP-based auto-discovery for a generic L2VPN service In this section we specify how BGP can be used to discover the
is described in [I-D.ietf-l3vpn-bgpvpn-auto], section 3.2. In this information necessary to build VPLS instances.
section we specify how BGP-based auto-discovery can be used to build
VPLS instances.
When BGP-based autodiscovery is used for VPLS, the AFI/SAFI will 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, there must be at least one In order to use BGP-based auto-discovery, there must be at least one
globally unique identifier associated with a VPLS, and each such globally unique identifier associated with a VPLS, and each such
identifier must be encodable as an 8-byte Route Distinguisher (RD). identifier must be encodable as an 8-byte Route Distinguisher (RD).
Any method of assigning one or more unique identifiers to a VPLS and Any method of assigning one or more unique identifiers to a VPLS and
encoding each of them as an RD (using the encoding techniques of encoding each of them as an RD (using the encoding techniques of
[RFC4364]) will do. [RFC4364]) will do.
It is RECOMMENDED that a single VPN-ID be assigned to a VPLS Each VSI needs to have a unique identifier that is encodable as a BGP
instance. That VPN-ID MAY be a VPN-ID as defined in [RFC2685], in NLRI. This is formed by prepending the RD (from the previous
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
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, but it must be unique within the VPLS instance. An
a single VPN from 1 to n) could be used if desired. alternate scheme to assign unique identifiers to each VSI within a
VPLS instance (e.g. numbering the VSIs of a single VPN from 1 to n)
could be used if desired.
Each VSI needs to be associated with one or more Route Target (RT) When using the procedures described in this document, it is necessary
Extended Communities. These control the distribution of the NLRI, to assign a single, globally unique VPLS-id to each VPLS instance[I-
and hence will control the formation of the overlay topology of D.ietf-l2vpn-vpls-ldp]. This VPLS-id must be encodable as a BGP
Extended Community[RFC4360]. As described in Section 6, two Extended
Community subtypes are defined by this draft for this purpose. The
Extended Community MUST be transitive.
The first Extended Community subtype is a two-octet AS specific
Extended Community. The second Extended Community subtype is an IPv4
address specific Extended Community. The encoding of such
Communities is defined in [RFC4360]. These encodings ensure that a
service provider can allocate a VPLS-id without risk of collision
with another provider. However, note that co-ordination of VPLS-ids
among providers is necessary for inter-provider L2VPNs, as described
in Section 4.4.
Each VSI also needs to be associated with one or more Route Target
(RT) Extended Communities. These control the distribution of the
NLRI, and hence will control the formation of the 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 receives a BGP update from which any of the elements
specified above is absent, the update should be ignored.
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 [RFC4364] 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. A VSI can be placed in it need not be) an encoding of the VPN-id. A VSI can be placed in
multiple VPLSes by assigning it multiple RTs. multiple VPLSes by assigning it multiple RTs.
skipping to change at page 15, line 38 skipping to change at page 16, line 4
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 = TBA, 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 the VPLS-id
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. 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 [I-D.ietf-l2vpn-vpls-bgp], the main difference being that defined in [I-D.ietf-l2vpn-vpls-bgp], the main difference being that
[I-D.ietf-l2vpn-vpls-bgp] also includes a label block in the NLRI. [I-D.ietf-l2vpn-vpls-bgp] also includes a label block in the NLRI.
Interoperability between the VPLS scheme defined here and that Interoperability between the VPLS scheme defined here and that
defined in [I-D.ietf-l2vpn-vpls-bgp] is beyond the scope of this defined in [I-D.ietf-l2vpn-vpls-bgp] is beyond the scope of this
document. 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 and the VPLS-id was carried in a BGP Extended Community. For
information is carried but is encoded slightly differently. signaling purposes, this information is encoded as follows. We
Specifically, we encode the RD in the AGI field, and place the encode the VPLS-id in the AGI field, and place the PE_addr (or, more
PE_addr (or, more generally, the VSI-ID that was advertised in BGP, precisely, the VSI-ID that was contained in the NLRI in BGP, minus
minus the RD) in the TAII field. The combination of AGI and TAII is 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
MUST be set to the PE_addr of the sending PE (or, more generally, the MUST be set to the PE_addr of the sending PE (or, more precisely, the
VSI-ID, without the RD, of the VSI associated with this VPLS in 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 sending PE), to enable signaling of the reverse half of the PW if
needed. 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 [I-D.ietf-pwe3-control-protocol]. The AGI field in LDP is defined in [I-D.ietf-pwe3-control-protocol]. The AGI field in
this case consists of a Type of 1, a length field of value 8, and the 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 8 bytes of the VPLS-id. The AIIs consist of a Type of 1, a length
of value 4, followed by the 4-byte PE address (or other 4-byte 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 identifier). See Section 6 for discussion of the AGI and AII Type
assignment. assignment.
The encoding of the AGI and AII in L2TP is specified in [I-D.ietf- The encoding of the AGI and AII in L2TP is specified in [I-D.ietf-
l2tpext-l2vpn]. 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
skipping to change at page 17, line 48 skipping to change at page 18, line 16
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
A framework for BGP-based auto-discovery for a generic L2VPN service In this section we specify how BGP can be used to discover the
is described in [I-D.ietf-l3vpn-bgpvpn-auto], section 3.2. In this information necessary to build VPWS instances.
section we specify how BGP-based auto-discovery can be used to build
VPWS instances.
When BGP-based autodiscovery is used for VPWS, the AFI/SAFI will 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.
In order to use BGP-based auto-discovery, there must be one or more In order to use BGP-based auto-discovery, there must be one or more
unique identifiers (the "color") associated with a particular VPWS unique identifiers associated with a particular VPWS instance. Each
instance. Each identifier must be encodable as an RD (Route identifier must be encodable as an RD (Route Distinguisher). The
Distinguisher). The globally unique identifier of a pool must be globally unique identifier of a pool must be encodable as NLRI; the
encodable as NLRI; the color would be encoded as the RD and the pool pool identifier, which we define to be a four-byte quantity, is
identifier as a four-byte quantity which is appended to the RD to appended to the RD to create the NLRI.
create the NLRI.
When using the procedures described in this document, it is necessary
to assign a single, globally unique identifier to each VPWS instance.
This identifier must be encodable as a BGP Extended
Community[RFC4360]. As described in Section 6, two Extended
Community subtypes are defined by this draft for this purpose. The
Extended Community MUST be transitive.
The first Extended Community subtype is a Two-octet AS specific
Extended Community. The second Extended Community subtype is an IPv4
address specific Extended Community. The encoding of such
Communities is defined in [RFC4360]. These encodings ensure that a
service provider can allocate a VPWS identifier without risk of
collision with another provider. However, note that co-ordination of
VPWS identifiers among providers is necessary for inter-provider
L2VPNs, as described in Section 4.4.
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 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 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 receives a BGP update from which any of the elements
specified above is absent, the update should be ignored.
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 = TBA, 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 the VPWS identifier;
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. 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 The LDP-based signaling follows the procedures specified in
[I-D.ietf-pwe3-control-protocol]. That is, one PE (PE1) sends a [I-D.ietf-pwe3-control-protocol]. That is, one PE (PE1) sends a
Label Mapping Message to another PE (PE2) to establish an LSP in one Label Mapping Message to another PE (PE2) to establish an LSP in one
direction. The address of PE2 is the next-hop address learned via direction. The address of PE2 is the next-hop address learned via
BGP as described above. If the message is processed successfully, BGP as described above. If the message is processed successfully,
and there is not yet an LSP for the pseudowire in the opposite and there is not yet an LSP for the pseudowire in the opposite
(PE1->PE2) direction, then PE2 sends a Label Mapping Message to PE1. (PE1->PE2) direction, then PE2 sends a Label Mapping Message to PE1.
Similarly, the L2TPv3-based signaling follows the procedures of Similarly, the L2TPv3-based signaling follows the procedures of
[I-D.ietf-l2tpext-l2vpn]. Additional details on the use of these [I-D.ietf-l2tpext-l2vpn]. Additional details on the use of these
signaling protocols follow. 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 VPWS identifier (as
pool's relative identifier as the SAII, and the remote pool's distributed in the Extended Community Attribute by BGP) as the AGI,
relative identifier as the TAII. the local pool's relative identifier as the SAII, and the remote
pool's 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 [I-D.ietf-pwe3-control-protocol]. The AGI field in LDP is defined in [I-D.ietf-pwe3-control-protocol]. The AGI field in
this case consists of a Type of 1, a length field of value 8, and the 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 8 bytes of the VPWS identifier. The TAII consists of a Type of 1, a
of value 4, followed by the 4-byte remote pool number. The SAII length field of value 4, followed by the 4-byte remote pool number.
consists of a Type of 1, a length field of value 4, followed by the The SAII consists of a Type of 1, a length field of value 4, followed
4-byte local pool number. See Section 6 for discussion of the AGI by the 4-byte local pool number. See Section 6 for discussion of the
and AII Type assignment. Note that the VPLS and VPWS procedures 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 defined in this document can make use of the same AGI Type (1) and
the same AII Type (1). the same AII Type (1).
The encoding of the AGI and AII in L2TP is specified in [I-D.ietf- The encoding of the AGI and AII in L2TP is specified in [I-D.ietf-
l2tpext-l2vpn]. 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 a pool, and there is already a
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
skipping to change at page 30, line 5 skipping to change at page 30, line 47
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
can import NLRI with that RT at the appropriate PEs. However this can import NLRI with that RT at the appropriate PEs. However this
does require both providers to communicate their choice of RTs for does require both providers to communicate their choice of RTs for
each VPN. Alternatively both providers could agree to use a common each VPN. Alternatively both providers could agree to use a common
RT for a given VPN. In any case communication of RTs between the RT for a given VPN. In any case communication of RTs between the
providers is essential. As in layer 3 VPNs, providers may configure providers is essential. As in layer 3 VPNs, providers may configure
RT filtering to ensure that only coordinated RT values are allowed RT filtering to ensure that only coordinated RT values are allowed
across the AS boundary. across the AS boundary.
Note that a single VPN identifier (carried in a BGP Extended
Community) is required for each VPLS or VPWS instance. The encoding
rules for these identifiers [RFC4360] ensure that collisions do not
occur with other providers. However, for a single VPLS or VPWS
instance that spans the networks of two or more providers, one
provider will need to allocate the identifier and communicate this
choice to the other provider(s), who must use the same value for
sites in the same VPLS or VPWS instance.
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 protocols are The security considerations related to the signaling protocols are
discussed in the relevant protocol specifications ([RFC3036] discussed in the relevant protocol specifications ([RFC3036]
[I-D.ietf-pwe3-control-protocol] [RFC3931] [I-D.ietf-l2tpext-l2vpn]). [I-D.ietf-pwe3-control-protocol] [RFC3931] [I-D.ietf-l2tpext-l2vpn]).
The security considerations related to BGP-based autodiscovery, The security considerations related to BGP-based autodiscovery,
including inter-AS issues, are discussed in [RFC4364]. including inter-AS issues, are discussed in [RFC4364]. L2VPNs that
use BGP-based autodiscovery may automate setup of security mechanisms
as well. Specification of automated security mechansims are outside
the scope of this document, but are recommended as a future work
item.
The security considerations related to the particular kind of L2VPN The security considerations related to the particular kind of L2VPN
service being supported are discussed in [I-D.ietf-l2vpn-l2- service being supported are discussed in [I-D.ietf-l2vpn-l2-
framework], [I-D.ietf-l2vpn-requirements], and [I-D.ietf-l2vpn-vpls- framework], [I-D.ietf-l2vpn-requirements], and [I-D.ietf-l2vpn-vpls-
ldp]. 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 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 should be the same as the values assigned NLRI. Both AFI and SAFI should be the same as the values assigned
for [I-D.ietf-l2vpn-vpls-bgp]. for [I-D.ietf-l2vpn-vpls-bgp]. That is, the AFI should be 25 (L2VPN)
and the SAFI should be 65 (already allocated for VPLS). The same AFI
and SAFI are used for both VPLS and VPWS autodiscovery as described
in this document.
[I-D.ietf-pwe3-iana-allocation] defines registries for "Attachment [I-D.ietf-pwe3-iana-allocation] defines registries for "Attachment
Group Identifier (AGI) Type" and "Attachment Individual Identifier Group Identifier (AGI) Type" and "Attachment Individual Identifier
(AII) Type". Type 1 in each registry has been assigned to the AGI (AII) Type". Type 1 in each registry has been assigned to the AGI
and AII formats defined in this document. and AII formats defined in this document.
This document requires two new LDP status codes. IANA already This document requires two new LDP status codes. IANA already
maintains a registry of name "STATUS CODE NAME SPACE" defined by maintains a registry of name "STATUS CODE NAME SPACE" defined by
[RFC3036]. The following values are suggested for assignment: [RFC3036]. The following values are suggested for assignment:
skipping to change at page 32, line 5 skipping to change at page 33, line 38
The document requires two new L2TP Result Codes for the CDN message. The document requires two new L2TP Result Codes for the CDN message.
IANA already maintains a registry of L2TP Result Code Values for the IANA already maintains a registry of L2TP Result Code Values for the
CDN message, defined by [RFC3438]. The following values are CDN message, defined by [RFC3438]. The following values are
requested for assignment: requested for assignment:
RC-TBD1: Attachment Circuit bound to different PE RC-TBD1: Attachment Circuit bound to different PE
RC-TBD2: Attachment Circuit bound to different remote Attachment RC-TBD2: Attachment Circuit bound to different remote Attachment
Circuit Circuit
[RFC4360] defines a registry entitled "Two-octet AS Specific Extended
Community". This document requests the assigment of a value in this
registry from the "transitive" range (0x0000-0x00FF). The proposed
value is as follows:
o 0x000A Two-octet AS specific Layer 2 VPN Identifier
[RFC4360] defines a registry entitled "IPv4 Address Specific Extended
Community". This document requests the assigment of a value in this
registry from the "transitive" range (0x0100-0x01FF). The proposed
value is as follows:
o 0x010A IPv4 address specific Layer 2 VPN Identifier
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, Francois LeFaucheur, and Matthew Bocci for Martini, Dave McDysan, Francois LeFaucheur, Russ Gardo, Keyur Patel,
their comments, criticisms, and helpful suggestions. Sam Henderson, and Matthew Bocci for 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. References 8. References
8.1. Normative References 8.1. Normative References
[I-D.ietf-idr-bgp-ext-communities]
Rekhter, Y., "BGP Extended Communities Attribute",
draft-ietf-idr-bgp-ext-communities-09 (work in progress),
July 2005.
[I-D.ietf-l2tpext-l2vpn] [I-D.ietf-l2tpext-l2vpn]
Luo, W., "L2VPN Extensions for L2TP", Luo, W., "L2VPN Extensions for L2TP",
draft-ietf-l2tpext-l2vpn-07 (work in progress), draft-ietf-l2tpext-l2vpn-07 (work in progress),
March 2006. March 2006.
[I-D.ietf-pwe3-control-protocol] [I-D.ietf-pwe3-control-protocol]
Martini, L., "Pseudowire Setup and Maintenance using the Martini, L., "Pseudowire Setup and Maintenance using the
Label Distribution Protocol", Label Distribution Protocol",
draft-ietf-pwe3-control-protocol-17 (work in progress), draft-ietf-pwe3-control-protocol-17 (work in progress),
June 2005. June 2005.
[I-D.ietf-pwe3-segmented-pw] [I-D.ietf-pwe3-segmented-pw]
Martini, L., "Segmented Pseudo Wire", Martini, L., "Segmented Pseudo Wire",
draft-ietf-pwe3-segmented-pw-01 (work in progress), draft-ietf-pwe3-segmented-pw-02 (work in progress),
October 2005. March 2006.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2685] Fox, B. and B. Gleeson, "Virtual Private Networks [RFC2685] Fox, B. and B. Gleeson, "Virtual Private Networks
Identifier", RFC 2685, September 1999. Identifier", RFC 2685, September 1999.
[RFC2858] Bates, T., Rekhter, Y., Chandra, R., and D. Katz, [RFC2858] Bates, T., Rekhter, Y., Chandra, R., and D. Katz,
"Multiprotocol Extensions for BGP-4", RFC 2858, June 2000. "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000.
[RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and [RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and
B. Thomas, "LDP Specification", RFC 3036, January 2001. B. Thomas, "LDP Specification", RFC 3036, January 2001.
[RFC3438] Townsley, W., "Layer Two Tunneling Protocol (L2TP) [RFC3438] Townsley, W., "Layer Two Tunneling Protocol (L2TP)
Internet Assigned Numbers Authority (IANA) Considerations Internet Assigned Numbers Authority (IANA) Considerations
Update", BCP 68, RFC 3438, December 2002. Update", BCP 68, RFC 3438, December 2002.
[RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling [RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling
Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005. Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.
[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
Communities Attribute", RFC 4360, February 2006.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006. Networks (VPNs)", RFC 4364, February 2006.
8.2. Informative References 8.2. Informative References
[I-D.ietf-l2vpn-l2-framework] [I-D.ietf-l2vpn-l2-framework]
Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual
Private Networks (L2VPNs)", Private Networks (L2VPNs)",
draft-ietf-l2vpn-l2-framework-05 (work in progress), draft-ietf-l2vpn-l2-framework-05 (work in progress),
June 2004. June 2004.
skipping to change at page 34, line 31 skipping to change at page 36, line 31
Service", draft-ietf-l2vpn-vpls-bgp-06 (work in progress), Service", draft-ietf-l2vpn-vpls-bgp-06 (work in progress),
December 2005. December 2005.
[I-D.ietf-l2vpn-vpls-ldp] [I-D.ietf-l2vpn-vpls-ldp]
Lasserre, M. and V. Kompella, "Virtual Private LAN Lasserre, M. and V. Kompella, "Virtual Private LAN
Services over MPLS", draft-ietf-l2vpn-vpls-ldp-08 (work in Services over MPLS", draft-ietf-l2vpn-vpls-ldp-08 (work in
progress), November 2005. progress), November 2005.
[I-D.ietf-l3vpn-bgpvpn-auto] [I-D.ietf-l3vpn-bgpvpn-auto]
Ould-Brahim, H., "Using BGP as an Auto-Discovery Mechanism Ould-Brahim, H., "Using BGP as an Auto-Discovery Mechanism
for Layer-3 and Layer-2 VPNs", for VR-based Layer-3 VPNs",
draft-ietf-l3vpn-bgpvpn-auto-06 (work in progress), draft-ietf-l3vpn-bgpvpn-auto-07 (work in progress),
June 2005. April 2006.
[I-D.ietf-pwe3-iana-allocation] [I-D.ietf-pwe3-iana-allocation]
Martini, L., "IANA Allocations for pseudo Wire Edge to Martini, L., "IANA Allocations for pseudo Wire Edge to
Edge Emulation (PWE3)", draft-ietf-pwe3-iana-allocation-15 Edge Emulation (PWE3)", draft-ietf-pwe3-iana-allocation-15
(work in progress), November 2005. (work in progress), November 2005.
[I-D.ietf-pwe3-ms-pw-arch] [I-D.ietf-pwe3-ms-pw-arch]
Bocci, M. and S. Bryant, "An Architecture for Multi- Bocci, M. and S. Bryant, "An Architecture for Multi-
Segment Pseudo Wire Emulation Edge-to-Edge", Segment Pseudo Wire Emulation Edge-to-Edge",
draft-ietf-pwe3-ms-pw-arch-00 (work in progress), draft-ietf-pwe3-ms-pw-arch-00 (work in progress),
 End of changes. 43 change blocks. 
94 lines changed or deleted 157 lines changed or added

This html diff was produced by rfcdiff 1.30. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/