Skip to main content

Advertising In-situ Flow Information Telemetry (IFIT) Capabilities in BGP
draft-ietf-idr-bgp-ifit-capabilities-02

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Active".
Authors Giuseppe Fioccola , Ran Pang , Subin Wang , Bruno Decraene , Shunwan Zhuang , Haibo Wang
Last updated 2023-03-09
Replaces draft-wang-idr-bgp-ifit-capabilities
RFC stream Internet Engineering Task Force (IETF)
Formats
Additional resources Mailing list discussion
Stream WG state WG Document
Document shepherd (None)
IESG IESG state I-D Exists
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-ietf-idr-bgp-ifit-capabilities-02
Network Working Group                                        G. Fioccola
Internet-Draft                                                    Huawei
Intended status: Standards Track                                 R. Pang
Expires: 10 September 2023                                  China Unicom
                                                                 S. Wang
                                                           China Telecom
                                                             B. Decraene
                                                                  Orange
                                                               S. Zhuang
                                                                 H. Wang
                                                                  Huawei
                                                            9 March 2023

 Advertising In-situ Flow Information Telemetry (IFIT) Capabilities in
                                  BGP
                draft-ietf-idr-bgp-ifit-capabilities-02

Abstract

   In-situ Flow Information Telemetry (IFIT) refers to network OAM data
   plane on-path telemetry techniques, in particular In-situ OAM (IOAM)
   and Alternate Marking.  This document defines a new BGP Router
   Capability Code 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 helps mitigating
   the leakage threat and facilitating the deployment of IFIT
   measurements on a per-service and on-demand basis.

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 10 September 2023.

Fioccola, et al.        Expires 10 September 2023               [Page 1]
Internet-Draft           BGP for IFIT Capability              March 2023

Copyright Notice

   Copyright (c) 2023 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 Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
     1.2.  Definitions and Acronyms  . . . . . . . . . . . . . . . .   4
   2.  IFIT Domain . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  IFIT Capabilities . . . . . . . . . . . . . . . . . . . . . .   5
     3.1.  Capabilities Advertisement  . . . . . . . . . . . . . . .   5
     3.2.  Error handling  . . . . . . . . . . . . . . . . . . . . .   6
     3.3.  Operation . . . . . . . . . . . . . . . . . . . . . . . .   7
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   6.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .   8
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   8
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   In-situ Flow Information Telemetry (IFIT) denotes a family of flow-
   oriented on-path telemetry techniques, including In-situ OAM (IOAM)
   [RFC9197] and Alternate Marking [RFC9341].  It can provide flow
   information on the entire forwarding path on a per-packet basis in
   real time.

Fioccola, et al.        Expires 10 September 2023               [Page 2]
Internet-Draft           BGP for IFIT Capability              March 2023

   IFIT is a solution focusing on network domains according to [RFC8799]
   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 [RFC8799], 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.

   This document defines a new BGP Router Capability Code 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, such
   as EVPNv4, EVPNv6, L2EVPN(EVPN VPWS and EVPN VPLS) routes, etc.  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 is
   also 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.

   This document defines an IFIT BGP Router Capability Code
   [I-D.ietf-idr-entropy-label].  This allows a distributed solution,
   while [I-D.ietf-idr-sr-policy-ifit] allows to centrally distribute
   Segment Routing (SR) Policies and can be considered as a centralized
   control solution.  Therefore, this document enables the IFIT
   application in networks where no controller is introduced and it
   helps network operators to deploy IFIT in their networks.

   Since BGP can be used to advertise a candidate path of a SR Policy
   ([I-D.ietf-idr-segment-routing-te-policy]), in a SR network it may be
   convenient to advertise IFIT capabilities in BGP as well, as
   specified in this document.  While, in other scenarios, ICMPv6 can
   also be an alternative solution ([I-D.ietf-ippm-ioam-conf-state]).

1.1.  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 [RFC2119],
   RFC 8174 [RFC8174].

Fioccola, et al.        Expires 10 September 2023               [Page 3]
Internet-Draft           BGP for IFIT Capability              March 2023

1.2.  Definitions and Acronyms

   *  IFIT: In-situ Flow Information Telemetry.  This term refers to the
      on-path telemetry techniques also known as In-situ OAM (IOAM)
      [RFC9197] and Alternate Marking [RFC9341].

   *  OAM: Operation Administration and Maintenance

   *  NLRI: Network Layer Reachable Information, the NLRI advertised in
      the BGP UPDATE as defined in [RFC4271] and [RFC4760].

2.  IFIT Domain

   IFIT deployment modes can include monitoring at node-level, tunnel-
   level, and service-level.  The requirement of this document is to
   provide IFIT deployment at service-level, since different services
   may have different IFIT requirements.  With the service-level
   solution, different IFIT methods can be deployed for different VPN
   services.

   The figure shows an implementation example of IFIT application in a
   VPN scenario.

                  +----+                          +----+
      +----+      |    |          +----+          |    |      +----+
      |CE1 |------|PE1 |==========|RR/P|==========|PE2 |------|CE2 |
      +----+      |    |          +----+          |    |      +----+
                  +----+                          +----+
                   |<------------IFIT Domain--------->|
                   |<---------------BGP-------------->|
      |<----------------------------VPN--------------------------->|

         Figure 1. Example of IFIT application in a VPN scenario

                                  Figure 1

   As Figure 1 shows, a traffic flow is sent out from the customer edge
   node CE1 to another customer edge node CE2.  In order to enable IFIT
   application for this flow, the IFIT header must be encapsulated in
   the packet at the ingress provider edge node PE1, referred to as the
   IFIT encapsulating node.  Then, transit nodes in the IFIT domain may
   be able to support the IFIT capabilities in order to inspect IFIT
   extensions and, if needed, to update the IFIT data fields in the
   packet.  Finally, the IFIT data fields must be exported and removed
   at egress provider edge node PE2 that is referred to as the IFIT
   decapsulating node.  This is essential to avoid IFIT data leakage
   outside the controlled domain.

Fioccola, et al.        Expires 10 September 2023               [Page 4]
Internet-Draft           BGP for IFIT Capability              March 2023

   Since the IFIT decapsulating node MUST be able to handle and remove
   the IFIT header, the IFIT encapsulating node MUST know if the IFIT
   decapsulating node supports the IFIT application and, more
   specifically, which capabilities can be enabled.

3.  IFIT Capabilities

   This document defines the IFIT Capabilities as a 32-bit bitmap.  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
       +-+-+-+-+-+----------------------------------------------------+
       |P|I|D|E|M|                      Reserved                      |
       +-+-+-+-+-+----------------------------------------------------+

        Figure 2. IFIT Capabilities

   *  P-Flag: IOAM Pre-allocated Trace Option Type flag.  When set, this
      indicates that the router is capable of IOAM Pre-allocated Trace
      [RFC9197].

   *  I-Flag: IOAM Incremental Trace Option Type flag.  When set, this
      indicates that the router is capable of IOAM Incremental Tracing
      [RFC9197].

   *  D-Flag: IOAM DEX Option Type flag.  When set, this indicates that
      the router is capable of IOAM DEX [RFC9326].

   *  E-Flag: IOAM E2E Option Type flag.  When set, this indicates that
      the router is capable of IOAM E2E processing [RFC9197].

   *  M-Flag: Alternate Marking flag.  When set, this indicates that the
      router is capable of processing Alternative Marking packets
      Alternate Marking [RFC9341].

   *  Reserved: Reserved for future use.  They MUST be set to zero on
      transmission and ignored upon receipt.

3.1.  Capabilities Advertisement

   The BGP Router Capabilities Attribute (RCA attribute, or just RCA) is
   defined in [I-D.ietf-idr-entropy-label].  It is an optional,
   transitive BGP attribute with type code 39.  The RCA has as its data
   a network layer address, representing the next hop of the route the
   RCA accompanies.  The RCA signals potentially useful optimizations,
   so it is desirable to make it transitive; the next hop data is to
   ensure correctness if it traverses BGP speakers that do not

Fioccola, et al.        Expires 10 September 2023               [Page 5]
Internet-Draft           BGP for IFIT Capability              March 2023

   understand the RCA.

   The Attribute Data field of the RCA attribute is encoded as a header
   portion that identifies the originator of the attribute, followed by
   one or more capability TLVs.

   It is modified or deleted when the next-hop is changed, to reflect
   the capabilities of the new next-hop.

   The IFIT Capabilities described above can be encoded as a BGP Router
   Capability Code in the RCA attribute.  It can be included in a BGP
   UPDATE message and indicates that the BGP Next-Hop supports the IFIT
   capabilities for the NLRI advertised in this BGP UPDATE.

   The Network Address of Next Hop, as part of the RCA, is the IPv4 or
   IPv6 Address of the IFIT decapsulating node.

   The IFIT Router Capability is defined below and is a triple
   (Capability Code, Capability Length, Capability Value) aka a TLV:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Capability Code (TBA1)    |        Capability Length      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       IFIT Capabilities       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 3. IFIT Router Capability

   *  Capability Code: a two-octet unsigned binary integer that
      indicates the type of Capability advertised and unambiguously
      identifies an individual capability.  This document defines a new
      Router Capability Code called IFIT Router Capability.  The
      Capability Code is TBA1.

   *  Capability Length: a two-octet unsigned binary integer that
      indicates the length, in octets, of the Capability Value field.
      The length MUST be four octets.

   *  IFIT Capabilities: as defined in Section 3.

3.2.  Error handling

   The IFIT Capabilities is considered malformed and must be disregarded
   if its length is other than four.

Fioccola, et al.        Expires 10 September 2023               [Page 6]
Internet-Draft           BGP for IFIT Capability              March 2023

3.3.  Operation

   A BGP speaker that sends an UPDATE with the BGP Router Capabilities
   Attribute MAY include the IFIT Capabilities if IFIT is configured and
   enabled.  The inclusion of the IFIT Capabilities 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 in the capability value.  This is
   applied for all routes indicated in the same NRLI.

   The IFIT Capabilities MUST reflect the capabilities of the router
   indicated in the BGP Next-Hop. If a BGP speaker sets the BGP Next-Hop
   to an address of a different router, it MUST NOT advertise the IFIT
   Capabilities not supported by this router.  Therefore the IFIT
   Capabilities MUST be re-advertised according to the new BGP Next-Hop.

   In case of large networks, the IFIT domain may span across multiple
   Autonomous Systems (ASes) and hence the IFIT Capabilities need to be
   able to cross AS boundaries if configured to do so.  In this case, it
   is also possible to pass this information between BGP clusters to
   keep the IFIT methods consistent.  BGP Link-State (BGP-LS) may allow
   to bring the information back to a centralized controller as well.

4.  IANA Considerations

   The IANA is requested to make the assignments in the "BGP Router
   Capability Codes" registry for the IFIT Router Capability:

               +=======+===================+===============+
               | Value | Description       | Reference     |
               +=======+===================+===============+
               | TBA1  | IFIT Capabilities | This document |
               +-------+-------------------+---------------+

                                  Table 1

5.  Security Considerations

   This document defines a new BGP Router Capability Code to advertise
   the IFIT capabilities.  It does not introduce any new security
   considerations beyond the one described in
   [I-D.ietf-idr-entropy-label].

Fioccola, et al.        Expires 10 September 2023               [Page 7]
Internet-Draft           BGP for IFIT Capability              March 2023

   IFIT methods are applied within a controlled domain and solutions
   MUST be taken to ensure that the IFIT data are properly propagated to
   avoid malicious attacks.  Both IOAM method [RFC9197] and Alternate
   Marking [RFC9341] [RFC9343] respectively discusses that the
   implementation of both methods MUST be within a controlled domain.

   The BGP Router Capability Attribute being a transitive attribute in
   order to facilitate early deployments it may leak outside of the
   domain if both the NLRI carrying this capability is advertised
   outside of the domain and the ASBR does not support
   [I-D.ietf-idr-entropy-label].  In general, it is not an issue for
   IFIT because the only information about the capabilities would be
   leaked.  However if any capability leakage must be avoided, one must
   ensure that all the border routers must support the BGP Capability
   code feature.

6.  Contributors

   The following people made significant contributions to this document:

   Yali Wang
   Huawei
   Email: wangyali11@huawei.com

   Yunan Gu
   Huawei
   Email: guyunan@huawei.com

   Tianran Zhou
   Huawei
   Email: zhoutianran@huawei.com

   Weidong Li
   Huawei
   Email: poly.li@huawei.com

7.  Acknowledgements

   The authors would like to thank Ketan Talaulikar, Haoyu Song, Jie
   Dong, Robin Li, Jeffrey Haas, Robert Raszuk, Zongpeng Du, Yisong Liu,
   Yongqing Zhu, Aijun Wang, Fan Yang for their reviews and suggestions.

8.  References

8.1.  Normative References

Fioccola, et al.        Expires 10 September 2023               [Page 8]
Internet-Draft           BGP for IFIT Capability              March 2023

   [I-D.ietf-idr-entropy-label]
              Decraene, B., Scudder, J., Henderickx, W., Kompella, K.,
              satyamoh@cisco.com, Uttaro, J., and B. Wen, "BGP Router
              Capabilities Attribute", Work in Progress, Internet-Draft,
              draft-ietf-idr-entropy-label-03, 20 February 2023,
              <https://datatracker.ietf.org/doc/html/draft-ietf-idr-
              entropy-label-03>.

   [I-D.ietf-idr-segment-routing-te-policy]
              Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P.,
              Jain, D., and S. Lin, "Advertising Segment Routing
              Policies in BGP", Work in Progress, Internet-Draft, draft-
              ietf-idr-segment-routing-te-policy-20, 27 July 2022,
              <https://datatracker.ietf.org/doc/html/draft-ietf-idr-
              segment-routing-te-policy-20>.

   [I-D.ietf-idr-sr-policy-ifit]
              Qin, F., Yuan, H., Yang, S., Zhou, T., and G. Fioccola,
              "BGP SR Policy Extensions to Enable IFIT", Work in
              Progress, Internet-Draft, draft-ietf-idr-sr-policy-ifit-
              05, 24 October 2022,
              <https://datatracker.ietf.org/doc/html/draft-ietf-idr-sr-
              policy-ifit-05>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC9197]  Brockners, F., Ed., Bhandari, S., Ed., and T. Mizrahi,
              Ed., "Data Fields for In Situ Operations, Administration,
              and Maintenance (IOAM)", RFC 9197, DOI 10.17487/RFC9197,
              May 2022, <https://www.rfc-editor.org/info/rfc9197>.

   [RFC9326]  Song, H., Gafni, B., Brockners, F., Bhandari, S., and T.
              Mizrahi, "In Situ Operations, Administration, and
              Maintenance (IOAM) Direct Exporting", RFC 9326,
              DOI 10.17487/RFC9326, November 2022,
              <https://www.rfc-editor.org/info/rfc9326>.

   [RFC9341]  Fioccola, G., Ed., Cociglio, M., Mirsky, G., Mizrahi, T.,
              and T. Zhou, "Alternate-Marking Method", RFC 9341,
              DOI 10.17487/RFC9341, December 2022,
              <https://www.rfc-editor.org/info/rfc9341>.

Fioccola, et al.        Expires 10 September 2023               [Page 9]
Internet-Draft           BGP for IFIT Capability              March 2023

   [RFC9343]  Fioccola, G., Zhou, T., Cociglio, M., Qin, F., and R.
              Pang, "IPv6 Application of the Alternate-Marking Method",
              RFC 9343, DOI 10.17487/RFC9343, December 2022,
              <https://www.rfc-editor.org/info/rfc9343>.

8.2.  Informative References

   [I-D.ietf-ippm-ioam-conf-state]
              Min, X., Mirsky, G., and L. Bo, "Echo Request/Reply for
              Enabled In-situ OAM Capabilities", Work in Progress,
              Internet-Draft, draft-ietf-ippm-ioam-conf-state-10, 21
              November 2022, <https://datatracker.ietf.org/doc/html/
              draft-ietf-ippm-ioam-conf-state-10>.

   [RFC4271]  Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
              Border Gateway Protocol 4 (BGP-4)", RFC 4271,
              DOI 10.17487/RFC4271, January 2006,
              <https://www.rfc-editor.org/info/rfc4271>.

   [RFC4760]  Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
              "Multiprotocol Extensions for BGP-4", RFC 4760,
              DOI 10.17487/RFC4760, January 2007,
              <https://www.rfc-editor.org/info/rfc4760>.

   [RFC8799]  Carpenter, B. and B. Liu, "Limited Domains and Internet
              Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020,
              <https://www.rfc-editor.org/info/rfc8799>.

Authors' Addresses

   Giuseppe Fioccola
   Huawei
   Munich
   Germany
   Email: giuseppe.fioccola@huawei.com

   Ran Pang
   China Unicom
   Beijing
   China
   Email: pangran@chinaunicom.cn

   Subin Wang
   China Telecom
   Guangzhou
   China

Fioccola, et al.        Expires 10 September 2023              [Page 10]
Internet-Draft           BGP for IFIT Capability              March 2023

   Email: wangsb6@chinatelecom.cn

   Bruno Decraene
   Orange
   Email: bruno.decraene@orange.com

   Shunwan Zhuang
   Huawei
   Beijing
   China
   Email: zhuangshunwan@huawei.com

   Hiabo Wang
   Huawei
   Beijing
   China
   Email: rainsword.wang@huawei.com

Fioccola, et al.        Expires 10 September 2023              [Page 11]