< draft-ietf-idr-sr-policy-ifit-00.txt   draft-ietf-idr-sr-policy-ifit-01.txt >
IDR F. Qin IDR F. Qin
Internet-Draft China Mobile Internet-Draft China Mobile
Intended status: Standards Track H. Yuan Intended status: Standards Track H. Yuan
Expires: May 23, 2021 UnionPay Expires: August 13, 2021 UnionPay
T. Zhou T. Zhou
G. Fioccola G. Fioccola
Y. Wang Y. Wang
Huawei Huawei
November 19, 2020 February 9, 2021
BGP SR Policy Extensions to Enable IFIT BGP SR Policy Extensions to Enable IFIT
draft-ietf-idr-sr-policy-ifit-00 draft-ietf-idr-sr-policy-ifit-01
Abstract Abstract
Segment Routing (SR) policy is a set of candidate SR paths consisting Segment Routing (SR) policy is a set of candidate SR paths consisting
of one or more segment lists and necessary path attributes. It of one or more segment lists and necessary path attributes. It
enables instantiation of an ordered list of segments with a specific enables instantiation of an ordered list of segments with a specific
intent for traffic steering. In-situ Flow Information Telemetry intent for traffic steering. In-situ Flow Information Telemetry
(IFIT) refers to network OAM data plane on-path telemetry techniques, (IFIT) refers to network OAM data plane on-path telemetry techniques,
in particular the most popular are In-situ OAM (IOAM) and Alternate in particular the most popular are In-situ OAM (IOAM) and Alternate
Marking. This document defines extensions to BGP to distribute SR Marking. This document defines extensions to BGP to distribute SR
policies carrying IFIT information. So that IFIT methods can be policies carrying IFIT information. So that IFIT methods can be
enabled automatically when the SR policy is applied. enabled automatically when the SR policy is applied.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in BCP 14 [RFC2119]
[RFC8174] when, and only when, they appear in all capitals, as shown
here.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 13, 2021.
This Internet-Draft will expire on May 23, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. IFIT methods for SR Policy . . . . . . . . . . . . . . . . . 4 3. IFIT methods for SR Policy . . . . . . . . . . . . . . . . . 4
4. IFIT Attributes in SR Policy . . . . . . . . . . . . . . . . 4 4. IFIT Attributes in SR Policy . . . . . . . . . . . . . . . . 4
5. IFIT Attributes Sub-TLV . . . . . . . . . . . . . . . . . . . 5 5. IFIT Attributes Sub-TLV . . . . . . . . . . . . . . . . . . . 6
5.1. IOAM Pre-allocated Trace Option Sub-TLV . . . . . . . . . 6 5.1. IOAM Pre-allocated Trace Option Sub-TLV . . . . . . . . . 7
5.2. IOAM Incremental Trace Option Sub-TLV . . . . . . . . . . 7 5.2. IOAM Incremental Trace Option Sub-TLV . . . . . . . . . . 8
5.3. IOAM Directly Export Option Sub-TLV . . . . . . . . . . . 8 5.3. IOAM Directly Export Option Sub-TLV . . . . . . . . . . . 9
5.4. IOAM Edge-to-Edge Option Sub-TLV . . . . . . . . . . . . 9 5.4. IOAM Edge-to-Edge Option Sub-TLV . . . . . . . . . . . . 10
5.5. Enhanced Alternate Marking (EAM) sub-TLV . . . . . . . . 9 5.5. Enhanced Alternate Marking (EAM) sub-TLV . . . . . . . . 10
6. SR Policy Operations with IFIT Attributes . . . . . . . . . . 10 6. SR Policy Operations with IFIT Attributes . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.1. Normative References . . . . . . . . . . . . . . . . . . 12 10.1. Normative References . . . . . . . . . . . . . . . . . . 13
10.2. Informative References . . . . . . . . . . . . . . . . . 13 10.2. Informative References . . . . . . . . . . . . . . . . . 14
Appendix A. . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Appendix A. . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
Segment Routing (SR) policy [I-D.ietf-spring-segment-routing-policy] Segment Routing (SR) policy [I-D.ietf-spring-segment-routing-policy]
is a set of candidate SR paths consisting of one or more segment is a set of candidate SR paths consisting of one or more segment
lists and necessary path attributes. It enables instantiation of an lists and necessary path attributes. It enables instantiation of an
ordered list of segments with a specific intent for traffic steering. ordered list of segments with a specific intent for traffic steering.
In-situ Flow Information Telemetry (IFIT) denotes a family of flow- In-situ Flow Information Telemetry (IFIT) denotes a family of flow-
oriented on-path telemetry techniques (e.g. IOAM, Alternate oriented on-path telemetry techniques (e.g. IOAM, Alternate
Marking), which can provide high-precision flow insight and real-time Marking), which can provide high-precision flow insight and real-time
network issue notification (e.g., jitter, latency, packet loss).In network issue notification (e.g., jitter, latency, packet loss).In
particular, IFIT refers to network OAM data plane on-path telemetry particular, IFIT refers to network OAM (Operations, Administration,
techniques, including In-situ OAM (IOAM) [I-D.ietf-ippm-ioam-data] and Maintenance) data plane on-path telemetry techniques, including
and Alternate Marking [RFC8321]. It can provide flow information on In-situ OAM (IOAM) [I-D.ietf-ippm-ioam-data] and Alternate Marking
the entire forwarding path on a per-packet basis in real time. [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) An automatic network requires the Service Level Agreement (SLA)
monitoring on the deployed service. So that the system can quickly monitoring on the deployed service. So that the system can quickly
detect the SLA violation or the performance degradation, hence to detect the SLA violation or the performance degradation, hence to
change the service deployment. For this reason, the SR policy native change the service deployment. For this reason, the SR policy native
IFIT can facilitate the closed loop control and enable the automation IFIT can facilitate the closed loop control and enable the automation
of SR service. of SR service.
This document defines extensions to Border Gateway Protocol (BGP) to This document defines extensions to Border Gateway Protocol (BGP) to
distribute SR policies carrying IFIT information. So that IFIT distribute SR policies carrying IFIT information. So that IFIT
skipping to change at page 4, line 5 skipping to change at page 4, line 7
MPLS. MPLS.
The definition of these data plane IFIT methods for SR-MPLS and SRv6 The definition of these data plane IFIT methods for SR-MPLS and SRv6
imply requirements for various routing protocols, such as BGP, and imply requirements for various routing protocols, such as BGP, and
this document aims to define BGP extensions to distribute SR policies this document aims to define BGP extensions to distribute SR policies
carrying IFIT information. This allows to signal the IFIT carrying IFIT information. This allows to signal the IFIT
capabilities so IFIT methods are automatically configured and ready capabilities so IFIT methods are automatically configured and ready
to run when the SR Policy candidate paths are distributed through to run when the SR Policy candidate paths are distributed through
BGP. BGP.
It is to be noted that, for PCEP, [I-D.chen-pce-pcep-ifit] proposes It is to be noted that, for PCEP (Path Computation Element
the extensions to PCEP to distribute paths carrying IFIT information Communication Protocol), [I-D.chen-pce-pcep-ifit] proposes the
and therefore to enable IFIT methods for SR policy too. extensions to PCEP to distribute paths carrying IFIT information and
therefore to enable IFIT methods for SR policy too.
3. IFIT methods for SR Policy 3. IFIT methods for SR Policy
In-situ Operations, Administration, and Maintenance (IOAM) In-situ Operations, Administration, and Maintenance (IOAM)
[I-D.ietf-ippm-ioam-data] records operational and telemetry [I-D.ietf-ippm-ioam-data] records operational and telemetry
information in the packet while the packet traverses a path between information in the packet while the packet traverses a path between
two points in the network. In terms of the classification given in two points in the network. In terms of the classification given in
RFC 7799 [RFC7799] IOAM could be categorized as Hybrid Type 1. IOAM 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 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 offer the desired results. When SR policy enables the IOAM, the IOAM
skipping to change at page 4, line 31 skipping to change at page 4, line 34
The Alternate Marking [RFC8321]technique is an hybrid performance The Alternate Marking [RFC8321]technique is an hybrid performance
measurement method, per RFC 7799 [RFC7799] classification of measurement method, per RFC 7799 [RFC7799] classification of
measurement methods. Because this method is based on marking measurement methods. Because this method is based on marking
consecutive batches of packets. It can be used to measure packet consecutive batches of packets. It can be used to measure packet
loss, latency, and jitter on live traffic. loss, latency, and jitter on live traffic.
This document aims to define the control plane. While the relevant This document aims to define the control plane. While the relevant
documents for the data plane application of IOAM and Alternate documents for the data plane application of IOAM and Alternate
Marking are respectively [I-D.ietf-ippm-ioam-ipv6-options] and Marking are respectively [I-D.ietf-ippm-ioam-ipv6-options] and
[I-D.ietf-6man-ipv6-alt-mark] for Segment Routing over IPv6 data [I-D.ietf-6man-ipv6-alt-mark] for Segment Routing over IPv6 data
plane (SRv6). plane (SRv6), [I-D.ietf-mpls-rfc6374-sfl],
[I-D.gandhi-mpls-rfc6374-sr] and [I-D.gandhi-mpls-ioam-sr] for
Segment Routing over the MPLS data plane (SR-MPLS).
4. IFIT Attributes in SR Policy 4. IFIT Attributes in SR Policy
As defined in [I-D.ietf-idr-segment-routing-te-policy], the SR Policy As defined in [I-D.ietf-idr-segment-routing-te-policy], a new SAFI is
encoding structure is as follows: defined (the SR Policy SAFI with codepoint 73) as well as a new NLRI.
The NLRI contains the SR Policy candidate path and, according to
[I-D.ietf-idr-segment-routing-te-policy], the content of the SR
Policy Candidate Path is encoded in the Tunnel Encapsulation
Attribute defined in [I-D.ietf-idr-tunnel-encaps] using a new Tunnel-
Type called SR Policy Type with codepoint 15. The SR Policy encoding
structure is as follows:
SR Policy SAFI NLRI: <Distinguisher, Policy-Color, Endpoint> SR Policy SAFI NLRI: <Distinguisher, Policy-Color, Endpoint>
Attributes: Attributes:
Tunnel Encaps Attribute (23) Tunnel Encaps Attribute (23)
Tunnel Type: SR Policy Tunnel Type: SR Policy
Binding SID Binding SID
Preference SRv6 Binding SID
Priority Preference
Policy Name Priority
Explicit NULL Label Policy (ENLP) Policy Name
Segment List Policy Candidate Path Name
Weight Explicit NULL Label Policy (ENLP)
Segment Segment List
Segment Weight
... Segment
... Segment
...
...
A candidate path includes multiple SR paths, each of which is A candidate path includes multiple SR paths, each of which is
specified by a segment list. IFIT can be applied to the candidate 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 path, so that all the SR paths can be monitored in the same way. The
new SR Policy encoding structure is expressed as below: new SR Policy encoding structure is expressed as below:
SR Policy SAFI NLRI: <Distinguisher, Policy-Color, Endpoint> SR Policy SAFI NLRI: <Distinguisher, Policy-Color, Endpoint>
Attributes: Attributes:
Tunnel Encaps Attribute (23) Tunnel Encaps Attribute (23)
Tunnel Type: SR Policy Tunnel Type: SR Policy
Binding SID Binding SID
Preference SRv6 Binding SID
Priority Preference
Policy Name Priority
Explicit NULL Label Policy (ENLP) Policy Name
IFIT Attributes Policy Candidate Path Name
Segment List Explicit NULL Label Policy (ENLP)
Weight IFIT Attributes
Segment Segment List
Segment Weight
... Segment
... Segment
...
...
IFIT attributes can be attached at the candidate path level as sub- IFIT attributes can be attached at the candidate path level as sub-
TLVs. There may be different IFIT tools. The following sections TLVs. There may be different IFIT tools. The following sections
will describe the requirement and usage of different IFIT tools, and will describe the requirement and usage of different IFIT tools, and
define the corresponding sub-TLV encoding in BGP. define the corresponding sub-TLV encoding in BGP.
Once the IFIT attributes are signalled, if a packet arrives at the
headend and, based on the types of steering described in
[I-D.ietf-spring-segment-routing-policy], it may get steered into an
SR Policy where IFIT methods are applied. Therefore it will be
managed consequently with the corresponding IOAM or Alternate Marking
information according to the enabled IFIT methods.
Note that the IFIT attributes here described can also be generalized Note that the IFIT attributes here described can also be generalized
and included as sub-TLVs for other SAFIs and NLRIs. and included as sub-TLVs for other SAFIs and NLRIs.
5. IFIT Attributes Sub-TLV 5. IFIT Attributes Sub-TLV
The format of the IFIT Attributes Sub-TLV is defined as follows: The format of the IFIT Attributes Sub-TLV is defined as follows:
0 1 2 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 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
+---------------+---------------+ +---------------+---------------+
skipping to change at page 6, line 29 skipping to change at page 7, line 8
* Enhanced Alternate Marking (EAM) sub-TLV. * Enhanced Alternate Marking (EAM) sub-TLV.
The presence of the IFIT Attributes Sub-TLV implies support of IFIT The presence of the IFIT Attributes Sub-TLV implies support of IFIT
methods (IOAM and/or Alternate Marking). It is worth mentioning that methods (IOAM and/or Alternate Marking). It is worth mentioning that
IOAM and Alternate Marking can be activated one at a time or can IOAM and Alternate Marking can be activated one at a time or can
coexist; so it is possible to have only IOAM or only Alternate coexist; so it is possible to have only IOAM or only Alternate
Marking enabled as Sub-TLVs. The sub-TLVs currently defined for IOAM Marking enabled as Sub-TLVs. The sub-TLVs currently defined for IOAM
and Alternate Marking are detailed in the next sections. and Alternate Marking are detailed in the next sections.
In case of empty IFIT Attributes Sub-TLV, i.e. no further IFIT sub-
TLV and Length=0, IFIT methods will not be activated. If two
conflicting IOAM sub-TLVs are present (e.g. Pre-allocated Trace
Option and Incremental Trace Option) it means that they are not
usable and none of the two methods will be activated. The same
applies if there is more than one instance of the sub-TLV of the same
type. Anyway the validation of the individual fields of the IFIT
Attributes sub-TLVs are handled by the SRPM (SR Policy Module).
The process of stopping IFIT methods can be done by setting empty
IFIT Attributes Sub-TLV, while, for modifying IFIT methods
parameters, the IFIT Attributes Sub-TLVs can be updated accordingly.
Additionally the backward compatibility is guaranteed, since an
implementation that does not understand IFIT Attributes Sub-TLV can
simply ignore it.
5.1. IOAM Pre-allocated Trace Option Sub-TLV 5.1. IOAM Pre-allocated Trace Option Sub-TLV
The IOAM tracing data is expected to be collected at every node that 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 a packet traverses to ensure visibility into the entire path a packet
takes within an IOAM domain. The preallocated tracing option will takes within an IOAM domain. The preallocated tracing option will
create pre-allocated space for each node to populate its information. create pre-allocated space for each node to populate its information.
The format of IOAM pre-allocated trace option sub-TLV is defined as The format of IOAM pre-allocated trace option sub-TLV is defined as
follows: follows:
skipping to change at page 7, line 20 skipping to change at page 8, line 17
[I-D.ietf-ippm-ioam-data]. [I-D.ietf-ippm-ioam-data].
IOAM Trace Type: A 24-bit identifier which specifies which data types 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 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]. 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 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-flags] and section 4.4 of
[I-D.ietf-ippm-ioam-data]. [I-D.ietf-ippm-ioam-data].
Rsvd: A 4-bit field reserved for further usage. It MUST be zero. Rsvd: A 4-bit field reserved for further usage. It MUST be zero and
ignored on receipt.
5.2. IOAM Incremental Trace Option Sub-TLV 5.2. IOAM Incremental Trace Option Sub-TLV
The incremental tracing option contains a variable node data fields The incremental tracing option contains a variable node data fields
where each node allocates and pushes its node data immediately where each node allocates and pushes its node data immediately
following the option header. following the option header.
The format of IOAM incremental trace option sub-TLV is defined as The format of IOAM incremental trace option sub-TLV is defined as
follows: follows:
skipping to change at page 7, line 48 skipping to change at page 8, line 46
Fig. 3 IOAM Incremental Trace Option Sub-TLV Fig. 3 IOAM Incremental Trace Option Sub-TLV
Where: Where:
Type: 2 (to be assigned by IANA). Type: 2 (to be assigned by IANA).
Length: 6, it is the total length of the value field (not including Length: 6, it is the total length of the value field (not including
Type and Length fields). Type and Length fields).
All the other fields definistion is the same as the pre-allocated All the other fields definition is the same as the pre-allocated
trace option sub-TLV in section 4.1. trace option sub-TLV in section 4.1.
5.3. IOAM Directly Export Option Sub-TLV 5.3. IOAM Directly Export Option Sub-TLV
IOAM directly export option is used as a trigger for IOAM data to be 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 directly exported to a collector without being pushed into in-flight
data packets. data packets.
The format of IOAM directly export option sub-TLV is defined as The format of IOAM directly export option sub-TLV is defined as
follows: follows:
skipping to change at page 8, line 39 skipping to change at page 9, line 39
Type: 3 (to be assigned by IANA). Type: 3 (to be assigned by IANA).
Length: 12, it is the total length of the value field (not including Length: 12, it is the total length of the value field (not including
Type and Length fields). Type and Length fields).
Namespace ID: A 16-bit identifier of an IOAM-Namespace. The Namespace ID: A 16-bit identifier of an IOAM-Namespace. The
definition is the same as described in section 4.4 of definition is the same as described in section 4.4 of
[I-D.ietf-ippm-ioam-data]. [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].
IOAM Trace Type: A 24-bit identifier which specifies which data types 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 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]. 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 Rsvd: A 4-bit field reserved for further usage. It MUST be zero and
section 3.2 of [I-D.ietf-ippm-ioam-direct-export]. ignored on receipt.
Flow ID: A 32-bit flow identifier. The definition is the same as 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]. 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.
5.4. IOAM Edge-to-Edge Option Sub-TLV 5.4. IOAM Edge-to-Edge Option Sub-TLV
The IOAM edge to edge option is to carry data that is added by the The IOAM edge to edge option is to carry data that is added by the
IOAM encapsulating node and interpreted by IOAM decapsulating node. IOAM encapsulating node and interpreted by IOAM decapsulating node.
The format of IOAM edge-to-edge option sub-TLV is defined as follows: The format of IOAM edge-to-edge option sub-TLV is defined as follows:
0 1 2 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 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
+---------------+---------------+ +---------------+---------------+
skipping to change at page 9, line 47 skipping to change at page 10, line 47
5.5. Enhanced Alternate Marking (EAM) sub-TLV 5.5. Enhanced Alternate Marking (EAM) sub-TLV
The format of Enhanced Alternate Marking (EAM) sub-TLV is defined as The format of Enhanced Alternate Marking (EAM) sub-TLV is defined as
follows: follows:
0 1 2 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 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=5 | Length=4 | | Type=5 | Length=4 |
+-------------------------------+-------+-------+-------+-------+ +-------------------------------+-------+-------+-------+-------+
| FlowMonID | Period | Rsvd | | FlowMonID | Period |H|E| R |
+---------------------------------------+---------------+-------+ +---------------------------------------+---------------+-------+
Fig. 6 Enhanced Alternate Marking Sub-TLV Fig. 6 Enhanced Alternate Marking Sub-TLV
Where: Where:
Type: 5 (to be assigned by IANA). Type: 5 (to be assigned by IANA).
Length: 4, it is the total length of the value field (not including Length: 4, it is the total length of the value field (not including
Type and Length fields). Type and Length fields).
FlowMonID: A 20-bit identifier to uniquely identify a monitored flow FlowMonID: A 20-bit identifier to uniquely identify a monitored flow
within the measurement domain. The definition is the same as within the measurement domain. The definition is the same as
described in section 5.3 of [I-D.ietf-6man-ipv6-alt-mark]. described in section 5.3 of [I-D.ietf-6man-ipv6-alt-mark].
Period: Time interval between two alternate marking period. The unit Period: Time interval between two alternate marking period. The unit
is second. is second.
Rsvd: A 4-bit field reserved for further usage. It MUST be zero. H: A flag indicating that the measurement is Hop-By-Hop.
E: A flag indicating that the measurement is end to end.
R: A 2-bit field reserved for further usage. It MUST be zero and
ignored on receipt.
6. SR Policy Operations with IFIT Attributes 6. SR Policy Operations with IFIT Attributes
The details of SR Policy installation and use are specified in The details of SR Policy installation and use are specified in
[I-D.ietf-spring-segment-routing-policy]. This document complements [I-D.ietf-spring-segment-routing-policy]. This document complements
SR Policy Operations described in SR Policy Operations described in
[I-D.ietf-idr-segment-routing-te-policy] by adding the IFIT [I-D.ietf-idr-segment-routing-te-policy] by adding the IFIT
Attributes. Attributes.
The operations described in [I-D.ietf-idr-segment-routing-te-policy] The operations described in [I-D.ietf-idr-segment-routing-te-policy]
are always valid. The only difference is the addition of IFIT are always valid. The only difference is the addition of IFIT
Attributes Sub-TLVs for the SR Policy NLRI, that can affect its Attributes Sub-TLVs for the SR Policy NLRI, that can affect its
acceptance by a BGP speaker, but the implementation MAY provide an acceptance by a BGP speaker, but the implementation MAY provide an
option for ignoring the unrecognized or unsupported IFIT sub-TLVs. option for ignoring the unrecognized or unsupported IFIT sub-TLVs.
SR Policy NLRIs that have been determined acceptable, usable and SR Policy NLRIs that have been determined acceptable, usable and
valid can be evaluated for propagation, including the IFIT valid can be evaluated for propagation, including the IFIT
information. information.
The error handling actions are also described in The error handling actions are also described in
[I-D.ietf-idr-segment-routing-te-policy]. [I-D.ietf-idr-segment-routing-te-policy],indeed A BGP Speaker MUST
perform the syntactic validation of the SR Policy NLRI to determine
if it is malformed, including the TLVs/sub-TLVs. In case of any
error detected, either at the attribute or its TLV/sub-TLV level, the
"treat-as-withdraw" strategy MUST be applied.
The validation of the IFIT Attributes sub-TLVs introduced in this The validation of the IFIT Attributes sub-TLVs introduced in this
document MUST be performed to determine if they are malformed or document MUST be performed to determine if they are malformed or
invalid. The validation of the individual fields of the IFIT invalid. The validation of the individual fields of the IFIT
Attributes sub-TLVs are handled by the SRPM (SR Policy Module). Attributes sub-TLVs are handled by the SRPM (SR Policy Module).
7. IANA Considerations 7. IANA Considerations
This document defines a new sub-TLV in the registry "BGP Tunnel This document defines a new sub-TLV in the registry "BGP Tunnel
Encapsulation Attribute sub-TLVs" to be assigned by IANA: Encapsulation Attribute sub-TLVs" to be assigned by IANA:
skipping to change at page 11, line 4 skipping to change at page 12, line 13
Attributes sub-TLVs are handled by the SRPM (SR Policy Module). Attributes sub-TLVs are handled by the SRPM (SR Policy Module).
7. IANA Considerations 7. IANA Considerations
This document defines a new sub-TLV in the registry "BGP Tunnel This document defines a new sub-TLV in the registry "BGP Tunnel
Encapsulation Attribute sub-TLVs" to be assigned by IANA: Encapsulation Attribute sub-TLVs" to be assigned by IANA:
Codepoint Description Reference Codepoint Description Reference
------------------------------------------------------------- -------------------------------------------------------------
TBD1 IFIT Attributes Sub-TLV This document TBD1 IFIT Attributes Sub-TLV This document
This document requests creation of a new registry called "IFIT This document requests creation of a new registry called "IFIT
Attributes Sub-TLVs". The allocation policy of this registry is Attributes Sub-TLVs". The allocation policy of this registry is
"Specification Required" according to RFC 8126 [RFC8126]. "Specification Required" according to RFC 8126 [RFC8126].
Following initial Sub-TLV codepoints are assigned by this document: The following initial Sub-TLV codepoints are assigned by this
document:
Value Description Reference Value Description Reference
------------------------------------------------------------- -------------------------------------------------------------
1 IOAM Pre-allocated Trace Option Sub-TLV This document 1 IOAM Pre-allocated Trace Option Sub-TLV This document
2 IOAM Incremental Trace Option Sub-TLV This document 2 IOAM Incremental Trace Option Sub-TLV This document
3 IOAM Directly Export Option Sub-TLV This document 3 IOAM Directly Export Option Sub-TLV This document
4 IOAM Edge-to-Edge Option Sub-TLV This document 4 IOAM Edge-to-Edge Option Sub-TLV This document
skipping to change at page 11, line 39 skipping to change at page 12, line 50
security considerations also apply to BGP sessions when carrying SR security considerations also apply to BGP sessions when carrying SR
Policy information. The isolation of BGP SR Policy SAFI peering Policy information. The isolation of BGP SR Policy SAFI peering
sessions may be used to ensure that the SR Policy information is not sessions may be used to ensure that the SR Policy information is not
advertised outside the SR domain. Additionally, only trusted nodes advertised outside the SR domain. Additionally, only trusted nodes
(that include both routers and controller applications) within the SR (that include both routers and controller applications) within the SR
domain must be configured to receive such information. domain must be configured to receive such information.
Implementation of IFIT methods (IOAM and Alternate Marking) are Implementation of IFIT methods (IOAM and Alternate Marking) are
mindful of security and privacy concerns, as explained in mindful of security and privacy concerns, as explained in
[I-D.ietf-ippm-ioam-data] and RFC 8321 [RFC8321]. Anyway incorrect [I-D.ietf-ippm-ioam-data] and RFC 8321 [RFC8321]. Anyway incorrect
IFIT parameters in the BGP extension SHOULD not have an adverse 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 effect on the SR Policy as well as on the network, since it affects
only the operation of the telemetry methodology. only the operation of the telemetry methodology.
9. Acknowledgements 9. Acknowledgements
The authors of this document would like to thank Ketan Talaulikar, The authors of this document would like to thank Ketan Talaulikar,
Joel Halpern, Jie Dong for their comments and review of this Joel Halpern, Jie Dong for their comments and review of this
document. document.
10. References 10. References
skipping to change at page 12, line 21 skipping to change at page 13, line 29
Pang, "IPv6 Application of the Alternate Marking Method", Pang, "IPv6 Application of the Alternate Marking Method",
draft-ietf-6man-ipv6-alt-mark-02 (work in progress), draft-ietf-6man-ipv6-alt-mark-02 (work in progress),
October 2020. October 2020.
[I-D.ietf-idr-segment-routing-te-policy] [I-D.ietf-idr-segment-routing-te-policy]
Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P.,
Rosen, E., Jain, D., and S. Lin, "Advertising Segment Rosen, E., Jain, D., and S. Lin, "Advertising Segment
Routing Policies in BGP", draft-ietf-idr-segment-routing- Routing Policies in BGP", draft-ietf-idr-segment-routing-
te-policy-11 (work in progress), November 2020. te-policy-11 (work in progress), November 2020.
[I-D.ietf-idr-tunnel-encaps]
Patel, K., Velde, G., Sangli, S., and J. Scudder, "The BGP
Tunnel Encapsulation Attribute", draft-ietf-idr-tunnel-
encaps-21 (work in progress), January 2021.
[I-D.ietf-ippm-ioam-data] [I-D.ietf-ippm-ioam-data]
Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields
for In-situ OAM", draft-ietf-ippm-ioam-data-10 (work in for In-situ OAM", draft-ietf-ippm-ioam-data-11 (work in
progress), July 2020. progress), November 2020.
[I-D.ietf-ippm-ioam-direct-export] [I-D.ietf-ippm-ioam-direct-export]
Song, H., Gafni, B., Zhou, T., Li, Z., Brockners, F., Song, H., Gafni, B., Zhou, T., Li, Z., Brockners, F.,
Bhandari, S., Sivakolundu, R., and T. Mizrahi, "In-situ Bhandari, S., Sivakolundu, R., and T. Mizrahi, "In-situ
OAM Direct Exporting", draft-ietf-ippm-ioam-direct- OAM Direct Exporting", draft-ietf-ippm-ioam-direct-
export-02 (work in progress), November 2020. export-02 (work in progress), November 2020.
[I-D.ietf-ippm-ioam-flags] [I-D.ietf-ippm-ioam-flags]
Mizrahi, T., Brockners, F., Bhandari, S., Sivakolundu, R., Mizrahi, T., Brockners, F., Bhandari, S., Sivakolundu, R.,
Pignataro, C., Kfir, A., Gafni, B., Spiegel, M., and J. Pignataro, C., Kfir, A., Gafni, B., Spiegel, M., and J.
skipping to change at page 13, line 19 skipping to change at page 14, line 32
[RFC7799] Morton, A., "Active and Passive Metrics and Methods (with [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with
Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799,
May 2016, <https://www.rfc-editor.org/info/rfc7799>. May 2016, <https://www.rfc-editor.org/info/rfc7799>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[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>.
[RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli,
L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi,
"Alternate-Marking Method for Passive and Hybrid "Alternate-Marking Method for Passive and Hybrid
Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321,
January 2018, <https://www.rfc-editor.org/info/rfc8321>. January 2018, <https://www.rfc-editor.org/info/rfc8321>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>. July 2018, <https://www.rfc-editor.org/info/rfc8402>.
skipping to change at page 13, line 41 skipping to change at page 15, line 14
[I-D.chen-pce-pcep-ifit] [I-D.chen-pce-pcep-ifit]
Chen, H., Yuan, H., Zhou, T., Li, W., Fioccola, G., and Y. Chen, H., Yuan, H., Zhou, T., Li, W., Fioccola, G., and Y.
Wang, "Path Computation Element Communication Protocol Wang, "Path Computation Element Communication Protocol
(PCEP) Extensions to Enable IFIT", draft-chen-pce-pcep- (PCEP) Extensions to Enable IFIT", draft-chen-pce-pcep-
ifit-01 (work in progress), September 2020. ifit-01 (work in progress), September 2020.
[I-D.gandhi-mpls-ioam-sr] [I-D.gandhi-mpls-ioam-sr]
Gandhi, R., Ali, Z., Filsfils, C., Brockners, F., Wen, B., Gandhi, R., Ali, Z., Filsfils, C., Brockners, F., Wen, B.,
and V. Kozak, "MPLS Data Plane Encapsulation for In-situ and V. Kozak, "MPLS Data Plane Encapsulation for In-situ
OAM Data", draft-gandhi-mpls-ioam-sr-03 (work in OAM Data", draft-gandhi-mpls-ioam-sr-05 (work in
progress), September 2020. progress), January 2021.
[I-D.gandhi-mpls-rfc6374-sr] [I-D.gandhi-mpls-rfc6374-sr]
Gandhi, R., Filsfils, C., Voyer, D., Salsano, S., and M. Gandhi, R., Filsfils, C., Voyer, D., Salsano, S., and M.
Chen, "Performance Measurement Using RFC 6374 for Segment Chen, "Performance Measurement Using RFC 6374 for Segment
Routing Networks with MPLS Data Plane", draft-gandhi-mpls- Routing Networks with MPLS Data Plane", draft-gandhi-mpls-
rfc6374-sr-05 (work in progress), June 2020. rfc6374-sr-05 (work in progress), June 2020.
[I-D.ietf-mpls-rfc6374-sfl] [I-D.ietf-mpls-rfc6374-sfl]
Bryant, S., Swallow, G., Chen, M., Fioccola, G., and G. Bryant, S., Swallow, G., Chen, M., Fioccola, G., and G.
Mirsky, "RFC6374 Synonymous Flow Labels", draft-ietf-mpls- Mirsky, "RFC6374 Synonymous Flow Labels", draft-ietf-mpls-
rfc6374-sfl-07 (work in progress), June 2020. rfc6374-sfl-08 (work in progress), December 2020.
Appendix A. Appendix A.
Authors' Addresses Authors' Addresses
Fengwei Qin Fengwei Qin
China Mobile China Mobile
No. 32 Xuanwumenxi Ave., Xicheng District No. 32 Xuanwumenxi Ave., Xicheng District
Beijing Beijing
China China
 End of changes. 31 change blocks. 
79 lines changed or deleted 139 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/