One document matched: draft-jounay-delord-l2vpn-ms-pw-provisioning-00.txt
Network Working Group Simon Delord
Internet Draft Mark Latham
Category: Informational Track Telstra
Expires: January 2010
Frederic Jounay
Philippe Niger
France Telecom
Y. Kamite
NTT Communications
July 2, 2009
MS-PW based L2VPN provisioning, auto-discovery, signaling
draft-jounay-delord-l2vpn-ms-pw-provisioning-00.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 January 2, 2010.
Abstract
[RFC5254] describes the requirements for service providers to extend
Pseudowires (PWs) across multiple network domains via the use of
multi-segment Pseudowires (MS-PWs). The architecture of MS-PWs is
described in [MS-PW ARCH] and several tools relating to provisioning,
auto-discovery and signaling have been developed to allow the
dynamic setup of MS-PWs.
Jounay et al. Expires January 2010 [Page 1]
Internet Draft MS-PW based L2VPN provisioning July 2009
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.2 Assumptions....................................................5
2. Terminology.....................................................6
3. Provider-Provisioned L2VPN Reference Model......................7
4. AII addressing considerations...................................8
4.1. IP addressing reference model.................................8
4.2. AII PW Layer 2 address (Type 2)...............................9
4.3. Model1: IP@ derived AII addressing plane......................9
4.3.1. N-AII addressing plane......................................9
4.3.2. C-AII addressing plane.....................................10
4.4. Model2: Non IP@ derived AII addressing plane.................11
4.4.1. N-AII addressing plane.....................................11
4.4.2. C-AII addressing plane.....................................11
5. L2VPN Provisioning.............................................11
5.1. VPWS.........................................................11
5.2. VPLS.........................................................12
6. Auto-Discovery.................................................12
6.1. Network AII Auto-Discovery...................................13
6.1.1. Scope for AII Auto-Discovery...............................13
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...........14
6.2. Service VPN Auto-Discovery...................................14
7. L2VPN Signaling................................................15
7.1. P2P MS-PW....................................................15
7.2. P2MP MS-PW...................................................16
8. Monitoring.....................................................16
9. Protection.....................................................16
10. Manageability considerations...................................16
11. Backward Compatibility.........................................16
Jounay et al. Expires January 2010 [Page 2]
Internet Draft MS-PW based L2VPN provisioning July 2009
12. Security Considerations........................................16
13. IANA Considerations............................................17
14. Acknowledgments................................................17
15. References.....................................................17
15.1. Normative References.........................................17
15.2. Informative References.......................................17
16. Author's Addresses.............................................19
17. Intellectual Property Statement................................19
Disclaimer of Validity.............................................19
Copyright Statement................................................19
Acknowledgment.....................................................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 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.
[MS-PW ARCH] 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 January 2010 [Page 3]
Internet Draft MS-PW based L2VPN provisioning July 2009
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 service
elements.
Network provisioning corresponds to the AII configuration at T-PE
(and also S-PE if required). The operator may require to configure
a set of AIIs per T-PE.
During the service provisioning, the operator selects one or more
AII 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.
Jounay et al. Expires January 2010 [Page 4]
Internet Draft MS-PW based L2VPN provisioning July 2009
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).
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
initiating MS-PWs via an LDP Label Mapping towards
the S-PE.
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 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 only (even though it is
possible to use L2TPv3, but this is not discussed here).
As per [MS-PW ARCH] 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.
Jounay et al. Expires January 2010 [Page 5]
Internet Draft MS-PW based L2VPN provisioning July 2009
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).
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 [MS-PW ARCH] 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],
[MS-PW ARCH], [SEG PW].
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.
Jounay et al. Expires January 2010 [Page 6]
Internet Draft MS-PW based L2VPN provisioning July 2009
C-AII ("a" on figures)
C-AII corresponds to the "customer" AII subnet addresses configured
on the access part, i.e. on T-PE. Therefore -AII correspond to the PW
endpoints addresses.
N-AII ("A" on figures)
N-AII corresponds to the "network" AII addresses configured on the
access/metro/core part, i.e. the AII loopback addresses configured on
T-PE and S-PE.
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.
Jounay et al. Expires January 2010 [Page 7]
Internet Draft MS-PW based L2VPN provisioning July 2009
4. AII addressing considerations
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).
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 should be relying on the IP addressing space. 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.
One of the AII addressing scheme can rely on the IP addressing
scheme.
Jounay et al. Expires January 2010 [Page 8]
Internet Draft MS-PW based L2VPN provisioning July 2009
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
correspond respectively to the local IP loopback address of T-PE1, T-
PE2 and S-PE5.
4.2. AII PW Layer 2 address (Type 2)
[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.The PW layer 2 addresses may be configured via NMS
or CLI.
Following is the format of the AII address as defined in [RFC5003]:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AII Type=02 | Length | Global ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Global ID (contd.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AC ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.3. Model1: IP Address derived AII addressing plane
In this first model, the MS-PW addressing scheme relies on the IP
allocation scheme.
4.3.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.
Jounay et al. Expires January 2010 [Page 9]
Internet Draft MS-PW based L2VPN provisioning July 2009
+----+ +----+ +----+ +-----+
|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.3.2. C-AII addressing plane
+----+ +--------+
| | | |
T-PE1 | a1 | | |
A1 | | | |
+----+ | |
+----+ | |
| | | S-PE5 |
T-PE2 | a2 | | A5 |
A2 | a3 | | |
+----+ +--------+
Figure 4 C-AII addressing reference model
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:
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.
Jounay et al. Expires January 2010 [Page 10]
Internet Draft MS-PW based L2VPN provisioning July 2009
4.4. 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.1. 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.4.2. 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)
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...).
Jounay et al. Expires January 2010 [Page 11]
Internet Draft MS-PW based L2VPN provisioning July 2009
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 local C-AII configured. 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.
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).
Jounay et al. Expires January 2010 [Page 12]
Internet Draft MS-PW based L2VPN provisioning July 2009
6.1. Network AII Auto-Discovery
6.1.1. Scope for AII Auto-Discovery
The AII auto-discovery is only required for the model 2, since the
model 1 assumes a direct 1:1 relationship between local IP address
and AII address. In the 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.
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 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.
Jounay et al. Expires January 2010 [Page 13]
Internet Draft MS-PW based L2VPN provisioning July 2009
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 frontier 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).
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 couple (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 to have to provision
on a specific T-PE all the remote identifiers of all other T-PEs
belonging to the same L2VPN.
Jounay et al. Expires January 2010 [Page 14]
Internet Draft MS-PW based L2VPN provisioning July 2009
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.)|
|------------|------|---------|--------|------|---------|--------|
| |Not |Not |Not | via | via | via |
| IP Based |needed|needed |Needed | LDP | IGP | MP-BGP |
| | | | | | | |
|------------|------|---------|--------|------|---------|--------|
| | | | | | | |
| | via | via | via | via | via | via |
| Non IP | LDP | IGP | MP-BGP | LDP | IGP | MP-BGP |
| Based | | | | | | |
|------------|------|---------|--------|------|---------|--------|
Table 1: Auto-discovery mechanisms for N-AII and C-AII/AGI
7. L2VPN Signaling
The signaling MUST comply with the procedures defined in [MS-PW ARCH]
and [DYN MS-PW] for services relying on MS-PWs and [SOURCE INIT P2MP
PW] or [LEAF INIT P2MP PW] or [MARTINI P2MP] 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 [MS-PW
ARCH] 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].
Jounay et al. Expires January 2010 [Page 15]
Internet Draft MS-PW based L2VPN provisioning July 2009
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. 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 the 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.
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 [RQTS P2MP PW]), 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 [LEAF INIT P2MP PW] or [SOURCE INIT P2MP PW].
Indeed the T-PE receiving the VPN information from the remote T-PE
may act as the root T-PE in the [SOURCE INIT P2MP PW] case or as a
leaf T-PE in the [LEAF INIT P2MP 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.
Jounay et al. Expires January 2010 [Page 16]
Internet Draft MS-PW based L2VPN provisioning July 2009
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
15.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4447] El-Aawar, N., Heron, G., Martini, L., Smith, T., Rosen,
"Pseudowire Setup and Maintenance Using the Label
Distribution Protocol (LDP)", April 2006
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
[RFC5254] Bitar, N., Bocci, M., and Martini, L., "Requirements
for inter domain Pseudo-Wires", October 2006
[MS-PW ARCH] Bocci, M., and Bryant, S.,T., " An Architecture for
Multi-Segment Pseudo Wire Emulation Edge-to-Edge",
Internet Draft, draft-ietf-pwe3-ms-pw-arch-06.txt,
October 2006
[SEG PW] Martini et al, "Segmented Pseudo Wire", Internet
Draft, draft-ietf-pwe3-segmented-pw-12.txt, October
2006
[DYN MS-PW] Balus, F., Bocci, M., Martini, L., "Dynamic
Placement of Multi Segment Pseudo Wires", Internet
Draft, draft-ietf-pwe3-dynamic-ms-pw-09.txt, October
2006
[RFC5003] Chris Metz et. al., "AII Types for Aggregation",
February 2007.
[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
Jounay et al. Expires January 2010 [Page 17]
Internet Draft MS-PW based L2VPN provisioning July 2009
[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
[RQTS P2MP PW] Jounay, ..." Requirements for P2MP PW".
[L2VPN OAM FWK] Sajassi, Mohan "L2VPN OAM Framework".
[SOURCE INIT P2MP PW]Jounay, F., Niger, P., "LDP Extensions for
Source-initiated Point-to-Multipoint
Pseudowire", draft-jounay-niger-pwe3-source-
initiated-p2mp-pw-00.txt, January 2007
[LEAF INIT P2MP PW] Jounay, F., "LDP Extensions for Leaf-
initiated Point-to-Multipoint Pseudowire"
draft-jounay-pwe3-leaf-initiated-p2mp-pw-
00.txt, January 2007
[MARTINI P2MP] Martini, "Signaling Root-Initiated Point-to-
Multipoint Pseudowires using LDP", draft-martini-
pwe3-p2mp-pw-00.txt, June 2009
Jounay et al. Expires January 2010 [Page 18]
Internet Draft MS-PW based L2VPN provisioning July 2009
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
Copyright Notice
Copyright (c) 2009 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 January 2010 [Page 19]
| PAFTECH AB 2003-2026 | 2026-04-24 03:29:07 |