| Internet-Draft | BGP Flow Specification for SRv6 | October 2024 |
| Li, et al. | Expires 18 April 2025 | [Page] |
This document proposes extensions to BGP Flow Specification for SRv6 for filtering packets with a SRv6 SID that matches a sequence of conditions.¶
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 BCP 14 [RFC2119][RFC8174] when, and only when, they appear in all capitals, as shown here.¶
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 18 April 2025.¶
Copyright (c) 2024 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
[RFC8955] describes in details about a new BGP NLRI to distribute a flow specification, which is an n-tuple comprising a sequence of matching criteria that can be applied to IP traffic. [RFC8956] extends [RFC8955] to make it also usable and applicable to IPv6 data packets. [I-D.ietf-idr-flowspec-l2vpn] extends the flow-spec rules for layer 2 Ethernet packets. [I-D.ietf-idr-flowspec-v2] specifies BGP Flow Specification Version 2.¶
Segment Routing (SR) for unicast traffic has been proposed to cope with the usecases in traffic engineering, fast re-reroute, service chain, etc. SR architecture can be implemented over an IPv6 data plane using a new type of IPv6 extension header called Segment Routing Header (SRH) [RFC8754]. SRv6 Network Programming [RFC8986] defines the SRv6 network programming concept and its most basic functions. An SRv6 SID may have the form of LOC:FUNCT:ARG::.¶
LOC: Each operator is free to use the locator length it chooses. Most often the LOC part of the SID is routable and leads to the node which instantiates that SID.¶
FUNCT: The FUNCT part of the SID is an opaque identification of a local function bound to the SID. E.g., End.X, End.T, End.DX2, etc.¶
ARG: A function may require additional arguments that would be placed immediately after the FUNCT.¶
This document specifies one new BGP Flow Specification (FS) component type to support Segment Routing over IPv6 data plane (SRv6) filtering for BGP Flow Specification Version 2. The match field is destination address of IPv6 header, but it's a SRv6 SID from SRH rather than a traditional IPv6 address (refer to Figure 1). To support these features, a Flowspec version that is IPv6 capable (i.e., AFI = 2) MUST be used. These match capabilities of the features MAY be permitted to match when there is an accompanying SRH.¶
+-----------------------------+
IPv6 Header| SA | DA |<--Match field of this document
+--------------------^--------+
|
+--------------------|--------+
| +-------------+ | +-------------------+
| | Segment[0] +-------> Loc | Func | Arg |
| +-------------+ | +-------------------+
| | Segment[1] | |
| +-------------+ |
| | ... | |
SR Header| +-------------+ |
| | Segment[n] | |
| +-------------+ |
| +-------------+ |
| ~ Option TLV ~ |
| +-------------+ |
+-----------------------------+
The Flow Specification NLRI-type consists of several optional components, each of which begins with a type field (1 octet) followed by a variable length parameter. 13 component types are defined in [RFC8955] and [RFC8956] for IPv4 and IPv6. This document defines one component type for SRv6.¶
[RFC8986] defines the format of SID is LOC:FUNCT:ARG::. In some scenarios, traffic packets can just match Locator, Function ID, Arguments or some combinations of these different fields. In order to match a part of SID, its prior parts need to be examined and matched first. For example, in order to match the Function ID (FUNCT), the Locator (LOC) needs to be examined and matched first. The new component type TBD1 defined below is for matching some parts of SID.¶
Encoding: <type, LOC-Len, FUNCT-Len, ARG-Len, [op, value]+>¶
The total of three lengths (i.e., LOC length + FUNCT length + ARG length) MUST NOT be greater than 128. If it is greater than 128, an error occurs and Error Handling is applied according to [RFC7606] and [RFC4760].¶
The operator (op) byte is encoded as:¶
0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | e | a | field type|lt |gt |eq | +---+---+---+---+---+---+---+---+¶
where the behavior of each operator bit has clear symmetry with that of [RFC8955]'s Numeric Operator field.¶
e - end-of-list bit. Set in the last {op, value} pair in the sequence.¶
a - AND bit. If unset, the previous term is logically ORed with the current one. If set, the operation is a logical AND. It should be unset in the first operator byte of a sequence. The AND operator has higher priority than OR for the purposes of evaluating logical expressions.¶
field type:¶
For an unknown type, Error Handling is applied according to [RFC7606] and [RFC4760].¶
lt - less than comparison between data' and value'.¶
gt - greater than comparison between data' and value'.¶
eq - equality between data' and value'.¶
The data' and value' used in lt, gt and eq are indicated by the field type in a operator and the value field following the operator.¶
The value field depends on the field type and has the value of SID's some parts rounding up to bytes (refer to the table below).¶
+-----------------------+------------------------------+ | Field Type | Value | +=======================+==============================+ | SID's LOC | value of LOC bits | +-----------------------+------------------------------+ | SID's FUNCT | value of FUNCT bits | +-----------------------+------------------------------+ | SID's ARG | value of ARG bits | +-----------------------+------------------------------+ | SID's LOC:FUNCT | value of LOC:FUNCT bits | +-----------------------+------------------------------+ | SID's FUNCT:ARG | value of FUNCT:ARG bits | +-----------------------+------------------------------+ | SID's LOC:FUNCT:ARG | value of LOC:FUNCT:ARG bits | +-----------------------+------------------------------+¶
An example of a Flow Specification NLRI encoding for: all SRv6 packets to LOC 2001:db8:3::/48 and FUNCT {range [0100, 0300]}.¶
Some Parts of SID
|
length v LOC==20010db80003 FUN>=100 FUN<=300
0x12 0f 30 10 40 01 2001 0db8 0003 4b 0100 bd 0300
^ ^ ^
| | |
Length of LOC FUN ARG¶
Decoded:
Value
0x12 length 18 octets (if len<240, 1 octet)
TBD1(0x0f) type type TBD1(0x0f) - Some Parts of SID
0x30 LOC Length = 48 (bits)
0x10 FUNCT Length = 16 (bits)
0x40 ARG Length = 64 (bits)
0x01 op LOC ==
0x2001 value LOC's value = 2001:db8:3
0x0db8
0x0003
0x4b op "AND", FUNCT >=
0x0100 value FUNCT's value = 0100
0xbd op end-of-list, "AND", FUNCT <=
0x0300 value FUNCT's value = 0300
¶
No new security issues are introduced to the BGP protocol by this specification over the security considerations in [RFC8955] and [RFC8956].¶
Under "Flow Spec Component Types" registry, IANA is requested to assign the following values:¶
+-----------+------------+-------------------+----------------+ | Value | IPv4 Name | IPv6 Name | Reference | +-----------+------------+-------------------+----------------+ | TBD1 | Unassigned | Some Parts of SID | This Document | +-----------+------------+-------------------+----------------+¶
The authors would like to thank Joel Halpern, Jeffrey Haas, Ketan Talaulikar, Aijun Wang, Dhruv Dhody, Shunwan Zhuang and Rainsword Wang for their valuable suggestions and comments on this draft.¶
Lei Li Huawei 156 Beiqing Road Beijing 100095 P.R. China Email: lily.lilei@huawei.com¶