Internet DRAFT - draft-liu-spring-aggregate-header-limit-problem

draft-liu-spring-aggregate-header-limit-problem







SPRING                                                            Y. Liu
Internet-Draft                                                       ZTE
Intended status: Informational                                    Y. Liu
Expires: 31 August 2024                                     China Mobile
                                                        28 February 2024


             Problem Statement with Aggregate Header Limit
           draft-liu-spring-aggregate-header-limit-problem-00

Abstract

   Aggregate header limit(AHL) is the total header size 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.  This document
   describes the problems for path calculation and function enablement
   without the awareness of AHL in SRv6, and the considerations for AHL
   collection are also included.

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 31 August 2024.

Copyright Notice

   Copyright (c) 2024 IETF Trust and the persons identified as the
   document authors.  All rights reserved.











Liu & Liu                Expires 31 August 2024                 [Page 1]

Internet-Draft           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 . . . . . . . . . . . . . .   3
     2.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
     2.2.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   3.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   4
   4.  AHL Collection Considerations . . . . . . . . . . . . . . . .   5
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   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] proposes the concept "aggregate header limit" to
   describe this size limit.  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.

   The introduction of IPv6 extension headers, especially SRH, and some
   advanced features/functions have increased the total packet header
   chain size greatly, which may cause inefficient packet processing due
   to aggregate header limit exceeding.

   This document describes the problems for path calculation and
   function enablement without the awareness of AHL, and provides some
   usecases with AHL, the considerations for AHL collection are also
   included.





Liu & Liu                Expires 31 August 2024                 [Page 2]

Internet-Draft           Aggregate Header Limit            February 2024


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.

   AHL: Aggregate header limit.  It the total header sizethat a router
   is able to process at full forwarding rate(e.g, at fast path).

   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 & Liu                Expires 31 August 2024                 [Page 3]

Internet-Draft           Aggregate Header Limit            February 2024


3.  Problem Statement

   The introduction of IPv6 extension headers, especially SRH, and some
   further features/functions have increased the total packet header
   chain size greatly.  Following are some possible scenarios that would
   greatly increase the difficulty of efficient packet processing from
   the aspects of total header size increasing.

   *  Unlike MPLS, even as an intermediate endpoint, the total SRH
      should be withine the processing buffer to achieve efficient
      packet forwarding.  And SRH itself may carry additional TLVs for
      additional functions, e.g, the SRH Opaque Metadata TLV and NSH
      Carrier TLV for SR service programming
      [I-D.ietf-spring-sr-service-programming].  Besides the headend
      node, the intermediate nodes may push extra header to the packet
      as well.  For example, for Binding SID, an SR Segment Endpoint
      nodes 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.

   *  For network performance measurement, several functions have been
      defined.  For IPv6 IOAM pre-allocated trace, the headend attachs
      the hop-by-hop/destination options header with the IOAM data
      fields as introduced in [RFC9486].  And to implement the
      Alternate-Marking Method in IPv6, the AltMark Option is carried by
      the Hop-by-Hop Options Header or the Destination Options
      Header[RFC9343].

   *  To improve the service capability of the network, features like
      network slicing and detnet are proposed.  For network slicing, the
      VTN Option in IPv6 Hop-by-Hop option are provided
      [I-D.ietf-6man-enhanced-vpn-vtn-id].  For detnet, there're
      discussion on carrying detnet related within the IPv6 extension
      headers, either as SRH TLV [draft-wang-detnet-tsn-over-srv6] or as
      Destination Options and Hop-by-Hop Options [draft-xiong-detnet-
      6man-queuing-option].

   Most of the functions mentioned above are not mutually-exclusive, the
   possibility of combination of extension headers/TLVs would make total
   header size even bigger.  Normally, there're different models/
   versions of network devices(i.e, switches, routers) from multiple
   vendors in an operator's network, different devices may have
   different aggregate header limits and different behaviors after
   aggregate header limit exceeding.  As more and more functions
   mentioned above are superimposed in the operator's network, packet
   dropping or rate limiting due to AHL exceeding is a potential risk,
   which makes it difficult to management the network.



Liu & Liu                Expires 31 August 2024                 [Page 4]

Internet-Draft           Aggregate Header Limit            February 2024


   Path calculation, whether by the controller or the headend, without
   the awareness of AHL of the nodes in the network and the prediction
   on which features would be enabled along the path, may result in a
   path with nodes with lower AHLs than required.  If the controller is
   aware of aforesaid information, e.g, when calculation certain path
   for SR Policy, and the controller knows that and per-hop IOAM and
   network slicing would be enabled for this SR Policy, the controller
   would leave out the space for HBH header with options for IOAM and
   VTN-ID and to ensure that the packet header size wouldn't exceed the
   AHLs of the intermediate segment endpoints along the list.

   The situation is similar for packet encapsulation triggered by
   function enablement, whether on the headend or the intermediate
   nodes, packets may be encapsulated with larger header size than the
   downstream nodes able to process.  If AHL information of the nodes/
   path can be obtained in advance, when the node needs to attach extra
   data along the existing path, and the aggregate header limit of the
   downstream nodes along the path are not sufficient to process the
   headers, the node may choose to not to use the related function and
   log an error.

4.  AHL Collection Considerations

   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.  Base on this definition, obtaining
   the minimum AHL along the path can be achieved by sending detection
   messages of certain size and receiving the ICMPv6 error messages.

   This may work when the network is small, with not many static paths.
   But there may be some problems in the following scenarios:

   *  When the number of paths increases, more and more detection
      messages need to be sent, and the burden of processing the
      received ICMPv6 error messages also increases

   *  For dynamic paths, the segment lists of them may change over time,
      which makes it more difficult to detect the AHLs.

   Signaling could be another option.  Considering that there're already
   mechanisms like IGP-MSD [RFC8491][RFC8476] to advertise certain size
   limit at per node and per link basis.  The mechanism for advertising
   AHL is similar with IGP-MSD.  In the inter-domain scenario, the BGP
   signaling may helps as well.

   For the controller, it can get the AHLs of the nodes in the network
   via BGP-LS, YANG or other south-north mechanisms.



Liu & Liu                Expires 31 August 2024                 [Page 5]

Internet-Draft           Aggregate Header Limit            February 2024


   The details of signaling mechanism is out of the scope of the
   document and would be discussed in separated documents.

5.  IANA Considerations

   This document makes no request of IANA.

6.  Security Considerations

   TBA

7.  References

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

   [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-14, 25 February 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-6man-
              hbh-processing-14>.

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

7.2.  Informative References

   [I-D.ietf-6man-enhanced-vpn-vtn-id]
              Dong, J., Li, Z., Xie, C., Ma, C., and G. S. Mishra,
              "Carrying Network Resource Partition (NRP) Information in
              IPv6 Extension Header", Work in Progress, Internet-Draft,



Liu & Liu                Expires 31 August 2024                 [Page 6]

Internet-Draft           Aggregate Header Limit            February 2024


              draft-ietf-6man-enhanced-vpn-vtn-id-06, 20 February 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-6man-
              enhanced-vpn-vtn-id-06>.

   [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-09, 20 February 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-spring-
              sr-service-programming-09>.

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








Liu & Liu                Expires 31 August 2024                 [Page 7]

Internet-Draft           Aggregate Header Limit            February 2024


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

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

   [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


   Yisong Liu
   China Mobile
   China
   Email: liuyisong@chinamobile.com


















Liu & Liu                Expires 31 August 2024                 [Page 8]