On Wed, Oct 25, 2023 at 12:59 AM <liu.ya...@zte.com.cn> wrote: > > Hi Tom, > > Thanks for your thoughts. > > In line with 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月24日 23:30 > Subject: Re: [IPv6] Fw: New Version Notification for > draft-liu-6man-max-header-size-00.txt > 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. > > > Yao>> Signaling works in some scenarios, but it doesn't fits all the cases > like you mentioned in the previous mails. > > For a sending node, even it gets all the extension header capabilities by > routing protocols, it can't make sure that the packet it sends would be > received by the DST node, because it may not be aware of which nodes the > packet would be transmitted through, especially for HBH. For example, the > source node sends a packet with certain DA and the HBH header encapsulated, > but the the source node doesn't know the all intermediate nodes and which > nodes need to process the HBH, so getting Maximum HBH Options header length > can't help.
Yao, I don't see how that's particularly different from the use case described in the draft. If we receive a route to some destination that says some maximum header is supported then that would seem to imply that if we send a packet to the destination all the nodes in the path to the destination will be able to process the larger header. As mentioned previously, the need for a maximum header length isn't unique to segment routing. If even just one intermediate node between segment endpoints enforces a limit less than what's advertised and drops packets because the header length is too long, then that breaks the whole path in segment routing. > > But for a direct connected upstream neighbor node, knowing the extension > header limits of its downstream neighbor may help its decisions on extension > header-related option. And the situation is better for DOH since we know > which nodes would process it. Right, and so the extension header limits of connected neighbors would be an attribute of the link. That information could be advertised in the routing protocol and then propagated as link state information throughout the whole table. This way an advertised route would include the limits for each node on the path to the destination (probably would roll up to be the minimum limit of a node in the path). We can do the same thing for path MTU as well. > > So the signaling proposal has to be related with specific scenario or > requirements as for my understanding. > > As for draft-herbert-eh-inflight-removal, I suppose that the requirement for > BGP extension for Maximum HBH Options header length comes from removing > extension headers by the egress router scenario in section 2.3.1. The egress > node gets the HBH header size limit of the BGP peer and if the limit is > exceeded, the egress node would remove the HBH, not sure if my understanding > is right. But I think as long as the requirement is worthy and clear, we can > try it. At an egress router we want to determine if the peer AS were sending into support extension headers or is going to drop packets with them. If we don't have any information like in a BGP route then the default would be to remove the HBH options header. If the BGP route says they are supported then we can forward the packets unchanged. Tom > > > Tom > > _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
