Skip to main content

Traffic Steering using BGP Flowspec with SRv6 Policy
draft-jiang-idr-ts-flowspec-srv6-policy-01

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
Authors Jiang Wenying , Yisong Liu , Yunan Gu
Last updated 2020-11-02 (Latest revision 2020-07-13)
Replaced by draft-ietf-idr-ts-flowspec-srv6-policy, draft-ietf-idr-ts-flowspec-srv6-policy
RFC stream (None)
Formats
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-jiang-idr-ts-flowspec-srv6-policy-01
Network Working Group                                               W. J
Internet-Draft                                                    Y. Liu
Intended status: Standards Track                            China Mobile
Expires: May 6, 2021                                               Y. Gu
                                                                  Huawei
                                                        November 2, 2020

          Traffic Steering using BGP Flowspec with SRv6 Policy
               draft-jiang-idr-ts-flowspec-srv6-policy-01

Abstract

   BGP Flow Specification (FlowSpec) [I-D.ietf-idr-rfc5575bis] has been
   proposed to distribute BGP FlowSpec NLRI to FlowSpec clients to
   mitigate (distributed) denial-of-service attacks, and to provide
   traffic filtering in the context of a BGP/MPLS VPN service.
   Recently, traffic steering applications in the context of SRv6 using
   FlowSpec aslo attract attention.  This document introduces the usage
   of BGP FlowSpec to steer packets into an SRv6 Policy.

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

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

   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 May 6, 2021.

J, et al.                  Expires May 6, 2021                  [Page 1]
Internet-Draft          FlowSpec with SRv6 Policy          November 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.  Definitions and Acronyms  . . . . . . . . . . . . . . . . . .   3
   3.  Operations  . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Application Example . . . . . . . . . . . . . . . . . . . . .   4
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   7.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .   6
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   6
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   Segment Routing IPv6 (SRv6) is a protocol designed to forward IPv6
   data packets on a network using the source routing model.  SRv6
   enables the ingress to add a segment routing header (SRH) [RFC8754]
   to an IPv6 packet and push an explicit IPv6 address stack into the
   SRH.  After receiving the packet, each transit node updates the IPv6
   destination IP address in the packet and segment list to implement
   hop-by-hop forwarding.

   SRv6 Policy [I-D.ietf-spring-segment-routing-policy] is a tunneling
   technology developed based on SRv6.  An SRv6 Policy is a set of
   candidate paths consisting of one or more segment lists, that is,
   segment ID (SID) lists.  Each SID list identifies an end-to-end path
   from the source to the destination, instructing a device to forward
   traffic through the path rather than the shortest path computed using
   an IGP.  The header of a packet steered into an SRv6 Policy is
   augmented with an ordered list of segments associated with that SRv6

J, et al.                  Expires May 6, 2021                  [Page 2]
Internet-Draft          FlowSpec with SRv6 Policy          November 2020

   Policy, so that other devices on the network can execute the
   instructions encapsulated into the list.

   The headend of an SRv6 Policy may learn multiple candidate paths for
   an SRv6 Policy.  Candidate paths may be learned via a number of
   different mechanisms, e.g., CLI, NetConf, PCEP, or BGP.

   [I-D.ietf-idr-rfc5575bis] defines the flow specification (FlowSpec)
   that allows to convey flow specifications and traffic Action/Rules
   associated (rate- limiting, redirect, remark ...).  BGP Flow
   specifications are encoded within the MP_REACH_NLRI and
   MP_UNREACH_NLRI attributes.  Rules (Actions associated) are encoded
   in Extended Community attribute.  The BGP Flow Specification function
   allows BGP Flow Specification routes that carry traffic policies to
   be transmitted to BGP Flow Specification peers to steer traffic.

   This document proposes BGP flow specification usage that are used to
   steer data flow into an SRv6 Policy as well as to indicate Tailend
   function.

2.  Definitions and Acronyms

   o  FlowSpec: Flow Specification

   o  SR: Segment Routing

   o  SRv6: IPv6 Segment Routing

   o  SID: Segment Identifier

   o  SRH: Segment Routing Header

   o  TE: Traffic Engineering

3.  Operations

   An SRv6 Policy [I-D.ietf-spring-segment-routing-policy] is identified
   through the tuple <headend, color, endpoint>.  In the context of a
   specific headend, one may identify an SRv6 policy by the <color,
   endpoint> tuple.  The headend is the node where the SRv6 policy is
   instantiated/implemented.  The headend is specified as an IPv4 or
   IPv6 address and is expected to be unique in the domain.  The
   endpoint indicates the destination of the SRv6 policy.  The endpoint
   is specified as an IPv6 address and is expected to be unique in the
   domain.  The color is a 32-bit numerical value that associates the
   SRv6 Policy, and it defines an application-level network Service
   Level Agreement (SLA) policy.

J, et al.                  Expires May 6, 2021                  [Page 3]
Internet-Draft          FlowSpec with SRv6 Policy          November 2020

   Assume one or multiple SRv6 Policies are already setup in the SRv6
   HeadEnd device.  In order to steer traffic into a specific SRv6
   policy at the Headend, one can use the SRv6 color extended community
   and endpoint to map to a satisfying SRv6 policy, and steer traffic
   into this specific policy.

   [I-D.ietf-idr-flowspec-redirect-ip] defines the redirect to IPv4 and
   IPv6 Next-hop action.  The IPv6 next-hop address in the FlowSpec NLRI
   can be used to specify the endpoint of the SRv6 Policy.  When the
   packets reach to the TailEnd device, some specific function
   imformation identifiers can be used decide how to further process the
   flows.  Several endpoint functions are already defined, e.g.,
   End.DT6: Endpoint with decapsulation and IPv6 table lookup, and
   End.DX6: Endpoint with decapsulation and IPv6 cross-connect.  The BGP
   Prefix-SID defined in [RFC8669] is utilized to enable SRv6 VPN
   services [I-D.ietf-bess-srv6-services].  SRv6 Services TLVs within
   the BGP Prefix-SID Attribute can be used to indicate the endpoint
   functions.

   This document proposes to carry the Color Extended Community and BGP
   Prefix-SID Attribute in the context of a Flowspec NLRI
   [I-D.ietf-idr-rfc5575bis] to an SRv6 Headend to steer traffic into
   one SRv6 policy, as well as to indicate specific Tailend functions.

   In this document, the usage of at most one Color Extended Community
   in combination at most one BGP Prefix SID Attribute is discussed.
   For the case that a flowspec route carries multiple Color Extend
   Communities and/or a BGP Prefix SID Attribute, a protocol extension
   to Flowspec is required, and is thus out of the scope of this
   document.

   However, the method proposed in this document still supports load
   balancing to the tailend device.  To achieve that, the headend device
   CAN set up multiple paths in one SRv6 policy, and use a Flowspec
   route to indicate the specific SRv6 policy.

4.  Application Example

   In following scenario, BGP FlowSpec Controller signals the function
   imformation (SRv6 SID: Service_id_x) to the HeadEnd device.

J, et al.                  Expires May 6, 2021                  [Page 4]
Internet-Draft          FlowSpec with SRv6 Policy          November 2020

      +------------+
      |  BGP FS    |
      | Controller |
      +------------+
         | Flowspec route to HeadEnd:
         |   NLRI: Filter Rules
         |   Redirect to IPv6 Nexthop: TailEnd's Address
         |   Policy Color: C1
         |   PrefixSID: Service_id_x
         |          .-----.
         |         (       )
         V     .--(         )--.
   +-------+  (                 )  +-------+
   |       |_( SRv6 Core Network )_|       |
   |HeadEnd| ( ================> ) |TailEnd|
   +-------+  (SR List<S1,S2,S3>)  +-------+
               '--(         )--'   Service SID: Service_id_x
                   (       )       (e.g.: End.DT4 or End.DT6 or others)
                    '-----'

         Figure 1: Steering the Flow into SRv6 Policy

   When the headend device (as a Flowspec client) receives such
   instructions, it will steer the flows matching the criteria in the
   Flowspec route into the SRv6 Policy matching the tuple (Endpoint:
   TailEnd's Address, Color: C1).  And the packets of such flows will be
   encapsulated with SRH using the SR List<S1, S2, S3, Service_id_x>.
   When the packets reach to the TailEnd device, they will be further
   procetssed per the function denoted by the Service_id_x.

   For the cases of intra-AS and inter-AS traffic steering using this
   method, the usages of Flowspec Color Extended Community with BGP
   prefix SID are the same for both scenarios.  The difference lie
   between the local SRv6 policy configurations.  For the inter-domain
   case, the operator can configure an inter-domain SRv6 policy/path at
   the Headend device.  For the intra-domain case, the operator can
   configure an intra-domain SRv6 policy/path at the Headend device.

5.  IANA Considerations

   No IANA actions are required for this document.

6.  Security Considerations

   This document does not change the security properties of SRv6 and
   BGP.

J, et al.                  Expires May 6, 2021                  [Page 5]
Internet-Draft          FlowSpec with SRv6 Policy          November 2020

7.  Contributors

   The following people made significant contributions to this document:

   Shunwan Zhaung
   Huawei
   Email: zhuangshunwan@huawei.com

   Haibo Wang
   Huawei
   Email: rainsword.wang@huawei.com

   Jie Dong
   Huawei
   Email: jie.dong@huawei.com

8.  Acknowledgements

   TBD

9.  References

9.1.  Normative References

   [I-D.ietf-bess-srv6-services]
              Dawra, G., Filsfils, C., Raszuk, R., Decraene, B., Zhuang,
              S., and J. Rabadan, "SRv6 BGP based Overlay services",
              draft-ietf-bess-srv6-services-04 (work in progress), July
              2020.

   [I-D.ietf-idr-flowspec-redirect-ip]
              Uttaro, J., Haas, J., Texier, M., Andy, A., Ray, S.,
              Simpson, A., and W. Henderickx, "BGP Flow-Spec Redirect to
              IP Action", draft-ietf-idr-flowspec-redirect-ip-02 (work
              in progress), February 2015.

   [I-D.ietf-idr-rfc5575bis]
              Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M.
              Bacher, "Dissemination of Flow Specification Rules",
              draft-ietf-idr-rfc5575bis-26 (work in progress), August
              2020.

   [I-D.ietf-idr-segment-routing-te-policy]
              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-09 (work in progress), May 2020.

J, et al.                  Expires May 6, 2021                  [Page 6]
Internet-Draft          FlowSpec with SRv6 Policy          November 2020

   [I-D.ietf-idr-tunnel-encaps]
              Patel, K., Velde, G., Sangli, S., and J. Scudder, "The BGP
              Tunnel Encapsulation Attribute", draft-ietf-idr-tunnel-
              encaps-19 (work in progress), September 2020.

   [I-D.ietf-spring-segment-routing-policy]
              Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and
              P. Mattes, "Segment Routing Policy Architecture", draft-
              ietf-spring-segment-routing-policy-08 (work in progress),
              July 2020.

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

   [RFC8669]  Previdi, S., Filsfils, C., Lindem, A., Ed., Sreekantiah,
              A., and H. Gredler, "Segment Routing Prefix Segment
              Identifier Extensions for BGP", RFC 8669,
              DOI 10.17487/RFC8669, December 2019,
              <https://www.rfc-editor.org/info/rfc8669>.

9.2.  Informative References

   [RFC4456]  Bates, T., Chen, E., and R. Chandra, "BGP Route
              Reflection: An Alternative to Full Mesh Internal BGP
              (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006,
              <https://www.rfc-editor.org/info/rfc4456>.

   [RFC8754]  Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
              Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
              (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
              <https://www.rfc-editor.org/info/rfc8754>.

Authors' Addresses

   Wenying Jiang
   China Mobile
   Beijing
   China

   Email: jiangwenying@chinamobile.com

J, et al.                  Expires May 6, 2021                  [Page 7]
Internet-Draft          FlowSpec with SRv6 Policy          November 2020

   Yisong Liu
   China Mobile
   Beijing
   China

   Email: liuyisong@chinamobile.com

   Yunan Gu
   Huawei
   Beijing
   China

   Email: guyunan@huawei.com

J, et al.                  Expires May 6, 2021                  [Page 8]