SPRING                                                            Z. Ali
Internet-Draft                                             K. Talaulikar
Intended status: Informational                               C. Filsfils
Expires: November 16, 2020                                     N. Nainar
                                                            C. Pignataro
                                                           Cisco Systems
                                                            May 15, 2020

 Bidirectional Forwarding Detection (BFD) for Segment Routing Policies
                        for Traffic Engineering


   Segment Routing (SR) allows a headend node to steer a packet flow
   along any path using a segment list which is referred to as a SR
   Policy.  Intermediate per-flow states are eliminated thanks to source
   routing.  The header of a packet steered in an SR Policy is augmented
   with the ordered list of segments associated with that SR Policy.
   Bidirectional Forwarding Detection (BFD) is used to monitor different
   kinds of paths between node.  BFD mechanisms can be also used to
   monitor the availability of the path indicated by a SR Policy and to
   detect any failures.  Seamless BFD (S-BFD) extensions provide a
   simplified mechanism which is suitable for monitoring of paths that
   are setup dynamically and on a large scale.

   This document describes the use of Seamless BFD (S-BFD) mechanism to
   monitor the SR Policies that are used for Traffic Engineering (TE) in
   SR deployments.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119 [RFC2119].

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 https://datatracker.ietf.org/drafts/current/.

Ali, et al.             Expires November 16, 2020               [Page 1]

Internet-Draft         BFD for SR Policies for TE               May 2020

   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 November 16, 2020.

Copyright Notice

   Copyright (c) 2020 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
   (https://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.  Choice of S-BFD over BFD  . . . . . . . . . . . . . . . . . .   4
   3.  Procedures  . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  S-BFD Discriminator . . . . . . . . . . . . . . . . . . .   5
     3.2.  S-BFD session Initiation by SBFDInitiator . . . . . . . .   5
     3.3.  Controlled Return Path  . . . . . . . . . . . . . . . . .   6
     3.4.  S-BFD Echo Recommendation . . . . . . . . . . . . . . . .   7
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   6.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .   8
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   8
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   Segment Routing (SR) ([RFC8402]) allows a headend node to steer a
   packet flow along any path for specific objectives like Traffic
   Engineering (TE) and to provide it treatment according to the
   specific established service level agreement (SLA) for it.
   Intermediate per-flow states are eliminated thanks to source routing.
   The headend node steers a flow into an SR Policy.  The header of a

Ali, et al.             Expires November 16, 2020               [Page 2]

Internet-Draft         BFD for SR Policies for TE               May 2020

   packet steered in an SR Policy is augmented with the ordered list of
   segments associated with that SR Policy.  SR Policy
   [I-D.ietf-spring-segment-routing-policy] specifies the concepts of SR
   Policy and steering into an SR Policy.

   SR Policy state is instantiated only on the head-end node and any
   intermediate node or the endpoint node does not require any state to
   be maintained or instantiated for it.  SR Policies are not signaled
   through the network nodes except the signaling required to
   instantiate them on the head-end in the case of a controller based
   deployment.  This enables SR Policies to scale far better than
   previous TE mechanisms.  This also enables SR Policies to be
   instantiated dynamically and on demand basis for steering specific
   traffic flows corresponding to service routes as they are signaled.
   These automatic steering and signaling mechanisms for SR Policies are
   described in SR Policy [I-D.ietf-spring-segment-routing-policy].

   There is a requirement to continuously monitor the availability of
   the path corresponding to the SR Policy along the nodes in the
   network to rapidly detect any failures in the forwarding path so that
   it could take corrective action to restore service.  The corrective
   actions may be either to invalidate the candidate path that has
   experienced failure and to switch to another candidate path within
   the same SR Policy OR to activate another backup SR Policy or
   candidate path for end-to-end path protection.  These mechanisms are
   beyond the scope of this document.

   Bidirectional Forwarding Detection (BFD) mechanisms have been
   specified for use for monitoring of unidirectional MPLS LSPs via BFD
   MPLS [RFC5884].  Seamless BFD [RFC7880] defines a simplified
   mechanism for using BFD by eliminating the negotiation aspect and the
   need to maintain per session state entries on the tail end of the
   policy, thus providing benefits such as quick provisioning, as well
   as improved control and flexibility for network nodes initiating path
   monitoring.  When BFD or S-BFD is used for verification of such
   unidirectional LSP paths, the reverse path is via the shortest path
   from the tail-end router back to the head-end router as determined by

   The SR Policy is essentially a unidirectional path through the
   network.  This document describes the use of BFD and more
   specifically S-BFD for monitoring of SR Policy paths through the
   network.  SR can be instantiated using both MPLS and IPv6 dataplanes.
   The mechanism described in this document applies to both these
   instantiations of SR Policy.

Ali, et al.             Expires November 16, 2020               [Page 3]

Internet-Draft         BFD for SR Policies for TE               May 2020

2.  Choice of S-BFD over BFD

   BFD MPLS [RFC5884] describes a mechanism where LSP Ping [RFC8029] is
   used to bootstrap the BFD session over an MPLS TE LSP path.  The LSP
   Ping mechanism was extended to support SR LSPs via SR LSP Ping
   [RFC8287] and a similar mechanism could have been considered for BFD
   monitoring of SR Policies on MPLS data-plane.  However, this document
   proposes instead to use S-BFD mechanism as it is more suitable for SR

   Some of the key aspects of SR Policies that are considered in
   arriving at this decision are as follows:

   o  SR Policies do not require any signaling to be performed through
      the network nodes in order to be setup.  They are simply
      instantiated on the head-end node via provisioning or even
      dynamically by a controller via BGP SR-TE
      [I-D.ietf-idr-segment-routing-te-policy] or using PCEP (PCEP SR
      [I-D.ietf-pce-segment-routing], PCE Initiated [RFC8281], PCEP
      Stateful [RFC8231]).

   o  SR Policies result in state being instantiated only on the head-
      end node and no other node in the network.

   o  In many deployments, SR Policies are instantiated dynamically and
      on-demand or in the case of automated steering for BGP routes,
      when routes are learnt with specific color communities (refer SR
      Policy [I-D.ietf-spring-segment-routing-policy] for details).

   o  SR Policies are expected to be deployed in much higher scale.

   o  SR Policies can be instantiated both for MPLS and IPv6 data-planes
      and hence a monitoring mechanism which works for both is

   In view of the above, the BFD mechanism to be used for monitoring
   them needs to be simple, lightweight, one that does not result in
   instantiation of per SR Policy state anywhere but the head-end and
   which can be setup and deleted dynamically and on-demand.  The S-BFD
   extensions provide this support as described in Seamless BFD
   [RFC7880].  Furthermore, S-BFD Use-Cases [RFC7882] clarifies the
   applicability in the Centralized TE and SR scenarios.

3.  Procedures

   The general procedures and mechanisms for S-BFD operations are
   specified in Seamless BFD [RFC7880].  This section describes the
   specifics related to S-BFD use for SR Policies.

Ali, et al.             Expires November 16, 2020               [Page 4]

Internet-Draft         BFD for SR Policies for TE               May 2020

   SR Policies are represented on a head-end router as <color,endpoint
   IP address> tuple.  The SRTE process on the head-end determines the
   tail-end node of a SR Policy on the basis of the endpoint IP address.
   In the cases where the SR Policy endpoint is outside the domain of
   the head-end node, this information is available with the centralized
   controller that computed the multi-domain SR Policy path for the

3.1.  S-BFD Discriminator

   In order to enable S-BFD monitoring for a given SR Policy, the S-BFD
   Discriminator for the tail-end node (i.e. one with the endpoint IP
   address) which is going to be the S-BFD Reflector is required.  ISIS
   S-BFD [RFC7883] and OSPF S-BFD [RFC7884] describe the extensions to
   the ISIS and OSPF link state routing protocols that allow all nodes
   to advertise their S-BFD Discriminators across the network.  BGP-LS
   S-BFD [I-D.ietf-idr-bgp-ls-sbfd-extensions] describes extensions for
   advertising the S-BFD discriminators via BGP-LS across domains and to
   a controller.  Thus, either the SRTE head-end node or the controller,
   as the case may be, have the S-BFD Discriminator of the tail-end node
   of the SR Policy available.

   When the end point IP address configured in the SR policy is IPv4, an
   implementation may support the use of end point address as the S-BFD
   Discriminator if SBFDReflector is enabled to associate the end point
   address as Discriminator for the target identifier.

   The selection of S-BFD Discriminator from IGP or end point address is
   a local implementation matter and can be controlled by configuration

3.2.  S-BFD session Initiation by SBFDInitiator

   The SRTE Process can straightaway instantiate the S-BFD mechanism on
   the SR Policy as soon as it is provisioned in the forwarding to start
   verification of the path to the endpoint.  No signaling or
   provisioning is required for the tail-end node on a per SR Policy
   basis and it just performs its role as a stateless S-BFD Reflector.
   The return path used by S-BFD is via the normal IP routing back to
   the head-end node.  Once the specific SR Policy path is verified via
   S-BFD, then it is considered as active and may be used for traffic

   The S-BFD monitoring continues for the SR Policy and any failure is
   notified to the SRTE process.  In response to the failure of a
   specific candidate path, the SRTE process may trigger any of the
   following based on local policy or implementation specific aspects
   which are outside the scope of this document:

Ali, et al.             Expires November 16, 2020               [Page 5]

Internet-Draft         BFD for SR Policies for TE               May 2020

   o  Trigger path-protection for the SR Policy

   o  Declare the specific candidate path as invalid and switch to using
      the next valid candidate path based on preference

   o  If no alternate candidate path is available, then handle the
      steering over that SR Policy based on its invalidation policy
      (e.g. drop or switch to best effort routing).

3.3.  Controlled Return Path

   S-BFD response from SBFDResponder is IP routed and so the procedure
   defined in the above sections will receive the response through
   uncontrolled return path.  S-BFD echo packets with relevant stack of
   segment ID can be used to control the return path.

           /                     \
           \                     /

            Forward Paths: A-B-C-D
            IP Return Paths: D-E-A

            Figure 1: S-BFD Echo Example

   Node A sending S-BFD control packets with segment stack {B, C, D}
   will cause S-BFD control packets to traverse the paths A-B-C-D in the
   forward direction.  The response S-BFD control packets from node D
   back to node A will be IP routed and will traverse the paths D-E-A.
   The SBFDInitiator sending such packets can also send S-BFD echo
   packets with segment stack {B, C, D, C, A}. S-BFD echo packets will
   u-turn on node D and traverse the paths D-C-B-A.  If required, the
   SBFDInitiator can possess multiple types of S-BFD echo packets, with
   each having varying return paths.  In this particular example, the
   SBFDInitiator can be sending two types of S-BFD echo packets in
   addition to S-BFD control packets.

   o  S-BFD Control Packets

      *  Segment Stack: {B, C, D}

      *  Return Path: D->E->A

   o  S-BFD Echo packets #1

Ali, et al.             Expires November 16, 2020               [Page 6]

Internet-Draft         BFD for SR Policies for TE               May 2020

      *  Segment Stack: {B, C, D, C, A}

      *  Return Path: D->C->B->A

   o  S-BFD Echo packets #2

      *  Segment Stack: {B, C, D, G, A}

      *  Return Path: D->G->F->A

   The SBFDInitiator can correlate the result of each packet type to
   determine the nature of the failure.  One such example of failure
   correlation is described in the figure below.

       |   |                      S-BFD Echo Pkt                       |
       |   +------------------------------------+----------------------+
       |   |              Success               |       Failure        |
       | |S|                                    |                      |
       |S|u|                                    |                      |
       |||c|                                    |Forward SID stack good|
       |B|c|             All is well            |Return SID stack bad  |
       |F|e|                                    |Return IP path good   |
       |D|s|                                    |                      |
       | |s|                                    |                      |
       |t|F|Forward SID stack good|             |                      |
       |r|a|Return SID stack good |Send Alert   |                      |
       |l|i|Return IP path bad    |Discrim S-BFD|                      |
       | |l+--------- OR ---------+w/ Forward   |Forward SID stack bad |
       |P|u|Forward SID stack is  |SID stack to |                      |
       |k|r|terminating on wrong  |differentiate|                      |
       |t|e|node                  |             |                      |

           Figure 2: SBFDInitiator Failure Correlation Example

3.4.  S-BFD Echo Recommendation

   o  It is RECOMMENDED to compute and use smallest number of segment
      stack to describe the return path of S-BFD echo packets to prevent
      the segment stack being too large.  How SBFDInitiator determines
      when to use S-BFD echo packets and how to identify corresponding

Ali, et al.             Expires November 16, 2020               [Page 7]

Internet-Draft         BFD for SR Policies for TE               May 2020

      segment stack for the return paths are outside the scope of this

   o  It is RECOMMENDED that SBFDInitiator does not send only S-BFD echo
      packets.  S-BFD echo packets are crafted to traverse the network
      and to come back to self, thus there is no guarantee that S-BFD
      echo are u-turning on the intended remote target.  On the other
      hand, S-BFD control packets can verify that segment stack of the
      forward direction reaches the intended remote target.  Therefore,
      an SBFDInitiator SHOULD send S-BFD control packets when sending
      S-BFD echo packets.

4.  IANA Considerations


5.  Security Considerations

   Procedures described in this document do not affect the BFD or
   Segment Routing security model.  See the 'Security Considerations'
   section of [RFC7880] for a discussion of S-BFD security and to
   [RFC8402] for analysis of security in SR deployments.

6.  Contributors

   Mallik Mudigonda
   Cisco Systems Inc.

   Email: mmudigon@cisco.com

7.  Acknowledgements

8.  References

8.1.  Normative References

              Li, Z., Zhuang, S., Talaulikar, K., Aldrin, S., Tantsura,
              J., and G. Mirsky, "BGP Link-State Extensions for Seamless
              BFD", draft-ietf-idr-bgp-ls-sbfd-extensions-02 (work in
              progress), May 2020.

              Filsfils, C., Sivabalan, S., Voyer, D., Bogdanov, A., and
              P. Mattes, "Segment Routing Policy Architecture", draft-
              ietf-spring-segment-routing-policy-07 (work in progress),
              May 2020.

Ali, et al.             Expires November 16, 2020               [Page 8]

Internet-Draft         BFD for SR Policies for TE               May 2020

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

   [RFC7880]  Pignataro, C., Ward, D., Akiya, N., Bhatia, M., and S.
              Pallagatti, "Seamless Bidirectional Forwarding Detection
              (S-BFD)", RFC 7880, DOI 10.17487/RFC7880, July 2016,

   [RFC7882]  Aldrin, S., Pignataro, C., Mirsky, G., and N. Kumar,
              "Seamless Bidirectional Forwarding Detection (S-BFD) Use
              Cases", RFC 7882, DOI 10.17487/RFC7882, July 2016,

   [RFC7883]  Ginsberg, L., Akiya, N., and M. Chen, "Advertising
              Seamless Bidirectional Forwarding Detection (S-BFD)
              Discriminators in IS-IS", RFC 7883, DOI 10.17487/RFC7883,
              July 2016, <https://www.rfc-editor.org/info/rfc7883>.

   [RFC7884]  Pignataro, C., Bhatia, M., Aldrin, S., and T. Ranganath,
              "OSPF Extensions to Advertise Seamless Bidirectional
              Forwarding Detection (S-BFD) Target Discriminators",
              RFC 7884, DOI 10.17487/RFC7884, July 2016,

   [RFC8402]  Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
              Decraene, B., Litkowski, S., and R. Shakir, "Segment
              Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
              July 2018, <https://www.rfc-editor.org/info/rfc8402>.

8.2.  Informative References

              Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P.,
              Rosen, E., Jain, D., and S. Lin, "Advertising Segment
              Routing Policies in BGP", draft-ietf-idr-segment-routing-
              te-policy-08 (work in progress), November 2019.

              Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W.,
              and J. Hardwick, "PCEP Extensions for Segment Routing",
              draft-ietf-pce-segment-routing-16 (work in progress),
              March 2019.

Ali, et al.             Expires November 16, 2020               [Page 9]

Internet-Draft         BFD for SR Policies for TE               May 2020

   [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, <https://www.rfc-editor.org/info/rfc5884>.

   [RFC8029]  Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N.,
              Aldrin, S., and M. Chen, "Detecting Multiprotocol Label
              Switched (MPLS) Data-Plane Failures", RFC 8029,
              DOI 10.17487/RFC8029, March 2017,

   [RFC8231]  Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path
              Computation Element Communication Protocol (PCEP)
              Extensions for Stateful PCE", RFC 8231,
              DOI 10.17487/RFC8231, September 2017,

   [RFC8281]  Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path
              Computation Element Communication Protocol (PCEP)
              Extensions for PCE-Initiated LSP Setup in a Stateful PCE
              Model", RFC 8281, DOI 10.17487/RFC8281, December 2017,

   [RFC8287]  Kumar, N., Ed., Pignataro, C., Ed., Swallow, G., Akiya,
              N., Kini, S., and M. Chen, "Label Switched Path (LSP)
              Ping/Traceroute for Segment Routing (SR) IGP-Prefix and
              IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data
              Planes", RFC 8287, DOI 10.17487/RFC8287, December 2017,

Authors' Addresses

   Zafar Ali
   Cisco Systems

   Email: zali@cisco.com

   Ketan Talaulikar
   Cisco Systems

   Email: ketant@cisco.com

   Clarence Filsfils
   Cisco Systems

   Email: cfilsfil@cisco.com

Ali, et al.             Expires November 16, 2020              [Page 10]

Internet-Draft         BFD for SR Policies for TE               May 2020

   Nagendra Kumar Nainar
   Cisco Systems

   Email: naikumar@cisco.com

   Carlos Pignataro
   Cisco Systems

   Email: cpignata@cisco.com

Ali, et al.             Expires November 16, 2020              [Page 11]