BGP Extension for Advertising In-situ Flow Information Telemetry (IFIT) Capabilities
draft-ietf-idr-bgp-ifit-capabilities-01
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 | 2022-09-08 | ||
| 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-01
Network Working Group G. Fioccola
Internet-Draft Huawei
Intended status: Standards Track R. Pang
Expires: 12 March 2023 China Unicom
S. Wang
China Telecom
B. Decraene
Orange
S. Zhuang
H. Wang
Huawei
8 September 2022
BGP Extension for Advertising In-situ Flow Information Telemetry (IFIT)
Capabilities
draft-ietf-idr-bgp-ifit-capabilities-01
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 extensions to Border
Gateway Protocol (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.
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 12 March 2023.
Fioccola, et al. Expires 12 March 2023 [Page 1]
Internet-Draft BGP for IFIT Capability September 2022
Copyright Notice
Copyright (c) 2022 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 . . . . . . . . . . . . . . . . . . 4
1.2. Definitions and Acronyms . . . . . . . . . . . . . . . . 4
2. IFIT Domain . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. IFIT Capabilities . . . . . . . . . . . . . . . . . . . . . . 5
4. BGP Next-Hop IFIT Capability Advertisement . . . . . . . . . 6
5. IFIT Attribute Operation . . . . . . . . . . . . . . . . . . 7
6. Head-to-Tail and Hop-by-Hop Mechanisms . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
8. Security Considerations . . . . . . . . . . . . . . . . . . . 8
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
11.1. Normative References . . . . . . . . . . . . . . . . . . 9
11.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 [I-D.ietf-ippm-rfc8321bis]. It can
provide flow information on the entire forwarding path on a per-
packet basis in real time.
Fioccola, et al. Expires 12 March 2023 [Page 2]
Internet-Draft BGP for IFIT Capability September 2022
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 introduces extensions to Border Gateway Protocol (BGP)
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 would be 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 Next-Hop Capability Attribute according
to [I-D.ietf-idr-next-hop-capability]. It allows a distributed
solution that does not require the participation of centralized
control element, 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]).
Fioccola, et al. Expires 12 March 2023 [Page 3]
Internet-Draft BGP for IFIT Capability September 2022
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].
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 [I-D.ietf-ippm-rfc8321bis].
* 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
As the figure 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
Fioccola, et al. Expires 12 March 2023 [Page 4]
Internet-Draft BGP for IFIT Capability September 2022
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.
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 formed of 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
[I-D.ioamteam-ippm-ioam-direct-export].
* 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 [I-D.ietf-ippm-rfc8321bis].
* Reserved: Reserved for future use. They MUST be set to zero upon
transmission and ignored upon receipt.
Fioccola, et al. Expires 12 March 2023 [Page 5]
Internet-Draft BGP for IFIT Capability September 2022
4. BGP Next-Hop IFIT Capability Advertisement
The BGP Next-Hop Capability Attribute
[I-D.ietf-idr-next-hop-capability] is a non-transitive BGP attribute
and consists of a set of Next-Hop Capabilities. 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 Next-
Hop IFIT Capability Attribute. It can be included in a BGP UPDATE
message and indicates that the BGP Next-Hop supports the IFIT
capability for the NLRI advertised in this BGP UPDATE.
The IFIT Next-Hop 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ORIG. IP Address(4/16 octets) |
| ... |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3. BGP Next-Hop Capability
* 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 TBA1.
* 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.
* IFIT Capabilities: as defined in previous section. It should be
reserved in [I-D.ietf-idr-next-hop-capability].
* 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.
Fioccola, et al. Expires 12 March 2023 [Page 6]
Internet-Draft BGP for IFIT Capability September 2022
5. IFIT Attribute Operation
A BGP speaker that sends an UPDATE with the BGP Next-Hop Capability
Attribute MAY include the IFIT Next-Hop Capability, if IFIT is
configured and enabled. 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 in the
capability value. This is applied for all routes indicated in the
same NRLI.
The IFIT Next-Hop capability MUST reflect the capability 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 Next-Hop Capability not supported by this router. Therefore
the IFIT capability 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 capability 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.
6. Head-to-Tail and Hop-by-Hop Mechanisms
When all devices are upgraded to support IFIT, the hop-by-hop
mechanism can also be suitable.
In the current stage, where new and old devices are deployed
together, it is necessary to ensure that the tail node can properly
decapsulate the IFIT header, so it is needed an advertisement
mechanism from the head node to the tail node.
Further, different services on the egress node may have different
IFIT requirements, so the capability advertisement from the head node
to the tail node is always required.
However, it is worth noting that, once defined, hop-by-hop and head-
to-tail mechanisms can eventually be used together without conflict.
7. IANA Considerations
The IANA is requested to make the assignments for IFIT Next-Hop
Capability:
Fioccola, et al. Expires 12 March 2023 [Page 7]
Internet-Draft BGP for IFIT Capability September 2022
+=======+===================+===============+
| Value | Description | Reference |
+=======+===================+===============+
| TBA1 | IFIT Capabilities | This document |
+-------+-------------------+---------------+
Table 1
8. Security Considerations
This document defines extensions to BGP Next-Hop Capability to
advertise the IFIT capabilities. It does not introduce any new
security risks to BGP, as also mentioned in
[I-D.ietf-idr-next-hop-capability].
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 method [I-D.ietf-6man-ipv6-alt-mark] respectively discussed
that the implementation of both methods MUST be within a controlled
domain.
9. 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
10. 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.
Fioccola, et al. Expires 12 March 2023 [Page 8]
Internet-Draft BGP for IFIT Capability September 2022
11. References
11.1. Normative References
[I-D.ietf-6man-ipv6-alt-mark]
Fioccola, G., Zhou, T., Cociglio, M., Qin, F., and R.
Pang, "IPv6 Application of the Alternate Marking Method",
Work in Progress, Internet-Draft, draft-ietf-6man-ipv6-
alt-mark-16, 1 July 2022,
<https://www.ietf.org/archive/id/draft-ietf-6man-ipv6-alt-
mark-16.txt>.
[I-D.ietf-idr-next-hop-capability]
Decraene, B., Kompella, K., and W. Henderickx, "BGP Next-
Hop dependent capabilities", Work in Progress, Internet-
Draft, draft-ietf-idr-next-hop-capability-08, 8 June 2022,
<https://www.ietf.org/archive/id/draft-ietf-idr-next-hop-
capability-08.txt>.
[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://www.ietf.org/archive/id/draft-ietf-idr-segment-
routing-te-policy-20.txt>.
[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-
04, 7 July 2022, <https://www.ietf.org/archive/id/draft-
ietf-idr-sr-policy-ifit-04.txt>.
[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>.
Fioccola, et al. Expires 12 March 2023 [Page 9]
Internet-Draft BGP for IFIT Capability September 2022
11.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-04, 6 July
2022, <https://www.ietf.org/archive/id/draft-ietf-ippm-
ioam-conf-state-04.txt>.
[I-D.ietf-ippm-rfc8321bis]
Fioccola, G., Cociglio, M., Mirsky, G., Mizrahi, T., and
T. Zhou, "Alternate-Marking Method", Work in Progress,
Internet-Draft, draft-ietf-ippm-rfc8321bis-03, 25 July
2022, <https://www.ietf.org/archive/id/draft-ietf-ippm-
rfc8321bis-03.txt>.
[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", Work in Progress, Internet-Draft,
draft-ioamteam-ippm-ioam-direct-export-00, 12 October
2019, <https://www.ietf.org/archive/id/draft-ioamteam-
ippm-ioam-direct-export-00.txt>.
[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
Fioccola, et al. Expires 12 March 2023 [Page 10]
Internet-Draft BGP for IFIT Capability September 2022
Ran Pang
China Unicom
Beijing
China
Email: pangran@chinaunicom.cn
Subin Wang
China Telecom
Guangzhou
China
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 12 March 2023 [Page 11]