BGP Extension for Advertising In-situ Flow Information Telemetry (IFIT) Capabilities

In-situ Flow Information Telemetry (IFIT) denotes a family of flow-oriented on-path telemetry techniques, including In-situ OAM (IOAM) and Alternate Marking. It can provide flow information on the entire forwarding path on a per-packet basis in real time. IFIT is a solution focusing on network domains according to that introduces the concept of specific domain solutions. A network domain consists of a set of network devices or entities within a single administration. As mentioned in , for a number of reasons, such as policies, options supported, style of network management and security requirements, it is suggested to limit applications including the emerging IFIT techniques to a controlled domain. Hence, the family of emerging on-path flow telemetry techniques MUST be typically deployed in such controlled domains. The IFIT solution MAY be selectively or partially implemented in different vendors' devices as an emerging feature for various use cases of application-aware network operations. In addition, for some use cases, the IFIT are deployed on a per-service and on-demand basis. The figure shows an implementation example of IFIT for VPN scenario.

| |<---------------BGP-------------->| |<----------------------------VPN--------------------------->| ]]> As the figure shows, a traffic flow is sent out from the customer edge CE1 to another CE2. In order to enable IFIT application for this flow, the IFIT header must be encapsulated in the packet at the ingress node PE1 referred to as the IFIT encapsulating node. Then, transmit nodes in the IFIT domain must be able to support the IFIT capabilities to inspect IFIT command and update the IFIT data fields in the packet. Finally, the IFIT data fields MUST be exported and removed at egress node PE2 that is referred to as the IFIT decapsulating node to avoild IFIT data leakage outside the controlled domain. Hence, a head node needs to know if the IFIT decapsulating node are able to support the IFIT capabilities. This document defines extensions to Border Gateway Protocol (BGP) to advertise the supported IFIT capabilities of the egress node to the ingress node in an IFIT domain when the egress node distributes a route. Then the ingress node can learn the IFIT node capabilities associated to the routing information distributed between BGP peers and determine whether a particular IFIT Option type can be encapsulated in traffic packets which are forwarded along the path. Such advertisement would be useful for avoiding IFIT data leaking from the IFIT domain and measuring performance metrics on a per-service basis through steering packets of flow into a path where IFIT application are supported.

IFIT: In-situ Flow Information Telemetry OAM: Operation Administration and Maintenance NLRI: Network Layer Reachable Information, the NLRI advertised in the BGP UPDATE as defined in and .

This document defines the IFIT Capabilities formed of a 16-bit bitmap. The following format is used:

P-Flag: IOAM Pre-allocated Trace Option Type flag. When set, this indicates that the router is capable of IOAM Pre-allocated Trace . I-Flag: IOAM Incremental Trace Option Type flag. When set, this indicates that the router is capable of IOAM Incremental Tracing . D-Flag: IOAM DEX Option Type flag. When set, this indicates that the router is capable of IOAM DEX . E-Flag: IOAM E2E Option Type flag. When set, this indicates that the router is capable of IOAM E2E processing . M-Flag: Alternate Marking flag. When set, this indicates that the router is capable of processing Alternative Marking packets . Reserved: Reserved for future use. They MUST be set to zero upon transmission and ignored upon receipt.

For IPv4 networks , this section defines a new type of BGP extended community called IPv4-Address-Specific IFIT Extended Community. The IPv4-Address-Specific IFIT Tail Community can be used by the IFIT decapsulation node to notify the IFIT Capabilities to its parterner (as the IFIT encapsulation node). It is a transitive extended community with type 0x01 and sub-type TBA1. The format of this extended community is shown in Figure 2.

Originating IPv4 Address field: A 4 octets field. A IPv4 address of the IFIT decapsulation node. It is an IPv4 unicast address assigned by one of the Internet registries IFIT Capabilities: A 2 octets field. as defined in previous setion.

For IPv6 networks , this section defines a new type of BGP extended community called IPv6-Address-Specific IFIT Extended Community. The IPv6-Address-Specific IFIT Tail Community can be used by the IFIT decapsulation node to notify the IFIT Capabilities to its parterner (as the IFIT encapsulation node). It is a transitive IPv6 address specific extended community with type 0x00 and sub-type TBA2. The format of this extended community is shown in Figure 3.

Originating IPv6 Address field: A IPv6 address of the IFIT decapsulation node. It is an IPv6 unicast address assigned by one of the Internet registries. IFIT Capabilities: as defined in previous setion. In this option, the Originating IP Address (inclue IPv4 and IPv6) in the extended community attribute is used as the IFIT decapsulation node.

The BGP Next-Hop Capability Attribute is a non-transitive BGP attribute, which is modified or deleted when the next-hop is changed, to reflect the capabilities of the new next-hop. The attribute consists of a set of Next-Hop Capabilities. A IFIT Next-Hop Capability is a triple (Capability Code, Capability Length, Capability Value) aka a TLV:

Capability Code: a two-octets unsigned binary integer which indicates the type of "Next-Hop Capability" advertised and unambiguously identifies an individual capability. This document defines a new Next-Hop Capability, which is called IFIT Next-Hop Capability. The Capability Code is TBA3. Capability Length: a two-octets unsigned binary integer which indicates the length, in octets, of the Capability Value field. A length of 0 indicates that no Capability Value field is present. IFIT Capabilities: as defined in previous setion. ORIG. IP Address: An IPv4 or IPv6 Address of the IFIT decapsulation node. It is an IPv4 or IPv6 unicast address assigned by one of the Internet registries. A BGP speaker S that sends an UPDATE with the BGP Next-Hop Capability Attribute MAY include the IFIT Next-Hop Capability. The inclusion of the IFIT Next-Hop Capability with the NLRI advertised in the BGP UPDATE indicates that the BGP Next-Hop can act as the IFIT decapsulating node and it can process the specific IFIT encapsulation format indicated per the capability value. This is applied for all routes indicated in the same NRLI.

The IANA is requested to make the assignments for IPv4-Address-Specific IFIT Tail Community and IPv6-Address-Specific IFIT Tail Community: Value Description Reference TBA1 IPv4-Address-Specific IFIT Tail Community This document TBA2 IPv6-Address-Specific IFIT Tail Community This document The IANA is requested to make the assignments for IFIT Next-Hop Capability: Value Description Reference TBA3 IFIT Capabilities This document

This document defines extensions to BGP Extended Community and BGP Next-Hop Capability to advertise the IFIT capabilities. It does not introduce any new security risks to BGP. Solutions to ensure the IFIT data propagated in a controlled domain and avoild malicious attacks, both of iOAM method and Alternate Marking method have respectively discussed that the implementation of both methods must be within a controlled domain.

The following people made significant contributions to this document:

The authors would like to thank Giuseppe Fioccola, Jie Dong, Robin Li for their reviews and suggestions