Hi Yao, some responses inline... On Sun, Oct 22, 2023 at 9:14 AM <liu.ya...@zte.com.cn> wrote: > > Hi Tom, > > Thanks for your prompt and detailed reply. > > Please see in line with [Yao2]. > > > Regards, > > 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月21日 23:38 > Subject: Re: [IPv6] Fw: New Version Notification for > draft-liu-6man-max-header-size-00.txt > 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" > > > [Yao2]I think there might be some confusion in our draft, actually, what we > want to obtain is, for the devices with certain buffer,due to the buffer > size, what's the maximum header size that can be encapsulated in the packet, > if we want these headers all processed at the fast path. For some other > devices, they may don't have buffer, but there's certain processing size > limits as well. Although the requirement mainly comes from the SRv6 scenario, > the concept seems not encapsulation type specific. For example, there maybe > other headers following IPv6 extension headers, if it's expected that these > headers need to be process by some intermediate nodes and the packet needs to > be forwarded, the size of these headers need to be taken into account as well. > > And in MPLS there're potential usecases that the intermediate nodes need to > process the Post-Stack Network Actions beyond the label stack, e.g, IOAM in > MPLS as in draft-gandhi-mpls-ioam. The encapsulating node needs to know the > maximum packet processing size of the IOAM transit nodes to make the IOAM > function work. But considering that the Post-Stack Network Action is still > under discussion and the requirement isn't so clear. We just consider the > usecases in IPv6. > > Although the usecases list in our document can be cover by the IPv6 chain > size limit, but based on the above considerations, Aggregate Header Limit > seems like a more general solution. And we really want to hear opinions from > experts like you.
Okay, then the limit could be Aggregate header limits. RFC8883 defines a Destination Unreachable message when a header is exceeded. > > > > > > > > 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. > > [Yao2] Dynamic paths means the headend node may not know which nodes are in > the path at first, even for the static paths, they may not be configured on > the node at first, so the headend(it may even not know it is the headend node > at first) can't do header size limit discovery as soon as the domain is > formed. Unless it wants to discover this limit for all the nodes in the > domain by sending packets and receiving ICMP errors. Considering the number > of headends and SR Policies in a large domain with many nodes, there's a lot > of work. For the intermediate nodes that would do inserting or > encapsulating, the situation is similar. > > > > > 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. > > > [Yao2] The reason why signaling is considered is that there're already > mechanisms in IGP to signaling certain size limit at per node and per link > basis. Maximum SID Depth (MSD) is originally introduced the number of SIDs > supported by a node or a link on a node and extended to none-SR case further. > The signaling mechanism is general and not SR specific as in RFC8491 and > RFC8496. Taking node MSD as an example, it is included in the IS-IS Router > CAPABILITY TLV, it's a node's capability and would not included in detailed > routing table. So it seems like a new MSD type code would work. But MSD is a segment routing specific parameter, maximum header chain length isn't. For instance, the maximum header length needs to be considered for all nodes in the path by anyone sending extension headers. In the case of segment routing, this isn't just nodes that appear as intermediate destinations in a segment list like MSD is concerned with, but also other routers including those in the path between segment endpoints-- there may be a lot more of those. As I said, trying to figure out the maximum length of EH for some path is a common problem not just for segment routing. Potentially any host in the network would need to know this which could number in the 100Ks, and I don't believe all of them talking IGP will scale. I suppose if your intent is to solve the problem just for segment routing then the draft should be renamed to be "IPv6 Maximum Header Size Requirement for Segment Routing" or something like that. Tom > > > > > > 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. > > > [Yao2]As for my understanding , the consumer can decide for the Ethernet > header up to where can be seens as the aggregate header chain that need to > be processed by a forwarding node. But the aggregate header chain size limit > is determined by the node's buffer size. And the IPv6 header chain size limit > is determined by the node's buffer size as well. > > > 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. > > [Yao2] Thanks a lot for your patients and suggestions. RFC8883 and > draft-ietf-6man-eh-limits offers feasible solutions. What we try to propose > is that, leveraging the existing mechanisms, there might be an optional > solution which may be more convenient for some scenario. > > > > > 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
