Extensions to BGP-LS for Advertising In-situ Flow Information Telemetry (IFIT) Node Capability
draft-wang-idr-bgp-ls-ifit-node-capability-03

Abstract

This document defines a way for a Border Gateway Protocol Link-State (BGP-LS) speaker to announce In-situ Flow Information Telemetry (IFIT) node capabilities of routers to BGP-LS consumer (e.g. a centralized controller). In this document, IFIT Node Capability TLV is defined as a new Node Attribute TLV that is encoded in the BGP-LS attribute with Node NLRIs [RFC7752]. Such advertisements enable a centralized controller that can leverage this information in determining whether a particular IFIT Option type can be supported in a given network.

Requirements Language

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.

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 September 14, 2020.

Copyright Notice

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.

Table of Contents

• 1. Introduction
• 1.1. Terminology
• 2. Concepts
• 2.1. IFIT Domain
• 2.2. IFIT Node Capability Information
• 3. Advertisement of the IFIT Node Capabilities via BGP-LS
• 3.1. IFIT Node Capability TLV
• 4. IANA Considerations
• 4.1. TLV Code Point of the new IFIT Node Capability TLV within Node NLRIs
• 5. Security Considerations
• 6. Acknowledgements
• 7. References
• 7.1. Normative References
• 7.2. Informative References
• Authors' Addresses

1. Introduction

IFIT provides a complete framework architecture and a reflection-loop working solution for on-path flow telemetry [I-D.song-opsawg-ifit-framework]. At present, there are a family of emerging on-path flow telemetry techniques, including In-situ OAM (IOAM) [I-D.ietf-ippm-ioam-data], 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], etc. 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. 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 centralized controller need to know if routers are able to support the IFIT capabilities. BGP-LS defines a way to advertise topology and associated attributes and capabilities of the nodes in that topology to a centralized controller [RFC7752]. Therefore, this document defines extensions to BGP-LS to advertise the IFIT node capabilities to a centralized controller that can learn the IFIT node capability to determine whether a particular IFIT Option type can be supported in a given network.

1.1. Terminology

BGP-LS: Advertisement of Link-State and TE Information using Border Gateway Protocol

2. Concepts

2.1. IFIT Domain

IFIT is expected to be deployed in a specific domain referred as the IFIT domain. An IFIT domain MAY cross multiple network domains. One network domain MAY consists of multiple IFIT domain. Within the IFIT domain, the IFIT data fields of flow information head MAY be updated by network nodes that the packet traverses.

2.2. IFIT Node Capability Information

Each IFIT 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.ioamteam-ippm-ioam-direct-export] and Enhanced Alternate Marking (EAM) Option-Type [I-D.zhou-ippm-enhanced-alternate-marking]. So IFIT Option Types SHOULD be carried in IFIT node capability advertisment.

3. Advertisement of the IFIT Node Capabilities via BGP-LS

This document describes extensions enabling BGP-LS speakers to announce the IFIT node capabilities of routers in a network to a BGP-LS consumer (e.g. a centralized controller). The centralized controller can leverage this information in enabling IFIT applications in network domains based on IFIT node capabilities and OAM use cases.

3.1. IFIT Node Capability TLV

IFIT Node-Capability TLV is defined as a new Node Attribute TLV that is encoded in the BGP-LS attribute with Node NLRIs [RFC7752]. The IFIT Node Capability TLV is defined as a TLV triplet, i.e. a two-octet Type field, a two-octet Length field, and four-octet Value field. The Type field indicates the type of items in the Value field. The Length field indicates the length of the Value field in octets. The Value field indicates the IFIT Node Capability, which is a 4-octet IFIT Option Type-enabled Flag bitmask.

The IFIT Node Capability TLV has the following format:

     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             |
    +---------------------------------------------------------------+
    |                 IFIT Option Type-enabled Flag                 |
    +---------------------------------------------------------------+

Fig. 1 IFIT Node Capability TLV Format

Type: To be assigned by IANA

Length: A 2-octet field that indicates the length of the value.

IFIT Option Type-enabled Flag: A 4-octet field, which is defined as following:

      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
     +---------------------------------------------------------------+
     |p|i|d|e|m|                       Reserved                      |
     +---------------------------------------------------------------+

p-Flag: IOAM Pre-allocated Trace Option Type-enabled flag. If bit p is set (1), the router is capable of IOAM Pre-allocated Trace [I-D.ietf-ippm-ioam-data].

i-Flag: IOAM Incremental Trace Option Type-enabled flag. If bit i is set (1), the router is capable of IOAM Incremental Tracing [I-D.ietf-ippm-ioam-data].

d-Flag: IOAM DEX Option Type-enabled flag. If bit d is set (1), the router is capable of IOAM DEX [I-D.ioamteam-ippm-ioam-direct-export].

e-Flag: IOAM E2E Option Type-enabled flag. If bit e is set (1), the router is capable of IOAM E2E processing [I-D.ietf-ippm-ioam-data].

m-Flag: Enhanced Alternative Marking enabled flag. If bit m is set (1), then the router is capable of processing Enhanced Alternative Marking packets [I-D.zhou-ippm-enhanced-alternate-marking].

Reserved: Must be set to zero upon transmission and ignored upon receipt.

An IFIT node SHALL be capable of more than one IFIT option types. So in this case, IFIT Option Type-enabled Flag bitmap SHOULD has more than one bit being set.

4. IANA Considerations

4.1. TLV Code Point of the new IFIT Node Capability TLV within Node NLRIs

This document makes the following registrations for a Node Attribute TLV code point for the IFIT Node Capability TLV included with Node NLRIs.

5. Security Considerations

This document introduces new Node Attribute TLVs for the existing Node NLRIs. It does not introduce any new security risks to BGP-LS.

6. Acknowledgements

7. References

7.1. Normative References

7.2. Informative References

Authors' Addresses