Internet-Draft BGP Flow Specification for SRv6 October 2026
Li, et al. Expires 29 April 2027 [Page]
Workgroup:
IDR Working Group
Internet-Draft:
draft-ietf-idr-flowspec-srv6-11
Published:
Intended Status:
Standards Track
Expires:
Authors:
Z. Li
Huawei
J. dong
Huawei
C. Loibl
Next Layer Communications
G. Mishra
Verizon Inc.
Y. Zhu
China Telecom
S. Zhuang
Huawei

BGP Flow Specification for SRv6

Abstract

This document specifies extensions to BGP Flow Specification (BGP-FS) to enable filtering of IPv6 packets based on the structural components of a standard SRv6 Segment Identifier (SID) or an SRv6 Compressed SID (CSID) container present in the IPv6 Destination Address (representing the active segment of an SRv6 path). Both NEXT-CSID and REPLACE-CSID flavors defined in RFC 9800 are supported.

Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "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.

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 29 April 2027.

▲

Table of Contents

1. Introduction

[RFC8955] defines the BGP Flow Specification (BGP-FS) Network Layer Reachability Information (NLRI) to distribute traffic filtering rules, which consist of an n-tuple of matching criteria applied to IP packets. [RFC8956] extends this framework to IPv6 data packets. Additionally, [I-D.ietf-idr-flowspec-l2vpn] extends Flowspec rules for Layer 2 Ethernet frames, and [I-D.ietf-idr-flowspec-v2] specifies BGP Flow Specification Version 2.

Segment Routing over IPv6 (SRv6) [RFC8754] leverages the IPv6 data plane using a Segment Routing Header (SRH) to instantiate Segment Routing policy paths. The SRv6 Network Programming architecture [RFC8986] defines the standard structure of an SRv6 Segment Identifier (SID), formatted as LOC:FUNCT:ARG. Furthermore, [RFC9800] defines Compressed SRv6 Segment Identifiers (CSIDs) to optimize encoding efficiency, supporting two primary flavors: NEXT-CSID and REPLACE-CSID. In CSID container architecture, multiple CSIDs are packed within a 128-bit IPv6 Destination Address (DA) container. As packets traverse CSID nodes, the active CSID position within the container dynamically changes or shifts.

Existing IPv6 BGP-FS components [RFC8956] allow matching against the entire 128-bit IPv6 Destination Address (DA). However, both standard SRv6 SIDs and CSID containers embed structured sub-fields within the IPv6 DA. Filtering traffic based solely on a static 128-bit mask lacks the flexibility needed to apply policy rules to specific SRv6 function IDs or active Compressed SIDs across dynamically shifting DA containers.

This document defines two new BGP Flow Specification component types:

  1. Component Type TBD1: Standard SRv6 SID Structure Match [RFC8986].

  2. Component Type TBD2: SRv6 CSID Dynamic Structure Match [RFC9800].

The matching field is evaluated against the IPv6 Destination Address (or active SID within an SRH when present, as shown in Figure 1). To support this feature, a BGP-FS NLRI with AFI = 2 (IPv6) MUST be used.

            +-----------------------------+
 IPv6 Header|     SA      |     DA        |<-- Match Field
            +--------------------^--------+
                                 |
            +--------------------|--------+
            |             +-------------+ |     +-------------------+
            |             | Segment[0]  +-------> Loc | Func | Arg  |
            |             +-------------+ |     +-------------------+
            |             | Segment[1]  | |
            |             +-------------+ |
            |             |    ...      | |
   SR Header|             +-------------+ |
  (RFC 8754)|             | Segment[n]  | |
            |             +-------------+ |
            |             +-------------+ |
            |             ~  Option TLV ~ |
            |             +-------------+ |
            +-----------------------------+
Figure 1: Match Field

2. Definitions and Acronyms

In this document, the length parameters defining the constituent parts of a SID or CSID structure are defined as follows:

In addition, the sum of LN-Len and F-Len (LN-Len + F-Len) represents the total length of a single CSID (also referred to as the "CSID length").

3. The Flow Specification Encoding for SRv6

A Flow Specification NLRI consists of zero or more matching components. Components Type 1 through 13 are defined in [RFC8955] and [RFC8956]. This document defines two new component types for SRv6 SID and CSID sub-field filtering.

3.1. Component Type TBD1 - Standard SRv6 SID Structure Match

An SRv6 SID consists of Locator, Function, and Argument fields as defined in [RFC8986]. In operational scenarios, operators may need to filter traffic matching specific locators, functions, or arguments, or combinations thereof.

The new component type TBD1 (Standard SRv6 SID Structure Match) allows fine-grained matching on these individual fields or aggregated field combinations.

Encoding: <type, LOC-Len, FUNCT-Len, ARG-Len, [op, value]+>

o type (1 octet):
Indicates the new component type (TBD1, to be assigned by IANA).
o LOC-Len (1 octet):
Length of the Locator field in bits.
o FUNCT-Len (1 octet):
Length of the Function field in bits.
o ARG-Len (1 octet):
Length of the Argument field in bits.
o [op, value]+:
A sequence of one or more {operator, value} pairs specifying the matching logic applied to the SID sub-fields.

Validation Constraint:

The sum of LOC-Len, FUNCT-Len, and ARG-Len MUST NOT exceed 128 bits. If (LOC-Len + FUNCT-Len + ARG-Len) > 128, the NLRI is considered malformed, and BGP Error Handling MUST be applied according to [RFC7606] and [RFC4760].

The Operator byte (op) is encoded as follows:

   0   1   2   3   4   5   6   7
 +---+---+---+---+---+---+---+---+
 | e | a | field type|lt |gt |eq |
 +---+---+---+---+---+---+---+---+

The operator semantics follow the Numeric Operator definition in [RFC8955]:

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:

000:
SID's LOC
001:
SID's FUNCT
010:
SID's ARG
011:
SID's LOC:FUNCT
100:
SID's FUNCT:ARG
101:
SID's LOC:FUNCT:ARG

lt, gt, eq - Less-than, Greater-than, and Equal-to comparison operators, evaluated bitwise or numerically between the extracted SID sub-field and the provided value.

The length of the Value field following the operator byte is determined by the selected field type, rounded up to the nearest byte boundary (i.e., ceil(bits / 8)).

+---------------------+-------------------------------------------+
| Field Type          | Value Field Length                        |
+=====================+===========================================+
| SID's LOC           | ceil(LOC-Len / 8) octets                  |
+---------------------+-------------------------------------------+
| SID's FUNCT         | ceil(FUNCT-Len / 8) octets                |
+---------------------+-------------------------------------------+
| SID's ARG           | ceil(ARG-Len / 8) octets                  |
+---------------------+-------------------------------------------+
| SID's LOC:FUNCT     | ceil((LOC-Len + FUNCT-Len) / 8) octets    |
+---------------------+-------------------------------------------+
| SID's FUNCT:ARG     | ceil((FUNCT-Len + ARG-Len) / 8) octets    |
+---------------------+-------------------------------------------+
| SID's LOC:FUNCT:ARG | ceil((LOC-Len+FUNCT-Len+ARG-Len)/8) octets|
+---------------------+-------------------------------------------+

3.2. Component Type TBD2 - SRv6 CSID Dynamic Structure Match

[RFC9800] defines Compressed SRv6 Segment Identifiers (C-SIDs) to reduce header overhead, supporting two primary flavors: NEXT-CSID and REPLACE-CSID.

Per Section 3 and 4 of [RFC9800], both flavors position the currently active CSID immediately following the Locator-Block (LB) in the IPv6 Destination Address (DA):

NEXT-CSID Container Structure:
+------------------------------------------------------------------+
| Locator-Block | Active CSID | Next CSID_1 | Next CSID_2 ...|Zeros|
+------------------------------------------------------------------+

REPLACE-CSID Container Structure:
+------------------------------------------------------------------+
| Locator-Block | Active CSID |            Argument                |
+------------------------------------------------------------------+

Filtering rules MAY target either the Active CSID (applicable to both NEXT-CSID and REPLACE-CSID flavors) or the Next CSID (applicable specifically to the NEXT-CSID flavor).

Encoding: <type, LB-Len, LN-Len, F-Len, [op, value]+>
o type (1 octet):
Indicates component type TBD2 (to be assigned by IANA).
o LB-Len (1 octet):
Locator-Block Length in bits (e.g., 32 bits).
o LN-Len (1 octet):
Locator-Node Length in bits (e.g., 16 bits).
o F-Len (1 octet):
Function Length in bits (e.g., 16 bits).
o [op, value]+:
A sequence of one or more {operator, value} pairs.

Validation Constraint:

The Operator byte (op) for TBD2 is encoded as:

   0   1   2   3   4   5   6   7
 +---+---+---+---+---+---+---+---+
 | e | a | field type|lt |gt |eq |
 +---+---+---+---+---+---+---+---+

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:

000:
Locator-Block (LB)
001:
Active CSID Node ID (LN)
010:
Active CSID Function ID (F)
011:
Active CSID (LN:F)
100:
Next CSID (LN:F)
101:
Full CSID (LB:LN:F)
110:
Next CSID Node ID (LN)
111:
Next CSID Function (F)

Field Type 101 represents the Full CSID structure combining the Locator-Block (LB) and the Active CSID (LN:F) into a single matching value.

Dynamic Match Processing Logic:

When evaluating Component Type TBD2 against an incoming IPv6 packet:

  1. Locator-Block: Extracted starting at bit offset 0 with length LB-Len.

  2. Active CSID: The Active CSID (LN:F) is extracted starting at bit offset LB-Len with length (LN-Len + F-Len). In the context of the evaluating node, this represents the currently active CSID positioned immediately after the Locator-Block in the IPv6 DA.

  3. Next CSID:

    • For NEXT-CSID flavor: The subsequent CSID is extracted immediately following the Active CSID at bit offset (LB-Len + LN-Len + F-Len) with length (LN-Len + F-Len). If the extracted Next CSID is all zeros (indicating no further CSID exists in the container or a padded container), the Next CSID evaluation MUST result in no match (False).

    • For REPLACE-CSID flavor: Since the REPLACE-CSID structure does not support concatenated subsequent C-SIDs within the IPv6 DA container, any rule evaluating Next CSID (field type 100) against a REPLACE-CSID packet MUST result in no match (False).

+----------------------+-------------------------------------------+
| Field Type           | Value Field Length                        |
+======================+===========================================+
| Locator-Block (LB)   | ceil(LB-Len / 8) octets                   |
+----------------------+-------------------------------------------+
| Active CSID Node (LN)| ceil(LN-Len / 8) octets                   |
+----------------------+-------------------------------------------+
| Active CSID Func (F) | ceil(F-Len / 8) octets                    |
+----------------------+-------------------------------------------+
| Active CSID (LN:F)   | ceil((LN-Len + F-Len) / 8) octets         |
+----------------------+-------------------------------------------+
| Next CSID (LN:F)     | ceil((LN-Len + F-Len) / 8) octets         |
+----------------------+-------------------------------------------+
| Full CSID            | ceil((LB-Len + LN-Len + F-Len) / 8) octets|
+----------------------+-------------------------------------------+

3.3. Encoding Examples

3.3.1. Example 1: Standard SRv6 SID Structure Match (Type TBD1)

Consider a rule targeting all SRv6 traffic directed to Locator 2001:db8:3::/48 with a Function ID within the range [0x0100, 0x0300].

Given:

  • LOC-Len = 48 bits (6 octets)

  • FUNCT-Len = 16 bits (2 octets)

  • ARG-Len = 64 bits (8 octets)

Hexadecimal Encoding Sequence:

       Some Parts of SID
             |
length       v             LOC==20010db80003  FUN>=100  FUN<=300
0x11       TBD1 30 10 40   01 2001 0db8 0003  4b 0100   8d 0300
                ^  ^   ^
                |  |   |
    Length of LOC FUN ARG

Detailed Field Breakdown:

Decoded:
         Value
         0x11     length       17 octets (if len<240, 1 octet)
         TBD1     type         type TBD1 - SRv6 Standard SID
                                           Structure Match
         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
         0x8d     op           end-of-list, "AND", FUNCT <=
         0x0300   value        FUNCT's value = 0300

3.3.2. Example 2: SRv6 CSID Dynamic Structure Match (Type TBD2)

Consider an SRv6 network using a CSID container structure (applicable to either NEXT-CSID or REPLACE-CSID flavors) with Locator-Block 2001:db8::/32 (LB-Len=32), Node ID length LN-Len=16, and Function ID length F-Len=16. The rule targets traffic where the Active CSID Node ID equals 0x001A.

Given:

  • LB-Len = 32 bits (4 octets)

  • LN-Len = 16 bits (2 octets)

  • F-Len = 16 bits (2 octets)

Hexadecimal Sequence:

0x07 TBD2 20 10 10 89 001A

Detailed Field Breakdown:

Octet(s) Field      Value             Description
----------------------------------------------------------
0x07     Length     7 octets          Total length of the
                                      Component
TBD2     Type       TBD2              SRv6 CSID Dynamic
                                      Structure Match
0x20     LB-Len     32 bits           Locator-Block Length = 32
0x10     LN-Len     16 bits           Locator-Node Length = 16
0x10     F-Len      16 bits           Function Length = 16
0x89     Op 1       10001001(binary)  e=1, field=001(LN),op='=='
0x001A   Value 1    0x001A            Active CSID Node ID

3.3.3. Example 3: Dual Matching on Active CSID and Next CSID (NEXT-CSID Flavor)

In a multi-hop SRv6 domain using the NEXT-CSID flavor, policy rules may require matching both the node currently processing the packet (Active CSID) and the subsequent downstream segment (Next CSID) to enforce strict path-aware traffic filtering. (Note: This dual-matching capability is specific to the NEXT-CSID flavor).

Consider a NEXT-CSID network structured with:

  • Locator-Block Length (LB-Len) = 32 bits (4 octets)

  • Node ID Length (LN-Len) = 16 bits (2 octets)

  • Function ID Length (F-Len) = 16 bits (2 octets)

Matching Criterion:

Filter traffic where:

1. Active CSID (LN:F) equals 0x0001000A

2. AND Next CSID (LN:F) equals 0x0002000B

Hexadecimal Sequence:

0x0E TBD2 20 10 10 19 0001000A E1 0002000B

Detailed Field Breakdown:

Octet(s)   Field       Value       Description
----------------------------------------------------------
0x0E       Length      14 octets   Total length of the
                                   Component
TBD2       Type        TBD2        SRv6 CSID Dynamic
                                   Structure Match
0x20       LB-Len      32 bits     Locator-Block Length
0x10       LN-Len      16 bits     Locator-Node Length
0x10       F-Len       16 bits     Function Length

---        Operator 1: Active CSID Match
0x19       Op 1        0x19        binary 00011001
                                   (e=0, a=0, field=011,
                                   op='==')
0x0001000A Value 1     0x0001000A  Active CSID (LN:F)

---        Operator 2: Next CSID Match (AND Relationship)
0xE1       Op 2        0xE1        binary 11100001
                                   (e=1, a=1, field=100,
                                   op='==')
0x0002000B Value 2     0x0002000B  Next CSID (LN:F)

4. Security Considerations

This document introduces no new security vulnerabilities beyond those already documented in [RFC8955] and [RFC8956]. Because Flowspec rules can result in packet dropping or rate-limiting, implementations MUST verify the authorization of BGP peers sending SRv6 Flowspec rules to prevent potential Denial-of-Service (DoS) attacks or traffic hijacking.

5. IANA Considerations

Under the "Flow Spec Component Types" registry, IANA is requested to assign the following values:

+------+-----------+----------------------------------+-----------+
| Value| IPv4 Name | IPv6 Name                        | Reference |
+------+-----------+----------------------------------+-----------+
| TBD1 | Unassigned| SRv6 Standard SID Structure Match| This Doc  |
| TBD2 | Unassigned| SRv6 CSID Dynamic Structure Match| This Doc  |
+------+-----------+----------------------------------+-----------+

6. Acknowledgments

The authors would like to thank Joel Halpern, Jeffrey Haas, Ketan Talaulikar, Aijun Wang, Dhruv Dhody, Ming Shen and Rainsword Wang for their valuable suggestions and comments.

7. Contributors 

   Huaimo Chen
   Futurewei
   Email: hchen.ietf@gmail.com

   Lei Li
   Huawei
   P.R. China
   Email: lily.lilei@huawei.com

   Yanhe Fan
   Casa Systems
   United States of America
   Email: yfan@casa-systems.com

   Lei Liu
   Fujitsu
   United States of America
   Email: liulei.kddi@gmail.com

   Xufeng Liu
   Volta Networks
   United States of America
   Email: xufeng.liu.ietf@gmail.com

8. References

8.1. Normative References

[I-D.ietf-idr-flowspec-v2]
Hares, S., Eastlake, D. E., Yadlapalli, C., and S. Maduschke, "BGP Flow Specification Version 2", Work in Progress, Internet-Draft, draft-ietf-idr-flowspec-v2-04, , <https://datatracker.ietf.org/doc/html/draft-ietf-idr-flowspec-v2-04>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC4760]
Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, DOI 10.17487/RFC4760, , <https://www.rfc-editor.org/info/rfc4760>.
[RFC7606]
Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. Patel, "Revised Error Handling for BGP UPDATE Messages", RFC 7606, DOI 10.17487/RFC7606, , <https://www.rfc-editor.org/info/rfc7606>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.
[RFC8955]
Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M. Bacher, "Dissemination of Flow Specification Rules", RFC 8955, DOI 10.17487/RFC8955, , <https://www.rfc-editor.org/info/rfc8955>.
[RFC8956]
Loibl, C., Ed., Raszuk, R., Ed., and S. Hares, Ed., "Dissemination of Flow Specification Rules for IPv6", RFC 8956, DOI 10.17487/RFC8956, , <https://www.rfc-editor.org/info/rfc8956>.
[RFC9800]
Cheng, W., Ed., Filsfils, C., Li, Z., Decraene, B., and F. Clad, Ed., "Compressed SRv6 Segment List Encoding", RFC 9800, DOI 10.17487/RFC9800, , <https://www.rfc-editor.org/info/rfc9800>.

8.2. Informative References

[I-D.ietf-idr-flowspec-l2vpn]
Weiguo, H., Eastlake, D. E., Litkowski, S., and S. Zhuang, "BGP Dissemination of L2 Flow Specification Rules", Work in Progress, Internet-Draft, draft-ietf-idr-flowspec-l2vpn-27, , <https://datatracker.ietf.org/doc/html/draft-ietf-idr-flowspec-l2vpn-27>.
[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, , <https://www.rfc-editor.org/info/rfc8754>.
[RFC8986]
Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 (SRv6) Network Programming", RFC 8986, DOI 10.17487/RFC8986, , <https://www.rfc-editor.org/info/rfc8986>.

Authors' Addresses

Zhenbin Li
Huawei
156 Beiqing Road
Beijing, 100095
P.R. China
Jie Dong
Huawei
156 Beiqing Road
Beijing
100095
P.R. China
Christoph Loibl
Next Layer Communications
Mariahilfer Guertel 37/7
1150 Vienna
Austria
Gyan S. Mishra
Verizon Inc.
13101 Columbia Pike
Silver Spring, MD 20904
United States of America
Phone: 301 502-1347
Yongqing Zhu
China Telecom
109, West Zhongshan Road, Tianhe District
Guangzhou
510000
China
Shunwan Zhuang
Huawei
156 Beiqing Road
Beijing
100095
P.R. China