[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-muley-pwe3-redundancy) 00 01 02 03 04 05 06 07 08 09 RFC 6718

Network Working Group                          Praveen Muley, Ed.
Internet Draft                            Mustapha Aissaoui, Ed.
Intended Status: Informational                   Matthew Bocci, Ed.
Expires: March 2012                               Alcatel-Lucent

                                            September 22, 2011

                    Pseudowire Redundancy
               draft-ietf-pwe3-redundancy-05.txt

Abstract
  This document describes a framework comprised of a number of
  scenarios and associated requirements for pseudowire (PW)
  redundancy. A set of redundant PWs is configured between provider
  edge (PE) nodes in single segment PW applications, or between
  Terminating PE nodes in Multi-Segment PW applications. In order for
  the PE/T-PE nodes to indicate the preferred PW to use for forwarding
  PW packets to one another, a new PW status is required to indicate
  the preferential forwarding status of active or standby for each PW
  in the redundancy set.

Status of this Memo

  This Internet-Draft is submitted 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/1id-abstracts.html

  The list of Internet-Draft Shadow Directories can be accessed at
  http://www.ietf.org/shadow.html

  This Internet-Draft will expire on December 30, 2011




Muley et al.         Expires March 22, 2012              [Page 1]


Internet-Draft        Pseudowire Redundancy      September 22, 2011

Copyright Notice

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

Requirements Language
  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 [1].

Table of Contents
     Copyright Notice.....................................2
  1. Introduction.........................................3
  2. Terminology.........................................3
  3. Reference Models.....................................5
     3.1. PE Architecture..................................5
     3.2. PW Redundancy Network Reference Scenarios.............5
       3.2.1. Single Multi-Homed CE.........................5
       3.2.2. Multiple Multi-homed CEs.......................7
     3.3. Single Homed CE with MS-PW redundancy................9
     3.4. PW redundancy between MTU-s in H-VPLS...............10
     3.5. PW redundancy between VPLS n-PEs...................11
     3.6. PW redundancy in VPLS Bridge Module Model............11
  4. Generic PW redundancy requirements......................13
     4.1. Protection switching requirements..................13
     4.2. Operational requirements..........................13
  5. Security Considerations...............................14
  6. IANA considerations..................................14
  7. Major Contributing Authors............................15
  8. Acknowledgments.....................................15
  9. References.........................................16
     9.1. Normative References.............................16


Muley et al.         Expires March 22, 2012              [Page 2]


Internet-Draft        Pseudowire Redundancy      September 22, 2011

     9.2. Informative References...........................16
  Author's Addresses.....................................17


1. Introduction
  The objective of PW redundancy is to provide sparing of attachment
  circuits (ACs), Provider Edge nodes (PEs), and Pseudowires (PWs) to
  eliminate single points of failure, while ensuring that only one
  active path between a pair of Customer Edge nodes (CEs).
  In single-segment PW (SS-PW) applications, protection for the PW is
  provided by the PSN layer. This may be a Resource Reservation
  Protocol with Traffic Engineering (RSVP-TE) labeled switched path
  (LSP) with a fast-Reroute (FRR) backup or an end-to-end backup LSP.
  PSN protection mechanisms cannot protect against failure of the a PE
  node or the failure of the remote AC. Typically, this is supported
  by dual-homing a Cutomer Edge (CE) node to different PE nodes which
  provide a pseudowire emulated service across the PSN. A set of PW
  mechanisms is theerfore required that enables a primary and one or
  more backup backup PWs to terminate on different PE nodes.
  In multi-segment PW (MS-PW) applications, PSN protection mechanisms
  cannot protect against the failure of a switching PE (S-PE). A set
  of mechanisms that support the operation of a primary and one or
  more backup PWs via a diferent set of S-PEs is therefore required.
  The paths of these PWs are diverse in the sense that they are
  switched at different S-PE nodes.
  In both of these applications, PW redundancy is important to
  maximise the resiliency of the emulated service.
  This document describes framework for these applications and its
  associated operational requirements. The framework utilizes a new PW
  status, called the Preferential Forwarding Status of the PW. This is
  separate from the operational states defined in RFC4447 [2]. The
  mechanisms for PW redundancy are modeled on general protection
  switching principles.

2. Terminology
  o UP PW:  A PW which has been configured (label mapping exchanged
     between PEs) and s not in any of the PW defect states specified
     in [2]. Such a PW is available for forwarding traffic.


Muley et al.         Expires March 22, 2012              [Page 3]


Internet-Draft        Pseudowire Redundancy      September 22, 2011

  o DOWN PW: A PW that has either not been fully configured, or has
     been configured and is in any one of the PW defect states
     specified in [2]. Such a PW is not available for forwarding
     traffic.
  o Active PW.  An UP PW used for forwarding user, OAM and control
     plane traffic.
  o Standby PW. An UP PW that is not used for forwarding user traffic
     but may forward OAM and specific control plane traffic.
  o PW Endpoint: A PE where a PW terminates on a point where Native
     Service Processing is performed, e.g., A Single Segment PW (SS-
     PW) PE, a Multi-Segment Pseudowire (MS-PW) Terminating PE (T-PE),
     or a Hierarchical VPLS MTU-s or PE-rs.
  o Primary PW: the PW which a PW endpoint activates (i.e. uses for
     forwarding) in preference to any other PW when more than one PW
     qualifies for active state. When the primary PW comes back up
     after a failure and qualifies for the active state, the PW
     endpoint always reverts to it. The designation of Primary is
     performed by local configuration for the PW at the PE.
  o Secondary PW: when it qualifies for the active state, a Secondary
     PW is only selected if no Primary PW is configured or if the
     configured primary PW does not qualify for active state (e.g., is
     DOWN). By default, a PW in a redundancy PW set is considered
     secondary. There is no Revertive mechanism among secondary PWs.
  o Revertive protection switching. Traffic will be carried by
     primary PW if it is UP and a wait-to-restore timer expires and
     primary PW is made the Active PW.
  o Non-revertive protection switching. Traffic will be carried by
     the last PW  selected as a result of previous active PW entering
     Operationally DOWN state.
  o Manual selection of PW. The ability for the operator to manually
     select the primary/secondary PWs.
  This document uses the term 'PE' to be synonymous with both PEs as
         per RFC3985 and T-PEs as per RFC5659.
  This document uses the term 'PW' to be synonymous with both PWs as
         per RFC3985 and SS-PWs, MS-PWs, S-PEs, PW-segment and  PW
         switching point as per RFC5659.


Muley et al.         Expires March 22, 2012              [Page 4]


Internet-Draft        Pseudowire Redundancy      September 22, 2011

3. Reference Models
  Following sections describe show the reference architecture of the
  PE for PW redundancy and its usage in different topologies and
  applications.

3.1. PE Architecture
  Figure 1 shows the PE architecture for PW redundancy, when more than
  one PW in a redundant set is associated with a single AC. This is
  based on the architecture in Figure 4b of RFC3985 [3]. The forwarder
  selects which of the redundant PWs to use based on the criteria
  described in this document.
             +----------------------------------------+
             |                PE Device               |
             +----------------------------------------+
    Single   |                 |        Single        | PW Instance
     AC      |                 +      PW Instance     X<===========>
             |                 |                      |
             |                 |----------------------|
     <------>o                 |        Single        | PW Instance
             |    Forwarder    +      PW Instance     X<===========>
             |                 |                      |
             |                 |----------------------|
             |                 |        Single        | PW Instance
             |                 +      PW Instance     X<===========>
             |                 |                      |
             +----------------------------------------+

            Figure 1 PE architecture for PW redundancy
3.2. PW Redundancy Network Reference Scenarios
  This section presents a set of reference scenarios for PW
  redundancy.
3.2.1. Single Multi-Homed CE
  The following figure illustrates an application of single segment
  pseudowire redundancy. This scenario is designed to protect the
  emulated service against a failure of one of the PEs or ACs attached
  to the multi-homed CE. Protection against failures of the PSN
  tunnels is provided using PSN mechanisms such as MPLS Fast Reroute,
  so that these failures do not impact the PW.


Muley et al.         Expires March 22, 2012              [Page 5]


Internet-Draft        Pseudowire Redundancy      September 22, 2011

  CE1 is dual-homed to PE1 and PE3. A dual homing control protocol,
  the details of which are outside the scope of this document, selects
  which AC CE1 should use to forward towards the PSN, and which PE
  (PE1 or PE3) should forward towards CE1.

           |<-------------- Emulated Service ---------------->|
           |                                                  |
           |          |<------- Pseudo Wire ------>|          |
           |          |                            |          |
           |          |    |<-- PSN Tunnels-->|    |          |
           |          V    V                  V    V          |
           V    AC    +----+                  +----+     AC   V
     +-----+    |     | PE1|==================|    |     |    +-----+
     |     |----------|....|...PW1.(active)...|....|----------|     |
     |     |          |    |==================|    |          | CE2 |
     | CE1 |          +----+                  |PE2 |          |     |
     |     |          +----+                  |    |          +-----+
     |     |          |    |==================|    |
     |     |----------|....|...PW2.(standby)..|    |
     +-----+    |     | PE3|==================|    |
                AC    +----+                  +----+

          Figure 2 PW Redundancy with one Multi-Homed CE
  In this scenario, only one of the PWs should be used for forwarding
  between PE1 / PE3, and PE2. PW redundancy determines which PW to
  make active based on the forwarding state of the ACs so that only
  one path is available from CE1 to CE2.
  Consider the example where the AC from CE1 to PE1 is initially
  active and the AC from CE1 to PE3 is initially standby. PW1 is made
  active and PW2 is made standby in order to complete the path to CE2.
  On failure of the AC between CE1 and PE1, the forwarding state of
  the AC on PE3 transitions to Active. The preferential forwarding
  state of PW2 therefore needs to become active, and PW1 standby, in
  order to reestablish connectivity between CE1 and CE2. PE3 therefore
  uses PW2 to forward towards CE2, and PE2 uses PW2 instead of PW1 to
  forward towards CE1. PW redundancy in this scenario requires that
  the forwarding status of the ACs at PE1 and PE3 be signaled to PE2
  so that PE2 can choose which PW to make active.
  Changes occurring on the dual homed side of network due to a failure
  of the AC or PE are not propagated to the ACs on the other side of


Muley et al.         Expires March 22, 2012              [Page 6]


Internet-Draft        Pseudowire Redundancy      September 22, 2011

  the network. Furthermore, failures in the PSN are not be propagated
  to the attached CEs.

3.2.2. Multiple Multi-homed CEs
  This scenario, illustrated in Figure 3, is also designed to protect
  the emulated service against failures of the ACs and failures of the
  PEs. Here, both CEs, CE1 and CE2, are dual-homed to their respective
  PEs, PE1 and PE2, and PE3 and PE4. The method used by the CEs to
  choose which AC to use to forward traffic towards the PSN is
  determined by a dual-homing control protocol. The details of this
  protocol are outside the scope of this document.
  Note that the PSN tunnels are not shown in this figure for clarity.
  However, it can be assumed that each of the PWs shown is
  encapsulated in a separate PSN tunnel. Protection against failures
  of the PSN tunnels is provided using PSN mechanisms such as MPLS
  Fast Reroute, so that these failures do not impact the PW.

        |<-------------- Emulated Service ---------------->|
        |                                                  |
        |          |<------- Pseudowire ------->|          |
        |          |                            |          |
        |          |    |<-- PSN Tunnels-->|    |          |
        |          V    V                  V    V          |
        V    AC    +----+                  +----+     AC   V
  +-----+    |     |....|.......PW1........|....|     |    +-----+
  |     |----------| PE1|......   .........| PE3|----------|     |
  | CE1 |          +----+      \ /  PW3    +----+          | CE2 |
  |     |          +----+       X          +----+          |     |
  |     |          |    |....../ \..PW4....|    |          |     |
  |     |----------| PE2|                  | PE4|--------- |     |
  +-----+    |     |....|.....PW2..........|....|     |    +-----+
             AC    +----+                  +----+     AC


        Figure 3                    Multiple Multi-homed CEs with SS-PW redundancy

  PW1 and PW4 connect PE1 to PE3 and PE4, respectively. Similarly, PE2
  has PW2 and PW3 connect PE2 to PE4 and PE3. PW1, PW2, PW3 and PW4
  are all UP. In order to support N:1 or 1:1 protection, only one PW


Muley et al.         Expires March 22, 2012              [Page 7]


Internet-Draft        Pseudowire Redundancy      September 22, 2011

  MUST be selected to forward traffic. This document defines an
  additional PW that reflects this forwarding state, which is separate
  from the operational status of the PW. This is the 'Preferential
  Forwarding Status'.
  If a PW has a preferential forwarding status of 'active', it can be
  used for forwarding traffic. The actual UP PW chosen by the combined
  set of PEs that interconnect the CEs is determined by considering
  the preferential forwarding status of each PW at each PE. The
  mechanisms for achieving this selection are outside the scope of
  this document. Only one PW is used for forwarding.
  The following failure scenario illustrates the operation of PW
  redundancy in Figure 2. In the initial steady state, when there are
  no failures of the ACs, one of the PWs is chosen as the active PW,
  and all others are chosen as standby. The dual-homing protocol
  between CE1 and PE1/PE2 chooses to use the AC to PE2, while the
  protocol between CE2 and PE3/PE4 chooses to use the AC to PE4.
  Therefore the PW between PE2 and PE4 is chosen as the active PW to
  complete the path between CE1 and CE2.
  On failure of the AC between the dual-homed CE1 and PE2, the
  preferential forwarding status of the PWs at PE1, PE2, PE3 and PE4
  needs to change so as to re-establish a path from CE1 to CE2.
  Different mechanisms can beused to achieve this and these are beyond
  the scope of this document. After the change in status the algorithm
  for selection of PW needs to revaluate and select PW to forward
  traffic. In this application each dual-homing algorithm, i.e., {CE1,
  PE1, PE2} and {CE2, PE3, PE4}, selects the active AC independently.
  There is therefore a need to signal the active status of each AC
  such that the PEs can select a common active PW for forwarding
  between CE1 and CE2.
  Changes occurring on one side of network due to a failure of the AC
  or PE are not propagated to the ACs on the other side of the
  network. Furthermore, failures in the PSN are not be propagated to
  the attached CEs.
  Note that End-to-end native service protection switching can also be
  used to protect the emulated service in this scenario. In this case,
  PW3 and PW4 are not necessary.

  If the CEs do not perform native service protection switching, they
  may instead may use load balancing across the paths between the CEs.


Muley et al.         Expires March 22, 2012              [Page 8]


Internet-Draft        Pseudowire Redundancy      September 22, 2011

3.3. Single Homed CE with MS-PW redundancy
  This application is shown in Figure 4. The main objective is to
  protect the emulated service against failures of the S-PEs.
      Native   |<----------- Pseudowires ----------->|  Native
      Service  |                                     |  Service
       (AC)    |     |<-PSN1-->|     |<-PSN2-->|     |  (AC)
         |     V     V         V     V         V     V   |
         |     +-----+         +-----+         +-----+   |
  +----+ |     |T-PE1|=========|S-PE1|=========|T-PE2|   |   +----+
  |    |-------|......PW1-Seg1.......|.PW1-Seg2......|-------|    |
  | CE1|       |     |=========|     |=========|     |       | CE2|
  |    |       +-----+         +-----+         +-----+       |    |
  +----+        |.||.|                          |.||.|       +----+
                |.||.|         +-----+          |.||.|
                |.||.|=========|     |========== .||.|
                |.||...PW2-Seg1......|.PW2-Seg2...||.|
                |.| ===========|S-PE2|============ |.|
                |.|            +-----+             |.|
                |.|============+-----+============= .|
                |.....PW3-Seg1.|     | PW3-Seg2......|
                 ==============|S-PE3|===============
                               |     |
                               +-----+

  Figure 4 Single homed CE with multi-segment pseudowire redundancy
  CE1 is connected to PE1 and CE2 to PE2, respectively. There are
  three multi-segment PWs. PW1 is switched at S-PE1, PW2 is switched
  at S-PE2, and PW3 is switched at S-PE3.
  Since there is no multi-homing running on the ACs, the T-PE nodes
  would advertise 'Active' for the forwarding status based on a
  priority for the PW. Priorities associate meaning of 'primary PW'
  and 'secondary PW'. These priorities MUST be used in revertive mode
  as well and paths must be switched accordingly. The priority can be
  configuration or derivation from the PWid. Lower the PWid higher the
  priority. However, this does not guarantee selection of same PW by
  the T-PEs because, for example, mismatch of the configuration of the
  PW priority in each T-PE. The intent of this application is to have
  T-PE1 and T-PE2 synchronize the transmit and receive paths of the PW
  over the network. In other words, both T-PE nodes are required to
  transmit over the PW segment which is switched by the same S-PE.
  This is desirable for ease of operation and troubleshooting.



Muley et al.         Expires March 22, 2012              [Page 9]


Internet-Draft        Pseudowire Redundancy      September 22, 2011

3.4. PW redundancy between MTU-s in H-VPLS
  Following figure illustrates the application of use of PW redundancy
  to Hierarchical VPLS (H-VPLS). Here, and MTU-s is dual-homed to two
  PE-rs.

                    |<-PSN1-->|     |<-PSN2-->|
                    V         V     V         V
              +-----+         +-----+
              |MTU-s|=========|PE1  |========
              |..Active PW group....| H-VPLS-core
              |     |=========|     |=========
              +-----+         +-----+
                 |.|
                 |.|           +-----+
                 |.|===========|     |==========
                 |...Standby PW group|.H-VPLS-core
                  =============|  PE2|==========
                               +-----+

            Figure 5  Multi-homed MTU-s in H-VPLS core
  In Figure 5, the MTU-s is dual homed to PE1 and PE2 and has spoke
  PWs to each of them. The MTU-s needs to choose only one of the spoke
  PWs ( the active PW) to one of the PE to forward the traffic and the
  other to standby status. The MTU-s can derive the status of the PWs
  based on local policy configuration. PE1 and PE2 are connected to
  the H-VPLS core on the other side of network. The MTU-s communicates
  the status of its member PWs for a set of VSIs having common status
  of Active or Standby. Here the MTU-s controls the selection of PWs
  to forward the traffic. Signaling using PW grouping with a common
  group-id in PWid FEC Element or Grouping TLV in Generalized PWid FEC
  Element as defined in [2] to PE1 and PE2 respectively, is
  recommended to scale better.
  Whenever MTU-s performs a switchover, it needs to communicate to PE2
  for the Standby PW group the changed status of active.
  In this scenario, PE devices are aware of switchovers at MTU-s and
  could generate MAC Withdraw Messages to trigger MAC flushing within
  the H-VPLS full mesh. By default, MTU-s devices should still trigger
  MAC Withdraw messages as currently defined in [5] to prevent two
  copies of MAC withdraws to be sent (one by MTU-s and another one by
  PEs). Mechanisms to disable MAC Withdraw trigger in certain devices
  is out of the scope of this document.


Muley et al.         Expires March 22, 2012             [Page 10]


Internet-Draft        Pseudowire Redundancy      September 22, 2011

3.5. PW redundancy between VPLS n-PEs
  Following figure illustrates the application of use of PW redundancy
  for dual homed connectivity between PE devices in a ring topology.
            +-------+                     +-------+
            |  PE1  |=====================|  PE2  |====...
            +-------+    PW Group 1       +-------+
                ||                            ||
  VPLS Domain A ||                            || VPLS Domain B
                ||                            ||
            +-------+                     +-------+
            |  PE3  |=====================|  PE4  |==...
            +-------+    PW Group 2       +-------+
              Figure 6   Redundancy in Ring topology
  In Figure 6, PE1 and PE3 from VPLS domain A are connected to PE2 and
  PE4 in VPLS domain B via PW group 1 and group 2. Each of the PEs in
  the respective domains is connected to each other as well as forming
  the ring topology. Such scenarios may arise in inter-domain H-VPLS
  deployments where rapid spanning tree (RSTP) or other mechanisms may
  be used to maintain loop free connectivity of PW groups.
  [5] outlines multi-domain VPLS services without specifying how
  multiple redundant border PEs per domain per VPLS instance can be
  supported. In the example above, PW group 1 may be blocked at PE1 by
  RSTP and it is desirable to block the group at PE2 by virtue of
  exchanging the PW preferential forwarding status of Standby. How the
  PW grouping should be done here is again deployment specific and is
  out of scope of the solution.
3.6. PW redundancy in VPLS Bridge Module Model





Muley et al.         Expires March 22, 2012             [Page 11]


Internet-Draft        Pseudowire Redundancy      September 22, 2011

  ----------------------------+  Provider  +------------------------
                              .   Core     .
                  +------+    .            .    +------+
                  | n-PE |======================| n-PE |
       Provider   | (P)  |---------\    /-------| (P)  |  Provider
       Access     +------+    ._    \  /   .    +------+  Access
       Network                .      \/    .              Network
         (1)      +------+    .      /\    .    +------+     (2)
                  | n-PE |----------/  \--------| n-PE |
                  |  (B) |----------------------| (B)  |_
                  +------+    .            .    +------+
                              .            .
  ----------------------------+            +------------------------
                    Figure 7   Bridge Module Model
  In Figure 7, two provider access networks, each having two n-PEs,
  where the n-PEs are connected via a full mesh of PWs for a given
  VPLS instance. As shown in the figure, only one n-PE in each access
  network is serving as a Primary PE (P) for that VPLS instance and
  the other n-PE is serving as the backup PE (B). In this figure, each
  primary PE has two active PWs originating from it. Therefore, when a
  multicast, broadcast, and unknown unicast frame arrives at the
  primary n-PE from the access network side, the n-PE replicates the
  frame over both PWs in the core even though it only needs to send
  the frames over a single PW (shown with == in the figure) to the
  primary n-PE on the other side. This is an unnecessary replication
  of the customer frames that consumes core-network bandwidth (half of
  the frames get discarded at the receiving n-PE). This issue gets
  aggravated when there is three or more n-PEs per provider, access
  network. For example if there are three n-PEs or four n-PEs per
  access network, then 67% or 75% of core-BW for multicast, broadcast
  and unknown unicast are respectively wasted.



Muley et al.         Expires March 22, 2012             [Page 12]


Internet-Draft        Pseudowire Redundancy      September 22, 2011

  In this scenario, n-PEs can disseminate the status of PWs
  active/standby among them and furthermore to have it tied up with
  the redundancy mechanism such that per VPLS instance the status of
  active/backup n-PE gets reflected on the corresponding PWs emanating
  from that n-PE.
4. Generic PW redundancy requirements
4.1. Protection switching requirements
  o Protection architecture such as N:1,1:1 or 1+1 can be used. N:1
     protection case is somewhat inefficient in terms of capacity
     consumption hence implementations SHOULD support this method
     while  1:1 being subset and efficient MUST be supported. 1+1
     protection architecture can be supported but is left for further
     study.
  o Non-revertive mode MUST be supported, while revertive mode is an
     optional one.
  o Protection switchover can be operator driven like Manual
     lockout/force switchover or due to signal failure. Both methods
     MUST be supported and signal failure MUST be given higher
     priority than any local or far end request.
4.2.  Operational requirements
  o (T-)PEs involved in protecting a PW SHOULD automatically discover
     and attempt to resolve inconsistencies in the configuration of
     primary/secondary PW.
  o (T-)PEs involved in protecting a PW SHOULD automatically discover
     and attempt to resolve inconsistencies in the configuration of
     revertive/non-revertive protection switching mode.
  o (T-)PEs that do not automatically discover or resolve
     inconsistencies in the configuration of primary/secondary,
     revertive/non-revertive, or other parameters MUST generate an
     alarm upon detection of an inconsistent configuration.
  o (T-)PEs involved with protection switching MUST support the
     configuration of revertive or non-revertive protection switching
     mode.
  o (T-)PEs involved with protection switching SHOULD support the
     local invocation of protection switching.


Muley et al.         Expires March 22, 2012             [Page 13]


Internet-Draft        Pseudowire Redundancy      September 22, 2011

  o (T-)PEs involved with protection switching SHOULD support the
     local invocation of a lockout of protection switching.
  o In standby status PW can still receive packets in order to avoid
     black holing of in-flight packets during switchover. However in
     case of use of VPLS application packets are dropped in standby
     status except for the OAM packets.

5. Security Considerations
  This document expects extensions to LDP that are needed for
  protecting pseudo-wires. It will have the same security properties
  as in LDP [4] and the PW control protocol [2].
6. IANA considerations
  This document has no actions for IANA.

























Muley et al.         Expires March 22, 2012             [Page 14]


Internet-Draft        Pseudowire Redundancy      September 22, 2011

7. Major Contributing Authors
The editors would like to thank Pranjal Kumar Dutta, Marc Lasserre,
Jonathan Newton, Hamid Ould-Brahim, Olen Stokes, Dave Mcdysan, Giles
Heron and Thomas Nadeau who made a major contribution to the
development of this document.

  Pranjal Dutta
  Alcatel-Lucent
  Email: pranjal.dutta@alcatel-lucent.com

  Marc Lasserre
  Alcatel-Lucent
  Email: marc.lasserre@alcatel-lucent.com

  Jonathan Newton
  Cable & Wireless
  Email: Jonathan.Newton@cw.com

  Olen Stokes
  Extreme Networks
  Email: ostokes@extremenetworks.com

  Hamid Ould-Brahim
  Nortel
  Email: hbrahim@nortel.com

  Dave McDysan
  Verizon
  Email: dave.mcdysan@verizon.com

  Giles Heron
  Cisco Systems
  Email: giles.heron@gmail.com                                     Formatted:                                                                  Field Code      Thomas Nadeau                                                  Formatted:      Computer Associates                                             Formatted:      Email: tnadeau@lucidvision.com

8. Acknowledgments
  The authors would like to thank Vach Kompella, Kendall Harvey,
  Tiberiu Grigoriu, Neil Hart, Kajal Saha, Florin Balus and Philippe
  Niger for their valuable comments and suggestions.


Muley et al.         Expires March 22, 2012             [Page 15]


Internet-Draft        Pseudowire Redundancy      September 22, 2011

9. References
9.1. Normative References
  [1]  Bradner, S., "Key words for use in RFCs to Indicate
       Requirement Levels", BCP 14, RFC 2119, March 1997.
  [2]  Martini, L., et al., "Pseudowire Setup and Maintenance using
       LDP", RFC 4447, April 2006.
  [3]  Bryant, S., et al., " Pseudo Wire Emulation Edge-to-Edge
       (PWE3) Architecture", RFC 3985 March 2005
  [4]  Andersson, L., Minei, I., and B. Thomas, "LDP Specification",
       RFC 5036, January 2001
  [5]  Kompella,V., Lasserrre, M. , et al., "Virtual Private LAN
       Service (VPLS) Using LDP Signalling", RFC 4762, January 2007
9.2. Informative References
  [6]  Martini, L., et al., "Segmented Pseudo Wire", RFC6073, January
       2011.





















Muley et al.         Expires March 22, 2012             [Page 16]


Internet-Draft        Pseudowire Redundancy      September 22, 2011

Author's Addresses
  Praveen Muley
  Alcatel-Lucent
  701 E. Middlefiled Road
  Mountain View, CA, USA
  Email: Praveen.muley@alcatel-lucent.com

  Mustapha Aissaoui
  Alcatel-Lucent
  600 March Rd
  Kanata, ON, Canada K2K 2E6
  Email: mustapha.aissaoui@alcatel-lucent.com

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

























Muley et al.         Expires March 22, 2012             [Page 17]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/