Fw: New Version Notification for draft-liu-lsr -aggregate-header-limit-00.txt

<[email protected]>
Newsgroups gmane.ietf.ospf,gmane.ietf.ipv6
Message-ID <[email protected]>
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  


Original


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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.