PCE H. Chen
Internet-Draft China Telecom
Intended status: Standards Track H. Yuan
Expires: July 9, 2020 UnionPay
T. Zhou
W. Li
G. Fioccola
Huawei
January 6, 2020
PCEP SR Policy Extensions to Enable IFIT
draft-chen-pce-sr-policy-ifit-00
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) provides a reference framework that supports network OAM
applications to apply dataplane on-path telemetry techniques
acquiring data about a packet on its forwarding path. This document
defines extensions to PCEP to distribute SR policies carrying IFIT
information. So that IFIT behavior 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."
Chen, et al. Expires July 9, 2020 [Page 1]
Internet-Draft pcep-sr-policy-ifit January 2020
This Internet-Draft will expire on July 9, 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. IFIT Attributes in SR Policy . . . . . . . . . . . . . . . . 3
3. SR Policy for IOAM . . . . . . . . . . . . . . . . . . . . . 3
3.1. IOAM Pre-allocated Trace Option TLV . . . . . . . . . . . 4
3.2. IOAM Incremental Trace Option TLV . . . . . . . . . . . . 5
3.3. IOAM Directly Export Option TLV . . . . . . . . . . . . . 5
3.4. IOAM Edge-to-Edge Option TLV . . . . . . . . . . . . . . 6
4. SR Policy for Enhanced Alternate Marking . . . . . . . . . . 7
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. PCE Initiated SR Policy . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . 10
Appendix A. . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
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)
[I-D.song-opsawg-ifit-framework] provides a reference framework that
supports network OAM applications to apply dataplane on-path
Chen, et al. Expires July 9, 2020 [Page 2]
Internet-Draft pcep-sr-policy-ifit January 2020
telemetry techniques, including In-situ OAM (IOAM)
[I-D.ietf-ippm-ioam-data], Postcard Based Telemetry (PBT)
[I-D.song-ippm-postcard-based-telemetry], In-band Flow Analyzer (IFA)
[I-D.kumar-ippm-ifa], Enhanced Alternate Marking (EAM)
[I-D.zhou-ippm-enhanced-alternate-marking], and Hybrid Two Steps
(HTS) [I-D.mirsky-ippm-hybrid-two-step]. 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. The SR policy native IFIT can
facilitate the closed loop control, and enable the automation of SR
service.
This document defines extensions to PCEP to distribute SR policies
carrying IFIT information. So that IFIT behavior can be enabled
automatically when the SR policy is applied.
2. IFIT Attributes in SR Policy
SR Policy Association Group (SRPAG) is defined in
[I-D.barth-pce-segment-routing-policy-cp] to extend PCEP to support
association among candidate paths of a given SR policy. SR Policy
Identifiers TLV, SR Policy Name TLV, SR Policy Candidate Path
Identifiers TLV, and SR Policy Candidate Path Preference TLV are
introduced to construct the SR policy structure.
This document is to add IFIT attribute TLVs to the SRPAG. The
following sections will describe the requirement and usage of
different IFIT modes, and define the corresponding TLV encoding in
PCEP.
3. 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.
Chen, et al. Expires July 9, 2020 [Page 3]
Internet-Draft pcep-sr-policy-ifit January 2020
3.1. IOAM Pre-allocated Trace Option 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 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 | Rsvd1 |
+-------------------------------+-----------------------+-------+
| IOAM Trace Type | Flags | Rsvd2 |
+----------------------------------------------+--------+-------+
Fig. 1 IOAM Pre-allocated Trace Option 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 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].
Rsvd1: A 16-bit field reserved for further usage. It MUST be zero.
Rsvd2: A 4-bit field reserved for further usage. It MUST be zero.
Chen, et al. Expires July 9, 2020 [Page 4]
Internet-Draft pcep-sr-policy-ifit January 2020
3.2. IOAM Incremental Trace Option 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 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 | Rsvd1 |
+-------------------------------+-----------------------+-------+
| IOAM Trace Type | Flags | Rsvd2 |
+----------------------------------------------+--------+-------+
Fig. 2 IOAM Incremental Trace Option 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 definition is the same as the pre-allocated
trace option TLV in section 4.1.
3.3. IOAM Directly Export Option 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.
The format of IOAM directly export option TLV is defined as follows:
Chen, et al. Expires July 9, 2020 [Page 5]
Internet-Draft pcep-sr-policy-ifit January 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 | Flags |
+-------------------------------+---------------+---------------+
| IOAM Trace Type | Rsvd |
+-----------------------------------------------+---------------+
| Flow ID |
+---------------------------------------------------------------+
Fig. 3 IOAM Directly Export Option 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.ioamteam-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.ioamteam-ippm-ioam-direct-export].
Rsvd: A 4-bit field reserved for further usage. It MUST be zero.
3.4. IOAM Edge-to-Edge Option 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 TLV is defined as follows:
Chen, et al. Expires July 9, 2020 [Page 6]
Internet-Draft pcep-sr-policy-ifit January 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 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].
4. 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.
The Enhanced Alternate Marking (EAM)
[I-D.zhou-ippm-enhanced-alternate-marking] defines data fields for
the alternate marking with enough space, in particular for Postcard-
based Telemetry. More information can be considered within the
alternate marking field to facilitate the efficiency and ease the
deployment.
The format of EAM TLV is defined as follows:
Chen, et al. Expires July 9, 2020 [Page 7]
Internet-Draft pcep-sr-policy-ifit January 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 |
+---------------------------------------+---------------+-------+
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 2 of [I-D.zhou-ippm-enhanced-alternate-marking].
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.
5. Examples
5.1. PCE Initiated SR Policy
The interactions between the PCE and PCC is the same as described in
[I-D.barth-pce-segment-routing-policy-cp]. The only change is to
take the additional optional IFIT TLVs within the SRPAG object.
PCE sends PCInitiate message, containing the SRPAG Association
object. The Association Source is set to the IP address of the PCC
and the Association ID is set to 0xFFFF.
PCC uses the color, endpoint, preference and IFIT option from the
SRPAG object to create a new candidate path. If no SR policy exists
to hold the candidate path, then a new SR policy is created to hold
the new candidate-path. The Originator of the candidate path is set
to be the address of the PCE that is sending the PCInitiate message.
PCC sends a PCRpt message back to the PCE to report the newly created
Candidate Path. The PCRpt message contains the SRPAG Association
object. The Association Source is set to the IP address of the PCC
and the Association ID is set to a number that PCC locally chose to
represent the SR Policy.
Chen, et al. Expires July 9, 2020 [Page 8]
Internet-Draft pcep-sr-policy-ifit January 2020
6. IANA Considerations
This document defines new IFIT TLVs for carrying additional
information about SR policy and SR candidate paths. IANA is
requested to make the assignment of a new value for the existing
"PCEP TLV Type Indicators" registry as follows:
Codepoint Description Reference
-------------------------------------------------------------
TBD1 IOAM Pre-allocated Trace This document
Option TLV
TBD2 IOAM Incremental Trace This document
Option TLV
TBD3 IOAM Directly Export This document
Option TLV
TBD4 IOAM Edge-to-Edge This document
Option TLV
TBD5 Enhanced Alternate Marking This document
TLV
7. Security Considerations
TBD.
8. Acknowledgements
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>.
Chen, et al. Expires July 9, 2020 [Page 9]
Internet-Draft pcep-sr-policy-ifit January 2020
9.2. Informative References
[I-D.barth-pce-segment-routing-policy-cp]
Koldychev, M., Sivabalan, S., Barth, C., Li, C., and H.
Bidgoli, "PCEP extension to support Segment Routing Policy
Candidate Paths", draft-barth-pce-segment-routing-policy-
cp-04 (work in progress), October 2019.
[I-D.ietf-ippm-ioam-data]
Brockners, F., Bhandari, S., Pignataro, C., Gredler, H.,
Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov,
P., remy@barefootnetworks.com, r., daniel.bernier@bell.ca,
d., and J. Lemon, "Data Fields for In-situ OAM", draft-
ietf-ippm-ioam-data-08 (work in progress), October 2019.
[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-00
(work in progress), October 2019.
[I-D.ietf-spring-segment-routing-policy]
Filsfils, C., Sivabalan, S., Voyer, D., Bogdanov, A., and
P. Mattes, "Segment Routing Policy Architecture", draft-
ietf-spring-segment-routing-policy-06 (work in progress),
December 2019.
[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.
[I-D.kumar-ippm-ifa]
Kumar, J., Anubolu, S., Lemon, J., Manur, R., Holbrook,
H., Ghanwani, A., Cai, D., Ou, H., and L. Yizhou, "Inband
Flow Analyzer", draft-kumar-ippm-ifa-01 (work in
progress), February 2019.
[I-D.mirsky-ippm-hybrid-two-step]
Mirsky, G., Lingqiang, W., and G. Zhui, "Hybrid Two-Step
Performance Measurement Method", draft-mirsky-ippm-hybrid-
two-step-04 (work in progress), October 2019.
Chen, et al. Expires July 9, 2020 [Page 10]
Internet-Draft pcep-sr-policy-ifit January 2020
[I-D.song-ippm-postcard-based-telemetry]
Song, H., Zhou, T., Li, Z., Shin, J., and K. Lee,
"Postcard-based On-Path Flow Data Telemetry", draft-song-
ippm-postcard-based-telemetry-06 (work in progress),
October 2019.
[I-D.song-opsawg-ifit-framework]
Song, H., Qin, F., Chen, H., Jin, J., and J. Shin, "In-
situ Flow Information Telemetry", draft-song-opsawg-ifit-
framework-10 (work in progress), December 2019.
[I-D.zhou-ippm-enhanced-alternate-marking]
Zhou, T., Fioccola, G., Li, Z., Lee, S., and M. Cociglio,
"Enhanced Alternate Marking Method", draft-zhou-ippm-
enhanced-alternate-marking-04 (work in progress), October
2019.
Appendix A.
Authors' Addresses
Huanan Chen
China Telecom
Guangzhou
China
Email: chenhuan6@chinatelecom.cn
Hang Yuan
UnionPay
1899 Gu-Tang Rd., Pudong
Shanghai
China
Email: yuanhang@unionpay.com
Tianran Zhou
Huawei
156 Beiqing Rd., Haidian District
Beijing
China
Email: zhoutianran@huawei.com
Chen, et al. Expires July 9, 2020 [Page 11]
Internet-Draft pcep-sr-policy-ifit January 2020
Weidong Li
Huawei
156 Beiqing Rd., Haidian District
Beijing
China
Email: poly.li@huawei.com
Giuseppe Fioccola
Huawei
Riesstrasse, 25
Munich
Germany
Email: giuseppe.fioccola@huawei.com
Chen, et al. Expires July 9, 2020 [Page 12]