Dynamic Placement of Multi Segment Pseudowires
draft-ietf-pwe3-dynamic-ms-pw-17

quot;.
       -ii. Check that a PSN tunnel exists to the next hop S-PE or T-PE.
            If no tunnel exists to the next hop S-PE or T-PE the S-PE
            MAY attempt to setup a PSN tunnel.

Martini, et al.                                                [Page 13]
Internet Draft    draft-ietf-pwe3-dynamic-ms-pw-17.txt     June 19, 2013

      -iii. Check that a PSN tunnel exists to the previous hop. If no
            tunnel exists to the previous hop S-PE or T-PE the S-PE MAY
            attempt to setup a PSN tunnel.
       -iv. If the S-PE cannot get enough PSN resources to setup the
            segment to the next or previous S-PE or T-PE, a label
            release MUST be returned to the T-PE with a status message
            of "Resources Unavailable".
        -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. Allocate a new PW label for the forward direction.
      -vii. Install the FEC for the forward direction.
     -viii. Send the label mapping message with the new forward label
            and the FEC to the next hop S-PE/T-PE.

   For the reverse direction:
        -i. Install the received FEC for the reverse direction.
       -ii. Determine the next signaling hop by referencing the LDP
            sessions used to setup the PW in the Forward direction.
      -iii. Allocate a new PW label for the reverse direction.
       -iv. Install the FEC for the reverse direction.
        -v. Send the label mapping message with a new label and the FEC
            to the next hop S-PE/ST-PE.

7. Failure Handling Procedures

7.1. PSN Failures

   Failures of the PSN tunnel MUST be handled by PSN mechanisms. If the
   PSN is unable to re-establish the PSN tunnel, then the S-PE SHOULD
   follow the procedures defined in Section 8 of [RFC6073].

7.2. S-PE Specfic 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 such
   "LOOP_DETECTED", "PW_LOOP_DETECTED", "RESOURCE_UNAVAILBALE",
   "BAD_STRICT_HOP", "AII_UNREACHABLE" etc. All these failure codes
   indicate a generic class of PW failures at an S-PE or T-PE.

   When an unsolicited label release message with such a failure status
   code is received at T-PE then the T-PE MUST re-attempt to establish
   the PW immediately. However the T-PE MUST throttle its PW setup
   message retry attempts with an exponential backoff in situations

Martini, et al.                                                [Page 14]
Internet Draft    draft-ietf-pwe3-dynamic-ms-pw-17.txt     June 19, 2013

   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. If label release is received from an S-PE or T-PE in the
            forward signaling direction then S-PE MUST tear down both
            segments of the PW. The status code received in label
            release SHOULD be propagated while sending label release for
            the next-segment.
       -ii. If the label release is received from an S-PE or T-PE in the
            reverse Signaling direction do as follows:

            If the PW is set-up at S-PE with an Explicit Intent of Role
            then label release MUST be sent to the next PW segment with
            same status code. The forward signaling path SHOULD NOT be
            tear down in such case.

            If the PW is set-up at S-PE without an Explicit Intent of
            Role then tear down both segments of the PW as described in
            i.

7.3. PW Reachability Changes

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

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

   If there is a change in the L2 PW reachability information in the
   forward direction at S-PE, the S-PE MAY elect to tear down the MS-PW
   in both directions. A label withdrawal is sent on each direction
   followed by a unsolicited label release. The unsolicited label
   releases MUST be accompanied by the Status code "AII_UNREACHABLE".
   This procedure is OPTIONAL.

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

Martini, et al.                                                [Page 15]
Internet Draft    draft-ietf-pwe3-dynamic-ms-pw-17.txt     June 19, 2013

8. Operations and Maintenance (OAM)

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

   In the case of a MS-PW where the PW Endpoints are identified though
   using a globally unique, FEC 129-based AII addresses, there is no
   PWID defined on a per segment basis. Each individual PW segment is
   identified by the address of adjacent S-PE(s) in conjunction with the
   SAI and TAI. In this case, the following type MUST be used in place
   of type 0x01 in the PW switching point TLV:

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

   The above field MUST be included together with type 0x02 in the TLV
   once per individual PW Switching Point following the same rules and
   procedures as described in [RFC6073]. A more detailed description of
   this field is also in setion 7.4.1 of [RFC6073]

9. Security Considerations

   This document specifies only extensions to the protocols already
   defined in [RFC4447], and [RFC6073]. Each such protocol may have its
   own set of security issues, but those issues are not affected by the
   extensions specified herein. Note that the protocols for dynamically
   distributing PW Layer 2 reachability information may have their own
   security issues, however those protocols specifications are outside
   the scope of this document.

10. IANA Considerations

   IANA needs to correct a minor error in the registry "Pseudowire
   Switching Point PE sub-TLV Type". The entry 0x06 "L2 PW address of
   the PW Switching Point" should have Length 14.

Martini, et al.                                                [Page 16]
Internet Draft    draft-ietf-pwe3-dynamic-ms-pw-17.txt     June 19, 2013

10.1. LDP TLV TYPE NAME SPACE

   This document uses several new LDP TLV types, IANA already maintains
   a registry of name "TLV TYPE NAME SPACE" defined by RFC5036. The
   following values are suggested for assignment:

      TLV type  Description
       0x096E   Bandwidth TLV

10.2. LDP Status Codes

   This document uses several new LDP status codes, IANA already
   maintains a registry of name "STATUS CODE NAME SPACE" defined by
   RFC5036. The following values have been pre-allocated:

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

10.3. BGP SAFI

   IANA needs to allocate a new BGP SAFI for "Network Layer Reachability
   Information used for Dynamic Placement of Multi-Segment Pseudiwires"
   from the IANA "Subsequence Address Family Identifiers (SAFI)"
   registry. The following value has been pre-allocated:

   Value    Description                                     Reference
   -----    -----------                                     ---------
   6        Network Layer Reachability Information used [RFCxxxx]
            for Dynamic Placement of Multi-Segment
            Pseudowires

11. Normative References

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

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

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

Martini, et al.                                                [Page 17]
Internet Draft    draft-ietf-pwe3-dynamic-ms-pw-17.txt     June 19, 2013

   [RFC4447] "Pseudowire Setup and Maintenance Using the Label
        Distribution Protocol (LDP)", Martini L.,et al, RFC 4447,
        June 2005.

   [RFC5003] "Attachment Individual Identifier (AII) Types for
        Aggregation", Metz, et al, RFC5003, September 2007

12. Informative References

   [RFC5254] Martini et al, "Requirements for Multi-Segment Pseudowire
        Emulation Edge-to-Edge (PWE3)",
        RFC5254, Bitar, Martini, Bocci, October 2008

   [RFC5659] Bocci at al, "An Architecture for Multi-Segment Pseudo Wire
        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.

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

13. 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

Martini, et al.                                                [Page 18]
Internet Draft    draft-ietf-pwe3-dynamic-ms-pw-17.txt     June 19, 2013

   Florin Balus
   Alcatel-Lucent
   701 E. Middlefield Rd.
   Mountain View, CA 94043
   e-mail: florin.balus@alcatel-lucent.com

   Nabil Bitar
   Verizon
   40 Sylvan Road
   Waltham, MA 02145
   e-mail: nabil.bitar@verizon.com

   Himanshu Shah
   Ciena Corp
   35 Nagog Park,
   Acton, MA 01720
   e-mail: hshah@ciena.com

   Mustapha Aissaoui
   Alcatel-Lucent
   600 March Road
   Kanata
   ON, Canada
   e-mail: mustapha.aissaoui@alcatel-lucent.com

   Jason Rusmisel
   Alcatel-Lucent
   600 March Road
   Kanata
   ON, Canada
   e-mail: Jason.rusmisel@alcatel-lucent.com

   Yetik Serbest
   SBC Labs
   9505 Arboretum Blvd.
   Austin, TX 78759
   e-mail: Yetik_serbest@labs.sbc.com

Martini, et al.                                                [Page 19]
Internet Draft    draft-ietf-pwe3-dynamic-ms-pw-17.txt     June 19, 2013

   Andrew G. Malis
   Verizon
   117 West St.
   Waltham, MA 02451
   e-mail: andrew.g.malis@verizon.com

   Chris Metz
   Cisco Systems, Inc.
   3700 Cisco Way
   San Jose, Ca. 95134
   e-mail: chmetz@cisco.com

   David McDysan
   Verizon
   22001 Loudoun County Pkwy
   Ashburn, VA, USA 20147
   e-mail: dave.mcdysan@verizon.com

   Jeff Sugimoto
   Alcatel-Lucent
   701 E. Middlefield Rd.
   Mountain View, CA 94043
   e-mail: jeffery.sugimoto@alcatel-lucent.com

   Mike Duckett
   Bellsouth
   Lindbergh Center D481
   575 Morosgo Dr
   Atlanta, GA  30324
   e-mail: mduckett@bellsouth.net

   Mike Loomis
   Alcatel-Lucent
   701 E. Middlefield Rd.
   Mountain View, CA 94043
   e-mail: mike.loomis@alcatel-lucent.com

Martini, et al.                                                [Page 20]
Internet Draft    draft-ietf-pwe3-dynamic-ms-pw-17.txt     June 19, 2013

   Paul Doolan
   Mangrove Systems
   IO Fairfield Blvd
   Wallingford, CT, USA 06492
   e-mail: pdoolan@mangrovesystems.com

   Ping Pan
   Hammerhead Systems
   640 Clyde Court
   Mountain View, CA, USA 94043
   e-mail: ppan@hammerheadsystems.com

   Prayson Pate
   Overture Networks, Inc.
   507 Airport Blvd, Suite 111
   Morrisville, NC, USA 27560
   e-mail: prayson.pate@overturenetworks.com

   Vasile Radoaca
   Alcatel-Lucent
   Optics Divison, Westford, MA, USA
   email: vasile.radoaca@alcatel-lucent.com

   Yuichiro Wada
   NTT Communications
   3-20-2 Nishi-Shinjuku, Shinjuke-ku
   Tokyo 163-1421, Japan
   e-mail: yuichiro.wada@ntt.com

   Yeongil Seo
   Korea Telecom Corp.
   463-1 Jeonmin-dong, Yusung-gu
   Daejeon, Korea
   e-mail: syi1@kt.co.kr

Martini, et al.                                                [Page 21]
Internet Draft    draft-ietf-pwe3-dynamic-ms-pw-17.txt     June 19, 2013

Copyright Notice

   Copyright (c) 2012 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: December 2013

Martini, et al.                                                [Page 22]