Re: [spring] [IPv6] Fw: New Version Notification for draft-liu-6man-max-header-size-00.txt

[Tom Herbert <[e-mail]>]

On Thu, Oct 26, 2023 at 2:23 AM <[e-mail]> wrote:
>
> with Yao2>>
>
> Original
> From: TomHerbert <[e-mail]>
> To: 刘尧00165286;
> Cc: [e-mail] <[e-mail]>;[e-mail] <[e-mail]>;
> 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
> >
> >
>
>