BGP Extension for Advertising
In-situ Flow Information Telemetry (IFIT) CapabilitiesHuaweiBeijingChinawangyali11@huawei.comHuaweiBeijingChinazhuangshunwan@huawei.comHuaweiBeijingChinaguyunan@huawei.comChina UnicomBeijingChinapangran@chinaunicom.cnThis document defines extensions to BGP to advertise the In-situ Flow Information Telemetry (IFIT) capabilities. Within an IFIT domain, IFIT-capability advertisement from the tail node to the head node assists the head node to determine whether a particular IFIT Option type can be encapsulated in data packets. Such advertisement would be useful for mitigating the leakage threat and facilitating the deployment of IFIT measurements on a per-service and on-demand basis.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.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. The "network domain"
consists of a set of network devices or entities within a single
administration. One network domain MAY consists of multiple IFIT domain.
The family of emerging on-path flow telemetry techniques 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 usecases, the IFIT Features are
deployed on a per-service and on-demand basis. Within the IFIT domain,
one or more IFIT-options are added into packet at the IFIT-enabled head
node that is referred to as the IFIT encapsulating node. Then IFIT data
fields MAY be updated by IFIT transit nodes that the packet traverses.
Finally, the data fields are removed at a device that is referred to as
the IFIT decapsulating node. Hence, a head node needs to know if the
IFIT decapsulating node is able to support the IFIT capabilities.This document defines extensions to Border Gateway Protocol (BGP) to advertise the IFIT
capabilities of a tail node to a head node in an IFIT domain. Then the head node can learn the IFIT capabilities and determine whether a particular IFIT Option type can be encapsulated in traffic packets. Such advertisement would be useful for avoiding IFIT data leaking from the IFIT domain and facilitating the deployment of IFIT measurements on a per-service and on-demand basis.IFIT: In-situ Flow Information TelemetryOAM: Operation Administration and MaintenanceNLRI: 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 registriesIFIT 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:ValueDescriptionReferenceTBA1IPv4-Address-Specific IFIT Tail CommunityThis documentTBA2IPv6-Address-Specific IFIT Tail CommunityThis documentThe IANA is requested to make the assignments for IFIT Next-Hop Capability:ValueDescriptionReferenceTBA3IFIT CapabilitiesThis documentThis 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.The following people made significant contributions to this
document:TBD