| Network Working Group | Y. Wang |
| Internet-Draft | S. Zhuang |
| Intended status: Standards Track | Y. Gu |
| Expires: January 15, 2021 | Huawei |
| July 14, 2020 |
BGP Extension for Advertising In-situ Flow Information Telemetry (IFIT) Capabilities
draft-wang-idr-bgp-ifit-capabilities-00
This document defines extensions to BGP to advertise the In-situ Flow Information Telemetry (IFIT) capabilities. Within an IFIT measurement domain, the capability is meant to be advertised from the IFIT tail node to the head node to assist the head node to determine whether a particular IFIT Option type can be enabled. This facilitates 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.
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 January 15, 2021.
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.
At present, a family of on-path flow telemetry techniques referred in [I-D.song-opsawg-ifit-framework] are emerging, including In-situ OAM (IOAM) [I-D.ietf-ippm-ioam-data], Postcard-Based Telemetry (PBT) [I-D.song-ippm-postcard-based-telemetry], IOAM Direct Export (DEX) [I-D.ioamteam-ippm-ioam-direct-export], Enhanced Alternate Marking (EAM) [I-D.zhou-ippm-enhanced-alternate-marking].
In-situ Flow Information Telemetry (IFIT) determines network performance by measuring the packet loss and latency of service packets transmitted in an IP network. This feature is easy to deploy and provides an accurate assessment of network performance.
The IFIT model describes how service flows are measured to obtain packet loss and latency. Specifically, IFIT measures the packet loss and latency of service flows on the ingress and egress of the transit network, and summarizes desired performance indicators. The IFIT model is composed of three objects: target flow, transit network, and measurement system. The transit network only bears target flows. The target flows are not generated or terminated on the transit network. The transit network can be a Layer 2 (L2), Layer 3 (L3), or L2+L3 hybrid network. Each node on the transit network must be reachable at the network layer. The measurement system consists of the ingress (configured with IFIT and IFIT parameters) and multiple IFIT-capable devices.
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 BGP to advertise the IFIT capabilities to a head node, then the head node can learn the IFIT capabilities and determine whether a particular IFIT Option type can be supported by the sending side as the decapsulating node. This facilitates the deployment of IFIT measurements on a per-service and on-demand basis.
This document defines the IFIT Capabilities formed of a 16-bit bitmap. The following format is used:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|p|i|d|e|m| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. IFIT Capabilities
For IPv4 networks, this section defines a new type of BGP extended community [RFC4360] called IPv4-Address-Specific IFIT Extended Community. The IPv4-Address-Specific IFIT Extended 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 TBA.
The format of this extended community is shown in Figure 2.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x01) | Sub-Type (TBA)| IFIT Capabilities |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originating IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2. IPv4-Address-Specific IFIT Extended Community
For IPv6 networks, this section defines a new type of BGP extended community[RFC4360] called IPv6-Address-Specific IFIT Extended Community. The IPv6-Address-Specific IFIT Extended 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 TBA.
The format of this extended community is shown in Figure 3.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x00) | Sub-Type (TBA)| IFIT Capabilities |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originating IPv6 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originating IPv6 Address (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originating IPv6 Address (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originating IPv6 Address (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3. IPv6-Address-Specific IFIT Extended Community
In this mode, 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 [I-D.ietf-idr-next-hop-capability] 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 Next-Hop Capability is a triple (Capability Code, Capability Length, Capability Value) aka a TLV:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Capability Code (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Capability Length (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Capability Value (variable) |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4. BGP Next-Hop Capability
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IFIT Capabilities (2 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Originating IP Address | | (4 or 16 octets) | ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5. BGP Capability Value for IFIT
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.
A BGP speaker receiving an IFIT Next-Hop Capability containing the IFIT options that it can supports behaves as defined in the document defining these iFIT options.
TBD
TBD
The following people made significant contributions to this document:
Weidong Li Huawei Email: poly.li@huawei.com Haibo Wang Huawei Email: rainsword.wang@huawei.com Tianran Zhou Huawei Email: zhoutianran@huawei.com
TBD
| [I-D.ietf-bess-srv6-services] | Dawra, G., Filsfils, C., Raszuk, R., Decraene, B., Zhuang, S. and J. Rabadan, "SRv6 BGP based Overlay services", Internet-Draft draft-ietf-bess-srv6-services-03, July 2020. |
| [I-D.ietf-idr-next-hop-capability] | Decraene, B., Kompella, K. and W. Henderickx, "BGP Next-Hop dependent capabilities", Internet-Draft draft-ietf-idr-next-hop-capability-05, June 2019. |
| [I-D.ietf-ippm-ioam-data] | Brockners, F., Bhandari, S. and T. Mizrahi, "Data Fields for In-situ OAM", Internet-Draft draft-ietf-ippm-ioam-data-10, July 2020. |
| [I-D.ioamteam-ippm-ioam-direct-export] | Song, H., Gafni, B., Zhou, T., Li, Z., Brockners, F., Bhandari, S., Sivakolundu, R. and T. Mizrahi, "In-situ OAM Direct Exporting", Internet-Draft draft-ioamteam-ippm-ioam-direct-export-00, October 2019. |
| [I-D.song-ippm-postcard-based-telemetry] | Song, H., Zhou, T., Li, Z., Shin, J. and K. Lee, "Postcard-based On-Path Flow Data Telemetry", Internet-Draft draft-song-ippm-postcard-based-telemetry-07, April 2020. |
| [I-D.wang-idr-bgp-ls-ifit-node-capability] | Wang, Y., Zhou, T. and R. Pang, "Extensions to BGP-LS for Advertising In-situ Flow Information Telemetry (IFIT) Node Capability", Internet-Draft draft-wang-idr-bgp-ls-ifit-node-capability-03, March 2020. |
| [I-D.zhou-ippm-enhanced-alternate-marking] | Zhou, T., Fioccola, G., Lee, S., Cociglio, M. and W. Li, "Enhanced Alternate Marking Method", Internet-Draft draft-zhou-ippm-enhanced-alternate-marking-05, 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. |
| [I-D.song-opsawg-ifit-framework] | Song, H., Qin, F., Chen, H., Jin, J. and J. Shin, "In-situ Flow Information Telemetry", Internet-Draft draft-song-opsawg-ifit-framework-12, April 2020. |
| [RFC4271] | Rekhter, Y., Li, T. and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006. |
| [RFC4360] | Sangli, S., Tappan, D. and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, February 2006. |
| [RFC4760] | Bates, T., Chandra, R., Katz, D. and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, DOI 10.17487/RFC4760, January 2007. |