Yao – A few comments…
While I appreciate that the limits you are defining are different than any of the limits currently supported by the IGP MSD-Types registry, I think they still fall conceptually into the same generic bucket i.e., you want to advertise a limit related to a type of packet encapsulation used for forwarding. I see no need to create a new registry nor consume a new sub-TLV code point. The existing IGP MSD registry is very appropriate. It is not within the purview of the LSR WG to define these new limits. This needs to be discussed in the MPLS and SPRING WGs, respectively, and preferably the definitions of the new parameters and discussion of how they can be used is part of a document in each WG. The IGP draft then simply becomes a definition of how to advertise values defined in referenced documents from MPLS/SPRING. The IGP draft is still needed but must be preceded by the MPLS/SPRING work. I suggest you put this draft on hold for now. The Introduction discusses the parameters as limits to the processing capability of a given node (or link). If a packet were to arrive with an encap exceeding this limit it can be assumed that the packet would not be forwarded correctly. This makes sense. However, in Section 5 you introduce the phrase “node can read from an incoming [MPLS/IPv6] packet without performance impact” – which suggests that a node could indeed process the packet correctly – but it might be slower than packets received below the limit. I have difficulty understanding the operational definition of “performance impact” (Is 10% degradation OK but 50% not OK??) and its use is inconsistent with the description in the Introduction. I would expect that when these terms are discussed/defined by the MPLS/SPRING WGs this confusion will be eliminated – and at that point the IGP draft will simply reference definitions in other drafts – but I did want to highlight this inconsistency. Thanx for listening. Les From: Lsr <lsr-boun...@ietf.org> On Behalf Of liu.ya...@zte.com.cn Sent: Wednesday, October 11, 2023 2:20 AM To: lsr@ietf.org Subject: [Lsr] Fw: New Version Notification for draft-liu-lsr-igp-mpd-00.txt Dear All， We've submitted a new draft https://www.ietf.org/archive/id/draft-liu-lsr-igp-mpd-00.html. This document proposes the concept of Maximum Packet Depth(MPD) to represent the packet size that a node is able process from an incoming packet, and the signaling mechanism for MPD in IGP is defined as well. Welcome your review and comments！ Regards, Yao Original From: internet-dra...@ietf.org<mailto:internet-dra...@ietf.org> <internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>> To: 刘尧00165286;沈益明10054407; Date: 2023年10月10日 15:21 Subject: New Version Notification for draft-liu-lsr-igp-mpd-00.txt A new version of Internet-Draft draft-liu-lsr-igp-mpd-00.txt has been successfully submitted by Yao Liu and posted to the IETF repository. Name: draft-liu-lsr-igp-mpd Revision: 00 Title: Signaling Maximum Packet Depth(MPD) using IGP Date: 2023-10-10 Group: Individual Submission Pages: 9 URL: https://www.ietf.org/archive/id/draft-liu-lsr-igp-mpd-00.txt Status: https://datatracker.ietf.org/doc/draft-liu-lsr-igp-mpd/ HTML: https://www.ietf.org/archive/id/draft-liu-lsr-igp-mpd-00.html HTMLized: https://datatracker.ietf.org/doc/html/draft-liu-lsr-igp-mpd Abstract: This document proposes the concept of Maximum Packet Depth(MPD) to represent the packet size that a node is able process from an incoming packet, the signaling mechanism for MPD in IGP is also defined. The IETF Secretariat
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
