Network Working Group                                 Luca Martini (Ed.)
Internet Draft Engineering Task Force (IETF)                   L. Martini, Ed.
Request for Comments: 7267                           Cisco Systems Systems, Inc.
Expires: September 2014
Intended status: Standards Track                     Matthew Bocci (Ed.)
Updates: 6073                                         Florin Balus (Ed.)                                              M. Bocci, Ed.
Category: Standards Track                                  F. Balus, Ed.
ISSN: 2070-1721                                           Alcatel-Lucent

                                                          March 10,
                                                               June 2014

             Dynamic Placement of Multi-Segment Pseudowires

                  draft-ietf-pwe3-dynamic-ms-pw-22.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 September 10, 2014

Abstract

   RFC5254

   RFC 5254 describes the service provider requirements for extending
   the reach of pseudowires (PW) (PWs) across multiple Packet Switched
   Network domains.  A Multi-Segment multi-segment PW is defined as a set of two or
   more contiguous PW segments that behave and function as a single point-
   to-point
   point-to-point PW.  This document describes extensions to the PW
   control protocol to dynamically place the segments of the multi-segment multi-
   segment pseudowire among a set of Provider Edge (PE) routers.  This
   document also updates RFC6073 as follows: it updates RFC 6073 by updating the value of the length Length
   field of the PW Switching Point PE Sub-TLV Type 0x06 to 14.

Table

Status of Contents

    1        Introduction  .........................................   3
    1.1      Scope  ................................................   3
    1.2      Specification This Memo

   This is an Internet Standards Track document.

   This document is a product of Requirements  ........................   3
    1.3      Terminology  ..........................................   3
    1.4      Architecture Overview  ................................   4
    2        Applicability  ........................................   5
    2.1      Changes to Existing PW Signaling  .....................   5
    3        PW Layer 2 Addressing  ................................   6
    3.1      Attachment Circuit Addressing  ........................   6
    3.2      S-PE Addressing  ......................................   7
    4        Dynamic Placement the Internet Engineering Task Force
   (IETF).  It represents the consensus of MS-PWs  ..........................   7
    4.1      Pseudowire Routing Procedures  ........................   8
    4.1.1    AII PW Routing Table Lookup Aggregation Rules  ........   8
    4.1.2    PW Static Route  ......................................   9
    4.1.3    Dynamic Advertisement with BGP  .......................   9
    4.2      LDP Signaling  ........................................  11
    4.2.1    Multiple Alternative Paths in PW Routing  .............  13
    4.2.2    Active/Passive T-PE Election Procedure  ...............  13
    4.2.3    Detailed Signaling Procedures  ........................  14
    5        Failure Handling Procedures  ..........................  15
    5.1      PSN Failures  .........................................  15
    5.2      S-PE Specific Failures  ...............................  16
    5.3      PW Reachability Changes  ..............................  16
    6        Operations the IETF community.  It has
   received public review and Maintenance (OAM)  .....................  17
    7        Security Considerations  ..............................  17
    8        IANA Considerations  ..................................  18
    8.1      Corrections  ..........................................  18
    8.2      LDP TLV TYPE NAME SPACE  ..............................  18
    8.3      LDP Status Codes  .....................................  19
    8.4      BGP SAFI  .............................................  19
    9        References  ...........................................  19
    9.1      Normative References  .................................  19
    9.2      Informative References  ...............................  20
   10        Contributors  .........................................  20
   11        Acknowledgements  .....................................  21
   12        Author's Addresses  ...................................  21

1. Introduction

1.1. Scope

   [RFC5254] describes the service provider requirements has been approved for extending publication by the reach of pseudowires across multiple Packet Switched Network
   (PSN) domains. This is achieved using a Multi-Segment Pseudowire
   (MS-PW). An MS-PW
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is defined as a set available in Section 2 of two or more contiguous
   pseudowire (PW) segments that behave RFC 5741.

   Information about the current status of this document, any errata,
   and function how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc7267.

Copyright Notice

   Copyright (c) 2014 IETF Trust and the persons identified as a single point-
   to-point PW. the
   document authors.  All rights reserved.

   This architecture is described in [RFC5659].

   The procedures for establishing PWs that extend across a single PSN
   domain are described in [RFC4447], while procedures for setting up
   PWs across multiple PSN domains, or control plane domains are
   described in [RFC6073].

   The purpose of this document is subject to specify extensions to the
   pseudowire control protocol [RFC4447], BCP 78 and [RFC6073] procedures, to
   enable multi-segment PWs to be dynamically placed. The procedures
   follow the guidelines defined IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in [RFC5036] and enable effect on the reuse of
   existing TLVs, and procedures defined for Single-Segment Pseudowires
   (SS-PWs) in [RFC4447]. Dynamic placement date of point-to-multipoint
   (P2MP) PWs is for further study and outside the scope
   publication of this document.

1.2. Specification of Requirements

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted  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 RFC 2119.

1.3. Terminology

   [RFC5659] provides terminology for multi-segment pseudowires. Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

   This document defines the following additional terms:

     - Source Terminating Provider Edge (ST-PE). A Terminating Provider
       Edge (T-PE), which assumes may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the active signaling role and
       initiates copyright in some of this
   material may not have granted the signaling for multi-segment PW.
     - Target Terminating Provider Edge (TT-PE). A Terminating Provider
       Edge (T-PE) that assumes IETF Trust the passive signaling role. It waits and
       responds right to allow
   modifications of such material outside the multi-segment PW signaling message IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the reverse
       direction.

     - Forward Direction: ST-PE to TT-PE.
     - Reverse Direction: TT-PE to ST-PE.
     - Pseudowire Routing (PW routing): The dynamic placement IETF Standards Process, and derivative works of it may
   not be created outside the
       segments that compose an MS-PW, as well IETF Standards Process, except to format
   it for publication as the automatic
       selection an RFC or to translate it into languages other
   than English.

Table of S-PEs. Contents

   1. Introduction ....................................................4
      1.1. Scope ......................................................4
      1.2. Specification of Requirements ..............................4
      1.3. Terminology ................................................4
      1.4. Architecture Overview

   The following figure shows the reference model, derived from
   [RFC5659], ......................................5
   2. Applicability ...................................................6
      2.1. Changes to support Existing PW Signaling ...........................6
   3. PW Layer 2 Addressing ...........................................6
      3.1. Attachment Circuit Addressing ..............................7
      3.2. S-PE Addressing ............................................8
   4. Dynamic Placement of MS-PWs .....................................8
      4.1. Pseudowire Routing Procedures ..............................8
           4.1.1. AII PW Routing Table Lookup Aggregation Rules .......9
           4.1.2. PW Static Route .....................................9
           4.1.3. Dynamic Advertisement with BGP .....................10
      4.2. LDP Signaling .............................................11
           4.2.1. Multiple Alternative Paths in PW Routing ...........13
           4.2.2. Active/Passive T-PE Election Procedure .............14
           4.2.3. Detailed Signaling Procedures ......................15
   5. Procedures for Failure Handling ................................16
      5.1. PSN Failures ..............................................16
      5.2. S-PE Failures .............................................17
      5.3. PW Reachability Changes ...................................17
   6. Operations, Administration, and Maintenance (OAM) ..............18
   7. Security Considerations ........................................18
   8. IANA Considerations ............................................19
      8.1. Correction ................................................19
      8.2. LDP TLV Type Name Space ...................................19
      8.3. LDP Status Codes ..........................................20
      8.4. BGP SAFI ..................................................20
   9. References .....................................................20
      9.1. Normative References ......................................20
      9.2. Informative References ....................................21
   10. Contributors ..................................................22
   11. Acknowledgements ..............................................23

1.  Introduction

1.1.  Scope

   [RFC5254] describes the service provider requirements for extending
   the reach of pseudowires across multiple Packet Switched Network
   (PSN) domains.  This is achieved using a multi-segment pseudowire
   (MS-PW).  An MS-PW is defined as a set of two or more contiguous
   pseudowire (PW) segments that behave and function as a single point-
   to-point PW.  This architecture is described in [RFC5659].

   The procedures for establishing PWs that extend across a single PSN
   domain are described in [RFC4447], while procedures for setting up
   PWs across multiple PSN domains or control plane domains are
   described in [RFC6073].

   The purpose of this document is to specify extensions to the
   pseudowire control protocol [RFC4447], and [RFC6073] procedures, to
   enable multi-segment PWs to be dynamically placed.  The procedures
   follow the guidelines defined in [RFC5036] and enable the reuse of
   existing TLVs, and procedures defined for Single-Segment Pseudowires
   (SS-PWs) in [RFC4447].  Dynamic placement of point-to-multipoint
   (P2MP) PWs is for further study and outside the scope of this
   document.

1.2.  Specification of Requirements

   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 RFC 2119 [RFC2119].

1.3.  Terminology

   [RFC5659] provides terminology for multi-segment pseudowires.

   This document defines the following additional terms:

   - Source Terminating Provider Edge (ST-PE): A Terminating Provider
     Edge (T-PE) that assumes the active signaling role and initiates
     the signaling for multi-segment PWs.

   - Target Terminating Provider Edge (TT-PE): A Terminating Provider
     Edge (T-PE) that assumes the passive signaling role.  It waits and
     responds to the multi-segment PW signaling message in the reverse
     direction.

   - Forward Direction: ST-PE to TT-PE.

   - Reverse Direction: TT-PE to ST-PE.

   - Pseudowire Routing (PW routing): The dynamic placement of the
     segments that compose an MS-PW, as well as the automatic selection
     of Switching PEs (S-PEs).

1.4.  Architecture Overview

   The following figure shows the reference model, derived from
   [RFC5659], to support PW emulated services using multi-segment PWs.

      Native  |<------Multi-Segment Pseudowire------>|  |<---------Multi-Segment Pseudowire-------->|  Native
      Service |          PSN                PSN           |  Service
       (AC)   |     |<-Tunnel->|     |<-Tunnel->|     |<--Tunnel-->|     |<--Tunnel-->|     |   (AC)
         |    V     V     1      V     V     2      V     V     |
         |    +----+    +-----+          +----+     |
      +----+ |    |TPE1|===========|SPE1 |==========|TPE2|            +-----+            +-----+     | +----+
   +---+ |    |------|..... PW.Seg't1....X....PW.Seg't3.....|-------|    |T-PE1|============|S-PE1|============|T-PE2|     | +---+
   | CE1|   |------|...... PW.Seg't 1....X....PW.Seg't 3.......|-------|   |
   |CE1| |    |     |            |     |            |     | |CE2     | |CE2|
   |    |------|..... PW.Seg't2....X....PW.Seg't4.....|-------|   |------|...... PW.Seg't 2....X....PW.Seg't 4.......|-------|   |
      +----+
   +---+ |    |    |===========|     |==========|     |============|     |============|     |     | +----+ +---+
       ^      +----+      +-----+          +----+            +-----+            +-----+       ^
       |   Provider Edge 1          ^          Provider Edge 2    |
       |                            |                             |
       |                            |                             |
       |                    PW switching point                    |
       |                                                          |
           |<------------------
       |<-------------------- Emulated Service --------------->| ------------------>|

                      Figure 1: MS-PW Reference Model

   The PEs that provide services to CE1 and CE2 are Terminating PE1 (T-
   PE1)
   (T-PE1) and Terminating PE2 (T-PE2), respectively.  A PSN tunnel
   extends from T-PE1 to Switching PE1 (S-PE1), and a second PSN tunnel
   extends from S-PE1 to T-PE2 .  PWs are used to connect the attachment
   circuits (ACs) attached to PE1 to the corresponding ACs attached to
   T-PE2.

   A PW segment on PSN Tunnel 1 is connected to a PW segment on PSN
   Tunnel 2 at S-PE1 to complete the multi-segment PW (MS-PW) between
   T-PE1 and T-PE2.  S-PE1 is therefore the PW switching point and is
   referred to as the switching provider edge (S-PE).  PW Segment 1 and
   PW Segment 3 are segments of the same MS-PW MS-PW, while PW Segment 2 and
   PW Segment 4 are segments of another MS-PW.  PW segments of the same MS-
   PW
   MS-PW (e.g., PW segment Segment 1 and PW segment Segment 3) MUST be of the same PW
   type, and PSN tunnels can be of the same or a different technology.
   An S-PE switches an MS-PW from one segment to another based on the PW
   identifiers ( PWid, (PWid, or Attachment Individual Identifier (AII)).  How
   the PW protocol data units (PDUs) are switched at the S-PE depends on
   the PSN tunnel technology: in the case of a Multiprotocol Label
   Switching (MPLS) PSN to another MPLS PSN, PW switching involves a
   standard MPLS label swap operation.

   Note that although Figure 1 only shows a single S-PE, a PW may
   transit more than one S-PE along its path.  Although RFC5659 [RFC5659]
   describes MS-PWs that span more than one PSN, this document does not
   specify how the LDP Label Distribution Protocol (LDP) is used for PW
   control protocol [RFC4447] is used in an inter-AS (Autonomous System) environment.

2.  Applicability

   This document describes the case where the PSNs carrying the MS-PW
   are only MPLS PSNs using the Generalized Pseudowire Identifier (PWID) (PWid)
   Forwarding Equivalence Class (FEC) element (also known as FEC129). FEC 129).

   Interactions with an IP PSN using L2TPv3 the Layer 2 Tunneling Protocol
   version 3 (L2TPv3) as described in Section 8 of [RFC6073]
   section 7.4 are left
   for further study.

2.1.  Changes to Existing PW Signaling

   The procedures described in this document make use of existing LDP
   TLVs and related PW signaling procedures described in [RFC4447] and
   [RFC6073].  The following optional TLV is also defined:

   - A Bandwidth TLV to address QoS Signaling requirements (see
     Section 6.2.1). 4.2).

   This document also updates the value of the length Length field of the PW
   Switching Point PE Sub-TLV Type 0x06 to 14.

3.  PW Layer 2 Addressing

   Single segment

   Single-segment pseudowires on an MPLS PSN can use attachment circuit
   identifiers for a PW using FEC 129.  In the case of a dynamically
   placed MS-PW, there is a requirement for the attachment circuit
   identifiers to be globally unique, for the purposes of reachability
   and manageability of the PW.  Referencing figure Figure 1 above, individual
   globally unique addresses MUST be allocated to all the ACs and S-PEs
   of an MS-PW.

3.1.  Attachment Circuit Addressing

   The attachment circuit addressing is derived from [RFC5003] AII type
   2, Type 2
   [RFC5003], as shown here:

      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.) (continued)   |        Prefix                 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |       Prefix (contd.) (continued)      |        AC ID                  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      AC ID                    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 2: AII Type 2 TLV Structure

   The fields are defined in [RFC5003], Section 3.2. 3.2 of [RFC5003].

   Addressing schemes based on AII type Type 2 based addressing schemes permit varying levels of AII
   summarization, thus reducing the scaling burden on PW routing.  PW
   addressing based on AII Type 2 based PW addressing is suitable for point-to-point
   provisioning models where auto-discovery of the address at the Target
   T-PE TT-PE
   is not required.  That is, it is known a-priori a priori by provisioning.

   Implementations of the following procedure MUST interpret the AII
   type to determine the meaning of the address format of the AII,
   irrespective of the number of segments in the MS-PW.  All segments of
   the PW MUST be signaled with the same AII Type. type.

   A unique combination of Global ID, Prefix, and AC ID parts of the
   AII
   type Type 2 are assigned to each AC.  In general, the same Global ID
   and Prefix are be assigned for all ACs belonging to the same T-PE.
   This is not a strict requirement, however.  A particular T-PE might
   have more than one Prefix assigned to it, and likewise a fully
   qualified AII with the same Global ID/Prefix but different AC IDs
   might belong to different T-PEs.

   For the purpose of MS-PWs, the AII MUST be globally unique across all
   PSNs that are spanned by the MS-PW.

   The AII for a local attachement attachment circuit of a given T-PE of an MS-PW
   and the AII of the corresponding attachment circuit on a far-end T-PE
   (with respect to the LDP signaling) are known as the Source
   Attachment Individual Identifier (SAII) and Target Attachment
   Individual Identifier (TAII) as per [RFC6074].

3.2.  S-PE Addressing

   Each S-PE MUST be assigned an address which that uniquely identifies it
   from a pseudowire perspective, in order to populate the PW Switching
   Point PE (SP-PE) TLV specified in [RFC6073].  For this purpose, at
   least one Attachment Identifier (AI) address of the format similar to
   AII type Type 2 [RFC5003] composed of the Global ID, and Prefix part,
   only, MUST be assigned to each S-PE.

   If an S-PE is capable of Dynamic dynamic MS-PW signaling, signaling but is not assigned
   with an S-PE address, then on receiving a Dynamic dynamic MS-PW Label Mapping
   message the S-PE MUST return a Label Release with the
   "LDP_RESOURCES_UNAVAILABLE" ( 0x38)" "Resources
   Unavailable" (0x38) status code.

4.  Dynamic Placement of MS-PWs

   [RFC6073] describes a procedure for concatenating multiple
   pseudowires together.  This procedure requires each S-PE to be
   manually configured with the information required for each segment of
   the MS-PW.  The procedures in the following sections describe a
   method to extend [RFC6073] by allowing the automatic selection of pre-
   defined S-PEs,
   predefined S-PEs and dynamically establishing a an MS-PW between two T-
   PEs.
   T-PEs.

4.1.  Pseudowire Routing Procedures

   The AII type Type 2 described above contains a Global ID, Prefix, and
   AC ID.  The Target Attachment Individual Identifier (TAII) TAII is used by S-
   PEs S-PEs to determine the next SS-PW
   destination for LDP signaling.

   Once an S-PE receives a an MS-PW Label Mapping message containing a
   TAII with an AII that is not locally present, the S-PE performs a
   lookup in a PW AII routing table.  If this lookup results in an IP
   address for the next-hop PE with reachability information for the AII
   in question, then the S-PE will initiate the necessary LDP messaging
   procedure to set-up set up the next PW segment.  If the PW AII routing table
   lookup does not result in a an IP address for a next-hop PE, the
   destination AII has become unreachable, and the PW setup MUST fail.
   In this case case, the next PW segment is considered un-provisioned, unprovisioned, and a
   Label Release MUST be returned to the T-PE with a status message of
   "AII Unreachable".

   If the TAII of a an MS-PW Label Mapping message received by a PE
   contains the prefix Prefix matching a locally-provisioned the locally provisioned prefix on that PE,
   PE but an AC ID that is not provisioned, then the LDP liberal label
   retention procedures apply, and the Label Mapping message is
   retained.

   To allow for dynamic end-to-end signaling of MS-PWs, information MUST
   be present in S-PEs to support the determination of the next PW
   signaling hop.  Such information can be provisioned (equivalent to a
   static route) on each S-PE, or disseminated via regular routing
   protocols (e.g. (e.g., BGP).

4.1.1.  AII PW Routing Table Lookup Aggregation Rules

   All PEs capable of dynamic MS-PW path selection MUST build a PW AII
   routing table to be used for PW next-hop selection.

   The PW addressing scheme (AII type Type 2 as defined in [RFC5003])
   consists of a Global ID, a 32 bit prefix 32-bit Prefix, and a 32 bit 32-bit Attachment
   Circuit ID.

   An aggregation scheme similar to that used for classless IPv4
   addresses can be employed. An (8 bits)  A length mask (8 bits) is specified as a
   number ranging from 0 to 96 that indicates which Most Significant
   Bits (MSB) (MSBs) are relevant in the address field when performing the PW
   address matching
   address-matching algorithm.

                     0        31 32    63 64    95 (bits)
                    +-----------+--------+--------+
                    | Global ID | Prefix | AC ID  |
                    +-----------+--------+--------+

                      Figure 3: PW Addressing Scheme

   During the signaling phase, the content of the (fully qualified)
   TAII
   type Type 2 field from the FEC129 FEC 129 TLV is compared against routes
   from the PW Routing routing table.  Similar with to the IPv4 case, the route with
   the longest match is selected, determining the next signaling hop and
   implicitly the next PW Segment segment to be signaled.

4.1.2.  PW Static Route

   For the purpose of determining the next signaling hop for a segment
   of the pseudowire, the PEs MAY be provisioned with fixed route fixed-route
   entries in the PW next hop next-hop routing table.  The static PW entries will
   follow all the addressing rules and aggregation rules described in
   the previous sections.  The most common use of PW static provisioned
   routes is this example of the "default" route entry as follows:

   Global ID = 0 Prefix = 0 AC ID = 0 , 0, Prefix Length = 0
   Next Signaling Hop = {IP Address of next hop next-hop S-PE or T-PE}

4.1.3.  Dynamic Advertisement with BGP

   Any suitable routing protocol capable of carrying external routing
   information MAY be used to propagate MS-PW path information among S-
   PEs
   S-PEs and T-PEs.  However, T-PEs and S-PEs MAY choose to use the
   Border Gateway Protocol (BGP) [RFC4271] with the Multiprotocol
   Extensions as defined in [RFC4760] to propagate PW address
   information throughout the PSN.  PW address information is only
   propagated by PEs that are capable of PW switching.  Therefore, the
   multiprotocol BGP neighbor topology MUST coincide with the topology
   of T-PEs and S-PEs.

   Contrary to layer Layer 2 VPN signaling methods that use BGP [RFC6074] for
   auto discovery,
   auto-discovery [RFC6074], in the case of the dynamically placed
   MS-PW, the source T-PE knows a-priori a priori (by provisioning) the AC ID on
   the terminating T-PE that signaling should use. Hence  Hence, there is no
   need to advertise a "fully qualified" 96 bit 96-bit address on a per PW Attachment
   Circuit per-PW
   attachment circuit basis.  Only the T-PE Global ID, Prefix, and
   prefix length
   needs need to be advertised as part of well known well-known BGP procedures -
   procedures; see [RFC4760].

   Since PW Endpoints are provisioned in the T-PEs, the ST-PE will use
   this information to obtain the first S-PE hop (i.e., first BGP next
   hop) to where the first PW segment will be established.  Any
   subsequent S-PEs will use the same information (i.e. (i.e., the next BGP
   next-hop(s))
   next hop(s)) to obtain the next-signaling-hop(s) next signaling hop(s) on the path to the
   TT-PE.

   The PW dynamic path Network Layer Reachability Information (NLRI) is
   advertised in BGP UPDATE messages using the MP_REACH_NLRI and
   MP_UNREACH_NLRI attributes [RFC4760].  The {AFI, SAFI} value pair
   used to identify this NLRI is (AFI=25, SAFI=6 (pending IANA allocation)). SAFI=6).  A route target MAY
   also be advertised along with the NLRI.

   The Next Hop field of the MP_REACH_NLRI attribute SHALL be
   interpreted as an IPv4 address, address whenever the length of the NextHop
   address is 4 octets, and as a an IPv6 address, address whenever the length of
   the NextHop address is 16 octets.

   The NLRI field in the MP_REACH_NLRI and MP_UNREACH_NLRI is a prefix
   comprising an 8-octet Route Distinguisher, the Global ID, the Prefix,
   and the AC-ID, AC ID, and encoded as defined in section Section 4 of [RFC4760].

   This NLRI is structured as follows:

        Bit
        0     7 8             71 72      103 104  135 136   167
        +------+----------------+-----------+--------+--------+
        |Length|  Route Dist    | Global ID | Prefix | AC ID  |
        +------+----------------+-----------+--------+--------+

                      Figure 4: NLRI Field Structure

   The Length field is the Prefix prefix length of the Route Distinguisher +
   Global ID + Prefix + AC-ID AC ID in bits.

   Except for the default PW route, which is encoded as a 0 length 0-length
   Prefix, the minimum value of the length Length field is 96 bits.  Lengths of
   128 bits to 159 bits are invalid invalid, as the AC ID field cannot be
   aggregated.  The maximum value of the Length field is 160 bits.  BGP
   advertisements received with invalid Prefix lengths MUST be rejected
   as having a bad packet format.

4.2.  LDP Signaling

   The LDP signaling procedures are described in [RFC4447] and expanded
   in [RFC6073].  No new LDP signaling components are required for
   setting up a dynamically placed MS-PW.  However, some optional
   signaling extensions are described below.

   One of the requirements that MUST be met in order to enable achieve the QoS
   objectives for a PW to be achieved on a segment is that a PSN tunnel MUST be
   selected that can support at least the required class of service and
   that has sufficient bandwidth available.

   Such PSN tunnel selection can be achieved where the next hop for a PW
   segment is explicitly configured at each PE, whether the PE is a T-PE
   or an S-PE in the case of a segmented PW, without dynamic path
   selection (as per RFC6073). [RFC6073]).  In these cases, it is possible to
   explicitly configure the bandwidth required for a PW so that the T-PE
   or S-PE can reserve that bandwidth on the PSN tunnel.

   Where dynamic path selection is used and therefore the next-hop next hop is therefore
   not explicitly configured by the operator at the S-PE, a mechanism is
   required to
   signal the bandwidth for the PW from the T-PE to the S-
   PEs. S-PEs is
   required.  This is accomplished by including an optional PW Bandwidth
   TLV.  The PW Bandwidth TLV is specified as follows:

     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|     PW BW TLV  (0x096E)   |          TLV  Length          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     Forward SENDER_TSPEC                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     Reverse SENDER_TSPEC                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 5: PW Bandwidth TLV Structure

   The PW Bandwidth TLV fields are as follows:

   - TLV Length: The length of the value fields in octets.  Value = 64 64.

   - Forward SENDER_TSPEC = The the SENDER_TSPEC for the forward direction
     of the PW, as defined in [RFC2210] section 3.1. Section 3.1 of [RFC2210].

   - Reverse SENDER_TSPEC = The the SENDER_TSPEC for the reverse direction
     of the PW, as defined in [RFC2210] section 3.1. Section 3.1 of [RFC2210].

   The complete definitions of the content of the SENDER_TSPEC objects
   are found in [RFC2210] section 3.1. Section 3.1 of [RFC2210].  The forward SENDER_TSPEC
   refers to the data path in the direction of ST-PE to TT-PE.  The reverse
   SENDER_TSPEC refers to the data path in the direction TT-PE to ST-PE.

   In the forward direction, after a next hop next-hop selection is determined, a
   T/S-PE SHOULD reference the forward SENDER_TSPEC object to determine
   an appropriate PSN tunnel towards the next signaling hop.  If such a
   tunnel exists, the MS-PW signaling procedures are invoked with the
   inclusion of the PW Bandwidth TLV.  When the PE searches for a PSN
   tunnel, any tunnel which that points to a next hop equivalent to the next
   hop selected will be included in the search (the LDP address TLV is
   used to determine the next hop equivalence) next-hop equivalence).

   When an S/T-PE receives a PW Bandwidth TLV, once the PW next hop is
   selected, the S/T-PE MUST request the appropriate resources from the
   PSN.  The resources described in the reverse SENDER_TSPEC are
   allocated from the PSN toward the originator of the message or
   previous hop.  When resources are allocated from the PSN for a
   specific PW, the allocation SHOULD account for the resource usage of
   the resources by the PW.

   In the case where PSN resources towards the previous hop are not
   available, the following procedure MUST be followed:
        -i.

     i. The PSN MAY allocate more QoS resources, e.g. Bandwidth, e.g., bandwidth, to the
        PSN tunnel.
       -ii.

    ii. The S-PE MAY attempt to setup set up another PSN tunnel to accommodate
        the new PW QoS requirements.
      -iii.

   iii. If the S-PE cannot get enough resources to setup set up the segment in
        the MS-PW MS-PW, a Label Release MUST be returned to the previous hop
        with a status message of "Bandwidth resources
            unavailable" unavailable".

   In the latter case, the T-PE receiving the status message MUST also
   withdraw the corresponding PW Label Mapping message for the opposite
   direction if it has already been successfully setup. set up.

   If an ST-PE receives a Label Mapping message message, the following procedure
   MUST be followed:

   If the ST-PE has already sent a Label Mapping message for this PW PW,
   then the ST-PE MUST check that to see if this Label Mapping message
   originated from the same LDP peer to which the corresponding Label
   Mapping message for this particular PW was sent.  If it is the same
   peer, the PW is established.  If it is a different peer, then the
   ST-PE MUST send a Label Release message, message with a status code of "Duplicate AII" "PW
   Loop Detected" to the PE that originated the LDP Label Mapping
   message.

   If the PE has not yet sent a Label Mapping message for this
   particular PW , PW, then it MUST send the Label Mapping message to this
   LDP peer, regardless of what the PW TAII routing lookup result is.

4.2.1.  Multiple Alternative Paths in PW Routing

   A next hop next-hop selection for a specific PW may find a match with a PW
   route that has multiple next hops associated with it.  Multiple next
   hops may be either configured explicitly as static routes or may be learned
   through BGP routing procedures.  Implementations at an S-PE or T-PE
   MAY use selection algorithms, such as CRC32 on the FEC TLV, TLV or
   flow-aware flow-
   aware transport PW of PWs [RFC6391], for load balancing of PWs across
   multiple next-hops, next hops, so that each PW has a single next hop.  The
   details of such selection algorithms are outside the scope of this
   document.

4.2.2.  Active/Passive T-PE Election Procedure

   When a an MS-PW is signaled, each T-PE might independently initiate
   signaling the MS-PW.  This could result in a different path being
   used
   be by each direction of the PW.  To avoid this situation situation, one T-PE
   MUST initiate PW signaling (i.e. (i.e., take an active role), while the
   other T-
   PE T-PE waits to receive the LDP Label Mapping message before
   sending the LDP Label Mapping message for the reverse direction of
   the PW (i.e. (i.e., take a passive role).  The Active active T-PE (the ST-PE) and
   the Passive T-
   PE passive T-PE (the TT-PE) MUST be identified before signaling
   begins for a given MS-PW.  Both T-PEs MUST use the same method for
   identifying which is
   Active active and which is Passive. passive.

   A T-PE SHOULD determine whether it assumes the active role or the
   passive role using procedures similar to those of [RFC5036] [RFC5036],
   Section 2.5.2, Bullet 2.  The T-PE compares the Source Attachment
   Individual Identifier (SAII) [RFC6074] with the Target Attachment
   Individual Identifier (TAII) [RFC6074] as unsigned integers, and if
   the SAII > TAII, the T-PE assumes the active role. Otherwise  Otherwise, it
   assumes the passive role.

   The following procedure for comparing the SAII and TAII as unsigned
   integers SHOULD be used:

   - If the SAII Global ID > TAII Global ID, then the T-PE is active

     - else if the SAII Global ID < TAII Global ID ID, then the T-PE is
       passive

       - else if the SAII Prefix > TAII Prefix, then the T-PE is active

         - else if the SAII Prefix < TAII Prefix, then the T-PE is
           passive

           - else if the SAII AC-ID AC ID > TAII AC-ID, AC ID, then the T-PE is
             active

             - else if the SAII AC-ID AC ID < TAII AC-ID, AC ID, then the T-PE is
               passive

               - else there is a configuration error

4.2.3.  Detailed Signaling Procedures

   On receiving a Label Mapping message, the S-PE MUST inspect the FEC
   TLV.  If the receiving node has no local AII matching the TAII for
   that label mapping Label Mapping message, then the Label Mapping message SHOULD be
   forwarded on to another S-PE or T-PE.  The S-PE will check to see if
   the FEC is already installed for the forward direction:

   - If the FEC is already installed, installed and the received Label Mapping was
     received from the same LDP peer to which the forward LDP Label
     Mapping was sent, then this Label Mapping represents signaling in
     the reverse direction for this MS-PW segment.

   - If the FEC is already installed, installed and the received Label Mapping was
     received from a different LDP peer to which the forward LDP Label
     Mapping was sent, then the received Label Mapping MUST be released
     with the a status code of "PW_LOOP_DETECTED". "PW Loop Detected".

   - If the FEC is not already installed, then this represents signaling
     in the forward direction.

   The following procedures are then executed, depending on whether the
   Label Mapping was determined to be for the forward or the reverse
   direction of the MS-PW.

   For the forward direction:
        -i.

      i. Determine the next hop next-hop S-PE or T-PE according to the procedures
         above.  If next-hop reachability is not found in the S-PE's PW
         AII routing table table, then a Label Release MUST be sent with
         status code "AII_UNREACHABLE". "AII Unreachable".  If the next-hop S-
            PE S-PE or T-PE is
         found and is the same LDP Peer peer that sent the Label Mapping message
         message, then a Label Release MUST be returned with the status code "PW_LOOP_DETECTED".
         "PW Loop Detected".  If the SAII in the received Label Mapping
         is local to the S-PE S-PE, then a Label Release MUST be returned
         with status code
            "PW_LOOP_DETECTED".

       -ii. "PW Loop Detected".

     ii. Check that to see if a PSN tunnel exists to the next hop next-hop S-PE or
         T-PE.  If no tunnel exists to the next hop next-hop S-PE or T-PE, the
         S-PE MAY attempt to setup set up a PSN tunnel.
      -iii.

    iii. Check that to see if a PSN tunnel exists to the previous hop.  If no
         tunnel exists to the previous hop previous-hop S-PE or T-PE, the S-PE MAY
         attempt to setup set up a PSN tunnel.
       -iv.

     iv. If the S-PE cannot get enough PSN resources to setup set up the
         segment to the next next-hop or previous hop previous-hop S-PE or T-PE, a Label
         Release MUST be returned to the T-PE with a status message of
         "Resources Unavailable".
        -v.

      v. If the Label Mapping message contains a Bandwidth TLV, allocate
         the required resources on the PSN tunnels in the forward and
         reverse directions according to the procedures above.
       -vi.

     vi. Allocate a new PW label for the forward direction.
      -vii.

    vii. Install the FEC for the forward direction.
     -viii.

   viii. Send the Label Mapping message with the new forward label and
         the FEC to the next hop next-hop S-PE/T-PE.

   For the reverse direction:
        -i.

     i. Install the FEC received int he in the Label Mapping message for the
        reverse direction.
       -ii.

    ii. Determine the next signaling hop by referencing the LDP sessions
        used to setup set up the PW in the Forward forward direction.
      -iii.

   iii. Allocate a new PW label for the next hop in the reverse
        direction.
       -iv.

    iv. Install the FEC for the next hop in the reverse direction.
        -v.

     v. Send the Label Mapping message with a new label and the FEC to
        the next hop next-hop S-PE/ST-PE.

5.  Procedures for Failure Handling Procedures

5.1.  PSN Failures

   Failures of the PSN tunnel MUST be handled by PSN mechanisms.  An
   example of such a PSN mechanism is MPLS fast reroute [RFC4090].  If
   the PSN is unable to re-establish the PSN tunnel, then the S-PE
   SHOULD follow the procedures defined in Section 10 of [RFC6073].

5.2.  S-PE Specific Failures

   For defects in an S-PE, the procedures defined in [RFC6073] SHOULD be
   followed.  A T-PE or S-PE may receive an unsolicited Label Release
   message from another S-PE or T-PE with various failure codes codes, such
   "LOOP_DETECTED", "PW_LOOP_DETECTED", "RESOURCE_UNAVAILBALE",
   "BAD_STRICT_HOP", "AII_UNREACHABLE", etc. as
   "Loop Detected", "PW Loop Detected", "Resources Unavailable", "Bad
   Strict Node Error", or "AII Unreachable".  All these failure codes
   indicate a generic class of PW failures at an S-PE or T-PE.

   If an unsolicited Label Release message with such a failure status
   code is received at a T-PE, then it is RECOMMENDED that the T-PE
   attempt to re-establish the PW immediately. However  However, the T-PE MUST
   throttle its PW setup message retry attempts with an exponential
   backoff in situations where PW setup messages are being constantly
   released.  It is also RECOMMENDED that a T-PE detecting such a
   situation take action to notify an operator.

   S-PEs that receive an unsolicited Label Release message with a
   failure status code SHOULD follow the following procedures:

        -i. this procedure:

   i. If the Label Release is received from an S-PE or T-PE in the
      forward or reverse signaling direction direction, then the S-PE MUST tear
      down both segments of the PW.  The status code received in the
      Label Release message SHOULD be propagated when sending the Label
      Release for the next-segment. next segment.

5.3.  PW Reachability Changes

   In general general, an established MS-PW will not be affected by next-hop
   changes in AII reachability information.

   If there is a next-hop change in next-hop of the AII reachability information in the
   forward direction, the T-PE MAY elect to tear down the MS-PW by
   sending a label withdraw Label Withdraw message to the downstream S-PE or T-PE.  The
   teardown MUST be also be accompanied by a an unsolicited Label Release
   message,
   message and will be followed by and an attempt by the T-PE to
   re-establish of the
   MS-PW by T-PE. MS-PW.

   If there is a change in the AII reachability information in the
   forward direction at an S-PE, the S-PE MAY elect to tear down the
   MS-PW in both directions.  A label withdrawal is sent on in each
   direction followed by a an unsolicited Label Release.  The unsolicited
   Label
   Releases Release messages MUST be accompanied by the Status status code "AII_UNREACHABLE". "AII
   Unreachable".  This procedure is OPTIONAL.  Note that this procedure
   is likely to be disruptive to the emulated service.  PW Redundancy
   [RFC6718] MAY be used to maintain the connectivity used by the
   emulated service in the case of a failure of the PSN or S-PE.

   A change in AII reachability information in the reverse direction has
   no effect on an MS-PW.

6. Operations  Operations, Administration, and Maintenance (OAM)

   The OAM procedures defined in [RFC6073] may also be used also for
   dynamically placed MS-PWs.  A PW switching point Switching Point PE TLV [RFC6073] is
   used
   [RFC6073] to record the switching points that the PW traverses.

   In the case of a an MS-PW where the PW Endpoints are identified though by
   using a globally unique, FEC 129-based unique AII addresses, addresses based on FEC 129, there is no
   pseudowire identifier (PWID) (PWid) defined on a per-segment basis.  Each
   individual PW segment is identified by the address of the adjacent
   S-PE(s) in conjunction with the SAII and TAII.

   In this case, the following TLV type (0x06) MUST be used in place of
   type 0x01 in the PW switching point Switching Point PE TLV:

      Type      Length    Description
      ----      ------    -----------------------------------
      0x06        14      L2 PW address of PW Switching Point

   The above sub-TLV MUST be included in the PW Switching Point PE TLV
   once per individual PW Switching Point switching point, following the same rules and
   procedures as those described in [RFC6073].  A more detailed
   description of this sub-TLV is also given in setion Section 7.4.1 of
   [RFC6073].  However, the length value MUST be set to 14 (RFC6073 ([RFC6073]
   states that the length value is 12, but this does not correctly
   represent the actual length of the TLV).

7.  Security Considerations

   This document specifies extensions to the protocols already defined
   in [RFC4447], [RFC4447] and [RFC6073].  The extensions defined in this document
   do not affect the security considerations for those protocols, but
   [RFC4447] and [RFC6073] do impose a set of security considerations
   that are applicable to the protocol extensions specified in this
   document.

   It should be noted that the dynamic path selection mechanisms
   specified in this document enable the network to automatically select
   the S-PEs that are used to forward packets on the MS-PW.  Appropriate
   tools, such as the VCCV Trace Virtual Circuit Connectivity Verification (VCCV)
   trace mechanisms specified in [RFC6073], can be used by an operator
   of the network to verify the path taken by the MS-PW and satisfy themselves therefore be
   satisfied that it the path does not represent an additional security
   risk.

   Note that the PW control protocol may be used to establish and
   maintain an MS-PW across administrative boundaries.  Section 13 of
   [RFC6073] specifies security considerations applicable to LDP used in
   this manner, including considerations on for establishing the integrity
   of, and authenticating, LDP control messages. This  These considerations
   also apply to the protocol extensions specified in this document.

   Note that the protocols for dynamically distributing AII reachability
   information may have their own security considerations. However  However,
   those
   protocols protocol specifications are outside the scope of this document.

8.  IANA Considerations

8.1. Corrections  Correction

   IANA is requested to correct has corrected a minor error in the registry "Pseudowire Switching Point
   PE sub-TLV Type". Type" registry.  The entry 0x06 "L2 PW address of the PW
   Switching Point" should have has been corrected to Length 14 and the reference
   changed to [RFC6073] and [RFC-to-be] this document as follows:

   Type  Length  Description                          Reference --
   -----+---
   ---+------------------------------------+-------------------------
   ----  ------  -----------------------------------  ------------------
   0x06    14    L2 PW Address of PW Switching Point  [RFC6073] and
   [RFC-to-be]  [RFC6073][RFC7267]

8.2.  LDP TLV TYPE NAME SPACE Type Name Space

   This document defines one new LDP TLV types. type.  IANA already maintains a
   registry for LDP TLV types types, called "Type, Length,  and Value (TLV) the "TLV Type Name Space"
   registry, within the "Label Distribution Protocol (LDP) Parameters"
   registry as defined by RFC5036. [RFC5036].  IANA is requested to assign on
   permanent basis the value (0x096E) that has been assigned to this
   document by early allocation (TEMPORARY - Expires 2008-11-21).: the following
   value.

     Value    Description     Reference       Notes/Registration Date
   ------+----------------+---------------+-----------------------
     ------   -------------   -------------   -----------------------
     0x096E   Bandwidth TLV   This document

8.3.  LDP Status Codes

   This document defines three new LDP status codes.  IANA maintains a
   registry of these codes, called the "STATUS CODE NAME SPACE" "Status Code Name Space"
   registry, in the "Label Distribution Protocol (LDP) Parameters"
   registry as defined by RFC5036. [RFC5036].  The IANA is requested to assign on permanent basis the values that has
   been assigned to this document by early allocation
    (TEMPORARY - Expires 2008-11-21): the
   following values.

   Range/Value    E     Description                       Reference
   -------------
   -----------  -----   ----------------------            ---------   -------------------------------   -------------
   0x00000037     0     Bandwidth resources unavailable   This document
   0x00000038     0     Resources Unavailable             This document
   0x00000039     0     AII Unreachable                   This document

8.4.  BGP SAFI

   IANA needs to allocate has allocated a new BGP SAFI for "Network Layer Reachability
   Information used for Dynamic Placement of Multi-Segment Pseudowires"
   from
   in the IANA "Subsequence "SAFI Values" registry [RFC4760] within the "Subsequent
   Address Family Identifiers (SAFI)" (SAFI) Parameters" registry.  The IANA is requested to assign on permanent basis the
   values that has been
   assigned to this document by early allocation
   (TEMPORARY - Expires 2008-11-21):: the following value.

   Value   Description                                   Reference
   -----    -----------                                     ---------   -------------------------------------------   -------------
   6       Network Layer Reachability Information used        This document
           used for Dynamic Placement of Multi-Segment
           Pseudowires

9.  References

9.1.  Normative References

   [RFC6073] Martini et.al. "Segmented Pseudowire", RFC6073,
        January 2011

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2210]  Wroclawski, J. J., "The Use of RSVP with IETF Integrated
              Services", RFC 2210, September 1997

   [RFC5036] Andersson, Minei, Thomas. "LDP Specification"
        RFC5036, October 2007 1997.

   [RFC4447]  Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and
              G. Heron, "Pseudowire Setup and Maintenance Using the
              Label Distribution Protocol (LDP)", Martini L.,et al, RFC 4447,
        June 2005. April 2006.

   [RFC5003]  Metz, C., Martini, L., Balus, F., and J. Sugimoto,
              "Attachment Individual Identifier (AII) Types for
              Aggregation", Metz, et al, RFC5003, RFC 5003, September 2007 2007.

   [RFC5036]  Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
              "LDP Specification", RFC 5036, October 2007.

   [RFC6073]  Martini, L., Metz, C., Nadeau, T., Bocci, M., and M.
              Aissaoui, "Segmented Pseudowire", RFC 6073, January 2011.

9.2.  Informative References

   [RFC4090]  Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast
              Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
              May 2005.

   [RFC4271]  Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
              Border Gateway Protocol 4 (BGP-4)", RFC 4271,
              January 2006.

   [RFC4760]  Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
              "Multiprotocol Extensions for BGP-4", RFC 4760,
              January 2007.

   [RFC5254] Martini et al,  Bitar, N., Ed., Bocci, M., Ed., and L. Martini, Ed.,
              "Requirements for Multi-Segment Pseudowire Emulation Edge-to-Edge Edge-
              to-Edge (PWE3)",
        RFC5254, Bitar, Martini, Bocci, RFC 5254, October 2008 2008.

   [RFC5659] Bocci at al,  Bocci, M. and S. Bryant, "An Architecture for Multi-Segment Pseudo Wire Multi-
              Segment Pseudowire Emulation Edge-to-Edge", RFC5659,October  2009.

   [RFC4760] Bates, T., Rekhter, Y., Chandra, R. and D. Katz,
        "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007. 5659,
              October 2009.

   [RFC6074] E.  Rosen, W. Luo, B. E., Davie, V. B., Radoaca, V., and W. Luo,
              "Provisioning, Autodiscovery, Auto-Discovery, and Signaling in L2VPNs",
        RFC6074, January 2011

   [RFC4271] Rekhter, Y., et al, "A Border Gateway Protocol 4 (BGP-4)",
        RFC4271, Layer 2
              Virtual Private Networks (L2VPNs)", RFC 6074,
              January 2006 2011.

   [RFC6391]  Bryant, S., et al, Ed., Filsfils, C., Drafz, U., Kompella, V.,
              Regan, J., and S. Amante, "Flow-Aware Transport of
              Pseudowires over an MPLS Packet Switched Network", RFC6391,
              RFC 6391, November 2011

   [RFC4090] Pan, P., et al, "Fast Reroute Extensions to RSVP-TE for LSP
        Tunnels", RFC4090, May 2005 2011.

   [RFC6718]  Muley, P., et al, Aissaoui, M., and M. Bocci, "Pseudowire
              Redundancy", RFC6718, RFC 6718, August
        2012 2012.

10.  Contributors

   The editors gratefully acknowledge the following additional co-
   authors:  Mustapha Aissaoui, Nabil Bitar, Mike Loomis, David McDysan,
   Chris Metz, Andy Malis, Jason Rusmeisel, Himanshu Shah, Jeff
   Sugimoto.

11. Acknowledgements

   The editors also gratefully acknowledge the input of the following
   people:  Mike Duckett, Paul Doolan, Pranjal Dutta, Prayson Pate, Ping
   Pan, Vasile Radoaca, Yeongil Seo, Yetik Serbest, Yuichiro Wada.

12. Author's Addresses

   Luca Martini
   Cisco Systems, Inc.
   9155 East Nichols Avenue, Suite 400
   Englewood, CO, 80112
   e-mail: lmartini@cisco.com

   Matthew Bocci
   Alcatel-Lucent,
   Voyager Place
   Shoppenhangers Road
   Maidenhead
   Berks, UK
   e-mail: matthew.bocci@alcatel-lucent.com

   Florin Balus
   Alcatel-Lucent
   701 E. Middlefield Rd.
   Mountain View, CA 94043
   e-mail: florin.balus@alcatel-lucent.com people for their
   contributions to this document:

   Nabil Bitar
   Verizon
   40 Sylvan Road
   Waltham, MA  02145
   e-mail:
   US

   EMail: nabil.bitar@verizon.com

   Himanshu Shah
   Ciena Corp Corp.
   35 Nagog Park, Park
   Acton, MA  01720
   e-mail:
   US

   EMail: hshah@ciena.com

   Mustapha Aissaoui
   Alcatel-Lucent
   600 March Road
   Kanata
   ON, Canada
   e-mail:

   EMail: mustapha.aissaoui@alcatel-lucent.com

   Jason Rusmisel
   Alcatel-Lucent
   600 March Road
   Kanata
   ON, Canada
   e-mail:

   EMail: Jason.rusmisel@alcatel-lucent.com

   Andrew G. Malis
   Huawei
   2330 Central Expressway
   Santa Clara Clara, CA  95050
   e-mail:
   US

   EMail: agmalis@gmail.com
   Chris Metz
   Cisco Systems, Inc.
   3700 Cisco Way
   San Jose, Ca. CA  95134
   e-mail:
   US

   EMail: chmetz@cisco.com

   David McDysan
   Verizon
   22001 Loudoun County Pkwy Pkwy.
   Ashburn, VA, USA VA  20147
   e-mail:
   US

   EMail: dave.mcdysan@verizon.com

   Jeff Sugimoto
   Alcatel-Lucent
   701 E. Middlefield Rd.
   Mountain View, CA  94043
   e-mail:
   US

   EMail: jeffery.sugimoto@alcatel-lucent.com

   Mike Loomis Loomis
   Alcatel-Lucent
   701 E. Middlefield Rd.
   Mountain View, CA  94043
   US

   EMail: mike.loomis@alcatel-lucent.com

11.  Acknowledgements

   The editors also gratefully acknowledge the input of the following
   people:  Paul Doolan, Mike Duckett, Pranjal Dutta, Ping Pan, Prayson
   Pate, Vasile Radoaca, Yeongil Seo, Yetik Serbest, and Yuichiro Wada.

Authors' Addresses

   Luca Martini (editor)
   Cisco Systems, Inc.
   9155 East Nichols Avenue, Suite 400
   Englewood, CO  80112
   US

   EMail: lmartini@cisco.com

   Matthew Bocci (editor)
   Alcatel-Lucent
   Voyager Place
   Shoppenhangers Road
   Maidenhead
   Berks, UK

   EMail: matthew.bocci@alcatel-lucent.com

   Florin Balus (editor)
   Alcatel-Lucent
   701 E. Middlefield Rd.
   Mountain View, CA  94043
   e-mail: mike.loomis@alcatel-lucent.com

Copyright Notice

   Copyright (c) 2014 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.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008. The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

   Expiration Date: September 2014
   US

   EMail: florin@nuagenetworks.net