PW Endpoint Fast Failure Protection
draft-ietf-pals-endpoint-fast-protection-00

PCE working group                                               D. Lopez
Internet-Draft                                            Telefonica I+D
Intended status: Standards Track                                   Q. Wu
Expires: February 14, 2015                                      D. Dhody
                                                                  Huawei
                                                                 D. King
                                                      Old Dog Consulting
                                                         August 13, 2014

IGP extension for PCEP security capability support in the PCE discovery
                draft-wu-pce-discovery-pceps-support-01

Abstract

   When a Path Computation Element (PCE) is a Label Switching Router
   (LSR) participating in the Interior Gateway Protocol (IGP), or even a
   server participating in IGP, its presence and path computation
   capabilities can be advertised using IGP flooding.  The IGP
   extensions for PCE discovery (RFC 5088 and RFC 5089) define a method
   to advertise path computation capabilities using IGP flooding for
   OSPF and IS-IS respectively.  However these specifications lack a
   method to advertise PCEP security (e.g., Transport Layer
   Security(TLS)) support capability.

   This document proposes new capability flag bit for PCE-CAP-FLAGS sub-
   TLV that can be announced as attribute in the IGP advertisement to
   distribute PCEP security support information.

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).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on February 14, 2015.

Lopez, et al.           Expires February 14, 2015               [Page 1]
Internet-Draft       IGP discovery for PCEP Security         August 2014

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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions used in this document . . . . . . . . . . . . . .   3
   3.  IGP extension for PCEP security capability support  . . . . .   3
     3.1.  Use of PCEP security capability support for PCE discovery   3
   4.  Backward Compatibility Consideration  . . . . . . . . . . . .   4
   5.  Management Considerations . . . . . . . . . . . . . . . . . .   4
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   5
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   5

1.  Introduction

   As described in [RFC5440], PCEP communication privacy is one
   importance issue, as an attacker that intercepts a Path Computation
   Element (PCE) message could obtain sensitive information related to
   computed paths and resources.

   Among the possible solutions mentioned in these documents, Transport
   Layer Security (TLS) [RFC5246] provides support for peer
   authentication, and message encryption and integrity.  In order for a
   Path Computation Client(PCC) to begin a connection with a PCE server
   using TLS, PCC SHOULD know whether PCE server supports TLS as a
   secure transport.

   [RFC5088] and [RFC5089] define a method to advertise path computation
   capabilities using IGP flooding for OSPF and IS-IS respectively.
   However [RFC5088] and [RFC5089] lacks a method to advertise PCEP
   security (e.g., TLS) support capability.

Lopez, et al.           Expires February 14, 2015               [Page 2]
Internet-Draft       IGP discovery for PCEP Security         August 2014

   This document proposes new capability flag bits for PCE-CAP-FLAGS
   sub- TLV that can be announced as attributes in the IGP advertisement
   (defined in [RFC5088] and [RFC5089]) to distribute PCEP security
   support information.

2.  Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL&Yimin Shen, et al.      Expires November 7, 2015               [Page 21]
Internet-Draft     PW Endpoint Fast Failure Protection          May 2015

   the primary PE, the TLV SHOULD carry the context identifier of the
   {primary PE, protector}. In the centralized protector model, the TLV
   SHOULD carry to the backup PE multiple context identifiers, one for
   each {primary PE, protector} where the backup PE serves as a backup
   for the primary PE.  This TLV SHOULD NOT be advertised by the primary
   PE or the backup PE to the protector.

   The processing of the Egress Protection Capability TLV by a receiving
   router SHOULD follow the procedures defined in RFC 5561.  In
   particular, the router SHOULD advertise PW information to the
   protector by using the Protection FEC Element TLV, only after it has
   received the Egress Protection Capability TLV from the protector.  It
   SHOULD validate each context identifier included in the TLV, and
   advertise the information of only those PWs that are associated with
   the context identifier.  It SHOULD withdraw previously advertised
   Protection FEC TLVs, when the protector has withdrawn a previously
   advertised context identifier or the entire Egress Protection
   Capability TLV via Capability message.

   The encoding of the Egress Protection Capability TLV is defined as
   below.  It conforms to the format of Capability Parameter TLV
   specified in RFC 5561.

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |U|F|  Egress Protection (TBD)  |              Length           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |S| Reserved    |                                               |
     +-+-+-+-+-+-+-+-+                                               |
     |                                                               |
     ~                Capability Data = context identifier(s)        ~
     |                                                               |
     |                                               +-+-+-+-+-+-+-+-+
     |                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 11

   The U-bit MUST be set to 1 so that a receiver MUST silently ignore
   this TLV if unknown to it, and continue processing the rest of the
   message.

   The F-bit MUST be set to 0 since this TLV is sent only in
   Initialization and Capability messages, which are not forwarded.

   The TLV Code Point is TBD.  It needs to be assigned by IANA.

Yimin Shen, et al.      Expires November 7, 2015               [Page 22]
Internet-Draft     PW Endpoint Fast Failure Protection          May 2015

   The S-bit indicates whether the sender is advertising (S=1) or
   withdrawing (S=0) the capability.

   The "Capability Data" is encoded with the context identifier of the
   {primary PE, protector}.

6.2.  PW Label Distribution from Primary PE to Protector

   A primary PE SHOULD advertise a primary PW's label to a protector by
   sending a Label Mapping message.  The message includes a Protection
   FEC Element TLV (see Section 6.4 for encoding), and an Upstream-
   Assigned Label TLV (RFC 6389) encoded with the PW's label.  The
   combination of the Protection FEC Element TLV and the PW label
   represents the primary PE's forwarding state for the PW.  The Label
   Mapping message SHOULD also carry an IPv4/v6 Interface_ID TLV (RFC
   6389, RFC 3471) encoded with the context identifier of the {primary
   PE, protector}.

   The protector that receives this Label Mapping message SHOULD install
   a forwarding entry for the PW label in the label space identified by
   the context identifier.  The nexthop of the forwarding entry SHOULD
   ensure packets to be sent towards the target CE via a backup AC or a
   backup (S-)PE, depending on the protection scenario.  The protector
   SHOULD silently discard a Label Mapping message if the included
   context identifier is unknown to it.

6.3.  PW Label Distribution from Backup PE to Protector

   In the centralized protector model, a backup PE SHOULD advertise a
   backup PW's label to a protector by sending a Label Mapping message.
   The message includes a Protection FEC Element TLV and a Generic Label
   TLV encoded with the backup PW's label.  This Protection FEC Element
   MUST be identical to the Protection FEC Element TLV that the primary
   PE advertises to the protector (Section 6.2).  The context identifier
   SHOULD NOT be encoded in Interface_ID TLV in this message.

   The protector that receives this Label Mapping message SHOULD
   associate the backup PW with the primary PW, based on the common
   Protection FEC Element TLV.  It SHOULD distinguish between the Label
   Mapping message from the primary PE and the Label Mapping message
   from the backup PE based on the respective presence and absence of
   context identifier in Interface_ID TLV.  It SHOULD install a
   forwarding entry for the primary PW's label in the label space
   identified by the context identifier.  The nexthop of the forwarding
   entry SHOULD indicate a label swap to the backup PW's label, followed
   by a label push or IP header push for a transport tunnel to the
   backup PE.

Yimin Shen, et al.      Expires November 7, 2015               [Page 23]
Internet-Draft     PW Endpoint Fast Failure Protection          May 2015

6.4.  Protection FEC Element TLV

   The Protection FEC Element TLV has type 0x83.  Its format is defined
   as below:

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Type(0x83)  |    Reserved   | Encoding Type |    Length     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                                                               |
     ~                         PW Information                        ~
     |                                                               |
     |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 12

   - Encoding Type

      Type of format that PW Information field is encoded.

   - Length

      Length of PW Information field in octets.

   - PW Information

      Field of variable length that specifies a PW

   For Encoding Type, 1 is defined for the PWid FEC Element format, and
   2 is defined for the Generalized PWid FEC Element format (RFC 4447).

6.4.1.  Encoding Format for PWid

Yimin Shen, et al.      Expires November 7, 2015               [Page 24]
Internet-Draft     PW Endpoint Fast Failure Protection          May 2015

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Type(0x83)  |    Reserved   |  Enc Type(1)  |   Length(16)  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      Ingress PE Address                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       Egress PE Address                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                            Group ID                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                             PW ID                             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |C|           PW Type           |           Reserved            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 13

   - Ingress PE Address

      IP address of the ingress PE of PW.

   - Egress PE Address

      IP address of the egress PE of PW.

   - Group ID

      An arbitrary 32-bit value that represents a group of PWs and that
      is used to create groups in the PW space.

   - PW ID

      A non-zero 32-bit connection ID that, together with the PW Type
      field, identifies a particular PW.

   - Control word bit (C)

      A bit that flags the presence of a control word on this PW.  If C
      = 1, control word is present; If C = 0, control word is not
      present.

   - PW Type

      A 15-bit quantity that represents the type of PW.

Yimin Shen, et al.      Expires November 7, 2015               [Page 25]
Internet-Draft     PW Endpoint Fast Failure Protection          May 2015

6.4.2.  Encoding Format for Generalized PWid

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Type(0x83)  |    Reserved   |  Enc Type(2)  |   Length      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      Ingress PE Address                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       Egress PE Address                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |C|           PW Type           |           Reserved            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   AGI Type    |    Length     |      Value                    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~                    AGI  Value (contd.)                        ~
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   AII Type    |    Length     |      Value                    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~                   SAII  Value (contd.)                        ~
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   AII Type    |    Length     |      Value                    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~                   TAII Value (contd.)                         ~
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 14

   - Ingress PE Address

      IP address of the ingress PE of PW.

   - Egress PE Address

      IP address of the egress PE of PW.

   - Control word bit (C)

      A bit that flags the presence of a control word on this PW.  If C
      = 1, control word is present; If C = 0, control word is not
      present.

   - PW Type

      A 15-bit quantity that represents the type of PW.

Yimin Shen, et al.      Expires November 7, 2015               [Page 26]
Internet-Draft     PW Endpoint Fast Failure Protection          May 2015

   - AGI Type, Length, Value, AGI Value

      Attachment Group Identifier of PW.

   - SAII Type, Length, Value, SAII Value

      Source Attachment Individual Identifier of PW.

   - TAII Type, Length, Value, TAII Value

      Target Attachment Individual Identifier of PW.

7.  IANA Considerations

   This document defines the encoding of the Capability Parameter TLV
   for the new "Egress Protection Capability" in Section 6.  This would
   require IANA to assign a TLV Code Point to it.

   This document defines a new LDP Protection FEC Element TLV in
   Section 6.  IANA has assigned the type value 0x83 to it.

8.  Security Considerations

   The security considerations discussed in RFC 5036, RFC 5331, RFC
   3209, and RFC 4090 apply to this document.

9.  Acknowledgements

   This document leverages work done by Hannes Gredler, Yakov Rekhter,
   Minto Jeyananth, Kevin Wang and several on MPLS edge protection.
   Thanks to Nischal Sheth and Bhupesh Kothari for their contribution.
   Thanks to John E Drake, Andrew G Malis, Alexander Vainshtein, and
   Steward Bryant for valuable comments that helped shape this document
   and improve its clarity.

10.  References

10.1.  Normative References

   [RFC3985]  Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-
              Edge (PWE3) Architecture", RFC 3985, March 2005.

   [RFC5659]  Bocci, M. and S. Bryant, "An Architecture for Multi-
              Segment Pseudowire Emulation Edge-to-Edge", RFC 5659,
              October 2009.

Yimin Shen, et al.      Expires November 7, 2015               [Page 27]
Internet-Draft     PW Endpoint Fast Failure Protection          May 2015

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

   [RFC5331]  Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream
              Label Assignment and Context-Specific Label Space", RFC
              5331, August 2008.

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

   [RFC5561]  Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL.
              Le Roux, "LDP Capabilities", RFC 5561, July 2009.

   [RFC2205]  Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
              Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
              Functional Specification", RFC 2205, September 1997.

   [RFC3209]  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
              and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
              Tunnels", RFC 3209, December 2001.

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

   [RFC5286]  Atlas, A. and A. Zinin, "Basic Specification for IP Fast
              Reroute: Loop-Free Alternates", RFC 5286, September 2008.

   [RFC5714]  Shand, M. and S. Bryant, "IP Fast Reroute Framework", RFC
              5714, January 2010.

   [RFC3471]  Berger, L., "Generalized Multi-Protocol Label Switching
              (GMPLS) Signaling Functional Description", RFC 3471,
              January 2003.

   [RFC3472]  Ashwood-Smith, P. and L. Berger, "Generalized Multi-
              Protocol Label Switching (GMPLS) Signaling Constraint-
              based Routed Label Distribution Protocol (CR-LDP)
              Extensions", RFC 3472, January 2003.

   [RFC3031]  Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
              Label Switching Architecture", RFC 3031, January 2001.

   [RFC2328]  Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.

   [RFC5880]  Katz, D. and D. Ward, "Bidirectional Forwarding Detection
              (BFD)", RFC 5880, June 2010.

Yimin Shen, et al.      Expires November 7, 2015               [Page 28]
Internet-Draft     PW Endpoint Fast Failure Protection          May 2015

   [RFC6389]  Aggarwal, R. and JL. Le Roux, "MPLS Upstream Label
              Assignment for LDP", RFC 6389, November 2011.

   [IP-LDP-FRR-MRT]
              Atlas, A. and R. Kebler, "An Architecture for IP/LDP Fast-
              Reroute Using Maximally Redundant Trees", draft-ietf-
              rtgwg-mrt-frr-architecture (work in progress), 2011.

10.2.  Informative References

   [RFC5920]  Fang, L., "Security Framework for MPLS and GMPLS
              Networks", RFC 5920, July 2010.

Authors' Addresses

   Yimin Shen
   Juniper Networks
   10 Technology Park Drive
   Westford, MA  01886
   USA

   Phone: +1 9785890722
   Email: yshen@juniper.net

   Rahul Aggarwal
   Arktan, Inc

   Email: raggarwa_1@yahoo.com

   Wim Henderickx
   Alcatel-Lucent
   Copernicuslaan 50
   2018 Antwerp
   Belgium

   Email: wim.henderickx@alcatel-lucent.be

   Yuanlong Jiang
   Huawei Technologies

   Email: jiangyuanlong@huawei.com

Yimin Shen, et al.      Expires November 7, 2015               [Page 29]