On Mon, Oct 23, 2023 at 6:02 AM <liu.ya...@zte.com.cn> wrote: > > Hi Tom， > > In line with [Yao3].
Hi Yao, I've be thinking how to generalize this. Would it make sense to add > > > 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月23日 06:06 > Subject: Re: [IPv6] Fw: New Version Notification for > draft-liu-6man-max-header-size-00.txt > 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. > > > [Yao3] Although MSD is defined originally for SR, it has been extended to > support the none SR case (in MPLS) , and the IGP extension for MSD signaling > is not SR specific. > > But I understand your concerns, we'll focus on our main requirements in SR. > Thanks again for your comments and suggestions. Hi Yao, I've been thinking about how to generalize the ideas in the draft. Do you think it would be feasible to add capability TLVs to various routing protocols for all the limits described draft-ietf-6man-eh-limits (Max aggregate hdr, max DO and HBH opts EH length, max number of HBH or Destopt options, etc.)? I would be especially interested to have Maximum HBH Options header length in BGP; that would work really well with draft-herbert-eh-inflight-removal as a means to extend the limit domain wrt reachability for packets with HBH options. I also think the other limits would have value to be advertised as well. Tom _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
