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.
>
>
> 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.
>
> Another question of mine is, for a router with certain buffer size, aren't
> the IPv6 header chain limit size and the whole header chain limit of the same
> value?
The IPv6 header chain consists of the IPv6 header and any extension
headers defined in RFC8200. The aggregate header chain consists of the
IPv6 header chain and some number of headers that follow which could
include headers for encapsulation, transport layer headers, etc. The
IPv6 header chain is well defined, but the aggregate header chain size
is defined by the consumer.
[Yao2]As for my understanding , the consumer can decide for the Ethernet header
up to where can be seens as the aggregate header chain that need to be
processed by a forwarding node. But the aggregate header chain size limit is
determined by the node's buffer size. And the IPv6 header chain size limit is
determined by the node's buffer size as well.
A couple of general points:
* The draft states "Although there are already some related works on
packet processing size, but they are not sufficient.", if you want to
make that argument then please reference RFC8883 and
draft-ietf-6man-eh-limits and describe why they're not sufficient.
* I know that your primary motivation for this draft is segment
routing, but extension header limits are a general problem and not
unique to segment routing. Please consider the general problem of how
hosts can productively use extension headers in environments where
intermediate nodes may enforce limits.
[Yao2] Thanks a lot for your patients and suggestions. RFC8883 and
draft-ietf-6man-eh-limits offers feasible solutions. What we try to propose is
that, leveraging the existing mechanisms, there might be an optional solution
which may be more convenient for some scenario.
Tom
>
>
> 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月20日 01:03
> Subject: Re: [IPv6] Fw: New Version Notification for
> draft-liu-6man-max-header-size-00.txt
> Please look at draft-ietf-6man-eh-limits that is.
>
> Tom
>
> On Thu, Oct 19, 2023 at 10:02 AM Tom Herbert <t...@herbertland.com> wrote:
> >
> > Yao,
> >
> > Please look at draft-herbert-6man-eh-limits and RFC8883. The draft
> > defines limits for things like maximum IPv6 header chain and maximum
> > extension header size. The RFC defines ICMP errors that can be sent if
> > a limit is exceeded.
> >
> > These can be applied to easily discover what the maximum IPv6 header
> > length is in a limited domain (like segment routing domain). A host
> > would send packets with extension headers, could be probes, to a
> > destination. If routers in the path can't handle the size of the IPv6
> > header they can drop the packet and send an ICMP error per RFC8883.
> >
> > Tom
> >
> >
> > On Thu, Oct 19, 2023 at 9:06 AM <liu.ya...@zte.com.cn> wrote:
> > >
> > > Dear All，
> > >
> > > We've submitted a new draft
> > > https://www.ietf.org/archive/id/draft-liu-6man-max-header-size-00.html.
> > >
> > > This document proposes the concept and the requirement of IPv6 Maximum
> > > Header Size to represent the total header size(IPv6 header and IPv6
> > > extension headers) that a node is able to process from an incoming packet
> > > in IPv6, as well as the signaling requirement for it.
> > >
> > >
> > > Welcome your review and comments！
> > >
> > >
> > > Regards,
> > >
> > > Yao
> > >
> > > Original
> > > From: internet-dra...@ietf.org <internet-dra...@ietf.org>
> > > Date: 2023年10月19日 23:59
> > > Subject: New Version Notification for
> > > draft-liu-6man-max-header-size-00..txt
> > > A new version of Internet-Draft draft-liu-6man-max-header-size-00.txt has
> > > been
> > > successfully submitted by Yao Liu and posted to the
> > > IETF repository.
> > >
> > > Name: draft-liu-6man-max-header-size
> > > Revision: 00
> > > Title: IPv6 Maximum Header Size Requirement
> > > Date: 2023-10-19
> > > Group: Individual Submission
> > > Pages: 6
> > > URL:
> > > https://www.ietf.org/archive/id/draft-liu-6man-max-header-size-00.txt
> > > Status: https://datatracker.ietf.org/doc/draft-liu-6man-max-header-size/
> > > HTML:
> > > https://www.ietf.org/archive/id/draft-liu-6man-max-header-size-00.html
> > > HTMLized:
> > > https://datatracker.ietf.org/doc/html/draft-liu-6man-max-header-size
> > >
> > >
> > > Abstract:
> > >
> > > This document proposes the concept and the requirement of IPv6
> > > Maximum Header Size to represent the total header size that a node is
> > > able to process from an incoming packet in IPv6, as well as the
> > > requirement for it.
> > >
> > >
> > >
> > > The IETF Secretariat
> > >
> > >
> > > --------------------------------------------------------------------
> > > IETF IPv6 working group mailing list
> > > i...@ietf.org
> > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > > --------------------------------------------------------------------
>
>
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
