Internet DRAFT - draft-liu-lsr-aggregate-header-limit
draft-liu-lsr-aggregate-header-limit
LSR Y. Liu
Internet-Draft Y. Shen
Intended status: Informational ZTE
Expires: 22 August 2024 19 February 2024
Signaling Aggregate Header Size Limit via IGP
draft-liu-lsr-aggregate-header-limit-00
Abstract
This document proposes extensions for IGP to order to advertise the
aggregate header limit of a node or a link on a node to for efficient
packet processing. Aggregate header limit is the total header
size(e.g, in IPv6, it includes the IPv6 header chain as well as any
headers that are part of network encapsulation that precedes the
innermost transport layer) that a router is able to process at full
forwarding rate, for some devices, this limit is related with its
buffer size and buffer design.
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 22 August 2024.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
Liu & Shen Expires 22 August 2024 [Page 1]
Internet-Draft IGP for Aggregate Header Limit February 2024
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. Conventions used in this document . . . . . . . . . . . . . . 4
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Requirements Language . . . . . . . . . . . . . . . . . . 4
3. IGP Extensions . . . . . . . . . . . . . . . . . . . . . . . 5
4. Implementation Considerations . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . 6
8.2. Informative References . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
In terms of processing packets, a device has various limits. One of
the limits is the aggregate header limit. As described in [RFC8883],
some hardware devices implement a parsing buffer of a fixed size to
process packets. The parsing buffer is expected to contain all the
headers that a device needs to examine. If the aggregate length of
headers in a packet exceeds the size of the parsing buffer, a device
will either discard the packet or defer processing to a software slow
path. [RFC8883] defines one code for ICMPv6 Destination Unreachable
that is sent by a node that is unable to process the headers of a
packet due to the aggregate size of the packet headers exceeding a
processing limit.
The introduction of IPv6 extension headers, especially SRH, has
increased the total packet header chain size greatly. And the
possibility of combination of extension headers packets would make
total header size even bigger.
The headend node can attach data on the packet. For SRv6 IOAM pre-
allocated trace, the headend attachs the hop-by-hop options header
with the IOAM data fields ahead of SRH as introduced in [RFC9486].
In the case of SR service
Liu & Shen Expires 22 August 2024 [Page 2]
Internet-Draft IGP for Aggregate Header Limit February 2024
programming[I-D.ietf-spring-sr-service-programming], the SRH Opaque
Metadata TLV and NSH Carrier TLV may be inserted by the headend. For
network slicing purpose, the VTN Option in IPv6 Hop-by-Hop option may
be carried in the packet [I-D.ietf-6man-enhanced-vpn-vtn-id]. And
all the above functions may be used in combination.
The intermediate nodes may increase the header size of the packet
either. The IPv6 extension headers, as well as their TLVs may be
attached by the intermediate destination nodes(e.g SR Segment
Endpoint nodes) via inserting or tunneling. For example, for Binding
SID, an SR Segment Endpoint nodes with an End.B6.Encaps/
End.B6.Encaps.Red [RFC8986] SID instantiated would push a new IPv6
header with its own SRH containing an segment list above the original
IPv6 header. And in the case of TI-LFA
[I-D.ietf-rtgwg-segment-routing-ti-lfa], the PLR node may push a
repair SID list to the original packet.
So for efficient packet processing, in many cases it's very important
to obtain the aggregate header limit that the downstream nodes are
able to process.
As per [RFC8883], an ICMPv6 Destination Unreachable error with code
for "Headers too long" SHOULD be sent when a node discards a packet
because the aggregate length of the headers in the packet exceeds the
processing limits of the node.
While sending ICMPv6 messages for aggregate header size limit
detecting is a solution, in an SR domain, there may be many
nodes(either as headend or intermediate nodes) able to increase the
total header size, and the SR path can be dynamic, which makes it not
easy for these node to obtain the Aggregate Header Limits of the
downstream nodes by sending and processing the ICMP messages. For
example, node A is the headend of 2 SR policies, each SR policy is
consist of 2 candidate paths, and each candidate path includes 2
segment lists, and each segment list contains 8 segments. For
simplicity, assuming that there's no sharing nodes, in this case,
node A needs to send at least 64 ICMPv6 massages, on message for each
node to obtain the size limit of the downstream nodes.
Signaling could be another solution. There're already mechanisms
like IGP-MSD to advertise certain size limit at per node and per link
basis, for both MPLS/SR-MPLS [RFC8491] [RFC8476] and SRv6 [RFC9352],
and the MSD signaling mechanism is not SR-specific. With IGP
signaling, the headend as well as intermediate nodes, can get
aggregate header limits of all the nodes in the domain, which helps
when there're a large amount of paths or the paths are dynamic.
Session 4 provides some possible implementation usages with the IGP
extension.
Liu & Shen Expires 22 August 2024 [Page 3]
Internet-Draft IGP for Aggregate Header Limit February 2024
Based on the considerations above, this document proposes extensions
for IGP to order to advertise the aggregate header limit of a node or
a link on a node for efficient packet processing.
2. Conventions used in this document
2.1. Terminology
The terminology defined in [I-D.ietf-6man-hbh-processing] and
[RFC8491] are used in this document
MSD: Maximum SID Depth.
Forwarding Plane: Routers exchange user data through the forwarding
plane. Routers process fields contained in packet headers. However,
they do not process information contained in packet payloads.
Control Plane: Routers exchange management and routing information.
They also exchange routing information with one another. Management
and routing information are processed by its recipient. Management
and control information can be forwarded by a router that process
fields contained in packet headers.
Fast Path: A path through a router that is optimized for forwarding
packets. The Fast Path might be supported by Application Specific
Integrated Circuits (ASICS), Network Processor (NP), or other special
purpose hardware. This is the usual processing path within a router
taken by the forwarding plane.
Slow Path: A path through a router that is capable of general purpose
processing and is not optimized for any particular function. This
processing path is used for packets that require special processing
or differ from assumptions made in Fast Path heuristics or to process
router control protocols used by the control plane.
Full Forwarding Rate: This is the rate that a router can forward
packets without adversely impacting the aggregate forwarding rate.
For example, a router could process packets at a rate that allows it
to maintain the full speed on its outgoing interfaces, which is
sometimes called "wire speed".
2.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 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Liu & Shen Expires 22 August 2024 [Page 4]
Internet-Draft IGP for Aggregate Header Limit February 2024
3. IGP Extensions
[RFC8491] and [RFC8476] define the means to advertise node-/link-
specific values for MSDs of various types separately for IS-IS and
OSPF, and it's not SR specific. This document leverages the MSD
advertising mechanism in IGP.
A new "IGP MSD-Type value" code is required for aggregate header size
and its value field represents the the total header size that a
router is able to process at full forwarding rate. The total header
size is the size of headers from ethernet header to any headers that
are part of network encapsulation that precedes the innermost
transport layer.
Editor's note: a) Currently the document leverages the existing IGP-
MSD sub-TLV for aggregate header limit advertising by defining a new
type of MSD for protocol simplicity. But considering that MSDs are
now mainly related with the number of SIDs or labels, it can be
further discussed whether defining new types of sub-TLVs is
necessary. b) The term "full forwarding rate" is used instead of
"fast path" following the definition in
[I-D.ietf-6man-hbh-processing].
4. Implementation Considerations
With the IGP extension introduced in this document, how to leverage
the aggregate header size limit is implementation specific and the
details are out of scope of the document. This section provides some
possible usages.
For the intermediate nodes, the aggregate header limits helps when it
needs to increase the size of the packet header(e.g, inserting/
encapsulating headers) that the downstream nodes are expected to
process in the data plane, if the downstream limits are exceeded, the
node MAY choose to not to use the related feature/function and log an
error.
For the headend node, it MAY calculate the SRv6 paths with the
awareness of the aggregate header limits of all the nodes within the
IGP domain. Or when the headend needs to attach extra data along the
existing paths, e.g, IOAM data in the HBH header, if the aggregate
header limit of the nodes along the path are not sufficient to
process the headers(e.g, for intermediate endpoints, it's HBH+SRH),
the headend node MAY choose to not to use the related feature/
function and log an error.
Liu & Shen Expires 22 August 2024 [Page 5]
Internet-Draft IGP for Aggregate Header Limit February 2024
For the controller/PCE, it can collect the aggregate header limits
advertised by IGP via BGP-LS for path computing and other management
purpose, e.g, whether to enable certain function on certain path or
not.
It should be noticed that, even with the IGP extension introduced in
this document, packet being dropped or sent to slow path due to
aggregate header limit exceeding can not be completely avoided. As
mentioned in [RFC8883], an intermediate node may perform deep packet
inspection(DPI) beyond the header chain for ECMP or other purpose.
If the header-size-increasing nodes or the controller are not aware
of the DPI nodes along the path, the packet forwarding may still be
impacted due to aggregate header limit exceeding on the DPI nodes.
For example, for an SRv6 segment list A-B-C, there's an intermediate
node X between B and C, which is not aware of SRH. In many cases, X
may just forward the packets as normal IPv6 packets, but if X would
perform DPI and node A is not aware of that, node A may encapsulate
an packet with larger header chain size than X is able to process,
which would have an impact on the packet forwarding.
5. IANA Considerations
This document requests that IANA allocate a code point from the "IGP
MSD-Types" registry in the "Interior Gateway Protocol (IGP)
Parameters" namespace for "Aggregate Header Limit", referencing this
document.
6. Security Considerations
Security considerations as specified by [RFC8491] and [RFC8476]are
applicable to this document.
7. Acknowledgement
The author would like to thank Tom Herbert, Les Ginsberg and Acee
Lindem for their comments.
8. References
8.1. Normative 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-12, 18 December 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-6man-eh-
limits-12>.
Liu & Shen Expires 22 August 2024 [Page 6]
Internet-Draft IGP for Aggregate Header Limit February 2024
[I-D.ietf-6man-hbh-processing]
Hinden, R. M. and G. Fairhurst, "IPv6 Hop-by-Hop Options
Processing Procedures", Work in Progress, Internet-Draft,
draft-ietf-6man-hbh-processing-13, 18 February 2024,
<https://datatracker.ietf.org/api/v1/doc/document/draft-
ietf-6man-hbh-processing/>.
[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>.
[RFC8883] Herbert, T., "ICMPv6 Errors for Discarding Packets Due to
Processing Limits", RFC 8883, DOI 10.17487/RFC8883,
September 2020, <https://www.rfc-editor.org/info/rfc8883>.
8.2. Informative References
[I-D.ietf-6man-enhanced-vpn-vtn-id]
Dong, J., Li, Z., Xie, C., Ma, C., and G. S. Mishra,
"Carrying Virtual Transport Network (VTN) Information in
IPv6 Extension Header", Work in Progress, Internet-Draft,
draft-ietf-6man-enhanced-vpn-vtn-id-05, 6 July 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-6man-
enhanced-vpn-vtn-id-05>.
[I-D.ietf-rtgwg-segment-routing-ti-lfa]
Bashandy, A., Litkowski, S., 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-
13, 16 January 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-
segment-routing-ti-lfa-13>.
[I-D.ietf-spring-sr-service-programming]
Clad, F., Xu, X., Filsfils, C., Bernier, D., Li, C.,
Decraene, B., Ma, S., Yadlapalli, C., Henderickx, W., and
S. Salsano, "Service Programming with Segment Routing",
Work in Progress, Internet-Draft, draft-ietf-spring-sr-
service-programming-08, 21 August 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-spring-
sr-service-programming-08>.
Liu & Shen Expires 22 August 2024 [Page 7]
Internet-Draft IGP for Aggregate Header Limit February 2024
[RFC8476] Tantsura, J., Chunduri, U., Aldrin, S., and P. Psenak,
"Signaling Maximum SID Depth (MSD) Using OSPF", RFC 8476,
DOI 10.17487/RFC8476, December 2018,
<https://www.rfc-editor.org/info/rfc8476>.
[RFC8491] Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg,
"Signaling Maximum SID Depth (MSD) Using IS-IS", RFC 8491,
DOI 10.17487/RFC8491, November 2018,
<https://www.rfc-editor.org/info/rfc8491>.
[RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W.,
and J. Hardwick, "Path Computation Element Communication
Protocol (PCEP) Extensions for Segment Routing", RFC 8664,
DOI 10.17487/RFC8664, December 2019,
<https://www.rfc-editor.org/info/rfc8664>.
[RFC8814] Tantsura, J., Chunduri, U., Talaulikar, K., Mirsky, G.,
and N. Triantafillis, "Signaling Maximum SID Depth (MSD)
Using the Border Gateway Protocol - Link State", RFC 8814,
DOI 10.17487/RFC8814, August 2020,
<https://www.rfc-editor.org/info/rfc8814>.
[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>.
[RFC9352] Psenak, P., Ed., Filsfils, C., Bashandy, A., Decraene, B.,
and Z. Hu, "IS-IS Extensions to Support Segment Routing
over the IPv6 Data Plane", RFC 9352, DOI 10.17487/RFC9352,
February 2023, <https://www.rfc-editor.org/info/rfc9352>.
[RFC9486] Bhandari, S., Ed. and F. Brockners, Ed., "IPv6 Options for
In Situ Operations, Administration, and Maintenance
(IOAM)", RFC 9486, DOI 10.17487/RFC9486, September 2023,
<https://www.rfc-editor.org/info/rfc9486>.
Authors' Addresses
Yao Liu
ZTE
China
Email: liu.yao71@zte.com.cn
Liu & Shen Expires 22 August 2024 [Page 8]
Internet-Draft IGP for Aggregate Header Limit February 2024
Yiming Shen
ZTE
China
Email: shen.yiming@zte.com.cn
Liu & Shen Expires 22 August 2024 [Page 9]