One document matched: draft-jounay-delord-l2vpn-ms-pw-provisioning-01.txt
Differences from draft-jounay-delord-l2vpn-ms-pw-provisioning-00.txt
Network Working Group Simon Delord
Internet Draft Mark Latham
Category: Informational Track Telstra
Expires: June 2010
Frederic Jounay
Tom Nadeau Philippe Niger
BT France Telecom
Dave McDysan Yuji Kamite
Verizon NTT Communications
January 08, 2010
MS-PW based L2VPN provisioning, auto-discovery, signaling
draft-jounay-delord-l2vpn-ms-pw-provisioning-01.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May, 2010.
Abstract
Service Providers (SPs) have described the requirements to allow them
to extend the Pseudowires (PWs) across multiple domains via the use
of multi-segment Pseudowires (MS-PWs). Several tools relating to
Jounay et al. Expires June, 2010 [Page 1]
Internet Draft MS-PW based L2VPN provisioning January 2010
provisioning, auto-discovery and signaling have been developed to
allow the dynamic setup of MS-PWs.
However there is no end to end view that describes how these tools
can be used in carrier networks. This document aims at providing this
view by describing the different stages required for an end to end
L2VPN service setup relying on MS-PWs. These stages are VPN
provisioning, auto-discovery (network and service), signaling and
monitoring.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Table of Contents
1. Introduction....................................................3
1.1. High-level L2VPN setup procedure..............................4
1.1.1. L2VPN Provisioning..........................................4
1.1.2. L2VPN Auto-discovery........................................4
1.1.3. L2VPN Signaling.............................................5
1.1.4. L2VPN Monitoring............................................5
1.2. Assumptions...................................................5
2. Terminology.....................................................6
3. Provider-Provisioned L2VPN Reference Model......................7
4. AII Addressing Considerations...................................7
4.1. IP addressing reference model.................................8
4.2. Model1: IP Address derived AII addressing plane...............9
4.2.1. N-AII addressing plane......................................9
4.2.2. C-AII addressing plane......................................9
4.3. Model2: Non IP Address derived AII addressing plane..........10
4.4. N-AII addressing plane.......................................10
4.5. C-AII addressing plane.......................................10
5. L2VPN Provisioning.............................................11
5.1. VPWS.........................................................11
5.2. VPLS.........................................................11
6. Auto-Discovery.................................................12
6.1. Network AII Auto-Discovery...................................12
6.1.1. Scope for AII Auto-Discovery...............................12
6.1.2. N-AII Auto-discovery.......................................13
6.1.2.1. N-AII Auto-discovery in the access network...............13
6.1.2.2. N-AII Auto-discovery in the metro/core network...........13
6.2. Service VPN Auto-Discovery...................................14
6.3. Auto-discovery summary.......................................14
7. L2VPN Signaling................................................15
7.1. P2P MS-PW....................................................15
7.2. P2MP MS-PW...................................................16
8. Monitoring.....................................................16
9. Protection.....................................................16
Jounay et al. Expires June, 2010 [Page 2]
Internet Draft MS-PW based L2VPN provisioning January 2010
10. Manageability considerations..................................16
11. Backward Compatibility........................................16
12. Security Considerations.......................................16
13. IANA Considerations...........................................16
14. Acknowledgments...............................................16
15. References....................................................16
15.1. Normative References........................................17
15.2. Informative References......................................17
16. Author's Addresses............................................18
Copyright Notice..................................................19
1. Introduction
This document provides a framework regarding the different steps
required for a L2VPN setup when the end to end architecture relies
on the MS-PW construct. It describes how some of the tools currently
available can work together to achieve the setup of point to point
(P2P), point to multipoint (P2MP) or multipoint to multipoint (MP2MP)
L2VPNs over MS-PWs.
[RFC4447] defines two different types of Forwarding Equivalent Clas-
ses (FEC) called the PWid FEC (type 128) and the Generalised ID (GID)
FEC (type 129).The PWid FEC element includes a fixed-length 32-bit
value called the PWid that serves as an endpoint identifier. The same
PWid value must be configured on the local and remote PE prior to PW
setup. The GID FEC element includes TLV fields for attachment
individual identifiers (AIIs) that, in conjunction with an attachment
group identifier (AGI), serve as PW endpoint identifiers.
The use of the GID FEC TLV provides the flexibility to structure AII
values to best fit the needs of a particular application or
provisioning model. The use of FEC128 for MS-PWs is therefore not
considered in this version of the document.
[RFC5659] defines two different deployment models, the inter-carrier
model and the intra-carrier model. The different architecture
scenarios described in this version focus on the intra-carrier model.
The structure of this document is therefore described as follows
- section 4: AII addressing considerations
- section 5: VPN provisioning for P2P, P2MP and MP2MP services
- section 6: Auto-discovery
- section 7: VPN Signaling for P2P, P2MP and MP2MP L2VPN services
- section 8: VPN Monitoring for P2P, P2MP and MP2MP L2VPN services
Jounay et al. Expires June, 2010 [Page 3]
Internet Draft MS-PW based L2VPN provisioning January 2010
1.1. High-level L2VPN setup procedure
To setup any L2VPN service relying on MS-PWs, every service provider
will have to go through the four following phases (that usually
happen in the following order):
- L2VPN provisioning
- L2VPN auto-discovery
- L2VPN signaling
- L2VPN monitoring
1.1.1. L2VPN Provisioning
The provisioning phase covers two sub-elements, the provisioning of
the network elements and the provisioning of the individual services.
The Network element provisioning corresponds to the AII configuration
at T-PE(and also S-PE if required). The operator may configure a set
of AIIs per T-PE.
During service provisioning, the operator selects one or more AIIs
from the AII subset and binds it to the VPN to be setup. The service
provisioning also includes the endpoints components configuration
(either by manual intervention or via NMS)of the VPN (for example a
VLAN, a DLCI, a VPI/VCI on a physical interface). The operator then
associates this endpoint to a VPN instance.
When two Attachment Circuits are to be connected by a MS-PW and use
the FEC Type 129, only one of them needs to be provisioned with the
remote endpoint identifier ([L2VPN SIG] section 3.1.1.2).
A service auto-discovery mechanism would let all endpoints of a VPN
advertising in which VPN they participate so the signaling can be
initiated automatically (as per [L2VPN Sig] section 3.5).
1.1.2. L2VPN Auto-discovery
Auto-discovery covers two sub-elements, the auto-discovery of the
network elements and the auto-discovery of the service elements.
Network auto-discovery allows network elements to reach each other.
In the context of MS-PWs, the network discovery part is the
populating by all the network elements (T-PEs and S-PEs) of their own
PW AII routing table to allow them to reach any other part of the
network. There is no notion of VPN id in this phase since the AII is
supposed to be globally unique.
Service Discovery allows endpoints participating in a specific VPN to
discover each other and eventually automate the signaling between
them without manual intervention.
The service discovery part is for the T-PEs to announce their
AII/AGIs to the rest of the network (all the other S-PEs and T-PEs).
Jounay et al. Expires June, 2010 [Page 4]
Internet Draft MS-PW based L2VPN provisioning January 2010
1.1.3. L2VPN Signaling
Signaling is the last operation to happen before the L2VPN service is
up and running. It corresponds to the building of the forwarding
plane in the service provider network.
In the case of MS-PWs, this will correspond to the T-PEs/S-PEs
initiating MS-PWs via an LDP Label Mapping towards the S-PE/T-PEs.
1.1.4. L2VPN Monitoring
The aim of L2VPN monitoring is described in [L2VPN OAM FWK]. The main
focus of this document is on fault detection, notification as well as
L2VPN performance management.
The first function is to check the status of the MS-PW and notify the
service endpoints of the alarm condition, or error so that a specific
action can be taken accordingly to the criticality of the event.
The second function is to check the performance against specific
parameters on the L2VPN.
1.2. Assumptions
This document assumes that the underlying network layer of the
interconnecting domains is MPLS (LDP or RSVP-TE based) only (even
though it is possible to use L2TPv3, but this is not discussed here).
As per [RFC5659] the interconnection of MPLS domains falls into the
cases of intra and inter providers which is an administrative
partition of the domains.
Another type of partition that will be called logical/architectural
partition corresponds to the separation of MPLS domains into
different functional responsibilities. Typically core networks run an
IGP as well as BGP (or even MP-BGP) whereas access networks do not
necessarily run either one or the other. That is, the dynamic routing
domain is located in the metro/core but it is not always fully
transparent across all access networks.
Both these types of partitions are complementary, e.g. it is possible
to have an inter-provider partition between an access and a
metro/core domain (this is the case when a SP uses another SP
infrastructure for last mile access) and have an intra-provider case
between two core/metro networks (one example being when a single SP
decouples the administrative responsibilities per geographical
regions or network technologies).
Jounay et al. Expires June, 2010 [Page 5]
Internet Draft MS-PW based L2VPN provisioning January 2010
Similar tools can therefore be available in different metro/core dom-
ains (typically MP-BGP and high-end MPLS capabilities such as FRR)
even if these domains do not belong to the same SP, however a
restricted set of tools may only be available in access networks.
As a consequence, S-PEs as defined in [RFC5659] will either be
administrative domain separation points (e.g an ASBR) or
architectural domain separation points (e.g the first IP point to run
an IGP or MP-BGP or the first IP point to run MPLS FRR for protection
mechanisms).
There are therefore two sets of challenges for the deployment of
L2VPN services relying on MS-PWs that come from either:
- Different architectural domains that rely on different set of
tools (typically an access to metro interconnection).
- Different administrative domains that may or may not rely on a
similar/different set of tools.
The authors believe that at the moment, the end to end approach that
presents most difficulties is an L2VPN service setup across different
architectural regions (access to metro/core to access). This will
therefore be the focus of this document (as presented in figure 1)
but may evolve in future versions.
2. Terminology
This document uses terminology described in [RFC4447], [L2VPN
SIG],[RFC5659], [SEG PW], [RFC5003].
It also introduces additional terms needed in the context of PW
addressing plane.
The Exterior AII TLV only contains the prefix and global ID of the T-
PE. Such summarization allows the content of the Exterior AII TLV to
remain unchanged when an AC is added or removed, thus removing a need
to re-advertise the Exterior AII TLV. S-PEs use AII summarization
that minimizes the impact on the S-PEs' advertisements into backbone
on changes to Exterior AII received in a non-backbone advertisements.
C-AII ("a" on figures)
C-AII corresponds to the "customer" AII addresses (GID, Prefix, ACID)
configured on the access part, i.e. on T-PE. Therefore C-AII
correspond to the PW endpoints addresses.
N-AII ("A" on figures)
N-AII corresponds to the "network" AII addresses (GID, Prefix)
configured on the access/metro/core part, i.e. the AII loopback
addresses configured on T-PE and S-PE.
Jounay et al. Expires June, 2010 [Page 6]
Internet Draft MS-PW based L2VPN provisioning January 2010
3. Provider-Provisioned L2VPN Reference Model
Figure 1 describes the L2VPN MS-PW Reference Model. The AC are not
shown on the Figure but are attached to T-PEs. The proposed model
assumes the existence of a T-LDP signaling adjacency between T-PE/S-
PE, S-PE/S-PE and/or S-PE/T-PE.
|<---Access--->|<-----Metro/Core network----->|<---Access--->|
| T-LDP | T-LDP | T-LDP |
| | IGP (IS-IS, OSPF) | |
V V BGP V V
+----+ +----+ +-----+ +----+ +----+
|TPE1+---------+ | | | | | |TPE9|
+----+ |S-PE+---------+S-PE | |S-PE+-----------+ |
+----+ | 5 | | 7 | | 8 | | |
|TPE2+---------+ | | | | | | |
| | +----+ | | | | +----+
| | +----+ | | | |
| +---------+ | | +---------+ |
+----+ |S-PE| | | | |
| 6 | | | | |
+----+ | | | | | | +----+
|TPE3+---------+ | | | | | |TPE |
+----+ | +---------+ | | +-----------+ 10 |
+----+ | | | | | | | |
|TPE4+---------+ | | | | | | |
+----+ +----+ +-----+ +----+ +----+
Figure 1 Provider-Provisioned L2VPN Reference Model
In this model, it is assumed that neither MP-BGP nor an IGP are
available on the access part of the network. [OSPF AII REACH] and
[LDP AII REACH] explain why this could be the case.
4. AII Addressing Considerations
[RFC5003] describes the fields that identify PW endpoints called
attachment individual identifiers (AII) and the structures that
support AII aggregation for improved scalability and VPN auto-
discovery. In this document we refer to the PW layer 2 addresses
(type 2) defined in [RFC5003]. The AII may be configured via NMS ou
CLI.
This document considers two types of addressing spaces for MS-PWs the
first one called an N-AII related to network elements and another one
called the C-AII related to the MS-PW endpoints (or the L2VPN service
endpoints).
Jounay et al. Expires June, 2010 [Page 7]
Internet Draft MS-PW based L2VPN provisioning January 2010
The N-AII will typically be a unique identifier within an
administrative domain (or as per RFC5003 recommendation be globally
unique) that will identify a specific network element that can
establish and maintain MS-PWs; this is similar to the use of an IP
loopback address used for management.Note that N-AII may be optional
and is only required for specific SP requirements.
This differentiation is important when it comes to the auto-discovery
phase of the L2VPN setup process. It is possible to automate part or
all of the MS-PW addressing space based on whether the SP wants to
achieve network and or service endpoints discovery.
Another consideration in this section is whether the AII addressing
space (AII Prefix field) should be relying on the IP addressing space
(IP loopback). Typical reasons for separating the AII and IP
addressing schemes are security reasons, inter-domain architecture
and service provider policy ([RFC5254] also references some other
elements).
The main advantage of keeping a PW addressing scheme based on the IP
addressing scheme is to release some of the constraints during the
provisioning as well as the auto-discovery phases.
4.1. IP addressing reference model
+----+ +--------+
| | | |
T-PE1 | ip11/xx--- |
IP1/32 | | | |
+----+ ip10/xx |
+----+ | |
| | | S-PE5 |
T-PE2 | ip12/xx--- | IP5/32|
IP2/32 | | | |
+----+ +--------+
Figure 2 IP addressing reference model
This section is given as an example of a typical IP allocation
scheme for an access network. Ip10, 11, 12 are typically the
interface IP addresses whereas IP1, IP2 and IP3 are the loopback
addresses.
One of the AII addressing scheme can rely on the IP addressing
scheme.
At this step the IP addresses are configured locally on T-PE with
sometimes a summarization scheme being combined to it. In Figure 2,
ip10/xx is used at S-PE1 for summarizing ip11+ip12. IP1, IP2 and IP5
Jounay et al. Expires June, 2010 [Page 8]
Internet Draft MS-PW based L2VPN provisioning January 2010
correspond respectively to the local IP loopback address of T-PE1, T-
PE2 and S-PE5.
4.2. Model1: IP Address derived AII addressing plane
In this first model, the MS-PW addressing scheme relies on the IP
allocation scheme (e.g. IP loopback).
4.2.1. N-AII addressing plane
The N-AII configured on S-PE may be used for the Explicit Routing of
MS-PWs. The loopback addresses are derived from the IP loopback
addresses.
Figure 3 uses A1, A3, A5, A6, A7, A8, A9 as N-AII respectively
associated to T-PE1, T-PE3, S-PE5, S-PE6, S-PE7, S-PE8 and T-PE9.
In this case, An is composed of (ASN, IPn), IPn being the T-PEn IP
loopback address. ASN and IPn are encoded in appropriate fields in
Section 4.2 following [RFC5003] encoding. Note that the AC ID is
equal to 0. The ASN refers to an AS number.
+----+ +----+ +----+ +-----+
|TPE1| |S-PE| | | | |
| A1 +-----| 5 +---------+ | | | +----+
| | | A5 | |S-PE| |S-PE | |TPE9|
+----+ +----+ | 7 +---------+ 8 +-----| A9 |
+----+ +----+ | | | | | |
|TPE3| |T-PE| | | | | +----+
| A3 +-----+ 6 +---------+ A7 | | A8 |
| | | A6 | | | | |
+----+ +----+ +----+ +-----+
Figure 3 N-AII addressing plane
4.2.2. C-AII addressing plane
+----+ +--------+
| | | |
T-PE1 | a1 | | |
A1 | | | |
+----+ | |
+----+ | |
| | | S-PE5 |
T-PE2 | a2 | | A5 |
A2 | a3 | | |
+----+ +--------+
Figure 4 C-AII addressing reference model
Jounay et al. Expires June, 2010 [Page 9]
Internet Draft MS-PW based L2VPN provisioning January 2010
At this step the C-AII addresses are not attached to a physical or
virtual port of the T-PE equipment. This operation is part of VPN
provisioning.
The C-AII scheme corresponds to the AII addresses. These addresses
are derived directly from the IP addresses locally configured on T-PE
(typically the loopback or management address).
Therefore each endpoint to be configured on T-PEs is associated to a
different AC ID as follows:
e.g. AII (GID, Prefix, ACID)
a1: (ASN, IP1, ACID1)
a2: (ASN, IP2, ACID1)
a3: (ASN, IP2, ACID2)
A1: (ASN, IP1)
A2: (ASN, IP2)
A5: (ASN, IP5)
Note that the same ACID can be reused on a different T-PE since it is
appended with a different prefix.
4.3. Model2: Non IP Address derived AII addressing plane
In this second model, the MS-PW addressing scheme does not rely on
the IP allocation scheme.
4.4. N-AII addressing plane
In model 2, it is assumed that N-AII are not derived from the
provider's IP addressing scheme, e.g. A1 is not derived from the IP
loopback address IP1. In this case the provider allocates a unique
prefix per T or S-PE. The prefix MUST be unique per ASN.
4.5. C-AII addressing plane
The AII addressing plane is distinct from the IP addressing plane.
Where prefix1 is the assigned address for N-AII A1, then C-AII
addresses are:
a1: (ASN, Prefix1, ACID1)
a2: (ASN, Prefix2, ACID1)
a3: (ASN, Prefix2, ACID2)
A1: (ASN, Prefix1)
A2: (ASN, Prefix2)
A5: (ASN, Prefix5)
Jounay et al. Expires June, 2010 [Page 10]
Internet Draft MS-PW based L2VPN provisioning January 2010
The fact that C-AIIs configured on T-PE are derived from N-AII is to
derive benefit of the AII address aggregation. Therefore as explained
later for the AII auto-discovery step the C-AII subnet is implicitly
represented by the only N-AII, i.e. the Prefix field.
5. L2VPN Provisioning
5.1. VPWS
As discussed section 1.1, the FEC129 single sided provisioning allows
the SP when two Attachment circuits are to be connected by a PW, to
provision both ends and only one of them with the name of the other
remote end (which of course is the local name of the other Attachment
Circuit) as described in [L2VPN SIG] section 3.1.1.2.
It is recommended to let the SP enter or not an AGI value
corresponding to a VPN-id. This field is not compulsory since the
couple (SAII, TAII) is unique. However for some security purposes the
SP may choose to use the AGI for the VPN-id definition. In that case
the VPN-id must be provisioned on the both endpoints T-PEs. The T-PE
must associate the VPN-id with one of its local C-AII configured. The
couple (VPN-id, AII) corresponds to the MS-PW endpoint and needs to
be attached to a physical or virtual port (VID, etc...).
As described above, if one of the remote ends is provisioned with the
other end of the service, then there is no need for an auto-discovery
mechanism. Otherwise, if none of the endpoints knows the remote end
then service auto-discovery will need to be part of the setup
process.
5.2. VPLS
[L2VPN SIG] describes in section 3.2.1 the VPLS provisioning based on
the VPN-id, a globally unique identifier. The VPN-id must be
provisioned on each T-PE belonging to the VPN. The T-PE must
associate the VPN-id to one of its locally configured C-AII. The
selected C-AII is directly related to a Virtual Switching Instance
dedicated to the VPN.
Note that in VPLS the same C-AII selected at a T-PE may be used to
setup as many PWs as remote T-PEs belonging to the VPN. This case is
not defined in RFC4762 since it tackles flat VPLS. The use of non-
null TAII and SAII is mainly required for D-VPLS (Distributed VPLS -
when a VSI attaches to one or more MS-PWs) when it is desired to
setup MS-PW in an optimized routing way.
Jounay et al. Expires June, 2010 [Page 11]
Internet Draft MS-PW based L2VPN provisioning January 2010
T-PE1
+-----------+
| ... ===== .-----. =======T-PE2
| /VSI\...a1=====/ S-PEs \=======T-PE3
| \.../VPNid=====\ cloud /=======T-PE4
| ===== .-----. =======T-PE4
+-----------+
Figure 5: VSI - C-AII attachment
The same comment as in the previous section applies here. In order to
avoid provisioning at half of the T-PEs the remote endpoints of all
the other T-PEs, a service auto-discovery mechanism is required. Such
a mechanism is described in section 3.5 of [L2VPN SIG], however the
procedure and addressing scheme are conflicting with the procedure
described in [DYN MS-PW] and addressing scheme defined in [RFC5003].
6. Auto-Discovery
Auto-discovery covers two sub-elements, the auto-discovery of the
network elements (the N-AII) and the auto-discovery of the service
elements (the C-AIIs and AGIs). If we apply these 2 notions to the
concept of MS-PWs, the network discovery part will be the populating
by all the network elements (T-PEs and S-PEs) of their own PW AII
routing table to allow them to reach any other part of the network
(there is no notion of VPN id in this phase since the AII is supposed
to be "globally unique"), the service discovery part will be for the
T-PEs to announce their AII/AGIs to the rest of the network (all the
other S-PEs and T-PEs).
6.1. Network AII Auto-Discovery
6.1.1. Scope for AII Auto-Discovery
The AII auto-discovery is only required for model 2 (non IP derived),
since model 1 (IP derived) assumes a direct 1:1 relationship between
local IP address and AII address. In model 1 an IP routing lookup is
sufficient to select the next hop PE (the IP address is retrieved
from the TAII indicated in the FEC129 advertised in the LDP Label
Mapping message).
Since C-AII is assumed to be derived from N-AII, only the N-AII
configured on T-PE must be known in the PW routing table of S-PEs.
This is done using summarized Type 2 AIIs so that a separate
advertisement is not required to every AC. C-AIIs are summarized
using the aggregation rules for AII Type 2 described in [RFC5003].
Therefore only N-AII configured on the T-PEs need to be advertised in
the metro/core network.
Jounay et al. Expires June, 2010 [Page 12]
Internet Draft MS-PW based L2VPN provisioning January 2010
Referring to Figure 4 the set of C-AII (a2, a3) is summarized to A2.
Consequently S-PE5 only advertises A2.
The N-AII auto-discovery is only required for the model 2 since the
AII addressing scheme is assumed to be totally distinct from the IP
layer.
6.1.2. N-AII Auto-discovery
6.1.2.1. N-AII Auto-discovery in the access network
This document is limited to access networks using IP/MPLS as their
access technology and using MS-PW to support L2 services (as per
[RFC5254]).
The aim here is for the T-PE to announce to its directly connected S-
PE(s) the set AII which have been configured via CLI or NMS. As
explained above the set of C-AII is represented by the relevant N-
AII. T-PE may be configured with one or several default gateway in
case of dual-homing scenario.
The attached S-PE needs a mechanism to populate its AII PW routing
table towards the access. Where neither IGP nor BGP are available on
the access part, it is recommended to use [LDP AII REACH] to maintain
dynamically the S-PE PW routing table. Where IGP is extended to the
T-PE either [OSPF AII REACH] or [LDP AII REACH] may be used.
Another alternative would be to configure statically T-PE AII routes
on the S-PE, and inject them as Network AII's via IGP/BGP inside the
metro/core domain. Other alternatives may also be carried out.
6.1.2.2. N-AII Auto-discovery in the metro/core network
N-AII configured on T-PEs
In the MPLS network the S-PE at the edge of both the access and the
metro/core networks must advertise the set of C-AII configured on T-
PEs.
For consistency with the IP routing scheme managed by the SP, the T-
PE N-AII may be relayed in the metro/core network via BGP by using
the specific NLRI. [OSPF AII REACH] may also be used.
N-AII configured on S-PEs
A method is required to advertise the N-AII configured on each S-PE.
For consistency with the IP routing scheme, it is recommended to use
[OSPF AII REACH] (IS-IS ext. not yet defined).
Jounay et al. Expires June, 2010 [Page 13]
Internet Draft MS-PW based L2VPN provisioning January 2010
6.2. Service VPN Auto-Discovery
This step consists in informing each T-PE about the remote T-PEs
belonging to the same VPN. As explained in the section 6.1, the
presence of VPN-id may not be necessary for VPWS. In that case the SP
just has to provision the FEC associated to the VPWS.
Note that the PW endpoints at the both sides must be attached to a
physical or a logical port, so it is still required to provision this
attachment.
The following section describes the commonalities in terms of VPN
auto-discovery for VPWS and VPLS.
It is proposed to advertise the tuple (AGI,AII) identifying the VPN
on a particular T-PE via different auto-discovery protocols. In case
BGP is not available on the access part, it is recommended that the
access T-PE informs its VPN membership via [LDP L2VPN AD]. This would
require an extension to what is currently proposed in the draft as
its scope is limited to N-AII advertisement only.
The S-PE receives the VPN information and is in charge to relay it to
other S-PEs up to the remote T-PE. The S-PEs do not need to retrieve
any VPN information, they only maintain a PW routing information
based on AII addresses which have been previously filled during the
AII auto-discovery step. It is recommended to relay the VPN
information in the metro/core network via BGP as described in section
3.2.2 of [L2VPN SIG].
Note that this auto-discovery step is particularly useful for VPLS
when a new site is added to a VPN as it avoids having to provision on
a specific T-PE all the remote identifiers of all other T-PEs
belonging to the same L2VPN.
6.3. Auto-discovery summary
+----------------------------------------------------------------+
| Addressing | Network Discovery | Service Discovery |
| Scheme | (N-AII) | (C-AII) |
| |-------------------------|---------------- --------|
| | T-PE | S-PE | S-PE | T-PE | S-PE | S-PE |
| | | (no BGP | (BGP & | |(no BGP | (BGP & |
| | | but IGP)|IGP av.)| | but IGP)|IGP av.)|
|------------|-------------------------|------|---------|--------|
| Model1 | | via | via | via |
| IP Based | NOT NEEDED | LDP | IGP | MP-BGP |
| | | | | |
|------------|-------------------------|------|---------|--------|
| Model2 | | | | | | |
| Non IP | via | via | via | via | via | via |
| Based | LDP | IGP | MP-BGP | LDP | IGP | MP-BGP |
Jounay et al. Expires June, 2010 [Page 14]
Internet Draft MS-PW based L2VPN provisioning January 2010
| | | | | | | |
+----------------------------------------------------------------+
Table 1: Auto-discovery mechanisms for N-AII and C-AII/AGI
7. L2VPN Signaling
The signaling MUST comply with the procedures defined in [RFC5659]
and [DYN MS-PW] for services relying on MS-PWs and [LDP P2MP MS-PW]
for services relying on P2MP MS-PWs.
7.1. P2P MS-PW
S-PEs are assumed to be transparent to the VPN information (VPN-id)
and only base their processing (basically which hop to reach next) on
the C-AII, not the double C-AII & AGI.
The procedure MUST follow the signaling procedure defined in
[RFC5659] and [DYN MS-PW].
The MS-PW signaling is initiated at one of the MS-PW endpoints, i.e.
on a T-PE. The signaling occurs after the T-PE is manually configured
or dynamically discovers via an auto-discovery mechanism the remote
C-AII belonging to the VPN. The T-PE initiates an LDP Label Mapping
message to the S-PE selected to join the TAII.
The SAII is composed of the local C-AII and the VPN-Id (or AGI) and
the TAII corresponds to the C-AII retrieved from the auto-discovery
procedure corresponding to the C-AII configured on the remote T-PE
and attached also to the VPN.
When an S-PE receives the Label Mapping message, it checks if the
TAII contained in the FEC129 has a valid entry in its AII PW routing
table. If no matching is found an error procedure must be applied as
defined in [SEG PW].
Based on the result of the matching the S-PE validates as well its
PW-to-label bindings. This ends the PW setup between the S-PE and T-
PE.
In turn the S-PE selects the "next hops" to reach the TAII (This
selection may be constraint-based, e.g. capacity) . A next hop can be
another S-PE or directly the remote T-PE. The S-PE sends one Label
Mapping message to the selected next hop with the same FEC so far
used.
This process is repeated hop by hop until the MS-PW for this
direction is completely built. When receiving a Label Mapping message
T-PE checks that the TAII and the AGI included in the FEC129 are
locally configured.
If this is the case, the T-PE validates its forwarding plane by
acknowledging the PW-to-label binding for the last segment of the MS-
PW in this direction.
Jounay et al. Expires June, 2010 [Page 15]
Internet Draft MS-PW based L2VPN provisioning January 2010
Finally, the remote T-PE carries on the process by sending a Label
Mapping message in the reverse direction as per [RFC4447].
7.2. P2MP MS-PW
In the case where a P2MP topology is required (use cases can be found
in [P2MP PW REQ]), each T-PE MUST be capable to setup a P2MP MS-PW.
The mechanism described for P2P MS-PW may apply for P2MP MS-PW by
considering either [LDP P2MP MS-PW]. Indeed the T-PE receiving the
VPN information from the remote T-PE may act as the root T-PE in the
[LDP P2MP PW] case or as a leaf T-PE in the [LDP P2MP MS-PW].
This section will be completed in a future version.
8. Monitoring
This section will be completed in a next version, however all
mechanisms deployed here MUST comply with [L2VPN OAM FWK].
9. Protection
This section will be completed in a future version. Discuss
implications of BGP autodiscovery and reconvergence times.
10. Manageability considerations
This section will be added in a future version.
11. Backward Compatibility
This section will be added in a future version.
12. Security Considerations
This section will be added in a future version.
13. IANA Considerations
This draft does not define any new protocol element, and hence does
not require any IANA action.
14. Acknowledgments
This section will be added in a future version.
15. References
Jounay et al. Expires June, 2010 [Page 16]
Internet Draft MS-PW based L2VPN provisioning January 2010
15.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, March 1997.
[RFC4447] El-Aawar, N., Heron, G., Martini, L., Smith, T., Rosen,
E., "Pseudowire Setup and Maintenance Using the Label
Distribution Protocol (LDP)", April 2006
[RFC5254] Bitar, N., Bocci, M., and Martini, L., "Requirements for
inter domain Pseudo-Wires", October 2006
[RFC5659] Bocci, M., and Bryant, S.,T., " An Architecture for
Multi-Segment Pseudo Wire Emulation Edge-to-Edge",
October 2009
[RFC5003] A Mets, et al., "AII Types for Aggregation", September
2007
15.2. Informative References
[L2VPN SIG] Rosen, et al. "Provisioning, Auto-discovery, and
Signaling in L2VPNs", Internet Draft, draft-ietf-l2vpn-
signaling-08.txt, May 2006
[SEG PW] Martini et al, "Segmented Pseudo Wire", Internet Draft,
draft-ietf-pwe3-segmented-pw-13.txt, August 2009
[DYN MS-PW] Balus, F., Bocci, M., Martini, L., "Dynamic Placement of
Multi Segment Pseudo Wires", Internet Draft, draft-ietf-
pwe3-dynamic-ms-pw-10.txt, October 2009
[LDP AII REACH] Delord, S., Jounay, F., Niger, P. "LDP extension
for AII reachability", Internet Draft, draft-ietf-
delord-jounay-pwe3-ldp-aii-reachability-00.txt,
July 2007
[LDP L2VPN AD] Delord, S., Stein, Y., "LDP-based Auto-discovery
for L2 Services", Internet Draft, draft-stein-ldp-
auto-00.txt, July 2005
[OSPF AII REACH] Dolganow et al., "OSPF Extensions for Dynamic
Multi-segment Pseudo Wires", Internet Draft, draft-
ietf-dolganow-pwe3-ospf-ms-pw-ext-00.txt, February
2007
[P2MP PW REQ] Jounay, et al "Requirements for Point to Multipoint
Pseudowire", Internet Draft, July 2009.
[L2VPN OAM FWK] Sajassi, Mohan "L2VPN OAM Framework".
Jounay et al. Expires June, 2010 [Page 17]
Internet Draft MS-PW based L2VPN provisioning January 2010
[LDP P2MP MS-PW] Jounay, F., "LDP Extensions for Leaf-initiated
Point-to-Multipoint Pseudowire", Internet Draft,
draft-jounay-pwe3-leaf-initiated-p2mp-pw-00.txt,
January 2007
16. Author's Addresses
Frederic Jounay
France Telecom
2, avenue Pierre-Marzin
22307 Lannion Cedex
FRANCE
Email: frederic.jounay@orange-ftgroup.com
Philippe Niger
France Telecom
2, avenue Pierre-Marzin
22307 Lannion Cedex
FRANCE
Email: philippe.niger@orange-ftgroup.com
Simon Delord
Telstra
242 Exhibition Street
Melbourne, VIC, 3000, Australia
E-mail: simon.a.delord@team.telstra.com
Yuji Kamite
NTT Communications Corporation
Tokyo Opera City Tower
3-20-2 Nishi Shinjuku, Shinjuku-ku
Tokyo 163-1421
Japan
Email: y.kamite@ntt.com
Mark Latham
Telstra Corporation Limited
242 Exhibition Street
Melbourne, VIC, 3000, Australia
E-mail : mark.latham@team.telstra.com
Thomas D. Nadeau (editor)
BT
BT Centre
81 Newgate Street
London EC1A 7AJ
United Kingdom
Email: thomas.nadeau@bt.com
Dave McDysan
Verizon
Jounay et al. Expires June, 2010 [Page 18]
Internet Draft MS-PW based L2VPN provisioning January 2010
22001 Loudoun County PKWY
Ashburn, VA 20147
Phone: +1 707-886-1891
Email: dave.mcdysan@verizon.com
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Jounay et al. Expires June, 2010 [Page 19]
| PAFTECH AB 2003-2026 | 2026-04-24 03:28:28 |