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

[Gorry Fairhurst via Datatracker <[e-mail]>]

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?

* Section 5 may also be only informative?

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

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

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

* For example, Section 8 offers no interoperability requirements for reception
or processing. Similarly, in Section 9 I could not see any interoperability
requirements defined.

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

* Section 11: "Taking Advantage of Upgrades in the Underlay"  appears to
discuss interoperability recommendations, can these be formalised as RFC
recommendations in this specification?

---

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

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?

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

I hope that this review helps to improve the document,

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?

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

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

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

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

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

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

(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. /And to have
the ITR use its own IP address (its RLOC) as the source address./ - This
sentence is incomplete. /deployed for PIM [RFC7761]/deployed for PIM [RFC7761]./