[lisp] Gunter Van de Velde's Discuss on draft-ietf-lisp-rfc6831bis-07: (with DISCUSS and COMMENT)

[Gunter Van de Velde via Datatracker <[e-mail]>]

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.


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

[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”).

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

[COMMENT#4] I think that in section8.1.1, (RLOC,G) should be (S-RLOC,G-u).

[COMMENT#5] Should the reference for M Priority/M Weight policy not be RFC 9301
instead of RFC 6836?

[COMMENT#6] Outside of the boilerplate i just spotted 4 uppercase BCP14
language words through the document. Is that intentional for your proposed
standard?

Brgds,
Gunter Van de Velde
Routing Area Director