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.
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
