[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00 01 02 03

Internet Engineering Task Force                              V. Govindan
Internet-Draft                                              M. Mudigonda
Intended status: Standards Track                              A. Sajassi
Expires: January 7, 2017                                   Cisco Systems
                                                               G. Mirsky
                                                                Ericsson
                                                            July 6, 2016


                   Fault Management for EVPN networks
                      draft-gmsm-bess-evpn-bfd-00

Abstract

   This document proposes a proactive, in-band network OAM mechanism to
   detect loss of continuity and miss-connection faults that affect
   unicast and multi-destination paths, used by Broadcast, unknown
   Unicast and Multicast traffic, in an EVPN network.  The mechanisms
   proposed in the draft use the principles of the widely adopted
   Bidirectional Forwarding Detection protocol.

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 January 7, 2017.

Copyright Notice

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



Govindan, et al.         Expires January 7, 2017                [Page 1]


Internet-Draft          Fault management for EVPN              July 2016


   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
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  Scope of the Document . . . . . . . . . . . . . . . . . . . .   3
   3.  Motivation for running BFD at the network layer of EVPN . . .   3
   4.  Fault Detection of unicast traffic  . . . . . . . . . . . . .   4
   5.  Fault Detection of BUM traffic using ingress replication
       (MP2P)  . . . . . . . . . . . . . . . . . . . . . . . . . . .   5
   6.  Fault Detection of BUM traffic using P2MP tunnels (LSM) . . .   5
   7.  BFD packet encapsulation  . . . . . . . . . . . . . . . . . .   5
     7.1.  Using GAL/G-ACh encapsulation without IP headers  . . . .   5
       7.1.1.  Ingress replication . . . . . . . . . . . . . . . . .   5
         7.1.1.1.  Alternative encapsulation format  . . . . . . . .   5
       7.1.2.  LSM . . . . . . . . . . . . . . . . . . . . . . . . .   6
       7.1.3.  Unicast . . . . . . . . . . . . . . . . . . . . . . .   6
         7.1.3.1.  Alternative encapsulation format  . . . . . . . .   6
     7.2.  Using IP headers  . . . . . . . . . . . . . . . . . . . .   7
   8.  Scalability Considerations  . . . . . . . . . . . . . . . . .   7
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   10. Security Considerations . . . . . . . . . . . . . . . . . . .   8
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     11.1.  Normative References . . . . . . . . . . . . . . . . . .   8
     11.2.  Informative References . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   [I-D.salam-l2vpn-evpn-oam-req-frmwk] and
   [I-D.ooamdt-rtgwg-ooam-requirement] outlines the OAM requirements of
   Ethernet VPN networks [RFC7432].  This document proposes mechanisms
   for proactive fault detection at the network(overlay) OAM layer of
   EVPN.  EVPN fault detection mechanisms need to consider unicast and
   Broadcast and unknown Unicast (BUM) traffic separately since they map
   to different FECs in EVPN, hence this document proposes different
   fault detection mechanisms to suit each type using the principles
   of[RFC5880],[RFC5884] and Point-to-multipoint
   BFD[I-D.ietf-bfd-multipoint] and
   [I-D.ietf-bfd-multipoint-active-tail].







Govindan, et al.         Expires January 7, 2017                [Page 2]


Internet-Draft          Fault management for EVPN              July 2016


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

2.  Scope of the Document

   This document proposes proactive fault detection for EVPN [RFC7432]
   using BFD mechanisms for:

   o  Unicast traffic.

   o  BUM traffic using Multi-point-to-Point (MP2P) tunnels (ingress
      replication).

   o  BUM traffic using Point-to-Multipoint (P2MP) tunnels (LSM).

   This document does not discuss BFD mechanisms for:

   o  EVPN variants like PBB-EVPN [RFC7623].  This will be addressed in
      future versions.

   o  IRB solution based on EVPN
      [I-D.ietf-bess-evpn-inter-subnet-forwarding].  This will be
      addressed in future versions.

   o  EVPN using other encapsulations like VxLAN, NVGRE and MPLS over
      GRE [I-D.ietf-bess-evpn-overlay].

   o  BUM traffic using MP2MP tunnels will also be addressed in a future
      version of this document.

   This specification describes procedures only for BFD asynchronous
   mode.  BFD demand mode is outside the scope of this specification.
   Further, the use of the Echo function is outside the scope of this
   specification.

3.  Motivation for running BFD at the network layer of EVPN

   The choice of running BFD at the network layer of the OAM model for
   EVPN [I-D.salam-l2vpn-evpn-oam-req-frmwk] and
   [I-D.ooamdt-rtgwg-ooam-requirement] was made after considering the
   following:

   o  In addition to detecting link failures in the EVPN network, BFD
      sessions at the network layer can be used to monitor the
      successful programming of labels used for setting up MP2P and P2MP



Govindan, et al.         Expires January 7, 2017                [Page 3]


Internet-Draft          Fault management for EVPN              July 2016


      EVPN tunnels transporting Unicast and BUM traffic.  The scope of
      reachability detection covers the ingress and the egress EVPN PE
      nodes and the network connecting them.

   o  Monitoring a representative set of path(s) or a particular path
      among the multiple paths available between two EVPN PE nodes could
      be done by exercising the entropy labels when they are used.
      However paths that cannot be realized by entropy variations cannot
      be monitored.  Fault monitoring requirements outlined by
      [I-D.salam-l2vpn-evpn-oam-req-frmwk] are addressed by the
      mechanisms proposed by this draft.

   Successful establishment and maintenance of BFD sessions between EVPN
   PE nodes does not fully guarantee that the EVPN service is
   functioning.  For example, an egress EVPN-PE can understand the EVPN
   label but could switch data to incorrect interface.  However, once
   BFD sessions in the EVPN Network Layer reach UP state, it does
   provide additional confidence that data transported using those
   tunnels will reach the expected egress node.  When the BFD session in
   EVPN overlay goes down that can be used as indication of the Loss-of-
   Connectivity defect in the EVPN underlay that would cause EVPN
   service failure.

4.  Fault Detection of unicast traffic

   The mechanisms specified in BFD for MPLS LSPs [RFC5884] [RFC7726] can
   be applied to bootstrap and maintain BFD sessions for unicast EVPN
   traffic.  The discriminators required for de-multiplexing the BFD
   sessions MUST be exchanged using EVPN LSP ping specifying the Unicast
   EVPN FEC [I-D.jain-bess-evpn-lsp-ping] before establishing the BFD
   session.  This is needed since the MPLS label stack does not contain
   enough information to disambiguate the sender of the packet.  The
   usage of MPLS entropy labels take care of addressing the requirement
   of monitoring various paths of the multi-path server layer network
   [RFC6790].  Each unique realizable path between the participating PE
   routers MAY be monitored separately when entropy labels are used.
   The multi-path connectivity between two PE routers MUST be tracked by
   at least one representative BFD session, in which case the
   granularity of fault-detection would be coarser.  The PE node
   receiving the EVPN LSP ping MUST allocate BFD discriminators using
   the procedures defined in [RFC7726].  Note that once the BFD session
   for the EVPN label is UP, either end of the BFD session MUST NOT
   change the local discriminator values of the BFD Control packets it
   generates, unless it first brings down the session as specified in
   [RFC5884].






Govindan, et al.         Expires January 7, 2017                [Page 4]


Internet-Draft          Fault management for EVPN              July 2016


5.  Fault Detection of BUM traffic using ingress replication (MP2P)

   Ingress replication uses separate MP2P tunnels for transporting BUM
   traffic from the ingress PE (head) to a set of one or more egress PEs
   (tails).  The fault detection mechanism proposed by this document
   takes advantage of the fact that a unique copy is made by the head
   for each tail.  Another key aspect to be considered in EVPN is the
   advertisement of the inclusive multicast route.  The BUM traffic
   flows from a head node to a particular tail only after the head
   receives the inclusive multicast route containing the BUM EVPN label
   (downstream allocated) corresponding to the MP2P tunnel.  The head-
   end PE performing ingress replication MUST initiate an EVPN LSP ping
   using the inclusive multicast FEC [I-D.jain-bess-evpn-lsp-ping] upon
   receiving an inclusive multicast route from a tail to bootstrap the
   BFD session.  There MAY exist multiple BFD sessions between a head PE
   an individual tail due to the usage of entropy labels [RFC6790] for
   an inclusive multicast FEC.  The PE node receiving the EVPN LSP ping
   MUST allocate BFD discriminators using the procedures defined in
   [RFC7726].  Note that once the BFD session for the EVPN label is UP,
   either end of the BFD session MUST NOT change the local discriminator
   values of the BFD Control packets it generates, unless it first
   brings down the session as specified in [RFC5884].

6.  Fault Detection of BUM traffic using P2MP tunnels (LSM)

   TBD.

7.  BFD packet encapsulation

7.1.  Using GAL/G-ACh encapsulation without IP headers

7.1.1.  Ingress replication

   The packet contains the following labels: LSP label (transport) when
   not using PHP, the optional entropy label, the BUM label and the SH
   label[RFC7432] (where applicable).  The G-ACh type is set to TBD.
   The G-Ach payload of the packet MUST contain the L2 header (in
   overlay space) followed by the IP header encapsulating the BFD
   packet.  The MAC address of the inner packet is used to validate the
   <EVI, MAC> in the receiving node.  The discriminator values of BFD
   are obtained through negotiation through the out-of-band EVPN LSP
   ping.

7.1.1.1.  Alternative encapsulation format

   A new TLV can be defined as proposed in Sec 3 of [RFC6428] to include
   the EVPN FEC information as a TLV following the BFD Control packet.




Govindan, et al.         Expires January 7, 2017                [Page 5]


Internet-Draft          Fault management for EVPN              July 2016


   The format of the TLV can be reused from the EVPN Inclusive Multicast
   sub-TLV proposed by Fig 2 of [I-D.jain-bess-evpn-lsp-ping].

   A new type (TBD3) to indicate the EVPN Inclusive Multicast SubTLV is
   requested from the "CC/ CV MEP-ID TLV" registry [RFC6428].

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0 0 0 1|Version|     Flags     |       BFD CV Code Point TBD2  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      ~                  BFD Control Packet                           ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      ~               EVPN Inclusive Multicast TLV                    ~
      |                 (Type = TBD3)                                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Figure 1: BFD-EVPN CV Message for EVPN Multicast
                     (Ingress Replication)


7.1.2.  LSM

   TBD.

7.1.3.  Unicast

   The packet contains the following labels: LSP label (transport) when
   not using PHP, the optional entropy label and the EVPN Unicast label.
   The G-ACh type is set to TBD.  The G-Ach payload of the packet MUST
   contain the L2 header (in overlay space) followed by the IP header
   encapsulating the BFD packet.  The MAC address of the inner packet is
   used to validate the <EVI, MAC> in the receiving node.  The
   discriminator values of BFD are obtained through negotiation through
   the out-of-band EVPN ping.

7.1.3.1.  Alternative encapsulation format

   A new TLV can be defined as proposed in Sec 3 of [RFC6428] to include
   the EVPN FEC information as a TLV following the BFD Control packet.
   The format of the TLV can be reused from the EVPN MAC sub-TLV
   proposed by Fig 1 of [I-D.jain-bess-evpn-lsp-ping].  A new type
   (TBD4) to indicate the EVPN MAC SubTLV is requested from the "CC/ CV
   MEP-ID TLV" registry [RFC6428].




Govindan, et al.         Expires January 7, 2017                [Page 6]


Internet-Draft          Fault management for EVPN              July 2016


       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0 0 0 1|Version|     Flags     |       BFD CV Code Point TBD2  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      ~                  BFD Control Packet                           ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      ~                           EVPN MAC Sub TLV                    ~
      |                 (Type = TBD4)                                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        Figure 2: BFD-EVPN CV Message for EVPN Unicast


7.2.  Using IP headers

   The encapsulation option using IP headers will not be suited for
   EVPN, as using different values in the destination IP address for
   data and OAM (BFD) packets could cause the BFD packets to follow a
   different path than that of data packets.  Hence this option MUST NOT
   be used for EVPN.

8.  Scalability Considerations

   The mechanisms proposed by this draft could affect the packet load on
   the network and its elements especially when supporting
   configurations involving a large number of EVIs.  The option of
   slowing down or speeding up BFD timer values can be used by an
   administrator or a network management entity to maintain the overhead
   incurred due to fault monitoring at an acceptable level.

9.  IANA Considerations

   IANA is requested for two channel types from the "Pseudowire
   Associated Channel Types" registry in [RFC4385].

      TBD1 BFD-EVPN CC message

      TBD2 BFD-EVPN CV message

   Ed Note: Do we need a CC code point?  TBD

   IANA is requested to allocate the following code-points from the "CC/
   CV MEP-ID TLV" registry [RFC6428].  The parent registry is the
   "Pseudowire Associated Channel Types" registry of [RFC4385] .  All



Govindan, et al.         Expires January 7, 2017                [Page 7]


Internet-Draft          Fault management for EVPN              July 2016


   code points within this registry shall be allocated according to the
   "Standards Action" procedures as specified in [RFC5226].  The items
   tracked in the registry will be the type, associated name, and
   reference.  The requested values are:

      TBD3 - CV code-point for BFD EVPN Inclusive multicast.

      TBD4 - CV code-point for BFD EVPN Unicast.

10.  Security Considerations

   TBD.

11.  References

11.1.  Normative References

   [I-D.ietf-bess-evpn-inter-subnet-forwarding]
              Sajassi, A., Salam, S., Thoria, S., Rekhter, Y., Drake,
              J., Yong, L., and L. Dunbar, "Integrated Routing and
              Bridging in EVPN", draft-ietf-bess-evpn-inter-subnet-
              forwarding-01 (work in progress), October 2015.

   [I-D.ietf-bess-evpn-overlay]
              Sajassi, A., Drake, J., Bitar, N., Shekhar, R., Uttaro,
              J., and W. Henderickx, "A Network Virtualization Overlay
              Solution using EVPN", draft-ietf-bess-evpn-overlay-04
              (work in progress), June 2016.

   [I-D.ietf-bfd-multipoint]
              Katz, D., Ward, D., and J. Networks, "BFD for Multipoint
              Networks", draft-ietf-bfd-multipoint-08 (work in
              progress), April 2016.

   [I-D.ietf-bfd-multipoint-active-tail]
              Katz, D., Ward, D., and J. Networks, "BFD Multipoint
              Active Tails.", draft-ietf-bfd-multipoint-active-tail-02
              (work in progress), May 2016.

   [I-D.jain-bess-evpn-lsp-ping]
              Jain, P., Boutros, S., and S. Salam, "LSP-Ping Mechanisms
              for EVPN and PBB-EVPN", draft-jain-bess-evpn-lsp-ping-03
              (work in progress), May 2016.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.



Govindan, et al.         Expires January 7, 2017                [Page 8]


Internet-Draft          Fault management for EVPN              July 2016


   [RFC4385]  Bryant, S., Swallow, G., Martini, L., and D. McPherson,
              "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for
              Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385,
              February 2006, <http://www.rfc-editor.org/info/rfc4385>.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              DOI 10.17487/RFC5226, May 2008,
              <http://www.rfc-editor.org/info/rfc5226>.

   [RFC5880]  Katz, D. and D. Ward, "Bidirectional Forwarding Detection
              (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
              <http://www.rfc-editor.org/info/rfc5880>.

   [RFC5884]  Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow,
              "Bidirectional Forwarding Detection (BFD) for MPLS Label
              Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884,
              June 2010, <http://www.rfc-editor.org/info/rfc5884>.

   [RFC6428]  Allan, D., Ed., Swallow, G., Ed., and J. Drake, Ed.,
              "Proactive Connectivity Verification, Continuity Check,
              and Remote Defect Indication for the MPLS Transport
              Profile", RFC 6428, DOI 10.17487/RFC6428, November 2011,
              <http://www.rfc-editor.org/info/rfc6428>.

   [RFC6790]  Kompella, K., Drake, J., Amante, S., Henderickx, W., and
              L. Yong, "The Use of Entropy Labels in MPLS Forwarding",
              RFC 6790, DOI 10.17487/RFC6790, November 2012,
              <http://www.rfc-editor.org/info/rfc6790>.

   [RFC7432]  Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
              Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based
              Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February
              2015, <http://www.rfc-editor.org/info/rfc7432>.

   [RFC7623]  Sajassi, A., Ed., Salam, S., Bitar, N., Isaac, A., and W.
              Henderickx, "Provider Backbone Bridging Combined with
              Ethernet VPN (PBB-EVPN)", RFC 7623, DOI 10.17487/RFC7623,
              September 2015, <http://www.rfc-editor.org/info/rfc7623>.

   [RFC7726]  Govindan, V., Rajaraman, K., Mirsky, G., Akiya, N., and S.
              Aldrin, "Clarifying Procedures for Establishing BFD
              Sessions for MPLS Label Switched Paths (LSPs)", RFC 7726,
              DOI 10.17487/RFC7726, January 2016,
              <http://www.rfc-editor.org/info/rfc7726>.






Govindan, et al.         Expires January 7, 2017                [Page 9]


Internet-Draft          Fault management for EVPN              July 2016


11.2.  Informative References

   [I-D.ooamdt-rtgwg-ooam-requirement]
              Kumar, N., Pignataro, C., Kumar, D., Mirsky, G., Chen, M.,
              Nordmark, E., Networks, J., and D. Mozes, "Overlay OAM
              Requirements", draft-ooamdt-rtgwg-ooam-requirement-00
              (work in progress), March 2016.

   [I-D.salam-l2vpn-evpn-oam-req-frmwk]
              Salam, S., Sajassi, A., Aldrin, S., and J. Drake, "E-VPN
              Operations, Administration and Maintenance Requirements
              and Framework", draft-salam-l2vpn-evpn-oam-req-frmwk-02
              (work in progress), January 2014.

Authors' Addresses

   Vengada Prasad Govindan
   Cisco Systems

   Email: venggovi@cisco.com


   Mudigonda Mallik
   Cisco Systems

   Email: mmudigon@cisco.com


   Ali Sajassi
   Cisco Systems

   Email: sajassi@cisco.com


   Gregory Mirsky
   Ericsson

   Email: gregory.mirsky@ericsson.com













Govindan, et al.         Expires January 7, 2017               [Page 10]


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