BGP Extension for Advertising In-situ Flow Information Telemetry (IFIT) Capabilities
draft-wang-idr-bgp-ifit-capabilities-02

The information below is for an old version of the document
Document Type Active Internet-Draft (individual)
Authors Yali Wang  , Shunwan Zhuang  , Yunan Gu  , Ran Pang 
Last updated 2021-02-22 (latest revision 2020-10-27)
Stream (None)
Formats plain text xml pdf htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                            Y. Wang
Internet-Draft                                                 S. Zhuang
Intended status: Standards Track                                   Y. Gu
Expires: August 26, 2021                                          Huawei
                                                                 R. Pang
                                                            China Unicom
                                                       February 22, 2021

BGP Extension for Advertising In-situ Flow Information Telemetry (IFIT)
                              Capabilities
                draft-wang-idr-bgp-ifit-capabilities-02

Abstract

   This 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.

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].

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 August 26, 2021.

Wang, et al.             Expires August 26, 2021                [Page 1]
Internet-Draft           BGP for IFIT Capability           February 2021

Copyright Notice

   Copyright (c) 2021 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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Definitions and Acronyms  . . . . . . . . . . . . . . . . . .   3
   3.  IFIT Capabilities . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Option 1: Extension to BGP Extended Community for IFIT-
       Capability Advertisement  . . . . . . . . . . . . . . . . . .   4
     4.1.  IPv4-Address-Specific IFIT Tail Community . . . . . . . .   4
     4.2.  IPv6-Address-Specific IFIT Tail Community . . . . . . . .   5
   5.  Option 2: Extension to BGP Next-Hop Capability for IFIT-
       Capability Advertisement  . . . . . . . . . . . . . . . . . .   5
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   8.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .   7
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   7
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     10.1.  Normative References . . . . . . . . . . . . . . . . . .   7
     10.2.  Informative References . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   In-situ Flow Information Telemetry (IFIT) denotes a family of flow-
   oriented on-path telemetry techniques, including In-situ OAM (IOAM)
   [I-D.ietf-ippm-ioam-data] and Alternate Marking [RFC8321].  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

Wang, et al.             Expires August 26, 2021                [Page 2]
Internet-Draft           BGP for IFIT Capability           February 2021

   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.

2.  Definitions and Acronyms

   o  IFIT: In-situ Flow Information Telemetry

   o  OAM: Operation Administration and Maintenance

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

3.  IFIT Capabilities

   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

   o  P-Flag: IOAM Pre-allocated Trace Option Type flag.  When set, this
      indicates that the router is capable of IOAM Pre-allocated Trace
      [I-D.ietf-ippm-ioam-data].

   o  I-Flag: IOAM Incremental Trace Option Type flag.  When set, this
      indicates that the router is capable of IOAM Incremental Tracing
      [I-D.ietf-ippm-ioam-data].

Wang, et al.             Expires August 26, 2021                [Page 3]
Internet-Draft           BGP for IFIT Capability           February 2021

   o  D-Flag: IOAM DEX Option Type flag.  When set, this indicates that
      the router is capable of IOAM DEX
      [I-D.ioamteam-ippm-ioam-direct-export].

   o  E-Flag: IOAM E2E Option Type flag.  When set, this indicates that
      the router is capable of IOAM E2E processing
      [I-D.ietf-ippm-ioam-data].

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

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

4.  Option 1: Extension to BGP Extended Community for IFIT-Capability
    Advertisement

4.1.  IPv4-Address-Specific IFIT Tail Community

   For IPv4 networks [RFC4360], 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.

       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 (TBA1)|   Originating IPv4 Address    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Originating IPv4 Address(cont.)|     IFIT Capabilities         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           Figure 2. IPv4-Address-Specific IFIT Tail Community

   o  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 registries

   o  IFIT Capabilities: A 2 octets field. as defined in previous
      setion.

Wang, et al.             Expires August 26, 2021                [Page 4]
Internet-Draft           BGP for IFIT Capability           February 2021

4.2.  IPv6-Address-Specific IFIT Tail Community

   For IPv6 networks [RFC5701], 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.

       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 (TBA2)|   Originating IPv6 Address    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               Originating IPv6 Address (cont.)                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               Originating IPv6 Address (cont.)                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               Originating IPv6 Address (cont.)                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Originating IPv6 Address(cont.)|     IFIT Capabilities         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          Figure 3. IPv6-Address-Specific IFIT Tail Community

   o  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.

   o  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.

5.  Option 2: Extension to BGP Next-Hop Capability for IFIT-Capability
    Advertisement

   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 IFIT Next-Hop Capability is a triple (Capability Code, Capability
   Length, Capability Value) aka a TLV:

Wang, et al.             Expires August 26, 2021                [Page 5]
Internet-Draft           BGP for IFIT Capability           February 2021

       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 (TBA3)    |        Capability Length      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       IFIT Capabilities       | ORIG. IP Address(4/16 octets) |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Figure 4. BGP Next-Hop Capability

   o  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.

   o  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.

   o  IFIT Capabilities: as defined in previous setion.

   o  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.

6.  IANA Considerations

   The IANA is requested to make the assignments for IPv4-Address-
   Specific IFIT Tail Community and IPv6-Address-Specific IFIT Tail
   Community:

   +-------+-------------------------------------------+---------------+
   | Value | Description                               | Reference     |
   +-------+-------------------------------------------+---------------+
   | TBA1  | IPv4-Address-Specific IFIT Tail Community | This document |
   | TBA2  | IPv6-Address-Specific IFIT Tail Community | This document |
   +-------+-------------------------------------------+---------------+

Wang, et al.             Expires August 26, 2021                [Page 6]
Internet-Draft           BGP for IFIT Capability           February 2021

   The IANA is requested to make the assignments for IFIT Next-Hop
   Capability:

               +-------+-------------------+---------------+
               | Value | Description       | Reference     |
               +-------+-------------------+---------------+
               | TBA3  | IFIT Capabilities | This document |
               +-------+-------------------+---------------+

7.  Security Considerations

   This 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.

8.  Contributors

   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

9.  Acknowledgements

   TBD

10.  References

10.1.  Normative References

   [I-D.ietf-idr-next-hop-capability]
              Decraene, B., Kompella, K., and W. Henderickx, "BGP Next-
              Hop dependent capabilities", draft-ietf-idr-next-hop-
              capability-06 (work in progress), October 2020.

   [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>.

Wang, et al.             Expires August 26, 2021                [Page 7]
Internet-Draft           BGP for IFIT Capability           February 2021

   [RFC4360]  Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
              Communities Attribute", RFC 4360, DOI 10.17487/RFC4360,
              February 2006, <https://www.rfc-editor.org/info/rfc4360>.

   [RFC5701]  Rekhter, Y., "IPv6 Address Specific BGP Extended Community
              Attribute", RFC 5701, DOI 10.17487/RFC5701, November 2009,
              <https://www.rfc-editor.org/info/rfc5701>.

10.2.  Informative References

   [I-D.ietf-ippm-ioam-data]
              Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields
              for In-situ OAM", draft-ietf-ippm-ioam-data-11 (work in
              progress), November 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", draft-ioamteam-ippm-ioam-direct-
              export-00 (work in progress), October 2019.

   [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>.

   [RFC8321]  Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli,
              L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi,
              "Alternate-Marking Method for Passive and Hybrid
              Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321,
              January 2018, <https://www.rfc-editor.org/info/rfc8321>.

Authors' Addresses

   Yali Wang
   Huawei
   Beijing
   China

   Email: wangyali11@huawei.com

Wang, et al.             Expires August 26, 2021                [Page 8]
Internet-Draft           BGP for IFIT Capability           February 2021

   Shunwan Zhuang
   Huawei
   Beijing
   China

   Email: zhuangshunwan@huawei.com

   Yunan Gu
   Huawei
   Beijing
   China

   Email: guyunan@huawei.com

   Ran Pang
   China Unicom
   Beijing
   China

   Email: pangran@chinaunicom.cn

Wang, et al.             Expires August 26, 2021                [Page 9]