On Fri, Oct 20, 2023 at 8:35 PM <liu.ya...@zte.com.cn> wrote: > > Hi Tom, > > > Thanks a lot for your comments! > > > There're two types of header limits mentioned in draft-ietf-6man-eh-limits > section 2.2.6. > > One is the size limit for the IPv6 header chain, and another is the whole > header chain size limit(or Aggregate Header Limit as in RFC8883). > > I think our requirement is similar with Aggregate Header Limit.
Hi Yao, I believe the focus in your draft is on SRH EH, that would be part of the IPv6 header chain.The ICMP error if the IPv6 header chain is too big is Parameter Problem with type 7 "Extension header chain too long" > > > While there're some description about Aggregate Header Limit in RFC8883, such > as: > > "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." "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." > > there seem no explicit definition about it. Answered in your question below. > > Do you think a more explicit description is required, such as, "Aggregate > Header Limit is the total header size(in IPv6, it comprise 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 device, this limit is related with its buffer > size". That would make sense > > > While sending ICMPv6 for nodes' header size limit detecting and collecting 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. So it's not easy for these node to obtain the Aggregate > Header Limits of the downstream nodes by sending and processing the ICMP > messages. There would be many ICMP messages produced and it's a burden for > the nodes in a large domain. The properties and handling of an ICMP message for an extension header limit being exceeded are essentially the same as an ICMP Packet too big. When a host receives an error like this they can adjust what they're doing-- in the case of a PTB message they will lower PMTU for a flow, in the case of extension header limited exceed they can reduce the size of EH they're sending. As you point out, paths can be dynamic so a host can periodically increase the size of extension headers to see if there's a new path to allow a larger limit. To mitigate concerns about a flood of ICMP messages they can always be rate limited by routers. > > So signaling this limit is proposed as a solution in our draft. > I have concerns about putting the information into a routing table. As I mentioned, extension header limits are like Path MTU, they are properties derived from every single node in some path to a destination. We don't put PMTU into routing tables, and I don't believe extension header limits should be there. IMO it would introduce a lot of complexity to both hosts as well as routing. For instance, PMTU discovery is implemented without relying on any other protocols such as IP and ICMP. This is good for hosts, and adapting host implementations for extension header limits is straightforward. But if hosts need to participate in routing protocols just to send extension headers then I don't see how that scales. > > Another question of mine is, for a router with certain buffer size, aren't > the IPv6 header chain limit size and the whole header chain limit of the same > value? The IPv6 header chain consists of the IPv6 header and any extension headers defined in RFC8200. The aggregate header chain consists of the IPv6 header chain and some number of headers that follow which could include headers for encapsulation, transport layer headers, etc. The IPv6 header chain is well defined, but the aggregate header chain size is defined by the consumer. A couple of general points: * The draft states "Although there are already some related works on packet processing size, but they are not sufficient.", if you want to make that argument then please reference RFC8883 and draft-ietf-6man-eh-limits and describe why they're not sufficient. * I know that your primary motivation for this draft is segment routing, but extension header limits are a general problem and not unique to segment routing. Please consider the general problem of how hosts can productively use extension headers in environments where intermediate nodes may enforce limits. Tom > > > Thanks, > > Yao > > Original > From: TomHerbert <t...@herbertland.com> > To: 刘尧00165286; > Cc: i...@ietf.org <i...@ietf.org>;spring@ietf.org <spring@ietf.org>; > Date: 2023年10月20日 01:03 > Subject: Re: [IPv6] Fw: New Version Notification for > draft-liu-6man-max-header-size-00.txt > Please look at draft-ietf-6man-eh-limits that is. > > Tom > > On Thu, Oct 19, 2023 at 10:02 AM Tom Herbert <t...@herbertland.com> wrote: > > > > Yao, > > > > Please look at draft-herbert-6man-eh-limits and RFC8883. The draft > > defines limits for things like maximum IPv6 header chain and maximum > > extension header size. The RFC defines ICMP errors that can be sent if > > a limit is exceeded. > > > > These can be applied to easily discover what the maximum IPv6 header > > length is in a limited domain (like segment routing domain). A host > > would send packets with extension headers, could be probes, to a > > destination. If routers in the path can't handle the size of the IPv6 > > header they can drop the packet and send an ICMP error per RFC8883. > > > > Tom > > > > > > On Thu, Oct 19, 2023 at 9:06 AM <liu.ya...@zte.com.cn> wrote: > > > > > > Dear All， > > > > > > We've submitted a new draft > > > https://www.ietf.org/archive/id/draft-liu-6man-max-header-size-00.html. > > > > > > This document proposes the concept and the requirement of IPv6 Maximum > > > Header Size to represent the total header size(IPv6 header and IPv6 > > > extension headers) that a node is able to process from an incoming packet > > > in IPv6, as well as the signaling requirement for it. > > > > > > > > > Welcome your review and comments！ > > > > > > > > > Regards, > > > > > > Yao > > > > > > Original > > > From: internet-dra...@ietf.org <internet-dra...@ietf.org> > > > Date: 2023年10月19日 23:59 > > > Subject: New Version Notification for > > > draft-liu-6man-max-header-size-00..txt > > > A new version of Internet-Draft draft-liu-6man-max-header-size-00.txt has > > > been > > > successfully submitted by Yao Liu and posted to the > > > IETF repository. > > > > > > Name: draft-liu-6man-max-header-size > > > Revision: 00 > > > Title: IPv6 Maximum Header Size Requirement > > > Date: 2023-10-19 > > > Group: Individual Submission > > > Pages: 6 > > > URL: > > > https://www.ietf.org/archive/id/draft-liu-6man-max-header-size-00.txt > > > Status: https://datatracker.ietf.org/doc/draft-liu-6man-max-header-size/ > > > HTML: > > > https://www.ietf.org/archive/id/draft-liu-6man-max-header-size-00.html > > > HTMLized: > > > https://datatracker.ietf.org/doc/html/draft-liu-6man-max-header-size > > > > > > > > > Abstract: > > > > > > This document proposes the concept and the requirement of IPv6 > > > Maximum Header Size to represent the total header size that a node is > > > able to process from an incoming packet in IPv6, as well as the > > > requirement for it. > > > > > > > > > > > > The IETF Secretariat > > > > > > > > > -------------------------------------------------------------------- > > > IETF IPv6 working group mailing list > > > i...@ietf.org > > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > > -------------------------------------------------------------------- > > _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
