Thank you, Gorry, sincerely for your review - Prasad -----Original Message----- From: Gorry Fairhurst <[email protected]> Sent: Monday, October 5, 2026 02:32 PM To: Vengada Prasad Govindan (venggovi) <[email protected]>; The IESG <[email protected]> Cc: [email protected]; [email protected]; [email protected]; [email protected] Subject: Re: Gorry Fairhurst's Discuss on draft-ietf-lisp-rfc6831bis-07: (with DISCUSS and COMMENT)
On 02/10/2026 10:30, Vengada Prasad Govindan (venggovi) wrote: > Hello Gorry, > Thank you for your detailed review notes, they are very helpful. > Please find responses inline with GVP1> All changes that are accepted > has been implemented in ver -09 of the draft > (draft-ietf-lisp-rfc6831bis-09) Thanks Prasad For me, these comments are resolved in the latest revision! I'd really like to thank you for the detailed consideration and rewrite of the document standards language and the careful way that you have addressed my comments (details below). I shall clear my DISCUSS position. Best wishes Gorry --- > > -----Original Message----- > From: Gorry Fairhurst via Datatracker <[email protected]> > Sent: Monday, September 14, 2026 02:44 PM > To: The IESG <[email protected]> > Cc: [email protected]; [email protected]; > [email protected]; [email protected] > Subject: Gorry Fairhurst's Discuss on draft-ietf-lisp-rfc6831bis-07: > (with DISCUSS and COMMENT) > > Gorry Fairhurst 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-posi > tions/ 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: > ---------------------------------------------------------------------- > > > > # Gorry Fairhurst WIT AD comments > > Thank you for the work that has been put into this document. > > Please find below some blocking DISCUSS points (easy to address), some > non-blocking COMMENT points/nits (replies would be appreciated even if > only for my own education). > > I was initially surprised to see the small difference from RFC 6831 > (given that described an experimental specification with many topics > that needed to be > explored) to this as a Proposed Standard. When I read further, I > found very few normative requirements and recommendations, and I would > like to raise this as the basis of my DISCUSS topics. > > ## DISCUSS (blocking) > > As noted in > https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positi > ons-20220121/, a DISCUSS ballot is a request to have a discussion on > the points below; I really think that the document would be improved > with a change here, but can be convinced otherwise. > > (1) I see descriptive non-normative sections in a part of the document > where I expected to see normative text. If these sections are > normative, then please explain the requirements and recommendations, > if not then please label them as informative, or better still, move > them before the present section 2 text to clearly show their informative > status. > > * Section 4: "Basic Overview" > - This seems to be a basic overview, with no normative requirements. > Ought this to be more correctly seen as further introduction and > context before what is currently section 2? > GVP1> Agree, the basic overview has now been rewritten and made normative > using requirement specification keywords. I have changed the title of the > section to Theory of Operation to reflect the current text. GF: Thanks, this is clear in the latest revision. > > * Section 5 may also be only informative? > GVP1> There are three changes that has made it normative. From the POV of the > reader, the placement of this is very ideal as Section 5. Hence, I changed > the text to make it Normative and re-aligned the flow for accommodating > unicast underlay as well. I reviewed the new flow and found it satisfactory > to me. GF: Thanks, that works well. > > * Section 7: "Multicast Protocol Changes" > - This seems to be argumentation that there are no changes to a set of > supporting protocols. This doesn't seem to provide any normative requirements. > If that is so, could this be moved before the declaration of the > requirements language in section 2? > --- > GVP1> Agreed, there is no normative specification required here. But moving > it early to Section 2 would confuse the reader without proper background. If > it is absolutely essential, I can find another place (maybe towards the end) > but I prefer to retain it if there is no violation of any rule. GF: GF: Thanks, this reads OK. > > (2) I see many places where protocol interactions are discussed and > described, but no normative requirements and recommendations are > provided. - I would like to understand whether the currently protocol > specification sufficiently robust for a PS specification? I expected > to see requirements for checks of the received protocol information, > or procedures about what to do if elements are malformed or not > present, but I could not find any (please tell me if I missed where these > were specified). > GVP1> I would request you to revisit this comment since Section 4 (Theory of > Operation) and Section 5 (Source Addresses v/s Group addresses). This has now > normative language. GF: This is addressed in the latest revision. > > * Section 6: "Locator Reachability Implications on LISP-Multicast" > - To me this seems to be normative and have implications on interoperability? > If so, I suggest this would benefit from some RFC-2119 language to > define those normative requirements. > GVP1> Agreed, I used RFC2119 language where required. > > * For example, Section 8 offers no interoperability requirements for > reception or processing. Similarly, in Section 9 I could not see any > interoperability requirements defined. > GVP1> ver-08 of the draft was submitted with the Section-8 rewritten > GVP1> with interoperability requirements (using RFC2119 keywords). Sec > GVP1> 9 is more on the operation side, hence there is not much scope > GVP1> for interoperability. Please let me know if you agree with this > GVP1> assessment. However please see below for certain changes in Sec > GVP1> 9.2 GF: Thanks, this is clear. > > * The discussion in Section 9.2 includes text like: "the number of > total combinations grows beyond comprehension", "To rationalize this > combinatorial nightmare, there are some guidelines that need to be put > in place" ... could this text be rewritten in a style more appropriate > for a standard? However, I'd like to understand how this has > progressed from the experimental RFC and what checks are required and > guidance has been derived from the experience. > GVP1> Agreed this section is now reworded to include guidance derived from > experience. > > * Section 11: "Taking Advantage of Upgrades in the Underlay" appears > to discuss interoperability recommendations, can these be formalised > as RFC recommendations in this specification? > GVP1> Agree with your observation. I think this can be removed from the > Proposed Standard safely without affecting the rest of the document. :-). > --- > > (3) Section 9.2 seems to offer two solution space options. > - Why are two different options still presented in a proposed > standard? I expected that part of the experiment in the former > specification was to identify a common solution. However, I can > understand if the WG was unable to specify a single design, but then > would like to understand if there are interoperability implications > and how is a conformant specification to evaluate this? > GVP1> Thanks for catching this. Retained only the mandatory option in this > case. :-). > > Section 9.3. "Making a Multicast Interworking Decision" > - I can understand that an experimental specification identifies areas > of complexity and gaps, but I expected the WG to make a decision > rather than stating this "can be quite complicated, and, if the design > is too ambitious, the dynamics of the protocol could cause a lot of > instability." followed by "sweet spot in the solution space in order to > optimize state requirements..." > Can this section be written as a set of requirements and recommendations? > GVP1> Thanks for pointing this out, the discussion on mPETR in the previous > sections already take care of the required specification. Removed this > subsection as it does not specify anything or add value. GF: OK. > > (4) Please explain the MTRACE requirements and how these will be realised. > Section 12: "Mtrace Considerations" > - For me, this text seems hard to realise, please clarify > "functionality MUST be consistent with unicast traceroute", especially > when followed in the next paragraph with a suggestion that there is no > current specification for this. > Maybe this is one case where the "MUST" is too strong, and this cannot > be an interoperability requirement? (I see the introduction correctly > notes this as > out-of-scope.) > GVP1> I believe this comment has been addressed in ver-08 as part of > addressing Ketan's similar comments. GF: It would of course be nice to say more, and I'm not against stating "wisdom" on how it might be done, but I think you have chosen the simplest approach, to simply leave for another document that does this. > > --- > > I hope that this review helps to improve the document, > GVP1> Sincerely, yes. It did help very much. Thanks > > Regards, > > Gorry Fairhurst > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > COMMENTS (non-blocking) > > (1) Since this RFC is progressing from EXP to PS, I expected to > understand the level of maturity of the specification, the experience > and specifically the answers to questions and concerns in the > experimental RFC. I may have missed this, but I did not see this in > either the Shepherd writeup, or the new document text, and it is > important to understand the actual maturity and interoperability experience. > I and therefore asking for this here: > > * I am unsure what is communicated by the Shepherd Write-up saying > "Implementations are already existing". Which implementations and what > level of interoperability was achieved? What was the deployment experience? > GVP1> Deployment experiences are documented in > GVP1> draft-ietf-lisp-multicast-deploy > > * RFC 6831 noted: "further deployment and experimentation would be > useful to understand the real-life performance of the LISP-Multicast > solution." Is this experience sufficient to underpin this elevation to > PS? Where is this analysed, and could this be provided in the current > document to explain how this has replaced an experimental specification? > --- > GVP1> Deployment experience is documented in > GVP1> draft-ietf-lisp-multicast-deploy GF: Aha. > > (2) Missing reference? I found this text, but did not find an > explanation or supporting reference: "Deployments have successfully > demonstrated the successful minimization of multicast state in the underlay." > GVP1> It is present in the previous sentence of the same paragraph. I hope > this is sufficient. GF: OK, I sorry missed that. > > (3) I read this text "Issues and concerns about the deployment of LISP > for Internet traffic are discussed in [RFC9300]." However, that > document is not specifically about issues. Without some clarification > or reference to a more specific section, this seems an unhelpful > statement, please explain what issues are to be highlighted. > GVP1> This is no longer needed in the PS RFC. Removed this sentence. > GVP1> All deployment experiences are documented in the > GVP1> draft-ietf-lisp-multicast-deploy > > (4) I read this text" To distinguish if the site can receive > dual-stack unicast packets as > well as dual-stack multicast packets, the Mpriority value setting > will be relative to an IPv4 or IPv6 RLOC See [RFC9300] for packet > format details." > - This was hard to parse, but seemed important, could this be clarified? > GVP1> Reworded this, thanks GF: Thanks. > > (5) For me, the following text seems odd: "There may be a security > concern...". > Did the WG see a concern or not? Was this in some deployment scenarios > or for certain uses? The current text seems speculative. > GVP1> Corrected the speculative text, added clarity to mitigate the > GVP1> risk by using allow/ deny access-lists. The Security > GVP1> Considerations section has been rewritten for better clarity > > (6) I expected the document to provide requirements and checks of > information, if these were clearly identified, then their security > properties ought to be discussed in section 12. > GVP1> Same comment as above. > > (7) NiTs: The following are editorial comments that I hope might > improve the next revision of this document: > > /The process is simply to copy/The process is to copy/ - please avoid > language that "sells" the protocol, "simply" seems inappropriate in a > PS RFC. /In the decapsulation case, the ETR simply removes/ - please > avoid language that "sells" the protocol, "simply" seems inappropriate in a > PS RFC. > GVP1> Agreed. All occurrences of the word "simply" are removed > /And to have > the ITR use its own IP address (its RLOC) as the source address./ - > This sentence is incomplete. > GVP1> Removed in ver-08 > /deployed for PIM [RFC7761]/deployed for PIM [RFC7761]./ > GVP1> Fixed GF: Thanks for addressing all these comments. _______________________________________________ lisp mailing list -- [email protected] To unsubscribe send an email to [email protected]
