Hi Liyan,
Thanks for your comments.
The main purpose of this paragraph is to declare that even with the IGP
extension in the draft and it is used for path computation, as long as the
path computation node doesn't know whether there're intermediate nodes(i.e, the
nodes between intermediate segment endpoints) along the path need to read
beyond the header chain as well (although in most cases, the intermediate nodes
just do normal IPv6 forwarding and maybe process HBH header), the packet may
still be dropped due to header size exceeding on these intermediate nodes.
It might be something that needs to awared when you implement this feature,
I'll try to refine it to avoid confusion.
Regards,
Yao
Original
From: LiyanGong <[email protected]>
To: 刘尧00165286;lsr <[email protected]>;ginsberg <[email protected]>;tom
<[email protected]>;acee.ietf <[email protected]>;
Cc: ipv6 <[email protected]>;
Date: 2024年02月28日 18:11
Subject: Re:[IPv6]Fw: New Version Notification
fordraft-liu-lsr-aggregate-header-limit-00.txt
Hi Yao,
There is one comment for you to consider.
In the last paragraph of Chapter Four, it discusses whether oversized packets
can be avoided from being discarded or sent to the control plane.
In my view the key point depends on whether this extension is applied to
routing calculations.
This paragraph describes situations where there are other types of device
access, which I think are beyond the scope of IGP and need not be reflected in
this draft.
Would it be better to delete this content?
Best Regards,
Liyan
----邮件原文----
发件人："liu.yao71" <[email protected]>
收件人：lsr <[email protected]>,ginsberg <[email protected]>,tom
<[email protected]>,"acee.ietf" <[email protected]>
抄 送: ipv6 <[email protected]>
发送时间：2024-02-22 15:39:08
主题：[IPv6]Fw: New Version Notification for
draft-liu-lsr-aggregate-header-limit-00.txt
Dear All,
A new draft
https://datatracker.ietf.org/doc/html/draft-liu-lsr-aggregate-header-limit-00
has just been submitted.
This document is a replacement of draft-liu-lsr-igp-mpd as well as
draft-liu-6man-max-header-size.
This document is written to propose extensions for IGP to order to advertise
the Aggregate Header Limit of a node or a link on a node to for efficient
packet processing, and to address the comments and discussions from Tom
Herbert, LesGinsberg and Acee Lindem of the previous drafts.
The the previous discussion can be found below.
https://mailarchive.ietf.org/arch/msg/lsr/ghbI7guNPMyhaxbUBd_4hGcO9zU/ (Les)
https://mailarchive.ietf.org/arch/msg/lsr/X1_LI0hZpO0i705PXNVYVrUL5lA/ (Acee)
https://mailarchive.ietf.org/arch/msg/ipv6/Mmj9ZYzxf0qQZCWX-iM3zp1bTsY/(Tom)
Below are the main points.
For Les's comments
1) To discuss the new concepts in the related WGs.-------- Instead of
introducing new concepts to the related WGs, it's mentioned by Tom that there's
already the concept about the maximum header size that a router can be
processed due to itself own limit is in already introduced in RFC8883, which is
called "Aggregate Header limit". So now this draft use this concept to replace
the self-invented ones in the previous draft.
2) No need to create a new registry nor consume a new sub-TLV code
point.--------IGP-MSD sub-TLV is leveraged as suggested.
3) The term "performance impact "is hard to understand.-----------The term
"with no performance impact" has been changed to "full forwarding rate" to
describe that a router can forward packets without adversely impacting the
aggregate forwarding rate following the definition in
draft-ietf-6man-hbh-processing.
For Acee's comments
1) What is advertised in the proposal?-------- In this new version, Aggregate
header limit is advertised, it is the total header size(e.g, in IPv6, it
includes 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 devices, this limit is
related with its buffer size and buffer design.
2) Would the nodes in the IGP domain make routing decisions based on of the
aggregate header size limit of nodes ,or would the IGP nodes use the
information to determine whether or not the features requiring the additional
headers can be used ? ------------ How to use this value is implementations
specific and optional. Section 4 of this draft provides some possible usages.
Many thanks to Tom for taking the time to discuss with me
on many key questions including, 1)with the existing ICMPv6 error messages for
header limit exceeding in RFC8883, is the signaling mechanism necessary, and 2)
after the IGP signaling is introduced, can situations like packet dropping due
to header limit exceeding be avoided.
1) When there are many nodes(either as headend or intermediate nodes) able to
increase the total header size in the domain, and the paths can be dynamic, by
sending and receiving ICMP messages to detect the limit of the nodes along all
paths is difficult. And more details and usecases are provided in section 1.
2) It has been mentioned in this draft that even with the IGP extension
introduced in this document, packet being dropped can not be completely avoided
and why.
Other discussions like whether it is useful to advertise other header
processing limits via routing protocols are not covered in this document.
Any comments or suggestion about this draft are more than welcome.
Thanks,
Yao
From: [email protected] <[email protected]>
To: 刘尧00165286;沈益明10054407;
Date: 2024年02月19日 16:46
Subject: New Version Notification for
draft-liu-lsr-aggregate-header-limit-00.txt
A new version of Internet-Draft draft-liu-lsr-aggregate-header-limit-00.txt
has been successfully submitted by Yao Liu and posted to the
IETF repository.
Name: draft-liu-lsr-aggregate-header-limit
Revision: 00
Title: Signaling Aggregate Header Size Limit via IGP
Date: 2024-02-19
Group: Individual Submission
Pages: 9
URL:
https://www.ietf.org/archive/id/draft-liu-lsr-aggregate-header-limit-00.txt
Status: https://datatracker.ietf.org/doc/draft-liu-lsr-aggregate-header-limit/
HTML:
https://www.ietf.org/archive/id/draft-liu-lsr-aggregate-header-limit-00.html
HTMLized:
https://datatracker.ietf.org/doc/html/draft-liu-lsr-aggregate-header-limit
Abstract:
This document proposes extensions for IGP to order to advertise the
aggregate header limit of a node or a link on a node to for efficient
packet processing. Aggregate header limit is the total header
size(e.g, in IPv6, it includes 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 devices, this limit is related with its
buffer size and buffer design.
The IETF Secretariat
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
