Signaling Aggregate Header Size Limit via IGP
draft-liu-lsr-aggregate-header-limit-00

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]