SPRING Working Group G. Fioccola
Internet-Draft T. Zhou
Intended status: Standards Track Huawei
Expires: 10 September 2023 M. Cociglio
Telecom Italia
G. Mishra
Verizon Inc.
X. Wang
Ruijie
9 March 2023
Segment Routing Header encapsulation for Alternate Marking Method
draft-fz-spring-srv6-alt-mark-05
Abstract
This document describes how the Alternate Marking Method can be used
as the passive performance measurement tool in an SRv6 network. It
defines how Alternate Marking data fields are transported as part of
the Segment Routing with IPv6 data plane (SRv6) header.
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 10 September 2023.
Fioccola, et al. Expires 10 September 2023 [Page 1]
Internet-Draft SRv6 AMM March 2023
Copyright Notice
Copyright (c) 2023 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
2. Application of the Alternate Marking to SRv6 . . . . . . . . 3
2.1. Controlled Domain . . . . . . . . . . . . . . . . . . . . 4
3. Definition of the SRH AltMark TLV . . . . . . . . . . . . . . 4
3.1. Data Fields Format . . . . . . . . . . . . . . . . . . . 4
4. Use of the SRH AltMark TLV . . . . . . . . . . . . . . . . . 7
5. Alternate Marking Method Operation . . . . . . . . . . . . . 8
6. Implementation Recommendations . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 9
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
11.1. Normative References . . . . . . . . . . . . . . . . . . 10
11.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction
[RFC9341] and [RFC9342] describe a passive performance measurement
method, which can be used to measure packet loss, latency and jitter
on live traffic. Since this method is based on marking consecutive
batches of packets, the method is often referred as Alternate Marking
Method.
This document defines how the Alternate Marking Method ([RFC9341])
can be used to measure packet loss and delay metrics for Segment
Routing with IPv6 data plane (SRv6).
[RFC8754] defines the Segment Routing Header (SRH) and how it is used
by nodes that are Segment Routing (SR) capable.
Fioccola, et al. Expires 10 September 2023 [Page 2]
Internet-Draft SRv6 AMM March 2023
[RFC9343] analyzes the possible implementation options for the
application of the Alternate Marking Method in an IPv6 domain.
[RFC9343] defines a new TLV that can be encoded in the Option Headers
(both Hop-by-hop or Destination) for the purpose of the Alternate
Marking Method application in an IPv6 domain.
This document defines how Alternate Marking data is carried as SRH
TLV, that can be can be piggybacked in the packet and transported as
part of the SRH. The usage of SRH TLV is introduced in [RFC8754].
2. Application of the Alternate Marking to SRv6
The Alternate Marking Method requires a marking field. A possibility
is already offered by [RFC9343] while the use of a new TLV to be
encoded in the SRH is defined in this document.
Since [RFC9343] defines the IPv6 Application of the Alternate Marking
Method through both Hop-by-Hop and Destination Options Header, it is
applicable also to SRv6 network. Indeed the use of Destination
Option Header carrying Alternate Marking bits coupled with SRH allows
to monitor every node along the SR path.
This document introduces the SRH TLV carrying Alternate Marking bits
and this can be a preferred approach in case of SRv6 network since it
does not rely on the use of Destination Option Header.
The optimization of both implementation and scaling of the Alternate
Marking Method is also considered and a way to identify flows is
required. The Flow Monitoring Identification field (FlowMonID), as
introduced in the next sections, goes in this direction and it is
used to identify a monitored flow.
Note that the FlowMonID is different from the Flow Label field of the
IPv6 Header ([RFC8200]). Flow Label is used for application service,
like load-balancing/equal cost multi-path (LB/ECMP) and QoS.
Instead, FlowMonID is only used to identify the monitored flow. The
reuse of flow label field for identifying monitored flows is not
considered since it may change the application intent and forwarding
behaviour. Furthermore the flow label may be changed en route and
this may also violate the measurement task. Those reasons make the
definition of the FlowMonID necessary for IPv6. Flow Label and
FlowMonID within the same packet have different scope, identify
different flows, and associate different uses.
An important point that will also be discussed in this document is
the the uniqueness of the FlowMonID and how to allow disambiguation
of the FlowMonID in case of collision.
Fioccola, et al. Expires 10 September 2023 [Page 3]
Internet-Draft SRv6 AMM March 2023
The following section highlights an important requirement for the
application of the Alternate Marking to IPv6 and SRv6. The concept
of the controlled domain is explained and it is considered an
essential precondition.
2.1. Controlled Domain
[RFC8799] introduces the concept of specific limited domain solutions
and, in this regard, it is reported the Application of the Alternate
Marking Method as an example.
IPv6 has much more flexibility than IPv4 and innovative applications
have been proposed, but for a number of reasons, such as the
policies, options supported, the style of network management and
security requirements, it is suggested to limit some of these
applications to a controlled domain. This is also the case of the
Alternate Marking application to SRv6 as assumed hereinafter.
Therefore, the application of the Alternate Marking Method to SRv6
MUST NOT be deployed outside a controlled domain. It is RECOMMENDED
that an implementation can be able to reject packets that carry
Alternate Marking data and are entering or leaving the controlled
domains.
3. Definition of the SRH AltMark TLV
A new TLV carrying the data fields dedicated to the alternate marking
method can be defined for the SRH extension headers.
This enables the Alternate Marking Method to take advantage of the
network programmability capability of SRv6 ([RFC8986]).
Specifically, the ability for an SRv6 endpoint to determine whether
to process or ignore some specific SRH TLVs is based on the SID
function. The nodes that are not capable of supporting the Alternate
Marking functionality do not have to look or process the SRH AltMark
TLV and can simply ignore it. This also enables collection of
Alternate Marking data only from the supporting segment endpoints.
3.1. Data Fields Format
The following figure shows the data fields format for enhanced
alternate marking TLV. This AltMark data is expected to be
encapsulated as SRH TLV.
Fioccola, et al. Expires 10 September 2023 [Page 4]
Internet-Draft SRv6 AMM March 2023
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRH TLV Type | SRH TLV Len | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FlowMonID |L|D| Reserved | NH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:
* SRH TLV Type: 8 bit identifier of the type of Option/TLV that
needs to be allocated. Unrecognised Types MUST be ignored on
receipt.
* SRH TLV Len: The length of the Data Fields of this TLV in bytes.
* FlowMonID: 20 bits unsigned integer. The FlowMon identifier is
described hereinafter.
* L: Loss flag as defined in [RFC9341] and [RFC9343];
* D: Delay flag as defined in [RFC9341] and [RFC9343];
* Reserved: is reserved for future use. These bits MUST be set to
zero on transmission and ignored on receipt.
* NH: NextHeader field, used to indicate the extended data fields.
These bits MUST be set to zero if the enhanced capabilities are
not activated.
The Flow Monitoring Identification (FlowMonID) is required for some
general reasons:
First, it helps to reduce the per node configuration. Otherwise,
each node needs to configure an access-control list (ACL) for each
of the monitored flows. Moreover, using a flow identifier allows
a flexible granularity for the flow definition.
Second, it simplifies the counters handling. Hardware processing
of flow tuples (and ACL matching) is challenging and often incurs
into performance issues, especially in tunnel interfaces.
Third, it eases the data export encapsulation and correlation for
the collectors.
The FlowMon identifier field is to uniquely identify a monitored flow
within the measurement domain. The field is set at the source node.
The FlowMonID can be uniformly assigned by the central controller or
Fioccola, et al. Expires 10 September 2023 [Page 5]
Internet-Draft SRv6 AMM March 2023
algorithmically generated by the source node. The latter approach
cannot guarantee the uniqueness of FlowMonID but it may be preferred
for local or private network, where the conflict probability is small
due to the large FlowMonID space.
It is important to note that if the 20 bit FlowMonID is set
independently and pseudo randomly there is a chance of collision.
So, in some cases, FlowMonID could not be sufficient for uniqueness.
This issue is more visible when the FlowMonID is pseudo randomly
generated by the source node and there needs to tag it with
additional flow information to allow disambiguation. While, in case
of a centralized controller, the controller should set FlowMonID by
considering these aspects and instruct the nodes properly in order to
guarantee its uniqueness.
The NH (NextHeader) field is used to indicate the extended data
fields which are used for enhanced capabilities:
NextHeader value of 0x00 is reserved for backward compatibility.
It means that there is no extended data field attached.
NextHeader values of 0x01-0x08 are reserved for private use or for
experimentation.
NextHeader value of 0x09 indicates the extended data fields. The
format is showed in the next figure.
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
+-------------------------------+-------------------------------+
| MetaInfo | Padding (variable) |
+-------------------------------+-------------------------------+
// Padding (variable) //
+-------------------------------+-------------------------------+
where:
* MetaInfo - A 16-bit Bitmap to indicate more meta data attached for
the enhanced function.
bit 0: if set to 1, it indicates a 6 bytes Timestamp that is
attached as Padding after the MetaInfo. This Timestamp can be
filled by the encapsulation node, and is taken all the way to
the decapsulation node. So that all the intermediate nodes
could compare it with its local time, and measure the one way
delay.
Fioccola, et al. Expires 10 September 2023 [Page 6]
Internet-Draft SRv6 AMM March 2023
bit 1: if set to 1, it indicates the control information to set
up the backward direction flow monitoring.
bit 2: if set to 1, it indicates a 4 bytes Sequence number that
is attached as Padding after the MetaInfo. The unique Sequence
could be used to detect the out-of-order packets, in addition
to the normal loss measurement. More over, the Sequence can be
used together with the latency measurement, so as to get the
per packet timestamp.
* Padding - These bits MUST be set to zero when not being used. It
is worth noting that the meta data information forming the Padding
must be ordered according to the order of the MetaInfo bits.
4. Use of the SRH AltMark TLV
SRv6 leverages the Segment Routing header which consists of a new
type of routing header. Like any other use case of IPv6, Hop-by-Hop
and Destination Options are useable when SRv6 header is present.
Because SRv6 is a routing header, destination options before the
routing header are processed by each destination in the route list.
SRH TLV can also be used to encode the AltMark Data Fields for SRv6
and to monitor every node along the SR path. For SRv6, it may be
preferred to use the SRH TLV, while for all the other cases with IPv6
data plane the use of the Hop-by-Hop and Destination Option to carry
AltMark data fields (as described in [RFC9343]) is the best choice.
It is to be noted that the SR nodes implementing the Alternate
Marking functionality follows the MTU and other considerations
outlined in [I-D.voyer-6man-extension-header-insertion].
Furthermore, in a SRv6 network, the intermediated nodes that are not
in the SID list do not consider the SRH, therefore they cannot
support and dig into the SRH TLV.
It is possible to summarize the procedure for AltMark data
encapsulation in SRv6 SRH:
* Ingress Node: As part of the SRH encapsulation, the ingress node
of an SR domain or an SR Policy [RFC9256] MAY add the AltMark TLV
in the SRH of the data packet, if it supports AltMark
functionality and based on local configuration.
Fioccola, et al. Expires 10 September 2023 [Page 7]
Internet-Draft SRv6 AMM March 2023
* Intermediate SR Node: The intermediate SR node is any node
receiving an IPv6 packet where the destination address of that
packet is a local SID. If an intermediate SR node is not capable
of processing AltMark TLV, it simply ignores it. While, if an
intermediate SR node is capable of processing AltMark TLV, it
checks if SRH AltMark TLV is present in the packet using
procedures defined in [RFC8754] and process it.
* Egress Node: The Egress node is the last node in the segment-
list of the SRH. The processing of AltMark TLV at the Egress node
is similar to the processing of AltMark TLV at the Intermediate SR
Nodes.
5. Alternate Marking Method Operation
[RFC9341], [RFC9342] describe the Alternate Marking Method in
general. While [RFC9343] describe in detail the application and the
Operation of the methodology for IPv6.
6. Implementation Recommendations
In a SRv6 network, it is supposed that the SR nodes support the
AltMark TLV while all the transit routers are not required to handle
the SRH TLV. But this may also depend on the implementation, and if
a transit router is configured to read the SRH TLV, the measurement
could also be done on that node.
As specified in [RFC9343], the use of the Destination Option
preceding the SRH is equivalent to SRH TLV. But, the approach with
the Destination Option requires two extension headers and this can
have operational implications, as described in [RFC9098] and
[I-D.ietf-6man-eh-limits]. For SRv6, it can be consistent to carry
an information related to the SRv6 path inside the SRH. Indeed, it
is likely that SR nodes support fast SRH parsing and processing while
may be configured to not handle Destination Options. Therefore, it
is RECOMMENDED to integrate the data fields directly into the SRH and
to encode the Alternate-Marking data fields into the SRH TLV. This
can mitigate the deployment issues of two extension headers and it
may be much more cost effective and optimal then adding an additional
Destination Option.
Since it is required to have only one solution, in case of SRH there
would be a single way to apply Alternate-Marking through SRH TLV.
For all the other cases with IPv6 data plane the use of the Hop-by-
Hop Options Header and Destination Options Header can be the only
option to carry the Alternate-Marking data fields. The rule of the
Destination Option preceding a Routing Header, as specified in
[RFC9343], must remain valid in general.
Fioccola, et al. Expires 10 September 2023 [Page 8]
Internet-Draft SRv6 AMM March 2023
7. Security Considerations
The security considerations of SRv6 are discussed in [RFC8754] and
[RFC8986], and the security considerations of Alternate Marking in
general and its application to IPv6 are discussed in [RFC9341] and
[RFC9343].
The Alternate Marking application to IPv6, defined in [RFC9343],
analyzes different security concerns and related solutions. These
aspects are valid and applicable also to this document. In
particular the fundamental security requirement is that Alternate
Marking MUST be applied in a specific limited domain, as also
mentioned in [RFC8799].
Alternate Marking is a feature applied to a trusted domain, where one
or several operators decide on leveraging and configuring Alternate
Marking according to their needs. Additionally, operators need to
properly secure the Alternate Marking domain to avoid malicious
configuration and attacks, which could include injecting malicious
packets into a domain. So the implementation of Alternate Marking is
applied within a controlled domain where the network nodes are
locally administered. A limited administrative domain provides the
network administrator with the means to select, monitor and control
the access to the network.
8. IANA Considerations
The SRH TLV Type should be assigned in IANA's Segment Routing Header
TLVs Registry.
This draft requests to allocate a SRH TLV Type for Alternate Marking
TLV data fields under registry name "Segment Routing Header TLVs"
requested by [RFC8754].
SRH TLV Type Description Reference
-----------------------------------------------------------
TBD AltMark Data Fields TLV This document
9. Acknowledgements
The authors would like to thank Haoyu Song for the precious comments
and suggestions.
10. Contributors
The following people provided relevant contributions to this
document:
Fioccola, et al. Expires 10 September 2023 [Page 9]
Internet-Draft SRv6 AMM March 2023
Massimo Nilo
Telecom Italia
Email: massimo.nilo@telecomitalia.it
Fabrizio Milan
Telecom Italia
Email: fabrizio.milan@telecomitalia.it
Fabio Bulgarella
Telecom Italia
Email: fabio.bulgarella@guest.telecomitalia.it
11. References
11.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>.
[RFC9341] Fioccola, G., Ed., Cociglio, M., Mirsky, G., Mizrahi, T.,
and T. Zhou, "Alternate-Marking Method", RFC 9341,
DOI 10.17487/RFC9341, December 2022,
<https://www.rfc-editor.org/info/rfc9341>.
[RFC9342] Fioccola, G., Ed., Cociglio, M., Sapio, A., Sisto, R., and
T. Zhou, "Clustered Alternate-Marking Method", RFC 9342,
DOI 10.17487/RFC9342, December 2022,
<https://www.rfc-editor.org/info/rfc9342>.
11.2. Informative References
[I-D.ietf-6man-eh-limits]
Herbert, T., "Limits on Sending and Processing IPv6
Extension Headers", Work in Progress, Internet-Draft,
draft-ietf-6man-eh-limits-02, 28 February 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-6man-eh-
limits-02>.
[]
Voyer, D., Filsfils, C., Dukes, D., Matsushima, S., Leddy,
J., Li, Z., and J. Guichard, "Deployments With Insertion
of IPv6 Segment Routing Headers", Work in Progress,
Internet-Draft, draft-voyer-6man-extension-header-
insertion-10, 20 November 2020,
<https://datatracker.ietf.org/doc/html/draft-voyer-6man-
extension-header-insertion-10>.
Fioccola, et al. Expires 10 September 2023 [Page 10]
Internet-Draft SRv6 AMM March 2023
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
(SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
<https://www.rfc-editor.org/info/rfc8754>.
[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>.
[RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
(SRv6) Network Programming", RFC 8986,
DOI 10.17487/RFC8986, February 2021,
<https://www.rfc-editor.org/info/rfc8986>.
[RFC9098] Gont, F., Hilliard, N., Doering, G., Kumari, W., Huston,
G., and W. Liu, "Operational Implications of IPv6 Packets
with Extension Headers", RFC 9098, DOI 10.17487/RFC9098,
September 2021, <https://www.rfc-editor.org/info/rfc9098>.
[RFC9256] Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov,
A., and P. Mattes, "Segment Routing Policy Architecture",
RFC 9256, DOI 10.17487/RFC9256, July 2022,
<https://www.rfc-editor.org/info/rfc9256>.
[RFC9343] Fioccola, G., Zhou, T., Cociglio, M., Qin, F., and R.
Pang, "IPv6 Application of the Alternate-Marking Method",
RFC 9343, DOI 10.17487/RFC9343, December 2022,
<https://www.rfc-editor.org/info/rfc9343>.
Authors' Addresses
Giuseppe Fioccola
Huawei
Riesstrasse, 25
80992 Munich
Germany
Email: giuseppe.fioccola@huawei.com
Tianran Zhou
Huawei
156 Beiqing Rd.
Fioccola, et al. Expires 10 September 2023 [Page 11]
Internet-Draft SRv6 AMM March 2023
Beijing
100095
China
Email: zhoutianran@huawei.com
Mauro Cociglio
Telecom Italia
Email: mauro.cociglio@outlook.com
Gyan S. Mishra
Verizon Inc.
Email: gyan.s.mishra@verizon.com
Xuewei Wang
Ruijie
Email: wangxuewei1@ruijie.com.cn
Fioccola, et al. Expires 10 September 2023 [Page 12]