IDR F. Qin
Internet-Draft China Mobile
Intended status: Standards Track H. Yuan
Expires: March 6, 2021 UnionPay
T. Zhou
G. Fioccola
Y. Wang
Huawei
September 2, 2020
BGP SR Policy Extensions to Enable IFIT
draft-qin-idr-sr-policy-ifit-03
Abstract
Segment Routing (SR) policy is a set of candidate SR paths consisting
of one or more segment lists and necessary path attributes. It
enables instantiation of an ordered list of segments with a specific
intent for traffic steering. In-situ Flow Information Telemetry
(IFIT) refers to network OAM data plane on-path telemetry techniques,
in particular the most popular are In-situ OAM (IOAM) and Alternate
Marking. This document defines extensions to BGP to distribute SR
policies carrying IFIT information. So that IFIT methods can be
enabled automatically when the SR policy is applied.
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 March 6, 2021.
Qin, et al. Expires March 6, 2021 [Page 1]
Internet-Draft bgp-sr-policy-ifit September 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. IFIT Attributes in SR Policy . . . . . . . . . . . . . . . . 4
4. SR Policy for IOAM . . . . . . . . . . . . . . . . . . . . . 5
4.1. IOAM Pre-allocated Trace Option Sub-TLV . . . . . . . . . 5
4.2. IOAM Incremental Trace Option Sub-TLV . . . . . . . . . . 6
4.3. IOAM Directly Export Option Sub-TLV . . . . . . . . . . . 6
4.4. IOAM Edge-to-Edge Option Sub-TLV . . . . . . . . . . . . 7
5. SR Policy for Enhanced Alternate Marking . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . 11
Appendix A. . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction
Segment Routing (SR) policy [I-D.ietf-spring-segment-routing-policy]
is a set of candidate SR paths consisting of one or more segment
lists and necessary path attributes. It enables instantiation of an
ordered list of segments with a specific intent for traffic steering.
In-situ Flow Information Telemetry (IFIT) denotes a family of flow-
oriented on-path telemetry techniques (e.g. IOAM, Alternate
Marking), which can provide high-precision flow insight and real-time
network issue notification (e.g., jitter, latency, packet loss).In
particular, IFIT refers to network OAM data plane on-path telemetry
techniques, including In-situ OAM (IOAM) [I-D.ietf-ippm-ioam-data]
Qin, et al. Expires March 6, 2021 [Page 2]
Internet-Draft bgp-sr-policy-ifit September 2020
and Alternate Marking [RFC8321]. It can provide flow information on
the entire forwarding path on a per- packet basis in real time.
An automatic network requires the Service Level Agreement (SLA)
monitoring on the deployed service. So that the system can quickly
detect the SLA violation or the performance degradation, hence to
change the service deployment. For this reason, the SR policy native
IFIT can facilitate the closed loop control and enable the automation
of SR service.
This document defines extensions to Border Gateway Protocol (BGP) to
distribute SR policies carrying IFIT information. So that IFIT
behavior can be enabled automatically when the SR policy is applied.
This BGP extension allows to signal the IFIT capabilities together
with the SR-policy. In this way IFIT methods are automatically
activated and running. The flexibility and dynamicity of the IFIT
applications are given by the use of additional functions on the
controller and on the network nodes, but this is out of scope here.
2. Motivation
IFIT Methods are being introduced in multiple protocols and below is
a proper picture of the relevant documents for Segment Routing.
Indeed the IFIT methods are becoming mature for Segment Routing over
the MPLS data plane (SR-MPLS) and Segment Routing over IPv6 data
plane (SRv6), that is the main focus of this draft:
IOAM: the reference documents for the data plane are
[I-D.ietf-ippm-ioam-ipv6-options] for SRv6 and
[I-D.gandhi-mpls-ioam-sr] for SR-MPLS.
Alternate Marking: the reference documents for the data plane are
[I-D.ietf-6man-ipv6-alt-mark] for SRv6 and
[I-D.ietf-mpls-rfc6374-sfl], [I-D.gandhi-mpls-rfc6374-sr] for SR-
MPLS.
The definition of these data plane IFIT methods for SR-MPLS and SRv6
imply requirements for various routing protocols, such as BGP, and
this document aims to define BGP extensions to distribute SR policies
carrying IFIT information. This allows to signal the IFIT
capabilities so IFIT methods are automatically configured and ready
to run when the SR Policy candidate paths are distributed through
BGP.
It is to be noted that, for PCEP, [I-D.chen-pce-pcep-ifit] proposes
the extensions to PCEP to distribute paths carrying IFIT information
and therefore to enable IFIT methods for SR policy too.
Qin, et al. Expires March 6, 2021 [Page 3]
Internet-Draft bgp-sr-policy-ifit September 2020
3. IFIT Attributes in SR Policy
As defined in [I-D.ietf-idr-segment-routing-te-policy], the SR Policy
encoding structure is as follows:
SR Policy SAFI NLRI: <Distinguisher, Policy-Color, Endpoint>
Attributes:
Tunnel Encaps Attribute (23)
Tunnel Type: SR Policy
Binding SID
Preference
Priority
Policy Name
Explicit NULL Label Policy (ENLP)
Segment List
Weight
Segment
Segment
...
...
A candidate path includes multiple SR paths, each of which is
specified by a segment list. IFIT can be applied to the candidate
path, so that all the SR paths can be monitored in the same way. The
new SR Policy encoding structure is expressed as below:
SR Policy SAFI NLRI: <Distinguisher, Policy-Color, Endpoint>
Attributes:
Tunnel Encaps Attribute (23)
Tunnel Type: SR Policy
Binding SID
Preference
Priority
Policy Name
Explicit NULL Label Policy (ENLP)
IFIT Attributes
Segment List
Weight
Segment
Segment
...
...
IFIT attributes can be attached at the candidate path level as sub-
TLVs. There may be different IFIT tools. The following sections
will describe the requirement and usage of different IFIT tools, and
define the corresponding sub-TLV encoding in BGP.
Qin, et al. Expires March 6, 2021 [Page 4]
Internet-Draft bgp-sr-policy-ifit September 2020
Note that the IFIT attributes here described can also be generalized
and included as sub-TLVs for other SAFIs and NLRIs.
4. SR Policy for IOAM
In-situ Operations, Administration, and Maintenance (IOAM)
[I-D.ietf-ippm-ioam-data] records operational and telemetry
information in the packet while the packet traverses a path between
two points in the network. In terms of the classification given in
RFC 7799 [RFC7799] IOAM could be categorized as Hybrid Type 1. IOAM
mechanisms can be leveraged where active OAM do not apply or do not
offer the desired results.
When SR policy enables the IOAM, the IOAM header will be inserted
into every packet of the traffic that is steered into the SR paths.
This document aims to define the control plane. While a relevant
document for the data plane is [I-D.ietf-ippm-ioam-ipv6-options] for
Segment Routing over IPv6 data plane (SRv6).
4.1. IOAM Pre-allocated Trace Option Sub-TLV
The IOAM tracing data is expected to be collected at every node that
a packet traverses to ensure visibility into the entire path a packet
takes within an IOAM domain. The preallocated tracing option will
create pre-allocated space for each node to populate its information.
The format of IOAM pre-allocated trace option sub-TLV is defined as
follows:
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 | Namespace ID |
+---------------+---------------+--------------+--------+-------+
| IOAM Trace Type | Flags | Rsvd |
+----------------------------------------------+--------+-------+
Fig. 1 IOAM Pre-allocated Trace Option Sub-TLV
Where:
Type: to be assigned by IANA.
Length: the total length of the value field not including Type and
Length fields.
Qin, et al. Expires March 6, 2021 [Page 5]
Internet-Draft bgp-sr-policy-ifit September 2020
Namespace ID: A 16-bit identifier of an IOAM-Namespace. The
definition is the same as described in section 4.4 of
[I-D.ietf-ippm-ioam-data].
IOAM Trace Type: A 24-bit identifier which specifies which data types
are used in the node data list. The definition is the same as
described in section 4.4 of [I-D.ietf-ippm-ioam-data].
Flags: A 4-bit field. The definition is the same as described in
[I-D.ietf-ippm-ioam-flags] and section 4.4 of
[I-D.ietf-ippm-ioam-data].
Rsvd: A 4-bit field reserved for further usage. It MUST be zero.
4.2. IOAM Incremental Trace Option Sub-TLV
The incremental tracing option contains a variable node data fields
where each node allocates and pushes its node data immediately
following the option header.
The format of IOAM incremental trace option sub-TLV is defined as
follows:
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 | Namespace ID |
+---------------+---------------+--------------+--------+-------+
| IOAM Trace Type | Flags | Rsvd |
+----------------------------------------------+--------+-------+
Fig. 2 IOAM Incremental Trace Option Sub-TLV
Where:
Type: to be assigned by IANA.
Length: the total length of the value field not including Type and
Length fields.
All the other fields definistion is the same as the pre-allocated
trace option sub-TLV in section 4.1.
4.3. IOAM Directly Export Option Sub-TLV
IOAM directly export option is used as a trigger for IOAM data to be
directly exported to a collector without being pushed into in-flight
data packets.
Qin, et al. Expires March 6, 2021 [Page 6]
Internet-Draft bgp-sr-policy-ifit September 2020
The format of IOAM directly export option sub-TLV is defined as
follows:
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 |
+-----------------------------------------------+---------------+
| Namespace ID | Flags |
+-------------------------------+---------------+---------------+
| IOAM Trace Type | Rsvd |
+-----------------------------------------------+---------------+
| Flow ID |
+---------------------------------------------------------------+
Fig. 3 IOAM Directly Export Option Sub-TLV
Where:
Type: to be assigned by IANA.
Length: the total length of the value field not including Type and
Length fields.
Namespace ID: A 16-bit identifier of an IOAM-Namespace. The
definition is the same as described in section 4.4 of
[I-D.ietf-ippm-ioam-data].
IOAM Trace Type: A 24-bit identifier which specifies which data types
are used in the node data list. The definition is the same as
described in section 4.4 of [I-D.ietf-ippm-ioam-data].
Flags: A 16-bit field. The definition is the same as described in
section 3.2 of [I-D.ietf-ippm-ioam-direct-export].
Flow ID: A 32-bit flow identifier. The definition is the same as
described in section 3.2 of [I-D.ietf-ippm-ioam-direct-export].
Rsvd: A 4-bit field reserved for further usage. It MUST be zero.
4.4. IOAM Edge-to-Edge Option Sub-TLV
The IOAM edge to edge option is to carry data that is added by the
IOAM encapsulating node and interpreted by IOAM decapsulating node.
The format of IOAM edge-to-edge option sub-TLV is defined as follows:
Qin, et al. Expires March 6, 2021 [Page 7]
Internet-Draft bgp-sr-policy-ifit September 2020
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 |
+-----------------------------------------------+---------------+
| Namespace ID | IOAM E2E Type |
+-------------------------------+-------------------------------+
Fig. 4 IOAM Edge-to-Edge Option Sub-TLV
Where:
Type: to be assigned by IANA.
Length: the total length of the value field not including Type and
Length fields.
Namespace ID: A 16-bit identifier of an IOAM-Namespace. The
definition is the same as described in section 4.6 of
[I-D.ietf-ippm-ioam-data].
IOAM E2E Type: A 16-bit identifier which specifies which data types
are used in the E2E option data. The definition is the same as
described in section 4.6 of [I-D.ietf-ippm-ioam-data].
5. SR Policy for Enhanced Alternate Marking
The Alternate Marking [RFC8321]technique is an hybrid performance
measurement method, per RFC 7799 [RFC7799] classification of
measurement methods. Because this method is based on marking
consecutive batches of packets. It can be used to measure packet
loss, latency, and jitter on live traffic.
This document aims to define the control plane. While a relevant
document for the data plane is [I-D.ietf-6man-ipv6-alt-mark] for
Segment Routing over IPv6 data plane (SRv6).
The format of Enhanced Alternate Marking (EAM) sub-TLV is defined as
follows:
Qin, et al. Expires March 6, 2021 [Page 8]
Internet-Draft bgp-sr-policy-ifit September 2020
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 |
+-------------------------------+-------+-------+-------+-------+
| FlowMonID | Period | Rsvd |
+---------------------------------------+---------------+-------+
Fig. 5 Enhanced Alternate Marking Sub-TLV
Where:
Type: to be assigned by IANA.
Length: the total length of the value field not including Type and
Length fields.
FlowMonID: A 20-bit identifier to uniquely identify a monitored flow
within the measurement domain. The definition is the same as
described in section 5.3 of [I-D.ietf-6man-ipv6-alt-mark].
Period: Time interval between two alternate marking period. The unit
is second.
Rsvd: A 4-bit field reserved for further usage. It MUST be zero.
6. IANA Considerations
This document defines new sub-TLVs in the registry "BGP Tunnel
Encapsulation Attribute sub-TLVs" to be assigned by IANA:
Codepoint Description Reference
-------------------------------------------------------------
TBD1 IOAM Pre-allocated Trace This document
Option Sub-TLV
TBD2 IOAM Incremental Trace This document
Option Sub-TLV
TBD3 IOAM Directly Export This document
Option Sub-TLV
TBD4 IOAM Edge-to-Edge This document
Option Sub-TLV
TBD5 Enhanced Alternate Marking This document
Sub-TLV
Qin, et al. Expires March 6, 2021 [Page 9]
Internet-Draft bgp-sr-policy-ifit September 2020
7. Security Considerations
The security mechanisms of the base BGP security model apply to the
extensions described in this document as well. See the Security
Considerations section of [I-D.ietf-idr-segment-routing-te-policy].
SR operates within a trusted SR domain RFC 8402 [RFC8402] and its
security considerations also apply to BGP sessions when carrying SR
Policy information. The isolation of BGP SR Policy SAFI peering
sessions may be used to ensure that the SR Policy information is not
advertised outside the SR domain. Additionally, only trusted nodes
(that include both routers and controller applications) within the SR
domain must be configured to receive such information.
Implementation of IFIT methods (IOAM and Alternate Marking) are
mindful of security and privacy concerns, as explained in
[I-D.ietf-ippm-ioam-data] and RFC 8321 [RFC8321]. Anyway incorrect
IFIT parameters in the BGP extension SHOULD not have an adverse
effect on the SR Policy as well as on the network, since it affects
only the operation of the telemetry methodology.
8. Acknowledgements
The authors of this document would like to thank Ketan Talaulikar and
Joel Halpern for their comments and review of this document.
9. References
9.1. Normative References
[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>.
[RFC7799] Morton, A., "Active and Passive Metrics and Methods (with
Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799,
May 2016, <https://www.rfc-editor.org/info/rfc7799>.
[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>.
Qin, et al. Expires March 6, 2021 [Page 10]
Internet-Draft bgp-sr-policy-ifit September 2020
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>.
9.2. Informative References
[I-D.chen-pce-pcep-ifit]
Chen, H., Yuan, H., Zhou, T., Li, W., Fioccola, G., and Y.
Wang, "Path Computation Element Communication Protocol
(PCEP) Extensions to Enable IFIT", draft-chen-pce-pcep-
ifit-00 (work in progress), August 2020.
[I-D.gandhi-mpls-ioam-sr]
Gandhi, R., Ali, Z., Filsfils, C., Brockners, F., Wen, B.,
and V. Kozak, "MPLS Data Plane Encapsulation for In-situ
OAM Data", draft-gandhi-mpls-ioam-sr-02 (work in
progress), March 2020.
[I-D.gandhi-mpls-rfc6374-sr]
Gandhi, R., Filsfils, C., Voyer, D., Salsano, S., and M.
Chen, "Performance Measurement Using RFC 6374 for Segment
Routing Networks with MPLS Data Plane", draft-gandhi-mpls-
rfc6374-sr-05 (work in progress), June 2020.
[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",
draft-ietf-6man-ipv6-alt-mark-01 (work in progress), June
2020.
[I-D.ietf-idr-segment-routing-te-policy]
Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P.,
Rosen, E., Jain, D., and S. Lin, "Advertising Segment
Routing Policies in BGP", draft-ietf-idr-segment-routing-
te-policy-09 (work in progress), May 2020.
[I-D.ietf-ippm-ioam-data]
Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields
for In-situ OAM", draft-ietf-ippm-ioam-data-10 (work in
progress), July 2020.
[I-D.ietf-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-ietf-ippm-ioam-direct-
export-01 (work in progress), August 2020.
Qin, et al. Expires March 6, 2021 [Page 11]
Internet-Draft bgp-sr-policy-ifit September 2020
[I-D.ietf-ippm-ioam-flags]
Mizrahi, T., Brockners, F., Bhandari, S., Sivakolundu, R.,
Pignataro, C., Kfir, A., Gafni, B., Spiegel, M., and J.
Lemon, "In-situ OAM Flags", draft-ietf-ippm-ioam-flags-02
(work in progress), July 2020.
[I-D.ietf-ippm-ioam-ipv6-options]
Bhandari, S., Brockners, F., Pignataro, C., Gredler, H.,
Leddy, J., Youell, S., Mizrahi, T., Kfir, A., Gafni, B.,
Lapukhov, P., Spiegel, M., Krishnan, S., and R. Asati,
"In-situ OAM IPv6 Options", draft-ietf-ippm-ioam-
ipv6-options-02 (work in progress), July 2020.
[I-D.ietf-mpls-rfc6374-sfl]
Bryant, S., Swallow, G., Chen, M., Fioccola, G., and G.
Mirsky, "RFC6374 Synonymous Flow Labels", draft-ietf-mpls-
rfc6374-sfl-07 (work in progress), June 2020.
[I-D.ietf-spring-segment-routing-policy]
Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and
P. Mattes, "Segment Routing Policy Architecture", draft-
ietf-spring-segment-routing-policy-08 (work in progress),
July 2020.
Appendix A.
Authors' Addresses
Fengwei Qin
China Mobile
No. 32 Xuanwumenxi Ave., Xicheng District
Beijing
China
Email: qinfengwei@chinamobile.com
Hang Yuan
UnionPay
1899 Gu-Tang Rd., Pudong
Shanghai
China
Email: yuanhang@unionpay.com
Qin, et al. Expires March 6, 2021 [Page 12]
Internet-Draft bgp-sr-policy-ifit September 2020
Tianran Zhou
Huawei
156 Beiqing Rd., Haidian District
Beijing
China
Email: zhoutianran@huawei.com
Giuseppe Fioccola
Huawei
Riesstrasse, 25
Munich
Germany
Email: giuseppe.fioccola@huawei.com
Yali Wang
Huawei
156 Beiqing Rd., Haidian District
Beijing
China
Email: wangyali11@huawei.com
Qin, et al. Expires March 6, 2021 [Page 13]