On Thu, Oct 26, 2023 at 2:23 AM <liu.ya...@zte.com.cn> wrote: > > with Yao2>> > > Original > From: TomHerbert <t...@herbertland.com> > To: 刘尧00165286; > Cc: i...@ietf.org <i...@ietf.org>;spring@ietf.org <spring@ietf.org>; > Date: 2023年10月25日 23:15 > Subject: Re: [IPv6] Fw: New Version Notification for > draft-liu-6man-max-header-size-00.txt > > > > > 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. > > > Yao2>>The original way we want to do with IGP signaling is to signal this > extension header limit as an attribute of the node/link just like what > IGP-MSD is signaled. > > In IGP for the none SR/SR-BE/SR explicit path, when a node calculate a route > to a certain destination, it knows (from its aspect, although may be not so > accurate) which nodes are on the path, and with the extension header limit > received from each node/link, it's aware of the minimum limit of the path to > the destination. > > But for the HBH header limit of the SR path with intermediate nodes, the > headend may not be able to know the limit, since it may only see the route to > the next SID and can't see all the intermediate nodes. In this case, maybe an > controller is needed.
Yao, I think you're still assuming that Maximum header length is only relevant to segment routing nodes. I claim it's not. One of the reasons that routers drop packets with extension headers is that they push the transport layers too deep in the packet and a router requires that they be accessed to forward the packet. This is described in section 8.1 of RFC9098. In the case of segment routing, this means it's possible for intermediate routers between the segments to drop packets with too many bytes of extension headers. Note that this is independent of what type of extension headers are present-- it could be routing headers, HBH options, IPsec, or a combination of different extensions headers. It's really about limitations of some hardware devices to parse deep into packets. So if we have an attribute of a route generically called Maximum Header length then I believe it's reasonable to assume that is a property of the route and the path not just the destination. I would expect that if we send a packet to the destination and don't exceed the advertised maximum header limit, the packet will be delivered to the destination. If the intent is that it's really just an attribute of the destination, then I suggest that the TLV be named accordingly. But in that case, be aware that it's entirely possible to send packets that don't exceed the advertised limit that are nevertheless dropped by some intermediate node since the header length exceeded their local limit which is less than the max header length specified in the route. Tom When we get a router advertisement thats > > Is your intent about extensions in IGP the same as above, or you want the > extension header limits signaled with the prefix reachability info? If it's > the latter case, it may works for BGP, but in IGP, I don't know how to make > the advertising route to include the limits for each node on the path to the > destination, or advertising with the minimum limit, usually IGP wouldn't > modify the information of the destination during advertising as for my > understanding. > > > > > > 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. > > > Yao2>> For path mtu/link mtu, there're some related works, such as > draft-hu-lsr-igp-link-mtu. In the draft, similarly, the link mtu is > advertised as an link attribute, either the IGP calculates the Path MTU of > per destination address, i.e, records the minimum link MTU of all the links > in the IGP SPF path as the Min Link MTU, or the controller collects the IGP > link mtu via BGP-LS for path computing. > > > > > > > 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. > > > Yao2>> I think it's a clear usecase and requirement. > > > Tom > > > > > > > Tom > > > > > > _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
