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" <liu.ya...@zte.com.cn>收件人：lsr <lsr@ietf.org>,ginsberg <ginsb...@cisco.com>,tom <t...@herbertland.com>,"acee.ietf" <acee.i...@gmail.com>抄 送: ipv6 <i...@ietf.org>发送时间：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 Les39s comments 1) To discuss the new concepts in the related WGs.-------- Instead of introducing new concepts to the related WGs, it39s mentioned by Tom that there39s 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 Acee39s 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 Original From: internet-dra...@ietf.org <internet-dra...@ietf.org> 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.txthas been successfully submitted by Yao Liu and posted to theIETF repository. Name: draft-liu-lsr-aggregate-header-limitRevision: 00Title: Signaling Aggregate Header Size Limit via IGPDate: 2024-02-19Group: Individual SubmissionPages: 9URL: https://www.ietf.org/archive/id/draft-liu-lsr-aggregate-header-limit-00.txtStatus: 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.htmlHTMLized: 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 Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
