| Link State Routing Working Group | Y. Wang |
| Internet-Draft | T. Zhou |
| Intended status: Standards Track | Huawei |
| Expires: January 29, 2021 | F. Qin |
| China Mobile | |
| H. Chen | |
| China Telecom | |
| R. Pang | |
| China Unicom | |
| July 28, 2020 |
IGP Extensions for In-situ Flow Information Telemetry (IFIT) Capability Advertisement
draft-wang-lsr-igp-extensions-ifit-01
This document extends Node and Link Attribute TLVs to Interior Gateway Protocols (IGP) to advertise supported In-situ Flow Information Telemetry (IFIT) capabilities at node and/or link granularity. An ingress router cannot insert IFIT-Data-Fields for packets going into a path unless an egress router has indicated via signaling that it has the capability to process IFIT-Data-Fields. In addition, such advertisements would be useful for ingress routers to gather each router's IFIT capability for achieving the computation of Traffic Engineering (TE) paths or loose TE paths that be able to fulfill the visibility of on-path OAM data.
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 29, 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.
IFIT provides a high-level framework and a reflection-loop solution for on-path telemetry [I-D.song-opsawg-ifit-framework]. At present, there is a family of emerging on-path telemetry techniques, including In-situ OAM (IOAM) [I-D.ietf-ippm-ioam-data], IOAM Direct Export (DEX) [I-D.ietf-ippm-ioam-direct-export], Enhanced Alternate Marking (EAM) [I-D.ietf-6man-ipv6-alt-mark], etc.
IFIT is a solution focusing on network domains. The "network domain" consists of a set of network devices or entities within a single Autonomous System (AS). The part of the network which employs IFIT is referred to as the IFIT domain. One network domain may consist of multiple IFIT domains. An IFIT domain may cross multiple network domains. The family of emerging on-path telemetry techniques may be partially enabled in different vendors' devices as an emerging feature for various use cases of application-aware network operations. So that in order to dynamically enable IFIT functionality in a network domain, it is necessary to advertise the information of IFIT option types supported in each device.
An ingress router cannot insert IFIT-Data-Fields for packets going into a path unless an egress router has indicated via signaling that it has the capability to process IFIT-Data-Fields. In addition, such advertisements would be useful for ingress routers to gather each router's IFIT capability for achieving the computation of TE paths or loose TE paths that be able to fulfill the visibility of on-path OAM data.
BGP-LS defines a way to advertise topology and associated attributes and capabilities of the nodes in that topology to a centralized controller [RFC7752]. Typically, BGP-LS is configured on a small number of nodes that do not necessarily act as head-ends. In order for BGP-LS to signal IFIT node capabilities for all the devices in the network, IFIT node capabilities SHOULD be advertised by every IGP router in the network.
This document defines a mechanism to signal the supported IFIT capabilities at node and/or link granularity using IS-IS, OSPFv2 and OSPFv3.
Following are abbreviations used in this document:
Each IFIT-capable node is configured with a node-id which uniquely identifies a node within the associated IFIT domain. To accommodate the different use cases or requirements of in-situ flow information telemetry, IFIT data fields updated by network nodes fall into different categories which are referred as different IFIT option types, including IOAM Trace Option-Types [I-D.ietf-ippm-ioam-data], IOAM Edge-to-Edge (E2E) Option-Type [I-D.ietf-ippm-ioam-data], IOAM DEX Option-Type [I-D.ietf-ippm-ioam-direct-export] and EAM Option-Type [I-D.ietf-6man-ipv6-alt-mark]. A subset or all the IFIT-Option-Types and their corresponding IFIT-Data-Fields can be associated to an IFIT-Namespace. Namespace identifiers allow a device which is IFIT-capable to determine whether IFIT-Option-Types need to be processed. So that IFIT-Option-Types and Namespace-IDs SHOULD be included in IFIT capability information.
This document defines the IFIT Capability information formed of one or more pairs of a 2-octet Namespace-ID and 16-bit Option-Type Flag.
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 +---------------------------------------------------------------+ | Namespace-ID_1 | Option-Type enabled Flag_1 | +---------------------------------------------------------------+ | Namespace-ID_2 | Option-Type enabled Flag_2 | +---------------------------------------------------------------+ | ... | ... | +---------------------------------------------------------------+
Fig. 1 IFIT Capability Format
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-------------------------------+
|p|i|d|e|m| Reserved |
+-------------------------------+
An IFIT node MAY be capable of more than one IFIT option types. In this case, Option-Type Flag can has more than one bit being set.
In this document, Link IFIT Capability is defined as the supported IFIT-Option-Types of the interface associated with the link. When all interfaces associated with links support the same IFIT-Option-Type, the Node IFIT Capability SHOULD represent the Link IFIT Capability. Both of Node and Link IFIT Capability information are formed of one or more pairs of Namespace-ID and Option-Type Flag.
When both of Node and Link IFIT Capability are advertised, the Link IFIT Capability information MUST take precedence over the Node IFIT Capability. Besides, when a Link IFIT Capability is not signaled, then the Node IFIT Capability SHOULD be considered to be the IFIT Capability for this link.
The IS-IS Extensions for advertising Router Information TLV named IS-IS Router CAPABILITY TLV [RFC7981], which allows a router to announce its capabilities within an IS-IS level or the entire routing domain. And [RFC5305] describes extensions to IS-IS to support Traffic Engineering.
According to the format of IS-IS Router CAPABILITY TLV [RFC7981], the Node IFIT sub-TLV within the body of the IS-IS router CAPABILITY TLV is composed of three fields, a one-octet Type field, a one-octet Length field, and a multiple of 4-octet Value field. The following format is used:
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 | Length | +---------------+---------------+-------------------------------+ | Node-IFIT-Capability | ~ ~ +---------------------------------------------------------------+
Fig. 2 IS-IS Node IFIT Sub-TLV Format
The Link IFIT sub-TLV is defined to carry the IFIT-Capability information of the interface associated with the link, which is formed of three fields, a one-octet Type field, a one-octet Length field, and a multiple of 4-octet Value field. The following format is used:
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 | Length | +---------------+---------------+-------------------------------+ | Link-IFIT-Capability | ~ ~ +---------------------------------------------------------------+
Fig. 3 IS-IS Link IFIT Sub-TLV Format
Given that OSPF uses the options field in LSAs and hello packets to advertise optional router capabilities [RFC7770], this document defines a new IFIT Node TLV within the body of the OSPF RI Opaque LSA [RFC7770] to carry the IFIT Capabilities of the router originating the RI LSA.
This document defines the Link IFIT sub-TLV to carry the IFIT-Capability information of the interface associated with the link. For OSPFv2, the link-level IFIT capability information is advertised as a sub-TLV of the OSPFv2 Extended Link TLV as defined in [RFC7684]. For OSPFv3, the link-level IFIT capability information is advertised a sub-TLV of the E-Router-LSA TLV as defined in [RFC8362].
The Node IFIT TLV is composed of three fields, a 2-octet Type field, a 2-octet Length field, and a multiple of 4-octet Value field. The following format is used:
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 | Length | +---------------------------------------------------------------+ | Node-IFIT-Capability | ~ ~ +---------------------------------------------------------------+
Fig. 4 OSPF Node IFIT TLV
The Link IFIT sub-TLV encoded in the OSPFv2 Extended Link TLV is constructed of three fields, a 2-octet Type field, a 2-octet Length field, and a multiple of 4-octet Value field. The following format is used:
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 | Length | +---------------------------------------------------------------+ | Link-IFIT-Capability | ~ ~ +---------------------------------------------------------------+
Fig. 5 OSPFv2 Link IFIT sub-TLV
The Link IFIT sub-TLV encoded in the OSPFv3 E-Router-LSA TLV is constructed of three fields, a 2-octet Type field, a 2-octet Length field, and a multiple of 4-octet Value field. The following format is used:
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 | Length | +---------------------------------------------------------------+ | Link-IFIT-Capability | ~ ~ +---------------------------------------------------------------+
Fig. 6 OSPFv3 Link IFIT sub-TLV
As any packet with IFIT-Data-Fields must not leak out from the IFIT domain, the IFIT decapsulating node must be able to capture packets with IFIT-specific header and metadata and recover their format before forwarding them out of the IFIT domain. Thus, an ingress router cannot insert IFIT-Data-Fields for packets going into a path unless an egress router has indicated via signaling that it has the capability to process IFIT-Data-Fields. In this case, such advertisements are helpful for avoiding the leak of IFIT-specific header and metadata.
In addition, such advertisements would be useful for ingress routers to gather each router's IFIT capability for achieving the computation of TE paths or loose TE paths that be able to fulfill the visibility of on-path OAM data. For example, for achieving the computation of low-latency SR-TE path, latency is expected to be collected at every node that a packet traverses to ensure performance visibility into the entire path. IOAM Trace Option-Types is a desired option to have a hop-by-hop latency measurement. If not all nodes on this path are IOAM Trace Option-Type capable, an incomplete measurement can have negative impacts on SR-TE path computation and adjustment for low-latency assurance.
IANA is requested to allocate values for the following new TLV and sub-TLVs.
| Type | Description |
|---|---|
| TBD | IS-IS Node IFIT Sub-TLV |
| TBD | IS-IS Link IFIT Sub-TLV |
| Type | Description |
|---|---|
| TBD | OSPF Node IFIT Capability TLV |
| TBD | OSPFv2 Link IFIT Capability sub-TLV |
| TBD | OSPFv3 Link IFIT Capability sub-TLV |
This document introduces new IGP Node and Link Attribute TLVs and sub-TLVs for the IFIT Capability advertisements at node and/or link granularity. It does not introduce any new security risks to IS-IS, OSPFv2 and OSPFv3.
The authors would like to thank Acee Lindem, Christian Hopps, Robert Raszuk, Les Ginsberg, Jeff Tantsura, Rakesh Gandhi and Greg Mirsky for the comments and advices.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [RFC5305] | "IS-IS Extensions for Traffic Engineering" |
| [RFC7684] | "OSPFv2 Prefix/Link Attribute Advertisement" |
| [RFC7752] | "North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP" |
| [RFC7770] | "Extensions to OSPF for Advertising Optional Router Capabilities" |
| [RFC7981] | "IS-IS Extensions for Advertising Router Information" |
| [RFC8362] | "OSPFv3 Link State Advertisement (LSA) Extensibility" |
| [I-D.ietf-6man-ipv6-alt-mark] | "IPv6 Application of the Alternate Marking Method" |
| [I-D.ietf-ippm-ioam-data] | "Data Fields for In-situ OAM" |
| [I-D.ietf-ippm-ioam-direct-export] | "In-situ OAM Direct Exporting" |
| [I-D.song-opsawg-ifit-framework] | "In-situ Flow Information Telemetry Framework" |