Internet DRAFT - draft-peng-spring-pmtu-sr-policy
draft-peng-spring-pmtu-sr-policy
SPRING Working Group S. Peng
Internet-Draft D. Dhody
Intended status: Standards Track Huawei Technologies
Expires: 26 April 2023 K. Talaulikar
Arrcus Inc
G. Mishra
Verizon Inc.
23 October 2022
Path MTU (PMTU) for Segment Routing Policy
draft-peng-spring-pmtu-sr-policy-01
Abstract
This document defines the Path MTU (PMTU) for SR Policy (called SR-
PMTU) and it applies to both SRv6 and SR-MPLS. The framework of SR-
PMTU for SR Policy is specified, including link MTU collection, SR-
PMTU Computation, SR-PMTU Enforcement, and Handling behaviors on the
headend.
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 26 April 2023.
Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
Peng, et al. Expires 26 April 2023 [Page 1]
Internet-Draft SR-PMTU October 2022
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. SR-PMTU Definition for SR Policy . . . . . . . . . . . . . . 4
4.1. SR-PMTU of a Segment List . . . . . . . . . . . . . . . . 4
4.2. SR-PMTU of a Candidate Path . . . . . . . . . . . . . . . 5
4.3. SR-PMTU of an SR Policy . . . . . . . . . . . . . . . . . 5
5. The Framework of SR-PMTU for SR Policy . . . . . . . . . . . 5
5.1. Link MTU Collection . . . . . . . . . . . . . . . . . . . 6
5.2. SR-PMTU Computation . . . . . . . . . . . . . . . . . . . 6
5.2.1. Loose TE Path . . . . . . . . . . . . . . . . . . . . 6
5.2.2. Strict TE Path . . . . . . . . . . . . . . . . . . . 7
5.2.3. Mixed Path . . . . . . . . . . . . . . . . . . . . . 7
5.2.4. Binding Path . . . . . . . . . . . . . . . . . . . . 7
5.2.5. TI-LFA . . . . . . . . . . . . . . . . . . . . . . . 7
5.2.6. Others . . . . . . . . . . . . . . . . . . . . . . . 8
5.3. SR-PMTU Enforcement . . . . . . . . . . . . . . . . . . . 8
5.4. Handling behaviors on the headend . . . . . . . . . . . . 9
5.4.1. SR-PMTU Constraints and Optimization . . . . . . . . 9
5.4.2. Fragmentation processing . . . . . . . . . . . . . . 9
6. SRv6-Specific Handling . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . 10
10.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction
Segment Routing (SR) [RFC8402] allows a node to steer a packet flow
along any path. The headend is a node where the instructions for
source routing (i.e., segments) are written into the packet and hence
becomes the starting node for a specific segment routing path.
Intermediate per-path states are eliminated thanks to source routing.
A Segment Routing Policy (SR Policy)
[I-D.ietf-spring-segment-routing-policy] is an ordered list of
segments (i.e., instructions) that represent a source-routed policy.
The headend node is said to steer a flow into a SR Policy. The
Peng, et al. Expires 26 April 2023 [Page 2]
Internet-Draft SR-PMTU October 2022
packets steered into an SR Policy have an ordered list of segments
associated with that SR Policy written into them. [RFC8660]
describes the representation and processing of this ordered list of
segments as an MPLS label stack for SR-MPLS, while [RFC8754] and
[RFC8986] describe the same for Segment Routing over IPv6 (SRv6) with
the use of the Segment Routing Header (SRH).
[RFC8402] introduces the SR Policy construct and provides an overview
of how it is leveraged for Segment Routing use-cases.
[I-D.ietf-spring-segment-routing-policy] updates [RFC8402] to specify
detailed concepts of SR Policy and steering packets into an SR
Policy.
This document extends the SR Policy to also include the Path MTU
information to SR Policy and applies to both SRv6 and SR-MPLS. The
SRv6-specific handling is specified in a separate section.
1.1. Motivation
The motivation for handling SR-PMTU for the SR paths includes (but is
not limited to):
* Being able to avoid fragmentation by being aware of the SR-PMTU
associated with the SR paths and policies at the headend.
* Being able to generate ICMP messages at the headend.
* When fragmentation is unavoidable, the ability to do it correctly
at the headend.
* Ability to use SR-PMTU as path computation constraint and
optimization criteria at the headend or the controller/PCE.
2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 RFC 2119 [RFC2119] RFC 8174 [RFC8174] when, and only when, they
appear in all capitals, as shown here.
3. Terminology
Peng, et al. Expires 26 April 2023 [Page 3]
Internet-Draft SR-PMTU October 2022
Link MTU: As per [RFC4821], the Maximum Transmission Unit, i.e.,
maximum IP packet size in bytes, that can be conveyed in one piece
over a link. This includes the IP header, but excludes link layer
headers and other framing that is not part of IP or the IP
payload. In case of MPLS, it also includes the label stack and in
case of IPv6, it includes IPv6 extension headers (including SRH).
Path MTU, or PMTU: The minimum link MTU of all the links in a path
between a source node and a destination node. In the scope of
this document, this is also called SR-PMTU for the SR paths and
policies. Note that the link MTU takes the SR overhead (label
stack or SRH) into consideration.
4. SR-PMTU Definition for SR Policy
Segment Routing policy architecture is specified in
[I-D.ietf-spring-segment-routing-policy]. An SR Policy is associated
with one or more candidate paths. A candidate path is selected when
it is valid and it is determined to be the best path of the SR
Policy. The selected path is referred to as the "active path" of the
SR policy. A candidate path is either dynamic, explicit, or
composite. The related concepts with the SR-PMTU definition in this
document are listed as follows.
An explicit/dynamic candidate path is expressed as a Segment-List or
a set of Segment-Lists directly or by computation. If a candidate
path is associated with a set of Segment-Lists, each Segment-List is
associated with weight for weighted load balancing. The default
weight is 1.
A composite candidate path acts as a container for grouping SR
Policies. The composite candidate path construct enables the
combination of SR Policies, each with explicit candidate paths and/or
dynamic candidate paths with potentially different optimization
objectives and constraints, for load-balanced steering of packet
flows over its constituent SR Policies
[I-D.ietf-spring-segment-routing-policy].
4.1. SR-PMTU of a Segment List
A Segment-List represents a specific source-routed path to send
traffic from the headend to the endpoint of the corresponding SR
policy [I-D.ietf-spring-segment-routing-policy]. The SR-PMTU of a
segment list is defined as the minimum link MTU of all the links in a
path between a source node and a destination node. Refer Section 5.2
for specific handling for Node, Adjacency and Binding SID (as well as
their combinations).
Peng, et al. Expires 26 April 2023 [Page 4]
Internet-Draft SR-PMTU October 2022
4.2. SR-PMTU of a Candidate Path
In the case of an explicit/dynamic candidate path, if it is expressed
as a single Segment-List, then the SR-PMTU of the candidate path is
the same as that of the SR-PMTU of the segment list as described in
the above section.
In the case of an explicit/dynamic candidate path, if it is expressed
as a set of Segment-Lists (for load-balancing), then the SR-PMTU of
the candidate path is defined as the minimum SR-PMTU of all the
Segment-Lists in the set.
In the case of a composite candidate path, then the SR-PMTU of the
composite candidate path is defined as the minimum SR-PMTU of all the
constituent SR Policies of this composite candidate path. The SR-
PMTU of each SR Policy is defined in the following subsection.
4.3. SR-PMTU of an SR Policy
According to [I-D.ietf-spring-segment-routing-policy], an SR Policy
is associated with one or more candidate paths. A candidate path is
selected when it is valid and it is determined to be the best path of
the SR Policy. The selected path is referred to as the "active path"
of the SR policy. Then the SR-PMTU for an SR Policy is defined as
the SR-PMTU of the selected/active candidate path of this SR policy.
In the case of an explicit/dynamic candidate path, the SR-PMTU
definition can be referred to in the above subsection.
In the case of a composite candidate path, the SR-PMTU is defined as
the minimum SR-PMTU of all the constituent SR policies. Since the
constituent SR Policies of a composite candidate path do not use
composite candidate paths, only explicit/dynamic candidate paths will
be used, then the SR-PMTU definition of explicit/dynamic candidate
path can be referred to in the above subsection.
5. The Framework of SR-PMTU for SR Policy
The framework of SR-PMTU for SR Policy includes link MTU collection,
SR-PMTU computation, SR-PMTU enforcement, and handling behaviors on
the headend.
Peng, et al. Expires 26 April 2023 [Page 5]
Internet-Draft SR-PMTU October 2022
+------------------+
+--------|Network Controller| SR-PMTU computation
| +--------/|\-------+
| |
SR-PMTU enforcement Link MTU Collection
| |
+-\|/-+ +-----------|-----------+ +-----+
Handling |Head |---| Segment Routing |---|End |
behaviors |end | | Network Domain | |Point|
+-----+ +-----------------------+ +-----+
<---------Link MTU collection---------|
Figure 1. The Framework of SR-PMTU for SR Policy
5.1. Link MTU Collection
SR-PMTU is defined as the minimum link MTU of all the links in a path
between a source node and a destination node. The link MTU needs to
be first collected. The link MTU can be collected through various
protocols such as IGP [I-D.hu-lsr-igp-path-mtu] and BGP-LS
[I-D.ietf-idr-bgp-ls-link-mtu], etc.
5.2. SR-PMTU Computation
The collected link MTU of all the related links are sent to the
network controller where the SR-PMTU is computed. Depending upon the
path type, the computation methods are different, which are described
in the following subsections.
5.2.1. Loose TE Path
In a loose TE path [RFC7855], only Node SIDs are used along the path.
Between two adjacent Node SIDs, generally, there are equal-cost
multipaths (ECMP). The SR-PMTU of the loose TE path is computed by
finding out the minimum SR-PMTU of all the ECMPs between two adjacent
Node SIDs along the loose TE path.
Note that an implementation could maintain the SR-PMTU value
associated with Node SIDs at the time of best path computation. The
details of which are out of the scope of this document.
Peng, et al. Expires 26 April 2023 [Page 6]
Internet-Draft SR-PMTU October 2022
5.2.2. Strict TE Path
In a strict TE path [RFC7855], only Adj SIDs are used along the path.
Since the link MTU of all the links being indicated by the Adj SIDs
of the strict TE path are sent to the network controller, the SR-PMTU
of the strict SR-TE path is computed by finding out the minimum link
MTU of all the links in the strict SR-TE path between its source node
and destination node.
5.2.3. Mixed Path
In a mixed path, both Node SIDs and Adj SIDs are used along the path.
The PMTU of the mixed TE path is computed by finding out the minimum
value of all the ECMPs between two adjacent Node SIDs and the link
MTU of all the links indicated by the Adj SIDs.
5.2.4. Binding Path
The Binding SID (BSID) [RFC8402] is bound to an SR Policy,
instantiation of which may involve a list of SIDs. The SR-PMTU of
the binding path is the same as that of an SR Policy as specified in
the above section modulo that it also includes the encapsulation
overhead associated with it (i.e. in case of SR-MPLS, the additional
label stack pushed in case of SR-MPLS and the outer IPv6 header with
its own SRH in case of SRv6). This is done to make sure the headend
of the SR path that includes a BSID is able to compute the SR-PMTU
correctly by taking the correct SR-PMTU of the binding path into
consideration along with other SIDs in the SR path.
5.2.5. TI-LFA
Topology Independent Loop-free Alternate Fast Re-route (TI-LFA)
[I-D.ietf-rtgwg-segment-routing-ti-lfa], aimed at providing
protection of node and adjacency segments within the SR framework.
The repair path is to pre-compute SPT_new(R,X) for each destination,
that is, the Shortest Path Tree rooted at node R in the state of the
network after the resource X has failed. An implementation is free
to use any local optimization to provide smaller SID lists by
combining Node SIDs and Adjacency SIDs. In addition, the usage of
Node-SIDs allows to maximize ECMPs over the repair path. Note that
while the PMTU of repair path might be different from the original
path, which could lead to fragmentation while the repair path is in
use. When the controller has computed the new path, its new PMTU
would be updated to the headend.
Peng, et al. Expires 26 April 2023 [Page 7]
Internet-Draft SR-PMTU October 2022
Note that it is possible for the headend implementation to take an
FRR overhead into consideration when determining if fragmentation
would be needed for the SR Path with TI-LFA enabled. If this is
used, an implementation SHOULD allow the value to be configured by an
operator.
5.2.6. Others
All other types of path can be considered here in future updates.
5.3. SR-PMTU Enforcement
Currently, there is still no SR-PMTU in the SR Policy encoding
structure [I-D.ietf-spring-segment-routing-policy]. As specified in
[I-D.ietf-idr-sr-policy-path-mtu], the SR-PMTU is encoded in the SR
policy structure as shown in Figure 2. After the SR-PMTU
computation, the SR-PMTU is enforced along with the SR Policy to the
headend of the corresponding path.
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
----> Path MTU (SR-PMTU)
Segment
Segment
...
...
Figure 2. The SR Policy encoding structure with SR-PMTU
When there are multiple paths that can be selected, the one with the
highest SR-PMTU will be enforced in order to avoid fragmentation on
the headend.
The PCEP extension to handle PMTU is specified in
[I-D.ietf-pce-pcep-pmtu].
Peng, et al. Expires 26 April 2023 [Page 8]
Internet-Draft SR-PMTU October 2022
5.4. Handling behaviors on the headend
After the SR-PMTU is computed and enforced on the headend, the
headend is going to perform the handling behaviors such as
encapsulation, fragmentation, etc. Note that this behavior is
similar to the existing behavior of MPLS and IPv6 dataplane.
5.4.1. SR-PMTU Constraints and Optimization
Generally, considering its services being carried, the operators set
an SR-PMTU limit aiming for a proper path selection that fulfills
packet size requirements hence avoiding fragmentation. Furthermore,
the encapsulation on the headend will introduce the overhead on top
of the packet to be encapsulated. Generally, the encapsulation
overhead has to be estimated according to the possible path hops and
sometimes the repair paths. Therefore, the SR-PMTU constraint is set
considering both the carried services and the encapsulation overhead.
When SR-PMTU-based path optimization is done, PCE will select the
path with the highest SR-PMTU among all the possible paths.
Even if the SR-PMTU is not considered by the PCE at the time of path
computation, the computed SR-PMTU is useful at the headend for the
reasons already stated in Section 1.1.
Once the SR-PMTU constraint is set on the headend, it is supposed to
be the lowest bound of the SR-PMTUs of all the paths being computed
locally or enforced by the controller in order to avoid
fragmentation.
5.4.2. Fragmentation processing
If the SR-PMTU of all the paths being computed locally or enforced by
the controller is smaller than the SR-PMTU constraint set on the
headend, the fragmentation will have to be handled. If fragmentation
is not possible, the headend could generate the ICMP messages to
notify the traffic source.
Over this selected path, on the headend, the packets are fragmented
in order to guarantee the size of the encapsulated packets is smaller
than the PMTU of the selected path.
Peng, et al. Expires 26 April 2023 [Page 9]
Internet-Draft SR-PMTU October 2022
6. SRv6-Specific Handling
In the case of SRv6, the SRH is included in the calculation of the
Link MTU and thus in the SR-PMTU. Note that the PMTU considerations
for IPv6 [RFC8201] apply for the SRv6. [RFC8754] also specify the
MTU considerations related to encapsulation with an outer IPv6 header
with SRH.
7. Security Considerations
[I-D.ietf-spring-segment-routing-policy] specifies in detail the SR
Policy construct (introduced [RFC8402]) and its security
consideration. The additional SR-MTU attribute information can be
sensitive in some deployments and could be used to influence SR path
setup and selection with adverse effect. The protocol extensions
that include SR-PMTU need to take this into consideration. This
document does not define any new protocol extensions and thus does
not introduce any further security considerations.
8. IANA Considerations
This document does not include an IANA request.
9. Acknowledgement
Thanks to xx for useful discussions and comments.
10. References
10.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>.
[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>.
[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>.
Peng, et al. Expires 26 April 2023 [Page 10]
Internet-Draft SR-PMTU October 2022
[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>.
[RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing with the MPLS Data Plane", RFC 8660,
DOI 10.17487/RFC8660, December 2019,
<https://www.rfc-editor.org/info/rfc8660>.
[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>.
[RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B.,
Litkowski, S., Horneffer, M., and R. Shakir, "Source
Packet Routing in Networking (SPRING) Problem Statement
and Requirements", RFC 7855, DOI 10.17487/RFC7855, May
2016, <https://www.rfc-editor.org/info/rfc7855>.
[I-D.ietf-spring-segment-routing-policy]
Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and
P. Mattes, "Segment Routing Policy Architecture", Work in
Progress, Internet-Draft, draft-ietf-spring-segment-
routing-policy-22, 22 March 2022,
<https://www.ietf.org/archive/id/draft-ietf-spring-
segment-routing-policy-22.txt>.
[I-D.ietf-rtgwg-segment-routing-ti-lfa]
Litkowski, S., Bashandy, A., Filsfils, C., Francois, P.,
Decraene, B., and D. Voyer, "Topology Independent Fast
Reroute using Segment Routing", Work in Progress,
Internet-Draft, draft-ietf-rtgwg-segment-routing-ti-lfa-
08, 21 January 2022, <https://www.ietf.org/archive/id/
draft-ietf-rtgwg-segment-routing-ti-lfa-08.txt>.
10.2. Informative References
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007,
<https://www.rfc-editor.org/info/rfc4821>.
Peng, et al. Expires 26 April 2023 [Page 11]
Internet-Draft SR-PMTU October 2022
[RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed.,
"Path MTU Discovery for IP version 6", STD 87, RFC 8201,
DOI 10.17487/RFC8201, July 2017,
<https://www.rfc-editor.org/info/rfc8201>.
[I-D.ietf-idr-bgp-ls-link-mtu]
Zhu, Y., Hu, Z., Peng, S., and R. Mwehaire, "Signaling
Maximum Transmission Unit (MTU) using BGP-LS", Work in
Progress, Internet-Draft, draft-ietf-idr-bgp-ls-link-mtu-
03, 30 May 2022, <https://www.ietf.org/archive/id/draft-
ietf-idr-bgp-ls-link-mtu-03.txt>.
[I-D.hu-lsr-igp-path-mtu]
Hu, Z., Peng, S., and X. Xi, "IGP Extensions for Path
MTU", Work in Progress, Internet-Draft, draft-hu-lsr-igp-
path-mtu-00, 19 October 2021,
<https://www.ietf.org/archive/id/draft-hu-lsr-igp-path-
mtu-00.txt>.
[I-D.ietf-idr-sr-policy-path-mtu]
Li, C., Zhu, Y., Sawaf, A. E., and Z. Li, "Segment Routing
Path MTU in BGP", Work in Progress, Internet-Draft, draft-
ietf-idr-sr-policy-path-mtu-05, 21 April 2022,
<https://www.ietf.org/archive/id/draft-ietf-idr-sr-policy-
path-mtu-05.txt>.
[I-D.ietf-pce-pcep-pmtu]
Peng, S., Li, C., Han, L., and L. Ndifor, "Support for
Path MTU (PMTU) in the Path Computation Element (PCE)
communication Protocol (PCEP)", Work in Progress,
Internet-Draft, draft-ietf-pce-pcep-pmtu-02, 6 July 2022,
<https://www.ietf.org/archive/id/draft-ietf-pce-pcep-pmtu-
02.txt>.
Authors' Addresses
Shuping Peng
Huawei Technologies
Huawei Campus, No. 156 Beiqing Rd.
Beijing
100095
China
Email: pengshuping@huawei.com
Peng, et al. Expires 26 April 2023 [Page 12]
Internet-Draft SR-PMTU October 2022
Dhruv Dhody
Huawei Technologies
Divyashree Techno Park, Whitefield
Bangalore 560066
India
Email: dhruv.ietf@gmail.com
Ketan Talaulikar
Arrcus Inc
India
Email: ketant.ietf@gmail.com
Gyan Mishra
Verizon Inc.
United States of America
Email: gyan.s.mishra@verizon.com
Peng, et al. Expires 26 April 2023 [Page 13]
