Thank you Gunter for your comments. Please find responses inline with GVP1> Thanks Prasad
-----Original Message----- From: Gunter Van de Velde via Datatracker <[email protected]> Sent: Tuesday, September 15, 2026 06:44 PM To: The IESG <[email protected]> Cc: [email protected]; [email protected]; [email protected]; [email protected] Subject: Gunter Van de Velde's Discuss on draft-ietf-lisp-rfc6831bis-07: (with DISCUSS and COMMENT) Gunter Van de Velde has entered the following ballot position for draft-ietf-lisp-rfc6831bis-07: 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-lisp-rfc6831bis/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- # Gunter Van de Velde, RTG AD, comments for review of draft-ietf-lisp-rfc6831bis-07 # The line, if any, numbers used are rendered from IETF idnits tool: https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-lisp-rfc6831bis-07.txt # Many thanks to Darren Dukes for the RTGDIR review and to Luigi Iannone for the shepherd write-up. # Thanks for this document and great write-up. When reviewing i found one blocking item [DISCUSS#1] and some comments that the authors and working group may want to consider. # [DISCUSS#1] Section 12: the mtrace requirement cannot be implemented Section 12 says that mtrace “MUST” show every hop from receiver to source, immediately followed by a statement that the design remains to be determined. In addition, section 1 also puts detailed mtrace behavior outside scope. An implementation cannot conform to the "MUST" of this undefined requirement. GVP1> Thanks, the section has been rewritten in version 08, to addresses this comment. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- [COMMENT#1] The abstract says that the specification supports both multicast and unicast underlays, including a mixture of multicast and unicast replication state. However, the exact behavior for those cases seems unclear. for example, when looking at Sections 8.1 and 8.2 only the multicast-underlay forwarding path is discussed and no unicast? GVP1> Thanks, this has been addressed in ver 08 as part of Ketan's comments [COMMENT#2] is there a reason RFC 9301 is not mentioned? Map-Requests, Map-Replies, Negative Map-Replies, Locator Records, and the multicast priority and weight fields are specified by RFC 9301, not RFC 9300. RFC 9301 therefore is a normative reference. Also have a look at exact field names and align rfc6831bit with rfc9301 names (for example “M Priority” vs “Mpriority”). GVP1> The reference to RFC9301 is now included, thanks [COMMENT#3] address-family behavior conflicts with RFC 9300 (see section 9.2) Section 9.2 says multicast ITRs will encapsulate only when the inner and outer headers use the same address family. RFC 9300, Section 5 requires support for all four IPv4/IPv6 inner/outer combinations. This restriction may be a reasonable, but the document currently also says its data plane conforms to RFC 9300 (section 8). GVP1> I think this is scope for future work. For now can we keep the existing text? [COMMENT#4] I think that in section8.1.1, (RLOC,G) should be (S-RLOC,G-u). GVP1> Thanks, fixed this in version 10. [COMMENT#5] Should the reference for M Priority/M Weight policy not be RFC 9301 instead of RFC 6836? GVP1> Thanks, this already has been fixed. [COMMENT#6] Outside of the boilerplate i just spotted 4 uppercase BCP14 language words through the document. Is that intentional for your proposed standard? GVP1> Please refer to version 09. There are many BCP14 keywords now compared to ver-07. Kindly let me know if the current document look satisfactory. Brgds, Gunter Van de Velde Routing Area Director _______________________________________________ lisp mailing list -- [email protected] To unsubscribe send an email to [email protected]
