Internet-Draft PMTU for SR Policy July 2022
Peng, et al. Expires 6 January 2023 [Page]
Workgroup:
SPRING Working Group
Internet-Draft:
draft-peng-spring-pmtu-sr-policy-00
Published:
Intended Status:
Standards Track
Expires:
Authors:
S. Peng
Huawei Technologies
D. Dhody
Huawei Technologies
K. Talaulikar
Arrcus Inc
G. Mishra
Verizon Inc.

Path MTU (PMTU) for Segment Routing Policy

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 6 January 2023.

Table of Contents

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 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 are specified in a separate section.

1.1. Motivation

The motivation for handling SR-PMTU for the SR paths includes (but not limited to):

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

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).

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.


                       +------------------+
              +--------|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

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. Depend 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 a Node SIDs at the time of best path computation. The details of which are out of scope of this document.

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 the all 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 allow 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.

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 the fragmentation on the headend.

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 a SR-PMTU limit aiming to a proper path selection that fulfill 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 SR-PMTU is not considered by the PCE at the time of path computation

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 are smaller than the SR-PMTU constraint set on the headend, the fragmentation will have to be handled. If the 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 smaller than the PMTU of the selected path.

6. SRv6 Specific Handling

In 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

TBD

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, , <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, , <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, , <https://www.rfc-editor.org/info/rfc8402>.
[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, , <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, , <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, , <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, , <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, , <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, , <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, , <https://www.rfc-editor.org/info/rfc4821>.
[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, , <https://www.rfc-editor.org/info/rfc8201>.
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, , <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, , <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, , <https://www.ietf.org/archive/id/draft-ietf-idr-sr-policy-path-mtu-05.txt>.

Authors' Addresses

Shuping Peng
Huawei Technologies
Huawei Campus, No. 156 Beiqing Rd.
Beijing
100095
China
Dhruv Dhody
Huawei Technologies
Divyashree Techno Park, Whitefield
Bangalore 560066
India
Ketan Talaulikar
Arrcus Inc
India
Gyan Mishra
Verizon Inc.
United States of America