[lisp] Re: Gorry Fairhurst's Discuss on draft-ietf-lisp-rfc6831bis-07: (with DISCUSS and COMMENT)

["Vengada Prasad Govindan (venggovi)" <[e-mail]>]

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

-----Original Message-----
From: Gorry Fairhurst via Datatracker <[e-mail]> 
Sent: Monday, September 14, 2026 02:44 PM
To: The IESG <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]
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-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:
----------------------------------------------------------------------



# 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-positions-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.

* 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. 

* 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.

(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.

* 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 with interoperability requirements (using RFC2119 keywords). Sec 9 is more on the operation side, hence there is not much scope for interoperability. Please let me know if you agree with this assessment. However please see below for certain changes in Sec 9.2 

* 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.

(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.

---

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 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 draft-ietf-lisp-multicast-deploy

(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.

(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. All deployment experiences are documented in the 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

(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 risk by using allow/ deny access-lists. The Security 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