Network Working Group Simon Delord (Ed.)
Internet Draft Telstra
Category: Standard Track
Expires: November 2010
Frederic Jounay
Yaakov(J) Stein Philippe Niger
RAD Data Communications France Telecom
Cao Wei Matthew Bocci
Huawei Mustapha Aissaoui
Alcatel-Lucent
Luca Martini
Cisco Systems Inc.
May 24, 2010
LDP extensions for AII reachability
draft-ietf-pwe3-ldp-aii-reachability-04.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 November 25, 2010.
Delord et al. Expires November 2010 [Page 1]
Internet Draft LDP AII Reachability May 2010
Abstract
The dynamic End-to-End Multisegment pseudowire setup requires PEs to
maintain a pseudowire routing table when using FEC129. There is a
requirement to automatically advertise Attachment Individual
Identifiers to enable the pseudowire routing tables to be populated.
Two mechanisms already exist, a BGP reachability information
distribution mechanism and an IGP based one. Here we define a third
solution relying on LDP. It allows for automatic advertisement of the
Attachment Individual Identifier prefixes provisioned on a T-PE when
this node does not run BGP or IGP. The mechanism described here runs
on the T-LDP (Targeted LDP) session between the T-PE and S-PE, and is
intended to complement existing PW routing mechanisms using BGP or
OSPF.
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
2. Scope and Applicability.........................................3
2.1. Scope.........................................................3
2.2. Applicability.................................................4
3. LDP Extensions..................................................5
3.1. LDP AII Address Family Type...................................5
3.2. LDP AII Reachability Capability Advertisement.................6
4. AII Reachability Advertisement Procedures.......................6
4.1. Detailed AII Address Message Procedures.......................6
4.1.1. T-PE Procedures.............................................7
4.1.2. S-PE Procedures.............................................7
5. Security Considerations.........................................7
6. IANA Considerations.............................................7
6.1. Address Family Type...........................................7
6.2. TLV TYPE NAME SPACE...........................................8
7. Acknowledgments.................................................8
8. References......................................................8
8.1. Normative References..........................................8
8.2. Informative References........................................8
Authors' Addresses.................................................8
Intellectual Property and Copyright Statements.....................9
Delord et al. Expires November 2010 [Page 2]
Internet Draft LDP AII Reachability May 2010
1. Introduction
This document describes procedures for PEs to populate their
Pseudowire (PW) routing tables via the Label Distribution Protocol
(LDP). It is targeted at MultiSegment Pseudowire (MS-PW)
applications. The dynamic End-to-End MS-PW architecture requires T-
PEs and S-PEs to maintain a PW routing tables when using FEC129. The
procedure addresses MS-PW architectures where a T-PE does not (for
whatever reason) run either an Interior Gateway Protocol (IGP) or
Multi-Protocol Border Gateway Protocol (MP-BGP). The mechanism
described here is intended to complement other existing PW routing
mechanisms already described in [DYN MS-PW], [BGP AD] and [OSPF MS-
PW].
The need for MS-PWs is presented in [RFC5254]. To allow for minimal
manual intervention/configuration, FEC129 needs to be used as per
[MS-PW] and [DYN MS-PW]. [RFC5003] describes the AII type and the
fields that identify pseudowire endpoints called attachment
individual identifiers (AII).
[DYN MS-PW] specifies a mechanism, based on the MP-BGP, that enables
the advertisement of MS-PW endpoint information in the form of
aggregated AIIs through the network, and thus allows the automatic
placement of MS-PWs.
[OSPF MS-PW] is another way of enabling the automatic placement of
MS-PWs across an OSPF domain when MP-BGP is not / cannot be used
(e.g. when PWE3 is extended into the access part of the network).
2. Scope and Applicability
2.1. Scope
One important application is the use of this LDP protocol extension
in access networks that use IP/MPLS as their access technology and
MS-PW to support L2 services (as per [RFC5254]). MP-BGP or an IGP is
often not available in this part of the network.
|<--- PW Segt 1----><-- PW Segt 2---><---- PW Segt 3---->|
+-----+ +-----+ +-----+ +-----+
|T-PE1+-------------+S-PE1+----------+S-PE2+--------------+T-PE2|
+-----+ +-----+ +-----+ +-----+
<-static-IP-routing--><------IGP/MP-BGP-available---------->
Figure 1 MS-PW Use Case
Figure 1 describes a typical use case where T-PE1 and T-PE2 need to
establish one or several MS-PWs between them. A MS-PW will be
Delord et al. Expires November 2010 [Page 3]
Internet Draft LDP AII Reachability May 2010
composed of at least two PW segments (PW Segt 1 between T-PE1 and S-
PE1, PW Segt 2 between S-PE1 and S-PE2 and PW Segt 3 between S-PE2
and T-PE2). However T-PE1 is not running either an IGP or MP-BGP and
only has one static default route and a T-LDP session towards SPE1.
SPE1, SPE2 and TPE2 are running an IGP and/or MP-BGP.
The aim here is for T-PE1 to announce to the S-PE(s) with which it
has a T-LDP session (there may be more than one S-PE) its locally
attached PW routes, so that the S-PE(s) can populate their AII PW
routing table with the T-PE prefixes.
The AII prefixes locally defined on the T-PE are then advertised via
an LDP Address Message containing a new Address Family. This new
address family capability will follow the processes defined in [RFC
5561].
This document does not presuppose any specific constraint on the AII
PW addressing space (i.e it does not require the AII PW addressing
space to be a subset of the IP addressing space). Therefore, this
document does not define a routing protocol as such, but rather a
"reachability" information distribution method by which a T-PE
advertises its AII to a S-PE. The S-PE will then aggregate and
advertise this information, using one of the MS-PW dynamic placement
mechanisms e.g. MP-BGP, to the other S-PEs and T-PEs in the network.
Note that the S-PE will also advertise it's locally attached
prefixes, and possibly an optional "default PW route".
2.2. Applicability
Section 7.1 of [DYN MS-PW] describes 7.1 the different rules for
aggregated AII PW routing table lookup. The next signaling hop for a
segment of the pseudowire may be determined via a fixed route (static
route and typically a "default route").
In the case of MPLS enabled access networks, an S-PE (e.g. a DSLAM or
other access node) will aggregate up to a few thousands devices that
may require several pseudowires (or "services") on each of those
devices.
These devices may not require either an IGP or MP-BGP to be
integrated into the network, for example because it may not be
desirable for a Service Provider to have to re-engineer their
metro/access architecture by extending their IGP or inserting MP-BGP
further down in the access network. However, they may already use
LDP functionality to setup and maintain pseudowires. They can also
be configured with one or two default static routes as described in
[DYN MS-PW], however on the S-PE side, the provisioning required
becomes increasingly complex. Furthermore, closer to the end node,
it is quite possible that some pseudowires will need to be setup,
removed or modified (e.g. for a bandwidth upgrade) over a short
timescale. Therefore, there is a need for a mechanism that will
alleviate the provisioning burden on the S-PE(s).
Delord et al. Expires November 2010 [Page 4]
Internet Draft LDP AII Reachability May 2010
3. LDP Extensions
3.1. LDP AII Address Family Type
In the case described in this document, we assume LDP sessions
between the T-PE and related S-PEs.
A new Address Family (AF) type called "AII address family" (TBA) is
defined for the Address-List TLV carried in LDP Address and Withdraw
Address messages.
This new AF allows LDP peers to advertise directly attached AII
prefixes, as part of an LDP Address Message and to withdraw directly
attached AII prefixes as part of an LDP Withdraw Address Message.
When a T-PE needs to advertise a new AII prefix to an S-PE, it sends
an LDP Address Message containing the AII prefixes to all the S-PEs
with which it maintains LDP sessions.
When a T-PE needs to withdraw an AII, it sends an LDP Withdraw
Address Message containing the AII prefixes to all S-PEs with which
it maintains LDP sessions.
The Address-List TLV is defined in [RFC5036].
AII address prefix is formatted according to AII Type II, defined in
[RFC5003] section 3.2 (figure 1).
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Address List (0x0101) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family | Prefix Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
~ AII Type II Address (32 - 64) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Prefix Length One octet unsigned integer containing the length
in bits of the address prefix that follows. The
minimum prefix length for an AII address MUST be
of 32 bits. Prefix lengths of 65 to 95 are
invalid as the AC ID field cannot be aggregated.
Two AII Address prefixes (PW routes) are said to match only when both
the AII Type II as well as the 8 bits prefix length are the same.
Delord et al. Expires November 2010 [Page 5]
Internet Draft LDP AII Reachability May 2010
3.2. LDP AII Reachability Capability Advertisement
In order to use this method of propagating l2 reachability
information a PE must first advertise this capability to all LDP
peers. This is achieved by using the methods in [RFC5561] and
advertising the AII Address Family LDP capability TLV. If an LDP peer
supports the dynamic capability advertisement, this can be done by
sending a new capability message with the S bit set for the AII
Address Family capability TLV when the first AII Prefix is enabled on
the PE. If the peer does not support dynamic capability
advertisement, then the AII Address Family TLV MUST be included in
the LDP initialization procedures in the capability parameter [RFC
5561].
The following TLV is defined to indicate the AII Address Family
capability:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0| AII Add. Family CAP(0x406)| Length (= 4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4. AII Reachability Advertisement Procedures
[RFC5036] defines the procedures by which LSRs maintain and exchange
label information via LDP.
This document does not change any of the standard LDP procedures; it
only adds the AII address family type for the Adress-List TLV carried
in LDP Address and Withdraw Address messages.
The rules for advertising and withdrawing addresses are as per [RFC
5036].
4.1. Detailed AII Address Message Procedures
In order for a T-PE to begin advertising its locally attached AII
prefixes to its S-PEs, the T-PE must know the address(es) of the
remote S-PE(s) and already have a T-LDP with each one of those. This
information may have been configured on the T-PE, or it may have been
learned dynamically via some autodiscovery procedure.
Delord et al. Expires November 2010 [Page 6]
Internet Draft LDP AII Reachability May 2010
4.1.1. T-PE Procedures
Upon provisioning the T-PE with a prefix of one or more specific
AII(s), the T-PE MUST send an Address Message including its ASN
and prefix, and optionally an aggregated AII representing its locally
attached AII address(es), to all the S-PEs with which it maintains T-
LDP sessions.
The addresses are structured according to AII type II [RFC5003].
The T-PE MUST only advertise its AIIs over its T-LDP sessions towards
its directly attached S-PEs.
Whenever an attachment circuit not addressed by an existing
aggregated already advertised AII is configured on a T-PE, the T-PE
MUST advertise the new address with an Address message.
Whenever a T-PE "de-activates" a previously advertised AII Prefix, it
SHOULD withdraw the AII Prefix with an Address Withdraw message.
A T-PE MAY re-advertise an address that it has previously advertised
without explicitly withdrawing the address. If the receiver already
has this address binding, it SHOULD take no further action.
A T-PE MAY withdraw an address without having previously advertised
it. If the receiving S-PE has no address binding, it SHOULD take no
further action.
4.1.2. S-PE Procedures
If a PE receives an address TLV containing an address family that it
does not support, it SHOULD follow the procedures defined in
[RFC5036].
An S-PE receiving an address list TLV containing one or more AII
addresses should install those addresses in its local PW routing
table. It MAY also re-advertise those addresses using any another
supported dynamic MS-PW routing protocol like BGP [DYN MS-PW] or OSPF
[OSPF MS-PW]. An S-PE MUST NOT send the attached T-PE address to
other S-PE using T-LDP, because it is not a local connected address.
The only routes that an S-PE MAY redistribute using T-LDP is
connected (local) routes and a "default" route as an exception.
5. Security Considerations
[MPLS SEC] provides a security framework for MPLS and GMPLS Networks.
It emphasizes LDP as well as inter-provider security considerations.
The same security framework and considerations apply to the
capability mechanism described in this document.
Delord et al. Expires November 2010 [Page 7]
Internet Draft LDP AII Reachability May 2010
6. IANA Considerations
6.1. Address Family Type
This document defines a new Address Family type called AII address
family (TBA) for the Adress-List TLV carried in LDP Address and
Address Withdraw messages.
The following value is suggested for assignment:
Registry Number Description
27 AII Attachment Individual Identifier
6.2. TLV TYPE NAME SPACE
This document uses a new LDP TLV type, IANA already maintains a
registry of name "TLV TYPE NAME SPACE" defined by [RFC5036]. The
following value is suggested for assignment:
TLV Type Description
0x406 AII address family capability TLV
7. Acknowledgments
The authors would like to thank Florin Balus, Wim Hendeickx, Jean-
Louis Le Roux, Ed Wong and Raymond Key for their valuable comments
and suggestions.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5036] Andersson, L., Doolan, P., Feldman, N., Fredette, A.,
Thomas, B., "LDP Specification", January 2001.
[RFC5003] Chris Metz et. al., "AII Types for Aggregation",
February 2007.
Delord et al. Expires November 2010 [Page 8]
Internet Draft LDP AII Reachability May 2010
8.2. Informative References
[MS-PW] Martini et al., "Segmented Pseudo Wire", Internet
Draft, draft-ietf-pwe3-segmented-pw-14.txt, April
2010
[DYN MS-PW] Bocci, M., Martini, L., "Dynamic placement of Multi
Segment Pseudo Wires", Internet Draft, draft-ietf-
pwe3-dynamic-ms-pw-10.txt, October 2009
[BGP AD] E. Rosen et. al., "Provisioning, Autodiscovery, and
Signaling in L2VPNs", draft-ietf-l2vpn-signaling-
08.txt, May 2006
[OSPF MS-PW] A. Dolganow, M. Bocci et. al., "OSPF Extensions for
Dynamic Multi- segment Pseudo
Wires",draft-dolganow-pwe3-ospf-ms-pw-ext-03.txt,
February 2008
[RFC5561] B. Thomas, "LDP Capabilities", July 2009
[MPLS SEC] L. Fang, "Security Framework for MPLS and GMPLS
Networks",draft-ietf-mpls-mpls-and-gmpls-security-
framework-09.txt, March 2010
[RFC5254] Bitar, N., Bocci, M., and Martini, L.,
"Requirements for inter domain Pseudo-Wires",October
2008
Author's Addresses
Simon Delord
Telstra
242 Exhibition St
Melbourne VIC 3000
Australia
Email: simon.a.delord@team.telstra.com
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
Delord et al. Expires November 2010 [Page 9]
Internet Draft LDP AII Reachability May 2010
Mustapha Aissaoui
Alcatel-Lucent
600 March Road
Kanata
ON, Canada
e-mail: mustapha.aissaoui@alcatel-lucent.com
Matthew Bocci
Alcatel-Lucent,
Voyager Place
Shoppenhangers Road
Maidenhead
Berks, UK
e-mail: matthew.bocci@alcatel-lucent.co.uk
Yaakov (Jonathan) Stein
RAD Data Communications
24 Raoul Wallenberg St., Bldg C
Tel Aviv 69719, Israel
EMail: yaakov_s@rad.com
Cao Wei
Huawei Technologies Co., Ltd.
Huawei Bld., No.3 Xinxi Rd.
Shang-Di Information Industry Base
Hai-Dian Distinct, Beijing 100085
China
Email: caowayne@huawei.com
Luca Martini
Cisco Systems, Inc.
9155 East Nichols Avenue, Suite 400
Englewood, CO, 80112
e-mail: lmartini@cisco.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
(http://trustee.ietf.org/license-info)
in effect on the date of publication of this document. Please review
these documents carefully, as they describe your rights and
restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License
text as described in Section 4.e of the Trust Legal Provisions and
are provided without warranty as described in the Simplified BSD
License.
Delord et al. Expires November 2010 [Page 10]
