Thank you, Parag, for the changes. As you have seen by now, I have cleared my previous DISCUSS ballot.
Regards -éric PS: please accept my apologies for delayed reaction From: "Parag Jain (paragj)" <par...@cisco.com> Date: Monday, 8 May 2023 at 19:22 To: Eric Vyncke <evyn...@cisco.com>, The IESG <i...@ietf.org> Cc: "draft-ietf-bess-evpn-lsp-p...@ietf.org" <draft-ietf-bess-evpn-lsp-p...@ietf.org>, "bess-cha...@ietf.org" <bess-cha...@ietf.org>, "bess@ietf.org" <bess@ietf.org>, Matthew Bocci <matthew.bo...@nokia.com> Subject: Re: Éric Vyncke's Discuss on draft-ietf-bess-evpn-lsp-ping-09: (with DISCUSS and COMMENT) Hello Eric Thank you for your careful review and valuable comments. We have addressed them in version 10 of the draft. Pls also see inline. From: Éric Vyncke via Datatracker <nore...@ietf.org> Date: Monday, April 24, 2023 at 6:02 AM To: The IESG <i...@ietf.org> Cc: draft-ietf-bess-evpn-lsp-p...@ietf.org <draft-ietf-bess-evpn-lsp-p...@ietf.org>, bess-cha...@ietf.org <bess-cha...@ietf.org>, bess@ietf.org <bess@ietf.org>, Matthew Bocci <matthew.bo...@nokia.com>, matthew.bo...@nokia.com <matthew.bo...@nokia.com> Subject: Éric Vyncke's Discuss on draft-ietf-bess-evpn-lsp-ping-09: (with DISCUSS and COMMENT) Éric Vyncke has entered the following ballot position for draft-ietf-bess-evpn-lsp-ping-09: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-lsp-ping/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thank you for the work put into this document, it can only help operations. Please find below two blocking DISCUSS points (easy to address), some non-blocking COMMENT points (but replies would be appreciated even if only for my own education). Special thanks to Matthew Bocci for the shepherd's detailed write-up including the WG consensus and the justification of the intended status. I hope that this review helps to improve the document, Regards, -éric # DISCUSS (blocking) As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion on the following topics: ## Missing normative references Even experienced authors sometimes forget to add normative references to RFC 2119 and RFC 8174 ;-) Paragj> added reference to rfc2119 and rfc8174. ## Section 4.4 Probably due to my lack of knowledge about EVPN and RFC 9136 et al, but I wonder how the length of the "IP Prefix" field can be known by the receiver ? There is a "IP Prefix length" field but it seems to indicate the prefix length, e.g., "IP Prefix Len" field could be 32 bit but the "IP Prefix" field itself could be the 128-bit value of 2001:db8:: May I strongly suggest adding clarification text if my understanding is incorrect ? Paragj>Added clarification text as follows: The EVPN IP Prefix Sub-TLV has the format as shown in Figure 4. The total length of this sub-TLV can be either 32 if IPv4 addresses are carried or 56 if IPv6 addresses are carried. The IP prefix and gateway IP address must be from the same IP address family. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # COMMENTS (non blocking) ## Typos I had not the same patience as Jim Guichard for catching all typos... But, it is surprising that there are so many left at this stage of the publication process. Please run a proof reader. Paragj> fixed. ## Section 1 Please expand "PBB" at first use. Paragj> done ## Section 4.1 Even if the old RFC 7432 (dated 8 years ago) only understands 48-bit MAC addresses, there are MAC addresses with different length. Should this document handle those MAC addresses ? Paragj> updated the doc to state that only 48 bit mac addresses are supported. ## Section 6.1 Is there a reason why the MAC addresses are not written in the IEEE standard way ? I.e., "00aa.00bb.00cc" should be written as "00-AA-00-BB-00-CC". Paragj> done In 2023, I would have preferred to have an IPv6 example rather than an IPv4 one. Paragj>Fixed. ## Section 7 Are there mitigation techniques ? paragj> added text. Thanks Parag
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
