The Locator/ID Separation Protocol (LISP) for Multicast Environments
draft-ietf-lisp-rfc6831bis-12

[Ballot comment]
Hi Prasad, all,

Many thanks for the follow-up.

The changes made in [1] addresses almost all the points raised in my previous ballot [2].

The only pending one is the following comment. Your proposed approach would work although I have a preferrence if this is covered in the doc itself. That's said, I hope this can be addressed before (or as part of) 8378bis:

...... from OLD Ballot .....

# Multiple LISP Multicast Solutions: Need for clear applicability/positioning

There are at least two approaches to provide multicast in LISP: 6831 and 8378
both were experimental. I see that the WG is also working on RFC8378bis. Each
of those have deployment assumptions either on the underlying network or the
Mapping System.

It seems that both mechanisms were deployed (as gleaned in this document),
which is great. However, I’m missing a discussion in both documents about the
target applicability of each. Having a brief text (common to both -bis
document) would help fix the this.

Better, based on the experience gained with both mechanisms, it would be
helpful to have some guidance when the optimization in 8378 would be sufficient
(for cases with uLISP).

GVP1> Thanks for the comment, this is very insightful. A few observations for your consideration: to my knowledge RFC6831 implementations are far ahead in implementation compared to RFC8378. Agreed both are in -bis stages now in the PS track, but the maturity of RFC6831 (deployment in particular) far exceeds RFC8378. Having said this, what you suggest is a very important aspect to be covered, my only request is we do it in a separate document rather than doing it in the respective -bis documents (6831-bis and 8378-bis). I hope this is reasonable to you. Kindly let me know
......

Cheers,
Med

[1] https://author-tools.ietf.org/iddiff?url1=draft-ietf-lisp-rfc6831bis-07&url2=draft-ietf-lisp-rfc6831bis-11&difftype=--html

[2] https://mailarchive.ietf.org/arch/msg/lisp/9QhERy5nm2at5vXFP5CJ61Rpd5Y/

[Ballot comment]

# Gorry Fairhurst WIT AD comments  (updated after revision of the I-D)

Thank you for the work that has been put into this document.

## Comments (previously blocking - here only for completeness)

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.



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

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]./

---

For me, the above 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 think that these updates helped to improve the document,

Regards,

Gorry Fairhurst

[Ballot comment]
I strongly support Gorry's DISCUSS, and would like to provide an additional example of the lack of normative guidance that I think makes this unready for publication as Proposed Standard (but is otherwise not a distinct DISCUSS from Gorry's, hence No Objection).

Section 10 is almost the same as the original experimental version and says when RFC 3956 is in use that:

>  it is the responsibility of ETRs in multicast receiver
>  sites to map the group address into a group address where the
>  Embedded-RP address is from the RLOC namespace.  The mapped RP
>  address is obtained from an EID-to-RLOC mapping database lookup.

While I saw there are implementations of RFC 6831, draft-ietf-lisp-multicast-deploy does not mention anyone supporting RFC 3956. Has Section 10 been exercised? By whom? This seems like a lot to leave up to implementers as written.

[Ballot comment]
Thanks to the authors and the WG for their work on this document.

I support the update from experimental to PS for this specification that has
implementations and deployment.

Note: Most of my review focuses on the changes since RFC6831 but it also goes
beyond that a bit given the change from experimental to PS:
https://author-tools.ietf.org/iddiff?url1=rfc6831&url2=draft-ietf-lisp-rfc6831bis-06&difftype=--html

Thanks for taking care of my discussion points from the original ballot.
This is now updated to reflect only the open items.

Note: this is not an editorial review but I see that the documents has
several nits that the authors should catch and fix.

Please find below some comments on this document, starting with those that
are document-wide:

1) On BCP 14 key word usage, document-wide: this is an observation about the
document as a whole rather than a defect at any one line. The body carries
hardly any key words; most importantly none of them in a forwarding-procedure
section. Now, lowercase prose is perfectly capable of carrying normative
meaning, but several of them have interoperability implications for which
BCP14 keywords would be appropriate. I am not going to get into individual
cases, so please audit them and replace where there is an interoperability
aspect and for things that are in scope of this document's specifications.

175   Therefore, there are only operational (and not protocol) changes for
176   PIM-ASM [RFC7761], Multicast Source Discovery Protocol (MSDP)
177   [RFC3618], Anycast-RP [RFC4610], and PIM-SSM [RFC4607].  BIDIR-PIM
178   [RFC5015], which typically does not run in an inter-domain
179   environment, is not addressed in depth in this document.

Four protocols are cited side by side in this sentence for the same
reason -- that they need operational rather than protocol changes -- and they
are classified differently. RFC 7761 (PIM-ASM) and RFC 4607 (PIM-SSM) are
normative; RFC 3618 (MSDP) is informative; RFC 4610 (Anycast-RP) is normative.
There is no principle distinguishing them, and RFC 3618's classification is
explained by the question on the RFC 6832 reference at line 1414 rather than
by the reference test.

Please consider a single pass over each of these, their implication, any
change or impact, and then the way they are referenced.

[Ballot comment]
Thanks to Magnus Nyström for their secdir review.

I am impressed at the work Vengada Prasad Govindan and the editors have done to clear discusses and address comments during this period of time!

I support the discuss ballot by Gorry,  that are about the use (or non-use) of BCP 14 language - clearly any requirement that is necessary for interoperability must use BCP 14 language.  In addition, the use of the word 'will' might very well be normative, but might be difficult for an implementer to find.  I encourage the use of obvious normative language (not necessarily BCP 14 style) to make it clear to an implementer what the actual requirements are to produce a compliant implementation. 

I support the comment by Ketan especially about the elevation from Experimental to Proposed Standard.  The diff between RFC 6831 and this draft appears to be minimal and contains no information about either the outcome of the experiment nor what changes lead to the elevation of the specification.  Appendix A lists the actual changes, but a statement in the Introduction which addresses 'why now?' would be useful.

Section 13:  I support the discuss by Mike Bishop.

Normative References:  Having a (recently) expired working group draft as a normative reference seems problematic (but necessary?).  I am assuming that there is a plan... but if there is not, this draft will not be published as it stands today.

[Ballot comment]
# [Updated] Gunter Van de Velde, RTG AD, comments for review of draft-ietf-lisp-rfc6831bis-08
# Many thanks to Darren Dukes for the RTGDIR review and to Luigi Iannone for the shepherd write-up.
# Original [DISCUSS]: https://mailarchive.ietf.org/arch/msg/lisp/vsLGKLZ8EnfOjHyniDRKNlJQKFY/
# [Updated] Many thanks to resolve the open DISCUSS with the v08 document https://mailarchive.ietf.org/arch/msg/i-d-announce/fm1lOWS_rDmJkDkGa4IJgfpz1rE/

Please find the following non-blocking comments:

[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

[Ballot discuss]
Section 16, Normative References:

1234 >    [I-D.ietf-pim-rfc8059-9798bis]
1235 >              Govindan, V. P. and S. Venaas, "PIM Join Attributes for
1236 >              Locator/ID Separation Protocol (LISP) Environments", Work
1237 >              in Progress, Internet-Draft, draft-ietf-pim-rfc8059-
1238 >              9798bis-01, 14 March 2026,

This is a normative reference to draft-ietf-pim-rfc8059-9798bis-01,
which is the specification this document actually depends on for the
PIM Join/Prune attributes it uses:

414 >        [I-D.ietf-pim-rfc8059-9798bis]; this document specifies no
415 >        additional state machinery.

653 >    specified in [I-D.ietf-pim-rfc8059-9798bis].

draft-ietf-pim-rfc8059-9798bis-01 expired in March 2026. There's
currently no path to publication for it.

The history here is worth spelling out, because I think it points to
an easy fix. Through -06, this document cited RFC 8059 and RFC 9798
directly for these attributes. Darren Dukes' RTGDIR review asked
whether those two should be normative or informative references. The
author's reply on the list was, in effect, that the question was moot
because both were being folded into a single reference to
draft-ietf-pim-rfc8059-9798bis, and that's what shipped in -08. Having
now read that bis draft, I don't think the trade was a good one: it's
a pure consolidation of RFC 8059 and RFC 9798 (it just moves the
Transport Attribute and Receiver RLOC Attribute registrations into one
document) and doesn't define anything new that this document actually
relies on. So the change that answered Darren's question left the
document with an unresolved dependency in its place.

I'd ask the authors to revert Section 4 item 8 and Section 7.1 to
citing RFC 8059 and RFC 9798 directly, and drop the reference to the
bis draft. That does bring Darren's original question back: RFC 8059
and RFC 9798 are Experimental, and this document targets Proposed
Standard, so citing them normatively is a downref. But that's a
well-understood problem with a known process.

I'd also note the shepherd write-up (answering as of -06) states there
are no normative references in an unclear state. That was accurate
when written; the -07/-08 revision changed that, and it's worth a
fresh look before this goes further.

[Ballot comment]
Section 17, Informative References, still carries a second, uncited
entry for the same draft:

1314 >    [draft-ietf-pim-rfc8059-9798bis]
1315 >              Govindan, V. and S. Venaas, "PIM Join Attributes for
1316 >              Locator/ID Separation Protocol (LISP) Environments", Work
1317 >              in Progress, Internet-Draft, draft-ietf-pim-rfc8059-
1318 >              9798bis-01, 14 March 2026,

Nothing in the body cites this anchor - both in-text uses I found
(Section 4 item 8 and Section 7.1) use [I-D.ietf-pim-rfc8059-9798bis],
which is the normative entry. This looks like debris from the same
edit that produced my DISCUSS.

---

Building on Ketan's DISCUSS-2 about the unicast receiving procedure,
the normative text in Section 8.3.2 has a scope problem:

811 >    When using a unicast underlay, an ETR MUST accept a unicast LISP-
812 >    encapsulated multicast packet only where the outer destination
813 >    address is one of its own RLOCs.  Additionally, it MAY check whether
814 >    the outer source address is the ITR RLOC it selected for the
815 >    (S-EID,G) in question.  It MUST discard the packet otherwise.

"Otherwise" is ambiguous between the two preceding sentences. If it
only refers back to the destination-address MUST, the optional source
check in the middle sentence is pointless - there's no discard
obligation tied to failing it. If it's meant to cover a failed source
check too, that needs to be MUST-level for a conforming implementation
to know what to do when it chooses to perform the check at all.

----------------------------------------------------------------------
NIT
----------------------------------------------------------------------

All comments below are about very minor potential issues that you may
choose to address in some way - or ignore - as you see fit. Some were
flagged by automated tools (via
https://github.com/larseggert/ietf-reviewtool), so there will likely
be some false positives. There is no need to let me know what you did
with these suggestions.

195 >    [I-D.ietf-lisp-multicast-deploy].  Deployments have successfuly
s/successfuly/successfully/

203 >    This document obsolotes [RFC6831], please see Appendix A for changes.
s/obsolotes/obsoletes/

660 >    There is no D -->ata-Probe logic for ETRs as there can be in the
s/D -->ata-Probe/Data-Probe/

1016 >      defined in Sec 5.4 of [RFC9301] When the M Priority is set to 255,
s/[RFC9301] When/[RFC9301].  When/

1368 >    important changes incude:
s/incude/include/

[Ballot comment]
I support the DISCUSS positions of Gorry Fairhurst, Gunter Van de Velde, Ketan Talaulikar, Mike Bishop, and Med Boucadair.

I have no further GEN area feedback.

[Ballot discuss]
# IESG review of draft-ietf-lisp-rfc6831bis-08

CC @MikeBishop

-08 was posted just as I balloted previously, so updating to track.

## Discuss

### Section 13

I am surprised, to put it mildly, that the new support for unicast
underlays doesn't bring with it any new Security Considerations. This text
appears largely unchanged from RFC 6831.

The new unicast mode makes the ITR's replication list programmable by a remote
party via RFC 8059's Receiver ETR RLOC Attribute. Yet RFC 8059 says "Security of
Join/Prune attributes is only guaranteed by the security of the PIM packet. The
attributes specified herein do not enhance or diminish the privacy or
authenticity of a Join/Prune message." That sounds suspiciously like a
traffic-redirection/amplification vector.

Has this been analyzed anywhere? If there's an existing mitigation (deployment
assumed fully trusted/single-operator, some out-of-band ACL, rate limiting at
the ITR) it should be stated.

[Ballot comment]
## Comments

### RFC 6832: Normative vs. Informative?

Comes up in several places within Section 9. Seems less critical to me than RFC
8059, but still worth a check.

#### Section 9, paragraph 1
```
    This section describes the multicast corollary to [RFC6832] regarding
    the interworking of multicast routing among LISP and non-LISP sites.
```
Is the multicast restatement of this problem in this document complete enough to
be read and implemented *without* consulting RFC6832?

#### Section 9.1.1, paragraph 1
```
    propagate the Join/Prune message out of the site.  This is no
    different than the unicast case that LISP Network Address Translation
    (LISP-NAT) in [RFC6832] solves.
```
Are you sure that an understanding of LISP-NAT isn't required to implement this
section?

#### Section 9.1.1, paragraph 5

I'm unclear how an ITR decides when it should route via an mPETR. Is
this clearly stated somewhere in this document or does it depend on RFC6832?

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Typos

#### "Abstract", paragraph 1
```
-    obsoletes RFC6831
+    obsoletes RFC 6831.
+                +    +
```

#### Section 1, paragraph 4
```
-        in other sites that are LISP enabled.
-                                    ^
+        in other sites that are LISP-enabled.
+                                    ^
```

#### Section 1, paragraph 13
```
-    even when the site is LISP enabled.  That is, internal operation of
-                              ^
-    multicast is unchanged, regardless of whether or not the site is LISP
+    even when the site is LISP-enabled.  That is, internal operation of
+                              ^
+    multicast is unchanged, regardless of whether or not the site is LISP-
+                                                                        +
```

#### Section 1, paragraph 13
```
-    LISP enabled.
-        ^
+    LISP-enabled.
+        ^
```

#### Section 1, final paragraph
```
  This document obsoletes [RFC6831]; please see Appendix A for changes.
                      ^            ^
```

#### Section 3, paragraph 10
```
+SP site (uLISP Site) that is also multicast-capable according to the procedur
+                                          ^
```

#### Section 4, paragraph 14
```
-        where fan-out occurs to multiple sites, a underlay router will
+        where fan-out occurs to multiple sites, an underlay router will
+                                                  +
```

#### Section 9.1, paragraph 1
```
-    LISP enabled.  So, most of the implications are in the underlay with
-        ^
+    LISP-enabled.  So, most of the implications are in the underlay with
+        ^
```

#### Section 9.1, paragraph 6
```
-    are LISP-Multicast enabled; that has been discussed in previous
-                      ^
+    are LISP-Multicast-enabled; that has been discussed in previous
+                      ^
```

#### Section 9.1.1, paragraph 1
```
-    In the first scenario, a site is LISP enabled for both unicast and
-                                        ^
+    In the first scenario, a site is LISP-enabled for both unicast and
+                                        ^
```

#### Section 9.1.1, paragraph 4
```
-    site is LISP enabled or not.  When it is not LISP enabled, the ITR
-                ^                                    ^
+    site is LISP-enabled or not.  When it is not LISP-enabled, the ITR
+                ^                                    ^
```

#### Section 9.1.4, paragraph 1
```
-    receiver site can determine if a source multicast site is LISP
+    receiver site can determine if a source multicast site is LISP-
+                                                                  +
```

#### Section 9.1.4, paragraph 1
```
-    multicast site is a uLISP site, it is LISP enabled, but the ITR, by
-                                              ^
+    multicast site is a uLISP site, it is LISP-enabled, but the ITR, by
+                                              ^
```

#### Section 9.1.4, paragraph 3
```
-    sites; since they think the source multicast site is LISP enabled,
-                                                            ^
-    the ETR cannot know if the ITR is LISP-Multicast enabled.  To solve
-                                                    ^
+    sites; since they think the source multicast site is LISP-enabled,
+                                                            ^
+    the ETR cannot know if the ITR is LISP-Multicast-enabled.  To solve
+                                                    ^
```

#### Section 9.2, paragraph 16
```
-      either LISP-Multicast or uLISP enabled.  This means that priority-
-                                    ^
+      either LISP-Multicast- or uLISP-enabled.  This means that priority-
+                            +        ^
```

#### Section 9.2, paragraph 18
```
-    *  When the source site is not LISP enabled, determining the address
-                                      ^
+    *  When the source site is not LISP-enabled, determining the address
+                                      ^
```

#### Section 13, paragraph 3
```
-    mechanisms deployed for PIM [RFC7761]
+    mechanisms deployed for PIM [RFC7761].
+                                        +
```

#### Section 14, paragraph 1
```
-    No requests are made to IANA
+    No requests are made to IANA.
+                                +
```

### Section 3, paragraph 15
```
        infrastructure.  It is likely a unicast PITR [RFC6832] hereafter
        referred to as uPITR in this document and an mPETR will be co-
```
This defines a new term inside the definition of a different term. Extract
"uPITR" as its own term and definition.

### Section 7.1, paragraph 2
```
  specified in [I-D.ietf-pim-rfc8059-9798bis].
```
This is both a Normative *and* an Informative reference with
different tags. Consolidate, please.

### Section 9.1.1, paragraph 6
```
    their way in the underlay to multicast PxTRs.  Let's call this use of
```
Generally best to avoid first-person language in RFCs.

### Section 12, paragraph 2
```
    [MTRACE] [RFC8487].
```
MTRACE appears to *be* RFC8487; why cite both?

### Grammar/style

#### Section 3, paragraph 5
```
ETR): as defined in [RFC9300]. Additionally it is a router that is on the pa
                              ^^^^^^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Additionally".

#### Section 3, paragraph 7
```
any-to-one mapping between S-EIDs and a S-RLOC. There is a possible solution
                                      ^
```
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

#### Section 8, paragraph 3
```
ticast site joins (S1-EID,Gi) through a underlay distribution tree of (RLOC1,
                                      ^
```
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

#### Section 9.1.5, paragraph 1
```
ves an (S-EID,G) join, it must select a S-RLOC for the same address family as
                                      ^
```
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF]. You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool

[Ballot discuss]
# IESG review of draft-ietf-lisp-rfc6831bis-07

CC @MikeBishop

## Discuss

### Section 4, paragraph 7
```
          PIM Join/ Prune message contains enough information to help the
          ITR build ingress-replicated unicast trees.
```
The "enough information" this message is specified in RFC 8059, but isn't
referenced here. Even where it is, it's only an Informative reference, not
Normative. Can this draft can be successfully implemented without consulting
RFC 8059?

### Section 13

I am surprised, to put it mildly, that the new support for unicast
underlays doesn't bring with it any new Security Considerations. This text
appears largely unchanged from RFC 6831.

The new unicast mode makes the ITR's replication list programmable by a remote
party via RFC 8059's Receiver ETR RLOC Attribute. Yet RFC 8059 says "Security of
Join/Prune attributes is only guaranteed by the security of the PIM packet. The
attributes specified herein do not enhance or diminish the privacy or
authenticity of a Join/Prune message." That sounds suspiciously like a
traffic-redirection/amplification vector.

Has this been analyzed anywhere? If there's an existing mitigation (deployment
assumed fully trusted/single-operator, some out-of-band ACL, rate limiting at
the ITR) it should be stated.

[Ballot comment]
## Comments

### RFC 6832: Normative vs. Informative?

Comes up in several places within Section 9. Seems less critical to me than RFC
8059, but still worth a check.

#### Section 9, paragraph 1
```
    This section describes the multicast corollary to [RFC6832] regarding
    the interworking of multicast routing among LISP and non-LISP sites.
```
Is the multicast restatement of this problem in this document complete enough to
be read and implemented *without* consulting RFC6832?

#### Section 9.1.1, paragraph 1
```
    propagate the Join/Prune message out of the site.  This is no
    different than the unicast case that LISP Network Address Translation
    (LISP-NAT) in [RFC6832] solves.
```
Are you sure that an understanding of LISP-NAT isn't required to implement this
section?

#### Section 9.1.1, paragraph 5

I'm unclear how an ITR decides when it should route via an mPETR. Is
this clearly stated somewhere in this document or does it depend on RFC6832?

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Typos

#### "Abstract", paragraph 1
```
-    obsoletes RFC6831
+    obsoletes RFC 6831.
+                +    +
```

#### Section 1, paragraph 4
```
-        in other sites that are LISP enabled.
-                                    ^
+        in other sites that are LISP-enabled.
+                                    ^
```

#### Section 1, paragraph 13
```
-    even when the site is LISP enabled.  That is, internal operation of
-                              ^
-    multicast is unchanged, regardless of whether or not the site is LISP
+    even when the site is LISP-enabled.  That is, internal operation of
+                              ^
+    multicast is unchanged, regardless of whether or not the site is LISP-
+                                                                        +
```

#### Section 1, paragraph 13
```
-    LISP enabled.
-        ^
+    LISP-enabled.
+        ^
```

#### Section 3, paragraph 10
```
+SP site (uLISP Site) that is also multicast-capable according to the procedur
+                                          ^
```

#### Section 4, paragraph 14
```
-        where fan-out occurs to multiple sites, a underlay router will
+        where fan-out occurs to multiple sites, an underlay router will
+                                                  +
```

#### Section 4, paragraph 18
```
-    (S-RLOC,G) joins and populates the OIF-list state for for the
-                                                          ----
```

#### Section 7.1, paragraph 2
```
-    [I-D.ietf-pim-jp-extensions-lisp]
+    [I-D.ietf-pim-jp-extensions-lisp].
+                                    +
```

#### Section 9.1, paragraph 1
```
-    LISP enabled.  So, most of the implications are in the underlay with
-        ^
+    LISP-enabled.  So, most of the implications are in the underlay with
+        ^
```

#### Section 9.1, paragraph 6
```
-    are LISP-Multicast enabled; that has been discussed in previous
-                      ^
+    are LISP-Multicast-enabled; that has been discussed in previous
+                      ^
```

#### Section 9.1.1, paragraph 1
```
-    In the first scenario, a site is LISP enabled for both unicast and
-                                        ^
+    In the first scenario, a site is LISP-enabled for both unicast and
+                                        ^
```

#### Section 9.1.1, paragraph 4
```
-    site is LISP enabled or not.  When it is not LISP enabled, the ITR
-                ^                                    ^
+    site is LISP-enabled or not.  When it is not LISP-enabled, the ITR
+                ^                                    ^
```

#### Section 9.1.4, paragraph 1
```
-    receiver site can determine if a source multicast site is LISP
+    receiver site can determine if a source multicast site is LISP-
+                                                                  +
```

#### Section 9.1.4, paragraph 1
```
-    multicast site is a uLISP site, it is LISP enabled, but the ITR, by
-                                              ^
+    multicast site is a uLISP site, it is LISP-enabled, but the ITR, by
+                                              ^
```

#### Section 9.1.4, paragraph 3
```
-    sites; since they think the source multicast site is LISP enabled,
-                                                            ^
-    the ETR cannot know if the ITR is LISP-Multicast enabled.  To solve
-                                                    ^
+    sites; since they think the source multicast site is LISP-enabled,
+                                                            ^
+    the ETR cannot know if the ITR is LISP-Multicast-enabled.  To solve
+                                                    ^
```

#### Section 9.2, paragraph 16
```
-      either LISP-Multicast or uLISP enabled.  This means that priority-
-                                    ^
+      either LISP-Multicast- or uLISP-enabled.  This means that priority-
+                            +        ^
```

#### Section 9.2, paragraph 18
```
-    *  When the source site is not LISP enabled, determining the address
-                                      ^
+    *  When the source site is not LISP-enabled, determining the address
+                                      ^
```

#### Section 13, paragraph 3
```
-    Deployments have been succesfully able to leverage existing security
-    mechanisms deployed for PIM [RFC7761]
+    Deployments have been successfully able to leverage existing security
+                              +
+    mechanisms deployed for PIM [RFC7761].
+                                        +
```

#### Section 14, paragraph 1
```
-    No requests are made to IANA
+    No requests are made to IANA.
+                                +
```

### Section 3, paragraph 15
```
        infrastructure.  It is likely a unicast PITR [RFC6832] hereafter
        referred to as uPITR in this document and an mPETR will be co-
```
This defines a new term inside the definition of a different term. Extract
"uPITR" as its own term and definition.

### Section 7.1, paragraph 2
```
    These attributes are further enhanced in
    [I-D.ietf-pim-jp-extensions-lisp]
```
This is now RFC9798.

### Section 9.1.1, paragraph 6
```
    their way in the underlay to multicast PxTRs.  Let's call this use of
```
Generally best to avoid first-person language in RFCs.

### Section 12, paragraph 2
```
    [MTRACE] [RFC8487].
```
MTRACE appears to *be* RFC8487; why cite both?

### Grammar/style

#### Section 3, paragraph 5
```
ETR): as defined in [RFC9300]. Additionally it is a router that is on the pa
                              ^^^^^^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Additionally".

#### Section 3, paragraph 7
```
any-to-one mapping between S-EIDs and a S-RLOC. There is a possible solution
                                      ^
```
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

#### Section 8, paragraph 3
```
ticast site joins (S1-EID,Gi) through a underlay distribution tree of (RLOC1,
                                      ^
```
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

#### Section 9.1.5, paragraph 1
```
ves an (S-EID,G) join, it must select a S-RLOC for the same address family as
                                      ^
```
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF]. You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool

[Ballot discuss]
Hi Dino, Dave, John, Stig, and Vengada,

Thank you for the effort put into this specification.

Please find below some points for discussion:

# Multiple LISP Multicast Solutions: Need for clear applicability/positioning

There are at least two approaches to provide multicast in LISP: 6831 and 8378 both were experimental. I see that the WG is also working on RFC8378bis. Each of those have deployment assumptions either on the underlying network or the Mapping System.

It seems that both mechanisms were deployed (as gleaned in this document), which is great. However, I’m missing a discussion in both documents about the target applicability of each. Having a brief text (common to both -bis document) would help fix the this.

Better, based on the experience gained with both mechanisms, it would be helpful to have some guidance when the optimization in 8378 would be sufficient (for cases with uLISP).

# BCP 229 on Deprecating Any-Source Multicast (ASM) for Interdomain Multicast

CURRENT:
  This document describes the design for inter-domain multicast
  overlays using the Locator/ID Separation Protocol (LISP) architecture
  and protocols.

  ..
  PIM-ASM:  The ASM mode of PIM [RFC7761], the most popular form of
      PIM, is deployed in the Internet today by having shared trees
      within a site and using source trees across sites. 

  …
  Therefore, there are only operational (and not protocol) changes for
  PIM-ASM [RFC7761], Multicast Source Discovery Protocol (MSDP)
  [RFC3618], Anycast-RP [RFC4610], and PIM-SSM [RFC4607].  BIDIR-PIM
  [RFC5015], which typically does not run in an inter-domain
  environment, is not addressed in depth in this document.
  …
  When ASM and PIM-BIDIR are used in an IPv6 inter-domain environment,
  a technique exists to embed the unicast address of an RP in an IPv6
  group address [RFC3956]. 

There are several statements in the document about the inter-domain scope. However, it is not clear to me to what extent the use of ASM mode in the document adheres to BCP 229, which deprecates ASM for interdomain.

Can we please clarify that?

# MSDP & IPv6

CURRENT:
  MSDP:  MSDP [RFC3618] is used to announce active multicast sources to
      other routing domains (or LISP sites). 

However, RFC 8815 says:

  As a result of this key scalability and security issue,
  along with other deployment challenges with the protocol, MSDP was
  never extended to support IPv6 and remains an Experimental protocol.

The document does not acknowledge these limitations, especially vs. IPv6.

# EIDs and PI

CURRENT:
  The terminology in this section is consistent with the definitions in
  [RFC9300] but is extended specifically to deal with the application
  of the terminology to multicast routing.

..but we do have statements such as:

CURRENT:

  Endpoint ID (EID):  As defined in [RFC9300], a 32-bit (for IPv4) or
      128-bit (for IPv6) value used in the source address field of the
      first (most inner) LISP header of a multicast packet.  The host
      obtains a destination group address the same way it obtains one
      today, as it would when it is a non-LISP site.  The source EID is
      obtained via existing mechanisms used to set a host's "local" IP
      address.  An EID is allocated to a host from an EID-Prefix block
      associated with the site in which the host is located.  An EID can
      be used by a host to refer to another host, as when it joins an
      SSM (S-EID,G) route using IGMP version 3 [RFC3376] or Multicast
      Listener Discovery Version 2 [RFC3810] [RFC4604].  LISP uses
      Provider-Independent (PI) blocks for EIDs; such EIDs MUST NOT be
      used as LISP RLOCs.

## EID can be assigned following conventional techniques in stub networks. Why do we need to make the assumption on the nature of EIDs for LISP in general?

## What that MUST NOT buy us here? Isn’t that interfering with the definition of RLOC:

CURRENT:
  Routing Locator (RLOC):  as defined in [RFC9300]

# MLD

CURRENT:
  The LISP-Multicast architecture will follow this high-level protocol
  and operational sequence:

  1.  Receiver hosts in multicast sites will join multicast content
        the way they do today -- they use IGMP.  When they use IGMPv3
        where they specify source addresses, they use source EIDs; that
        is, they join (S-EID,G).  If the multicast source is external to
        this receiver site, the PIM Join/Prune message flows toward the
        ETRs.

Not sure why only IGMP is called out here? I suggest to mention both IGMP and MLD.

# How the ETR knows the mode to use?

CURRENT:
  3.  When using a multicast underlay, the ETR will build two PIM
        Join/Prune messages, one that contains an (S-EID,G) entry that
        is unicast to the ITR that matches the RLOC the ETR selects, and
        the other that contains an (S-RLOC,G) entry so the underlay
        network can create multicast state from this ETR to the ITR.

  4.  When using a unicast underlay, the ETR will build one PIM Join/
        Prune message, one that contains an (S-EID,G) entry that is
        unicast to the ITR that matches the RLOC the ETR selects.  This
        PIM Join/ Prune message contains enough information to help the
        ITR build ingress-replicated unicast trees.

As the document is about operational changes, what are the required configuration actions at the ETR? is there a mode that is enabled by default? Please consider adding such details.

# The current model assumes that the same address family is used at stub networks and core LISP. How about having an IPv6-only core and having xTRs to use IPv4-conventred IPv6 addresses for servicing IPv4 endpoints? See, for example, Section 7 of RFC8114.

It is completely fine to declare this out of scope.

# Scalability

CURRENT:
  This architecture is consistent and scalable with the architecture
  presented in [RFC9300] where multicast state in the underlay operates
  on Locators, and multicast state at the sites operates on EIDs.

Some performance considerations need to be taken into account as several copies are replicated in the core. How to interpret “scalable” in this context?

# Possible solution

CURRENT:
  There is a possible solution to this problem that reduces the number
  of many-to-one occurrences of (S-EID,G) entries aggregating into a
  single (S-RLOC,G) entry.  If a physical ITR can be assigned multiple
  RLOC addresses and these addresses are advertised in mapping database
  entries, then ETRs at receiver sites have more RLOC address options
  and therefore can join different (RLOC,G) entries for each (S-EID,G)
  entry joined at the receiver site.  It would not scale to have a one-
  to-one relationship between the number of S-EID sources at a source
  site and the number of RLOCs assigned to all ITRs at the site, but
  "n" can reduce to a smaller number in the "n-to-1" relationship.  And
  in turn, this reduces the opportunity for data packets to be
  delivered to sites for groups not joined

## Was this tried in the deployments stated in the document?

## to what extent there are deployments that rely on such multiple RLOC allocation scheme?

## is this “possible solution” something that can be really recommended?

# Consistency with RFC9300

CURRENT:
  Multicast group addresses don't have to be associated with either the
  EID or RLOC namespace.  They actually are a namespace of their own
  that can be treated as logical with relatively opaque allocation.
  So, by their nature, they don't detract from an incremental
  deployment of LISP-Multicast.

rfc9300/#section-14
  In the context of LISP, a multicast group address is both an EID and an RLOC.

Instead of having text that may be interpreted as conflicting with RFC9300. I would suggest to leverage Section 14 of RFC9300.

[Ballot comment]
# Operational Considerations

CURRENT:
  Therefore, there are only operational (and not protocol) changes for
  PIM-ASM [RFC7761], Multicast Source Discovery Protocol (MSDP)
  [RFC3618], Anycast-RP [RFC4610], and PIM-SSM [RFC4607].  BIDIR-PIM
  [RFC5015], which typically does not run in an inter-domain
  environment, is not addressed in depth in this document.

The document is clear that the scope is on the operational changes. However, although the document includes a walk-though protocol operation, it does not include relevant configurations that are needed at various xTR elements. Please refer to draft-ietf-opsawg-rfc5706bis-07 - Guidelines for Considering Operations and Management in IETF Specifications for a guidance on considerations to take into account.


# Changes vs. 6831

Please include a description of the main changes vs. 6831. This can be added in an appendix.

# Successful deployment

CURRENT:
  Deployments have successfuly demonstrated the successful minimization
  of multicast state in the underlay.  The cost of this optimization is
  the extra amount of multicast packets that get sent in the same
  underlay tunnel.

## Not sure how that minimization was assessed and in which scale.

## Unless we have public pointers to cite here, I’m not sure having this text is helpful for readers.

# (nit) MP-BGP

OLD:
  MBGP:  Even though the Multiprotocol Extensions for BGP-4 (MBGP)
      [RFC4760]

NEW:
  MP-BGP:  Even though the Multiprotocol Extensions for BGP-4 (MP-BGP)
      [RFC4760]

Cheers,
Med

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

[Ballot 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

[Ballot 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

[Ballot 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]./

[Ballot comment]
Thanks for the work done (even if the subtleties of LISP combined with multicast are above my head). Thanks for addressing my previous DISCUSS https://mailarchive.ietf.org/arch/msg/lisp/9RmAVraRmODxF0opZceH_l3KX_Y/

[Ballot discuss]
Thanks to the authors and the WG for their work on this document.

I support the update from experimental to PS for this specification that has
implementations and deployment.

Note: Most of my review focuses on the changes since RFC6831 but it also goes
beyond that a bit given the change from experimental to PS:
https://author-tools.ietf.org/iddiff?url1=rfc6831&url2=draft-ietf-lisp-rfc6831bis-06&difftype=--html

I have some discussion points, comments and questions that are provided inline
with the idnits format of v06 of the document. Please look for the tag
at the end to make sure you are receiving the full review.

Before getting into the points, the one thing that I found challenging in this
document are its scoping boundaries; contradictions between some of the
scoping statements and the body of the document. Lack of clarity in relationships
with other documents that made me struggle with which references are normative
and which are informative.

1) The obsoletion has been performed as a relabel rather than as a
  re-specification. RFC 6831's Experimental hedges have been removed without
  the work they stood for being done, and nothing states what changed.

2) The document claims scope it does not specify, or contradicts its own scope
  statements. Most importantly the unicast underlay, which Section 4
  introduces and Sections 8 through 8.3 do not cover.

3) The reference set has not been maintained against the current corpus -- in
  one case to the point of a normative reference that is missing altogether.

Gaps in the specification of the unicast underlay model

666   The LISP-Multicast data-plane operation conforms to the operation and
667   packet formats specified in [RFC9300].  However, encapsulating a
668   multicast packet from an ITR is a much simpler process.  The process
669   is simply to copy the inner group address to the outer destination
670   address.  And to have the ITR use its own IP address (its RLOC) as
671   the source address.  The process is simpler for multicast because
672   there is no EID-to-RLOC mapping lookup performed during packet
673   forwarding.

675   In the decapsulation case, the ETR simply removes the outer header
676   and performs a multicast routing table lookup on the inner header
677   (S-EID,G) addresses.  Then, the OIF-list for the (S-EID,G) entry is
678   used to replicate the packet on site-facing interfaces leading to
679   multicast receiver hosts.

681   There is no Data-Probe logic for ETRs as there can be in the unicast
682   forwarding case.

419   10.  For the unicast underlay, the ITR makes individual copies for
420         every ETR, the outer destination is set to the S-RLOC of the ETR
421         and the outer source address is set to the S-RLOC of the ITR.

696   2.  When the ITR receives a multicast packet, it will have both S-EID
697       state and S-RLOC state stored.  Since the packet was received on
698       a site-facing interface, the RPF lookup is based on the S-EID
699       state.  If the RPF check succeeds, then the OIF-list contains
700       interfaces that are site facing and external facing.  For the
701       site-facing interfaces, no LISP header is prepended.  For the
702       external-facing interfaces a LISP header is prepended.  When the
703       ITR prepends a LISP header, it uses its own RLOC address as the
704       source address and copies the group address supplied by the IP
705       header that the host built as the outer destination address.

747   The following procedure is used by an ETR, when it receives a
748   multicast packet from a source outside of its site:

750   1.  When a multicast data packet is received by an ETR on an
751       external-facing interface, it will do an RPF lookup on the S-RLOC
752       state it has stored.  If the RPF check succeeds, the interfaces
753       from the OIF-list are used for replication to interfaces that are
754       site facing as well as interfaces that are external facing (this
755       ETR can also be a transit multicast router for receivers outside
756       of its site).  When the packet is to be replicated for an
757       external-facing interface, the LISP encapsulation header is not
758       stripped.  When the packet is replicated for a site-facing
759       interface, the encapsulation header is stripped.

761   2.  The packet without a LISP header is now forwarded down the
762       (S-EID,G) distribution tree in the receiver multicast site.

766   Multicast packet replication can happen in the following topological
767   locations:

769   *  In an IGP multicast router inside a site that operates on S-EIDs.

771   *  In a transit multicast router inside of the underlay that operates
772       on S-RLOCs.

774   *  At one or more ETR routers depending on the path a Join/Prune
775       message exits a receiver multicast site.

777   *  At one or more ITR routers in a source multicast site depending on
778       what priorities are returned in a Map-Reply to receiver multicast
779       sites.

781   In the last case, the source multicast site can do replication rather
782   than having a single exit from the site.  But this can occur only
783   when the priorities in the Map-Reply are modified for different
784   receiver multicast sites so that the PIM Join/Prune messages arrive
785   at different ITRs.

Section 4 states that this document covers both a multicast and a unicast
underlay, branching explicitly on the two as seen in the text above. Section 8
and its subsections -- the data-plane architecture and the ITR and ETR
forwarding procedures -- describe largely the multicast case. It also has very
little change from RFC 6831. I am not sure if one can build the unicast case
from this text.

Let me take some examples from the text above. Section 8's opening states the
encapsulation as a single unconditional case -- "The process is
simply to copy the inner group address to the outer destination address" --
which is true only for the multicast underlay. Section 4 item 10 says the
opposite for the unicast case, and it is the only paragraph in the document
that states the unicast outer header. Section 8.1's ITR procedure has the same
single case and is explicit that the outer destination is the group address
copied from the inner header. The pattern follows.

Now, a good deal of the ITR side is already specified elsewhere (RFC 8059) and
this document should not restate it. What no PIM document carries, and what
looks like this document's to specify, is the LISP data-plane half. So, what
I would like to see is the unicast underlay specified where the document
specifies forwarding, rather than in mostly in the overview. In Section 8,
state the two encapsulation cases -- outer destination equal to the inner
group address for the multicast underlay, outer destination equal to the
receiver ETR's RLOC for the unicast underlay -- and say how the case is
selected, citing informatively the draft-ietf-pim-rfc8059-9798bis for the
attribute that carries the receiver site's choice. In Section 8.1, add the
unicast branch to the ITR procedure, and only the part the PIM documents do
not carry: for each (S-EID,G) the ITR replicates once per multicast OIF-list
entry as today and once per entry in the unicast replication list, using its
own RLOC as outer source and that entry's RLOC as outer destination; and say
how Section 8.1.1's tagging rule applies to unicast entries on a multi-RLOC ITR.
In Section 8.2, add the ETR receive rule, per the companion discussion point.
In Section 8.3, add head-end replication at the ITR, and say that it trades underlay
state for ITR-side bandwidth and fan-out cost, which is the operational
consequence a deployer needs. Section 4 then becomes what it should be: an
overview that forward-references Section 8, rather than the only place the
feature is described.

If you would prefer the minimum edit, an alternative shape could be to keep
Section 4 as the narrative and add a new Section 8.4, "Unicast Underlay",
carrying the encoding reference, the ITR procedure, the ETR procedure and
the state model in one place.

Importantly, don't get into PIM machinery and explicitly say that it is out
of scope for this LISP document. I stumbled on the RFC 8059 and RFC 9798,
both being obsoleted by draft-ietf-pim-rfc8059-9798bis. While informative,
would be helpful to describe the relationships and boundaries between
these related documents in PIM and LISP WGs.

Receiving procedure for unicast - uRPF

747   The following procedure is used by an ETR, when it receives a
748   multicast packet from a source outside of its site:

750   1.  When a multicast data packet is received by an ETR on an
751       external-facing interface, it will do an RPF lookup on the S-RLOC
752       state it has stored.  If the RPF check succeeds, the interfaces
753       from the OIF-list are used for replication to interfaces that are
754       site facing as well as interfaces that are external facing (this
755       ETR can also be a transit multicast router for receivers outside
756       of its site).  When the packet is to be replicated for an
757       external-facing interface, the LISP encapsulation header is not
758       stripped.  When the packet is replicated for a site-facing
759       interface, the encapsulation header is stripped.

761   2.  The packet without a LISP header is now forwarded down the
762       (S-EID,G) distribution tree in the receiver multicast site.

This is the companion to the discussion point on the unspecified unicast
underlay. I have kept them apart because this one is on the receiver side.
In the multicast underlay the procedure above is good. What about the unicast
underlay?

What I would like to see added to Section 8.2 is the unicast branch: that an
ETR MUST accept a unicast LISP-encapsulated multicast packet only where the
outer destination address is one of its own RLOCs and the outer source address
is the ITR RLOC it selected for the (S-EID,G) in question, and MUST otherwise
discard the packet; that on acceptance it strips the header and applies the
Section 8.1.2 (S-EID,G) lookup; and that the transit-replication behaviour in
bullet 1 applies to the multicast underlay only. Separately, a sentence
recording the uRPF interaction RFC 8059 Section 1 describes would save an
operator from finding it out the hard way -- where the receiver site wishes to
receive a flow on an RLOC other than the one the Join/Prune was transmitted
from, the Receiver ETR RLOC Attribute conveys it, and deployers should expect
provider uRPF policy to constrain the transmit-side choice. There may be
something that I've got wrong or missed here. This is what comes to my mind
from looking at this document and RFC 8059 together to fill in the gap.

Mtrace - issue with use of MUST and reference problem

1180 12.  Mtrace Considerations

1182   Mtrace functionality MUST be consistent with unicast traceroute
1183   functionality where all hops from multicast receiver to multicast
1184   source are visible.

1186   The design for mtrace for use in LISP-Multicast environments is to be
1187   determined but should build upon mtrace version 2 specified in
1188   [MTRACE] [RFC8487].

181   The scope of this document does not cover multicast-based Traffic
182   Engineering (TE) relative to the TE-ITR (TE-based Ingress Tunnel
183   Router) and TE-ETR (TE-based Egress Tunnel Router) descriptions in
184   [RFC9300].  Similarly, specifying the detailed behavior for multicast
185   Proxy-ITRs (mPITRs) (Section 9.1.3), mtrace (Section 12), and locator
186   reachability (Section 6) is outside the scope of this document.

The MUST is unimplementable and not for this document's specification.
In a LISP overlay is it even achievable at all? The underlay hops between ITR
and ETR are in the RLOC namespace and the site hops are in the EID namespace,
so "all hops ... visible" requires a decision about which namespace a hop is
reported in, and this document does not specify.

The second part is from the Introduction, which lists mtrace among the things
that are out of scope. So a normative requirement is placed, in a section
the Introduction declares out of scope, on a design the same paragraph says
has not been produced. This isn't right for a Proposed Standard.

My suggested and preferred option would be to drop the requirement and keep the
statement of intent -- for example, "Mtrace version 2 [RFC8487] does not
currently define behaviour for LISP-Multicast environments. Defining it is
left to future work." -- and delete [MTRACE].

Now, if the WG wants a requirement here, state one that can be met:
that an ITR and an ETR MUST NOT silently drop Mtrace Version 2 request or
reply packets, and MUST forward them as ordinary multicast or unicast traffic
per Sections 8.1 and 8.2 -- that is, LISP is transparent to mtrace even though
it is not visible to it -- noting the consequence that a trace across a LISP
overlay will show the RLOC-namespace hops as a single hop. The first is the
one I would expect. What should not remain is a MUST attached to an
undetermined design.

Related points: [MTRACE] is an unversioned 2012 Internet-Draft citation
of the document that became RFC 8487, cited on the same line as RFC 8487; and
"should build upon" is a lowercase key word doing normative-looking work.

Missing normative reference to RFC 9301

1002   this problem, each mapping database entry will have a multicast
1003   2-tuple (Mpriority, Mweight) per RLOC [RFC9300].  When the Mpriority
1004   is set to 255, the site is considered not multicast capable.  So, an
1005   ETR in a LISP receiver multicast site can distinguish whether a LISP
1006   source multicast site is a LISP-Multicast site or a uLISP site.

1047   A LISP database mapping entry that describes the Locator-Set,
1048   Mpriority, and Mweight per locator address (RLOC), for an EID-Prefix
1049   associated with a site could have RLOC addresses in either IPv4 or
1050   IPv6 format.  When a mapping entry has a mix of RLOC-formatted
1051   addresses, it is an implicit advertisement by the site that it is a
1052   dual-stack site.  That is, the site can receive IPv4 or IPv6 unicast
1053   packets.

1055   To distinguish if the site can receive dual-stack unicast packets as
1056   well as dual-stack multicast packets, the Mpriority value setting
1057   will be relative to an IPv4 or IPv6 RLOC See [RFC9300] for packet
1058   format details.

Both passages above attribute M Priority and M Weight to RFC 9300. Neither
term appears anywhere in RFC 9300. The Map-Reply Locator record is in RFC 9301:

  M Priority:  Each RLOC is assigned a multicast Priority used by an
      ETR in a receiver multicast site to select an ITR in a source
      multicast site for building multicast distribution trees.  A value
      of 255 means the RLOC MUST NOT be used for joining a multicast
      distribution tree.  For more details, see [RFC6831].

Please add RFC 9301 as a normative reference, and replace reference to
[RFC9300] with [RFC9301] appropriately. Please also adopt the base
specification's terms: this document writes "Mpriority" and "Mweight" where
RFC 9301 says "M Priority" and "M Weight". I found more from RFC 9301 that
could be cited as terminology. Map-Request, Map-Reply, and the Negative
Map-Reply all seem like RFC 9301 constructs attributed to RFC 9300.

[Ballot comment]
Note: this is not an editorial review but I see that the documents has
several nits that the authors should catch and fix.

Please find below some comments on this document, starting with those that
are document-wide:

1) On BCP 14 key word usage, document-wide: this is an observation about the
document as a whole rather than a defect at any one line. The body carries
hardly any key words; most importantly none of them in a forwarding-procedure
section. Now, lowercase prose is perfectly capable of carrying normative
meaning, but several of them have interoperability implications for which
BCP14 keywords would be appropriate. I am not going to get into individual
cases, so please audit them and replace where there is an interoperability
aspect and for things that are in scope of this document's specifications.

2) On M Weight, in Section 9.1.4. RFC 9301 Section 5.4 defers to RFC 6831 for
the details of both M Priority and M Weight i.e., it points back to this
document. M Priority is partly covered (but please see my comment on
M Priority 255 at line 999). M Weight does not seem to be covered. To me
RFC 9301's own text is the fuller description. If there is something more
that was meant to be added or I am missing it, please let me know.

Perhaps add a short paragraph to Section 9.1.4, or a new subsection, specifying
receiver ETR behaviour for M Priority and M Weight: which ITR is selected
among those with equal M Priority, how M Weight distributes tree-building
across ITRs, and what a receiver does when all weights are equal. RFC 9301
Section 5.4's own wording is a reasonable starting point, and it should be
cited for the encoding, per the discussion point on the missing normative
reference. Alternatively, if RFC 9301's text is sufficient, say so explicitly.


All further comments are inline in the idnits output:


16   This document describes the design for inter-domain multicast
17   overlays using the Locator/ID Separation Protocol (LISP) architecture
18   and protocols.  The document specifies how LISP multicast overlays
19   operate over multicast and unicast underlays.  The mechanisms in this
20   specification indicate how a signal-based approach using the PIM
21   protocol can be used to program LISP encapsulators with a replication
22   list in a locator-set, where the replication list can be a mix of
23   multicast and unicast locators.  This document when approved
24   obsoletes RFC6831

This document obsoletes RFC 6831 and elevates it from
Experimental to Proposed Standard, and nowhere states what changed. The
elevation is the point of the document, but that is not the only thing in here.

Please add a "Changes from RFC 6831" section -- a numbered section in the
body, or an appendix, and not marked for deletion.

Please also add a paragraph to the Introduction stating that this document
obsoletes RFC 6831 and advances it from Experimental to Proposed Standard,
with a forward reference to the Changes section.


139   4.  How ASM-mode (Any Source Multicast), SSM-mode (Single Source
140       Multicast), and Bidir-mode (Bidirectional Shared Trees) service
141       models will operate.

Scenario 4 here lists Bidir-mode among the service models the
specification will address. Then the document says BIDIR-PIM "is not addressed
in depth in this document". Section 7 goes into BIDIR-PIM entry, and Section 10
is entirely about ASM and PIM-BIDIR with Embedded-RP. So a reader is told that
Bidir is addressed, then that it is not addressed in depth, then given two
sections of Bidir specification. So, there is contradiction. Please pick one
position and make the document consistent with it.

The underlying question is if BIDIR-PIM support in this document complete
enough to be implemented at Proposed Standard?


175   Therefore, there are only operational (and not protocol) changes for
176   PIM-ASM [RFC7761], Multicast Source Discovery Protocol (MSDP)
177   [RFC3618], Anycast-RP [RFC4610], and PIM-SSM [RFC4607].  BIDIR-PIM
178   [RFC5015], which typically does not run in an inter-domain
179   environment, is not addressed in depth in this document.

Four protocols are cited side by side in this sentence for the same
reason -- that they need operational rather than protocol changes -- and they
are classified differently. RFC 7761 (PIM-ASM) and RFC 4607 (PIM-SSM) are
normative; RFC 3618 (MSDP) is informative; RFC 4610 (Anycast-RP) is normative.
There is no principle distinguishing them, and RFC 3618's classification is
explained by the question on the RFC 6832 reference at line 1414 rather than
by the reference test.

Please consider a single pass over each of these, their implication, any
change or impact, and then the way they are referenced.


181   The scope of this document does not cover multicast-based Traffic
182   Engineering (TE) relative to the TE-ITR (TE-based Ingress Tunnel
183   Router) and TE-ETR (TE-based Egress Tunnel Router) descriptions in
184   [RFC9300].  Similarly, specifying the detailed behavior for multicast
185   Proxy-ITRs (mPITRs) (Section 9.1.3), mtrace (Section 12), and locator
186   reachability (Section 6) is outside the scope of this document.

The Introduction declares locator reachability out of scope and points
at Section 6. Section 6, quoted at line 531 below, then specifies what has to
happen: "all ETRs that are currently joined to that ITR will have to trigger a
new Join/Prune message for (S-RLOC,G) to the new ITR as well as send a unicast
encapsulated Join/Prune message telling the new ITR which (S-EID,G) is being
joined". That is behaviour, and behaviour with a real convergence consequence
-- a tree rebuild rather than an RPF change, as the section itself explains.
The same pattern applies to the two other things this paragraph names, mPITRs
at line 968 and mtrace at line 1180, each raised separately and the latter as
a discussion point. So is the scope statement is wrong about all three of the
things it names?

Section 6 is also incomplete in a way that matters operationally: nothing says
how the ETR detects that the ITR has gone unreachable, and the anycast
mitigation paragraph ends by admitting that the ETR "really doesn't know when
the ITR has changed", so the (S-EID,G) state arrives only at the next periodic
refresh, whose period the document does not state -- see the comment on the
ITR's replication-list state at line 383.

The document is correct about the cost, and locator reachability in LISP is
genuinely RFC 9300 and RFC 9301 territory. The comment is the contradiction,
and the fact that the scope statement disclaims the three sections that most
need scoping.

Please redraft this paragraph to say what is actually out of scope, rather
than naming sections that specify things. Something like: the mechanisms by
which an xTR determines locator reachability are as specified in [RFC9300] and
[RFC9301] and are not extended by this document; Section 6 describes the
consequences for multicast distribution trees when an ITR becomes unreachable.
Then apply the same treatment to mtrace and to mPITRs, so that the paragraph
and the sections agree. While there, Section 6 would be improved by one
sentence saying that detection is by the RFC 9300 and RFC 9301 mechanisms, and
that the (S-EID,G) re-signalling is bounded by the periodic refresh interval
-- which is the operationally significant number and is currently nowhere.

181   The scope of this document does not cover multicast-based Traffic
182   Engineering (TE) relative to the TE-ITR (TE-based Ingress Tunnel
183   Router) and TE-ETR (TE-based Egress Tunnel Router) descriptions in
184   [RFC9300].  Similarly, specifying the detailed behavior for multicast
185   Proxy-ITRs (mPITRs) (Section 9.1.3), mtrace (Section 12), and locator
186   reachability (Section 6) is outside the scope of this document.

So, again contradictions: that mPITR behaviour is out of scope, that
mPITRs  require configuration at multicast ETRs, and that the whole approach
is unfinished.

Three options come to my mind. (a) Remove the mPITR text from the normative
body and either drop it or move it to an appendix labelled  as a possible
future direction, which would make the Introduction's out-of-scope statement
true; Section 9.1.3 keeps its first two paragraphs, which describe the ETR's
lookup-and-forward behaviour for a non-LISP source and are complete. Or (b)
specify it, if the WG believes it is deployed: state the configuration, the
join propagation and the tree stitching normatively, and delete the
work-in-progress sentence. Or (c) keep it and say what is undetermined, replacing
"is undergoing more study and is a work in progress" with a specific statement
of what is not yet specified -- which is a legitimate thing for a Proposed
Standard to say about an optional deployment model, provided nothing normative
depends on it. Whichever is chosen, the Introduction's scope list and Section
9.1.3 must agree.

188   Deployments have successfuly demonstrated the successful minimization
189   of multicast state in the underlay.  The cost of this optimization is
190   the extra amount of multicast packets that get sent in the same
191   underlay tunnel.

This is the important sentence for the elevation from Experimental
to Proposed Standard, and it is the sentence standing where RFC 6831's call
for further experimentation stood. Some issues with it (skipping the nits).

It is unreferenced. No deployment is named, no report cited, no measurement
given. A claim of demonstrated deployment success is exactly the kind of claim
that justifies advancing an Experimental specification, and it is being made
with nothing behind it.

Some ways to address this: Cite some informative references, and attribute the
claim to it. Or replace the claim with what can be said without deployment
evidence: that the design reduces underlay multicast state from one entry per
(S-EID,G) to one entry per (S-RLOC,G), which is a property of the design, at
the cost stated in the following sentence. Or delete the sentence. The second
sentence is fine and should be kept in any case: "The cost of this
optimization is the extra amount of multicast packets that get sent in the
same underlay tunnel" is an honest statement of the trade-off, and it is the
same trade-off Section 4 and Section 8.1.2 describe.

284   (S-RLOC,G) State:  refers to multicast state in the underlay where S
285       is a source locator (the IP address of a multicast ITR) of a site
286       with a multicast source.  The (S-RLOC,G) is mapped from the
287       (S-EID,G) entry by doing a mapping database lookup for the EID-
288       Prefix that S-EID maps to.  An S-RLOC can appear in a PIM Join/
289       Prune message when it travels from an ETR to an ITR over the
290       Internet underlay.

There is a discrepancy between this definition of S-RLOC and how it
is used at line 419 below; see my suggestion there. If a term for the
receiver-side locator is wanted, RFC 8059 already uses "receiver ETR's RLOC";
perhaps adopt that rather than coining one. Or am I missing something?


316   Unicast LISP Encapsulated PIM Join/Prune Message:  this is a standard
317       PIM Join/Prune message (LISP-encapsulated with destination UDP
318       port 4341) that is sent by ETRs at multicast receiver sites to an
319       ITR at a multicast source site.  This message is sent periodically
320       as long as there are interfaces in the OIF-list for the (S-EID,G)
321       entry for which the ETR is joining.  A multicast ETR LISP
322       encapsulates PIM Join/Prune messages so PIM signalling is achieved
323       between the ETR and ITR.

Was carrying the unicast Join/Prune on the LISP data port, UDP
4341, rather than as an RFC 9301 Encapsulated Control Message on UDP 4342,
reconsidered when moving to Proposed Standard? This is just a question, and I
am not seeking a change that would be problematic for implementations.


383   4.  When using a unicast underlay, the ETR will build one PIM Join/
384         Prune message, one that contains an (S-EID,G) entry that is
385         unicast to the ITR that matches the RLOC the ETR selects.  This
386         PIM Join/ Prune message contains enough information to help the
387         ITR build ingress-replicated unicast trees.

399   7.  When using the unicast underlay the ITR create an explicitly
400         tracked list of unicast RLOC addresses that have joined the
401         tree.  This information is used for ingress-replication.

Items 4 and 7 introduce the unicast underlay's control state --
"enough information to help the ITR build ingress-replicated unicast trees"
here, and "an explicitly tracked list of unicast RLOC addresses that have
joined the tree" at line 399 -- without specifying what the information is,
how the list is maintained. This is odd for a specification. The information
is the Transport Attribute and the Receiver ETR RLOC Attribute, specified in
draft-ietf-pim-rfc8059-9798bis and Section 7.1 points at them.

My suggestion is not to import the machinery but to disclaim it. The lifecycle
of this state -- how an entry is created from a received Join, refreshed, aged
out on the Join/Prune holdtime, or removed on a Prune -- is PIM machinery, and
it belongs in the PIM attribute document rather than in a LISP WG document.
Importing it here would duplicate PIM specification in the wrong place and
create two texts to keep in step. What is missing is not the machinery but the
sentence that disclaims it: at present Section 4 asserts that the ITR builds
"an explicitly tracked list of unicast RLOC addresses" and the document then
says nothing further, which reads as an omission rather than as a deliberate
boundary. Adding, in Section 4 or alongside the Section 8 material that the
discussion point on the unspecified unicast underlay proposes, something to
the effect of:

  The creation, refresh, timeout and removal of the receiver-ETR RLOC
  entries tracked by the ITR follow the PIM Join/Prune state rules of
  [RFC7761] as extended by the attributes in
  [I-D.ietf-pim-rfc8059-9798bis]; this document specifies no additional
  state machinery.

would turn the gap into a boundary. Informative references are sufficient for
the pointer.

What does not get disclaimed this way is the LISP-side question -- what the
ITR does with the packet once it has the list, and what the ETR accepts on
receipt. Those are the two discussion points on the unicast underlay and on
the ETR receive path; they are this document's own business and cannot be
delegated to the PIM documents.


419   10.  For the unicast underlay, the ITR makes individual copies for
420         every ETR, the outer destination is set to the S-RLOC of the ETR
421         and the outer source address is set to the S-RLOC of the ITR.

This seems to contradict the definition at line 284. How about the
following?

CURRENT

  the outer destination is set to the S-RLOC of the ETR and the outer
  source address is set to the S-RLOC of the ITR.

SUGGEST

  the outer destination is set to the RLOC of the receiver ETR and the
  outer source address is set to the S-RLOC of the ITR.

445   Alternatively, [RFC9300] also has a mechanism where (S-EID,G) state
446   can reside in the underlay through the use of RPF Vectors [RFC5496]
447   in PIM Join/Prune messages.  However, few PIM implementations support
448   RPF Vectors, and LISP should avoid S-EID state in the underlay.  See
449   Section 5 for details.

RFC 5496 (RPF Vector TLV) is a normative reference, but the only thing
the document does with it is describe an approach it recommends against. Here:
"few PIM implementations support RPF Vectors, and LISP should avoid S-EID
state in the underlay". And in Section 11, quoted at line 1166 below: "this
solution is restricted to a small set of workable cases that would not be good
for general use of LISP-Multicast. In addition, due to slow convergence
properties, it is not recommended for LISP-Multicast."

That, to me, is an informative reference.

556   IGMPv1-v3, MLDv1-v2:  These protocols [RFC3376] [RFC3810] [RFC4604]
557       do not require any changes for LISP-Multicast for two reasons.
558       One is that they are link-local and not used over site boundaries,
559       and the second is that they advertise group addresses that don't
560       need translation.  Where source addresses are supplied in IGMPv3
561       and Multicast Listener Discovery version 2 (MLDv2) messages, they
562       are semantically regarded as EIDs and don't need to be converted
563       to RLOCs until the multicast tree-building protocol, such as PIM,
564       is received by the ETR at the site boundary.  Addresses used for
565       IGMP and MLD come out of the source site's allocated addresses,
566       which are therefore from the EID namespace.

The heading here covers five protocol versions and the citations cover
two of them plus a usage document: IGMPv1, IGMPv2 and MLDv1 are not cited at
all. IGMPv1 is RFC 1112 (STD 5), IGMPv2 is RFC 2236, MLDv1 is RFC 2710, IGMPv3
is now RFC 9776 (STD 100, obsoleting RFC 3376) and MLDv2 is now RFC 9777
(STD 101, obsoleting RFC 3810).

The link-local group membership reporting genuinely needs no change for
LISP-Multicast, for the two reasons the paragraph gives, and that is as true
of all the protocols. Only the citations are wrong.

Either cite the full set -- RFC 1112 (STD 5), RFC 2236, RFC 2710, RFC 9776
(STD 100), RFC 9777 (STD 101), and RFC 4604 for SSM usage -- or narrow the
claim to the versions the document actually cites and drop the "v1-v3" and
"v1-v2" framing. The second is probably better: what the paragraph is really
about is source addresses in IGMPv3 and MLDv2 reports being EIDs, which only
arises in the source-specific versions. A heading of "IGMPv3, MLDv2" with RFC
9776, RFC 9777 and RFC 4604 cited, plus one sentence noting that earlier
versions carry no source addresses and are equally unaffected, covers the
ground with three citations instead of six.

579   MSDP:  MSDP [RFC3618] is used to announce active multicast sources to
580       other routing domains (or LISP sites).  The announcements come
581       from the PIM Rendezvous Points (RPs) from sites where there are
582       active multicast sources sending to various groups.  In the
583       context of LISP-Multicast, the source addresses advertised in MSDP
584       will semantically be from the EID namespace since they describe
585       the identity of a source multicast host.  It will be true that the
586       state stored in MSDP caches from underlay routers will be from the
587       EID namespace.  An RP address inside of the site will be from the
588       EID namespace so it can be advertised and reached by an internal
589       unicast routing mechanism.  However, for MSDP peer-RPF checking to
590       work properly across sites, the RP addresses must be converted or
591       mapped into a routable address that is advertised and maintained
592       in the BGP routing tables in the underlay.  MSDP peering addresses
593       can come out of either the EID or a routable address namespace.
594       Also, the choice can be made unilaterally because the ITR at the
595       site will determine which namespace the destination peer address
596       is out of by looking in the mapping database service.  There are
597       no MSDP changes required to support LISP-Multicast.

"However, for MSDP peer-RPF checking to work properly across sites,
the RP addresses must be converted or mapped into a routable address that is
advertised and maintained in the BGP routing tables in the underlay" is a
requirement in lowercase, placed on an unnamed actor. The paragraph then ends
"There are no MSDP changes required to support LISP-Multicast", which is true
of the MSDP protocol and false of an MSDP deployment across LISP sites, since
a mapping step has just been introduced. Nothing says who performs the
conversion, where, or how -- whether in the xTR, as for PIM Join/Prune
messages in Sections 8 and 9, or in the RP, or by configuration.

The gap matters because MSDP peer-RPF is the mechanism by which an SA message
is accepted or discarded, so getting it wrong does not degrade: it silently
drops source announcements. The final sentence of the paragraph does say that
the choice of MSDP peering address namespace "can be made unilaterally because
the ITR at the site will determine which namespace the destination peer
address is out of by looking in the mapping database service", which addresses
the peering address but not the RP address carried inside the SA.

I would suggest making the paragraph descriptive and say what is out of scope.
Replace "must be converted or mapped" with a statement that inter-domain MSDP
across LISP sites requires the RP address carried in SA messages to be reachable
in the underlay for peer-RPF to succeed, and that specifying how that is achieved
is outside the scope of this document. The concluding sentence is then true as
written, which it is not today. This is the reading the document's own
Introduction already takes, listing MSDP among the protocols needing "only
operational (and not protocol) changes", so it is a matter of making Section 7
agree with Section 1 rather than of choosing a direction.

It also settles the reference. As written, a "must" makes the paragraph look
normative, which would make RFC 3618 -- Experimental, and cited informatively
here -- a normative reference and a downref. With the paragraph descriptive,
RFC 3618 is correctly an informative reference and should stay one: it is
cited for context about how MSDP behaves, not for anything an implementer of
this document has to do. Please confirm that it is intended as informative.


787   This policy technique, also used in [RFC6836] for unicast, is useful
788   for multicast to mitigate the problems of changing distribution tree
789   state as discussed in Section 6.

RFC 6836 specifies an alternative mapping-system topology; it is not
the specification of Locator priority and weight policy. Please correct me if
I am wrong. The technique this sentence describes -- returning
different priorities in Map-Replies to different requesters so that Join/Prune
messages arrive at different ITRs -- is a property of the Map-Reply Locator
record, which is RFC 9301 Section 5.4?

The RFC 6836 citation can then be kept or dropped: if the point is that the technique
has precedent in the LISP suite, RFC 9301 makes it better than RFC 6836 does;
if the point is historical, say "as originally described for unicast in
[RFC6836]". RFC 6836 stays informative either way.

On its own this is a small thing, but it is the third instance in the document
of content being attributed to the wrong LISP RFC -- the other two are the
subject of a discussion point -- which is why it is worth raising to me.

791 9.  LISP-Multicast Interworking

793   This section describes the multicast corollary to [RFC6832] regarding
794   the interworking of multicast routing among LISP and non-LISP sites.

796 9.1.  LISP and Non-LISP Mixed Sites

Is RFC 6832 intended to be informative here, and if so, how is
Section 9 implementable without it? Section 9.1.1 builds its entire non-LISP
interworking path on LISP-NAT and Proxy-ITR machinery that exists only in
RFC 6832; and Section 9.3, at line 1136, states the design conclusion in
RFC 6832's terms. And then RFC 6832 fails it as an informative reference.

If the answer is that RFC 6832 is needed to implement Section 9, then it
should be a normative reference, and the resulting downref simply has to be
declared rather than avoided.

If the answer is that RFC 6832 is genuinely background, then Section 9 needs
to say what a reader is expected to already know, because at present it opens
by describing itself as the multicast corollary to it.

Either way, this requires some fixing.

999   Special considerations are required for LISP receiver multicast
1000   sites; since they think the source multicast site is LISP enabled,
1001   the ETR cannot know if the ITR is LISP-Multicast enabled.  To solve
1002   this problem, each mapping database entry will have a multicast
1003   2-tuple (Mpriority, Mweight) per RLOC [RFC9300].  When the Mpriority
1004   is set to 255, the site is considered not multicast capable.  So, an
1005   ETR in a LISP receiver multicast site can distinguish whether a LISP
1006   source multicast site is a LISP-Multicast site or a uLISP site.

Section 9.1.4 reads an M Priority of 255 as meaning that the site is
not multicast capable. RFC 9301 Section 5.4 defines the field per RLOC: "A
value of 255 means the RLOC MUST NOT be used for joining a multicast
distribution tree." That is a statement about one Locator record, not about
the site. Section 8.1.1 of this document explicitly allows an ITR several
RLOCs, "assigned from either the same or different service providers", and
Section 9.2 contemplates a Locator-Set mixing address families in which the
multicast priorities are set per family -- so the document already confirms
that multicast priority varies across the Locator-Set.

The correct inference from a Map-Reply is therefore that a receiver ETR
concludes the source site cannot serve it by LISP multicast when every RLOC of
the relevant address family in the Locator-Set has an M Priority of 255. The
rule as written gives the wrong answer whenever a site is partially
multicast-enabled, which is the ordinary state of a site mid-upgrade -- and
mid-upgrade is exactly the case Section 9 exists to handle.

The consequence is real but bounded: an ETR that reads the first 255-valued
RLOC as a site-level verdict falls back to non-LISP treatment of a site that
is in fact multicast-capable via another RLOC, so multicast is delivered
natively rather than encapsulated. It degrades rather than breaks, and it
degrades differently in different implementations. How about the following?

SUGGEST

  An ETR in a LISP receiver multicast site determines that a LISP source
  multicast site is not LISP-Multicast capable when every RLOC of the
  appropriate address family in the site's Locator-Set has an M Priority
  of 255; in that case the source site is treated as a uLISP site for the
  purposes of this specification.

Please cite RFC 9301 Section 5.4 for the field, per the discussion point on
the missing normative reference, and note that this determination is per
address family, which Section 9.2 already requires.


1192   The security concerns for LISP-Multicast are mainly the same as for
1193   the base LISP specification [RFC9300] and for multicast in general,
1194   including PIM-ASM [RFC7761].

1196   There may be a security concern with respect to unicast PIM messages.
1197   When multiple receiver sites are joining an (S-EID1,G) distribution
1198   tree that maps to a (RLOC1,G) underlay distribution tree, and a
1199   malicious receiver site joins an (S-EID2,G) distribution tree that
1200   also maps to the (RLOC1,G) underlay distribution tree, the legitimate
1201   sites will receive data from S-EID2 when they did not ask for it.

1203   Deployments have been succesfully able to leverage existing security
1204   mechanisms deployed for PIM [RFC7761]

The mechanism this document is a standard PIM Join/Prune sent unicast,
LISP-encapsulated, from an ETR in an arbitrary remote site to an ITR,
on UDP 4341. RFC 7761's threat model for Join/Prune is explicitly predicated
on Join/Prune not being forwardable, in its Section 6.1.1:

  Join/Prune, Hello, and Assert messages are all sent to the link-local
  ALL-PIM-ROUTERS multicast address and thus are not forwarded by a
  compliant router.  A forged message of this type can only reach a LAN
  if it was sent by a local host or if it was allowed onto the LAN by a
  compromised or non-compliant router.

The mitigations already exist and are not cited. RFC 9798 Section 5, which
this document does cite, names them: PIM authentication mechanisms per RFC
5796 to validate join requests, explicit tracking mechanisms to manage joins,
and configurable controls allowing a maximum permissible number of groups for
each ETR RLOC used as the source of overlay joins. And RFC 8059 Section 6 is
explicit that the attributes give no protection of their own: "Security of
Join/Prune attributes is only guaranteed by the security of the PIM packet."

What I would suggest is Section 13 rewritten constructively rather than
asserting a level of assurance. State the aggregation exposure as a consequence
rather than a possibility, drop "may", and cross-reference Section 8.1.2 as the
mitigation -- having first made that filter normative, so that an ETR MUST
discard a decapsulated packet with no matching (S-EID,G) state and MUST NOT
forward it -- and note explicitly what the filter does not fix, since the
underlay bandwidth is still consumed and the exposure is degraded to a
bandwidth-exhaustion vector against the receiver site rather than eliminated.
Add the unicast Join/Prune to the section as its own exposure, and say plainly
that RFC 7761's link-local analysis does not apply to it, naming the controls:
an ITR SHOULD accept unicast LISP-encapsulated Join/Prune messages only from
RLOCs it can associate with a registered LISP site; implementations SHOULD
support explicit tracking and a configurable maximum number of groups and of
receiver-ETR RLOCs per (S-EID,G); and state what happens on breach. RFC 9798
Section 5 is the source for all three and should be cited here. Cite RFC 5796
and say what it does and does not cover -- it authenticates link-local PIM,
and therefore protects the intra-site portion of the tree but not the
inter-site unicast Join/Prune. And replace the deployment-experience sentence
with a reference, or delete it; as written it is the kind of claim the comment
on the Introduction's deployment assertion at line 188 is about.

If the position is that the inter-site unicast Join/Prune is expected to
run only between mutually known LISP sites, then please say so as an
applicability statement, with the consequence stated. That is a legitimate
answer, but it needs to be in the document rather than assumed.


1322   [I-D.ietf-pim-jp-extensions-lisp]
1323               Govindan, V. P. and S. Venaas, "PIM Join/Prune Attributes
1324               for LISP Environments using Underlay Multicast", Work in
1325               Progress, Internet-Draft, draft-ietf-pim-jp-extensions-
1326               lisp-09, 21 February 2025,
1327               .

draft-ietf-pim-jp-extensions-lisp was published as RFC 9798 and
both it and RFC 8059 are now consolidated by draft-ietf-pim-rfc8059-9798bis.
So the useful pointer for a reader of this document is the bis, not the two
superseded documents it consolidates.

Please replace both [RFC8059] and [I-D.ietf-pim-jp-extensions-lisp] with a
single informative reference to [I-D.ietf-pim-rfc8059-9798bis]. Perhaps:

CURRENT

  There are specific PIM Join/Prune attributes to build multicast
  distribution trees with either a native Multicast or Unicast
  underlay.  Please refer to [RFC8059] for such attributes.

  These attributes are further enhanced in
  [I-D.ietf-pim-jp-extensions-lisp]

SUGGEST

  The PIM Join/Prune attributes used to build multicast distribution
  trees with either a multicast or a unicast underlay, including the
  attribute by which a receiver site selects between them, are
  specified in [I-D.ietf-pim-rfc8059-9798bis].

Two properties of that reference are worth stating plainly, because they bound
what it can be. It must be informative. The bis normatively references this
document.

[Ballot discuss]

# Éric Vyncke INT AD comments for draft-ietf-lisp-rfc6831bis-06
CC @evyncke

Thank you for the work put into this document. As I am far from being a multicast expert, I must write that I was unable to do a deep review of the 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).

Please note that Dave Thaler is the Internet directorate reviewer (at my request) and you may want to consider this int-dir review as well when it will be available (no need to wait for it though):
https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6831bis/reviewrequest/24904/

I hope that this review helps to improve the document,

Regards,

-éric

Note: this ballot comments follow the Markdown syntax of https://github.com/mnot/ietf-comments/tree/main, i.e., they can be processed by a tool to create github issues.

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

### Obsoleted References

As noted by the id-nitsv3 tool, the references RFC 3376 and RFC 3810 have been obsoleted. Should the reference section be updated ?

### Section 4

`they use IGMP` humm what about IPv6 MLD ? Please also use "IGMP/MLD" or a similar construct. Possibly applicable to other places in the draft. Section 7 is better to this respect.

[Ballot comment]

## COMMENTS (non-blocking)

### Abstract

s/This document describes/This document *specifies*/ as it is a PS.

### Section 1

s/This specification will address/This specification *addresses*/ ?

s/The approach proposed in this specification/The approach *of this specification* is/ ?

### Section 12

Should it be clear that mtrace does not work in this setup ?

[Ballot comment]
I am unsure what is communicated by the Shepherd Write-up saying "Implementations are already existing". What? and What was 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?

I'll continue my review later.

Request for IETF Last Call review by RTGDIR Completed: Has Nits. Reviewer: Darren Dukes. Sent review to list. Submission of review completed at an earlier date.

Request for IETF Last Call review by SECDIR Completed: Has Nits. Reviewer: Magnus Nyström. Sent review to list. Submission of review completed at an earlier date.

The following Last Call announcement was sent out (ends 2026-08-26):

From: The IESG
To: IETF-Announce
CC: draft-ietf-lisp-rfc6831bis@ietf.org, ggx@gigix.net, james.n.guichard@futurewei.com, lisp-chairs@ietf.org, lisp@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (The Locator/ID Separation Protocol (LISP) for Multicast Environments) to Proposed Standard


The IESG has received a request from the Locator/ID Separation Protocol WG
(lisp) to consider the following document: - 'The Locator/ID Separation
Protocol (LISP) for Multicast Environments'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2026-08-26. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document describes the design for inter-domain multicast
  overlays using the Locator/ID Separation Protocol (LISP) architecture
  and protocols.  The document specifies how LISP multicast overlays
  operate over multicast and unicast underlays.  The mechanisms in this
  specification indicate how a signal-based approach using the PIM
  protocol can be used to program LISP encapsulators with a replication
  list in a locator-set, where the replication list can be a mix of
  multicast and unicast locators.  This document when approved
  obsoletes RFC6831




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6831bis/



No IPR declarations have been submitted directly on this I-D.

# Document History

Document: https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6831bis/

Title: The Locator/ID Separation Protocol (LISP) for Multicast Environments

Revision: draft-ietf-lisp-rfc6831bis-06

Shepherd: Luigi Iannone (ggx@gigix.net)

Writeup Template: https://datatracker.ietf.org/doc/shepherdwriteup-template/workinggroup



1. Does the working group (WG) consensus represent the strong concurrence of a few individuals, with others being silent, or did it reach broad agreement?

    Working Group Last Call on the mailing list shows a broad support for this document.

2. Was there controversy about particular points, or were there decisions where the consensus was particularly rough?

    There were no controversy or difficult decisions.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

    No one showed any form of discontent.

4. For protocol documents, are there existing implementations of the contents of the document? Have a significant number of potential implementers indicated plans to implement? Are any existing implementations reported somewhere, either in the document itself (as RFC 7942 recommends) or elsewhere (where)?

    This document is just an update of RFC 6831, basically upgrading it from experimental to standard track. Implementations are already existing. 


# Additional Reviews

5. Do the contents of this document closely interact with technologies in other IETF working groups or external organizations, and would it therefore benefit from their review? Have those reviews occurred? If yes, describe which reviews took place.

    No further reviews needed.
   
6. Describe how the document meets any required formal expert review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

    No formal review is required.

7. If the document contains a YANG module, has the final version of the module been checked with any of the recommended validation tools for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC 8342?

    This document does not contain a YANG Module.

8. Describe reviews and automated checks performed to validate sections of the final version of the document written in a formal language, such as XML code, BNF rules, MIB definitions, CBOR's CDDL, etc.

    The document does not contain anything written in a formal language, hence, no validation and/or check has been performed.


# Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this document is needed, clearly written, complete, correctly designed, and ready to be handed off to the responsible Area Director?

    The document is clearly written, needed, and ready to be handed off to the responsible AD.

10. Several IETF Areas have assembled lists of common issues that their reviewers encounter. For which areas have such issues been identified and addressed? For which does this still need to happen in subsequent reviews?

    The document does not touch any issue listed at: https://wiki.ietf.org/group/iesg/ExpertTopics

11. What type of RFC publication is being requested on the IETF stream (Best Current Practice, Proposed Standard, Internet Standard, Informational, Experimental or Historic)? Why is this the proper type of RFC? Do all Datatracker state attributes correctly reflect this intent?

    This draft is targeting Standard Track publication. It is the proper type of  RFC, since is the evolution of RFC 6831, which is experimental and is one of items in the LISP WG charter. Both the Datatracker and front page show the intended status. 

12. Have reasonable efforts been made to remind all authors of the intellectual property rights (IPR) disclosure obligations described in BCP 79? To the best of your knowledge, have all required disclosures been filed? If not, explain why. If yes, summarize any relevant discussion, including links to publicly-available messages when applicable.

    All the co-authors, did state explicitly that they are not aware of any IPR related to this document. No one else did any IPR disclosure. 

13. Has each author, editor, and contributor shown their willingness to be listed as such? If the total number of authors and editors on the front page is greater than five, please provide a justification.

    Each co-author is clearly willing to be listed as such.

14. Document any remaining I-D nits in this document. Simply running the idnits tool is not enough; please review the "Content Guidelines" on authors.ietf.org. (Also note that the current idnits tool generates some incorrect warnings; a rewrite is underway.)

    The idnits does not show any issues, except a warning about publication date (January 2026).

15. Should any informative references be normative or vice-versa? See the IESG Statement on Normative and Informative References.

    No reference should change type.

16. List any normative references that are not freely available to anyone. Did the community have sufficient access to review any such normative references?

    There is no reference with restricted access. 

17. Are there any normative downward references (see RFC 3967 and BCP 97) that are not already listed in the DOWNREF registry? If so, list them.

    There are no DOWNREF references.
s
18. Are there normative references to documents that are not ready to be submitted to the IESG for publication or are otherwise in an unclear state? If so, what is the plan for their completion?

    No normative references are in unclear state or not ready.

19. Will publication of this document change the status of any existing RFCs? If so, does the Datatracker metadata correctly reflect this and are those RFCs listed on the title page, in the abstract, and discussed in the introduction? If not, explain why and point to the part of the document where the relationship of this document to these other RFCs is discussed.

    This document will obsolete RFC 6831 as clearly marked in the header and abstract. 

20. Describe the document shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all aspects of the document requiring IANA assignments are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that each newly created IANA registry specifies its initial contents, allocations procedures, and a reasonable name (see RFC 8126).

    The IANA considerations section does not contain any action.

21. List any new IANA registries that require Designated Expert Review for future allocations. Are the instructions to the Designated Expert clear? Please include suggestions of designated experts, if appropriate.

    There is no new registries requiring Expert Review created in this document.

# Document History

Document: https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6831bis/

Title: The Locator/ID Separation Protocol (LISP) for Multicast Environments

Revision: draft-ietf-lisp-rfc6831bis-06

Shepherd: Luigi Iannone (ggx@gigix.net)

Writeup Template: https://datatracker.ietf.org/doc/shepherdwriteup-template/workinggroup



1. Does the working group (WG) consensus represent the strong concurrence of a few individuals, with others being silent, or did it reach broad agreement?

    Working Group Last Call on the mailing list shows a broad support for this document.

2. Was there controversy about particular points, or were there decisions where the consensus was particularly rough?

    There were no controversy or difficult decisions.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

    No one showed any form of discontent.

4. For protocol documents, are there existing implementations of the contents of the document? Have a significant number of potential implementers indicated plans to implement? Are any existing implementations reported somewhere, either in the document itself (as RFC 7942 recommends) or elsewhere (where)?

    This document is just an update of RFC 6831, basically upgrading it from experimental to standard track. Implementations are already existing. 


# Additional Reviews

5. Do the contents of this document closely interact with technologies in other IETF working groups or external organizations, and would it therefore benefit from their review? Have those reviews occurred? If yes, describe which reviews took place.

    No further reviews needed.
   
6. Describe how the document meets any required formal expert review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

    No formal review is required.

7. If the document contains a YANG module, has the final version of the module been checked with any of the recommended validation tools for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC 8342?

    This document does not contain a YANG Module.

8. Describe reviews and automated checks performed to validate sections of the final version of the document written in a formal language, such as XML code, BNF rules, MIB definitions, CBOR's CDDL, etc.

    The document does not contain anything written in a formal language, hence, no validation and/or check has been performed.


# Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this document is needed, clearly written, complete, correctly designed, and ready to be handed off to the responsible Area Director?

    The document is clearly written, needed, and ready to be handed off to the responsible AD.

10. Several IETF Areas have assembled lists of common issues that their reviewers encounter. For which areas have such issues been identified and addressed? For which does this still need to happen in subsequent reviews?

    The document does not touch any issue listed at: https://wiki.ietf.org/group/iesg/ExpertTopics

11. What type of RFC publication is being requested on the IETF stream (Best Current Practice, Proposed Standard, Internet Standard, Informational, Experimental or Historic)? Why is this the proper type of RFC? Do all Datatracker state attributes correctly reflect this intent?

    This draft is targeting Standard Track publication. It is the proper type of  RFC, since is the evolution of RFC 6831, which is experimental and is one of items in the LISP WG charter. Both the Datatracker and front page show the intended status. 

12. Have reasonable efforts been made to remind all authors of the intellectual property rights (IPR) disclosure obligations described in BCP 79? To the best of your knowledge, have all required disclosures been filed? If not, explain why. If yes, summarize any relevant discussion, including links to publicly-available messages when applicable.

    All the co-authors, did state explicitly that they are not aware of any IPR related to this document. No one else did any IPR disclosure. 

13. Has each author, editor, and contributor shown their willingness to be listed as such? If the total number of authors and editors on the front page is greater than five, please provide a justification.

    Each co-author is clearly willing to be listed as such.

14. Document any remaining I-D nits in this document. Simply running the idnits tool is not enough; please review the "Content Guidelines" on authors.ietf.org. (Also note that the current idnits tool generates some incorrect warnings; a rewrite is underway.)

    The idnits does not show any issues, except a warning about publication date (January 2026).

15. Should any informative references be normative or vice-versa? See the IESG Statement on Normative and Informative References.

    No reference should change type.

16. List any normative references that are not freely available to anyone. Did the community have sufficient access to review any such normative references?

    There is no reference with restricted access. 

17. Are there any normative downward references (see RFC 3967 and BCP 97) that are not already listed in the DOWNREF registry? If so, list them.

    There are no DOWNREF references.
s
18. Are there normative references to documents that are not ready to be submitted to the IESG for publication or are otherwise in an unclear state? If so, what is the plan for their completion?

    No normative references are in unclear state or not ready.

19. Will publication of this document change the status of any existing RFCs? If so, does the Datatracker metadata correctly reflect this and are those RFCs listed on the title page, in the abstract, and discussed in the introduction? If not, explain why and point to the part of the document where the relationship of this document to these other RFCs is discussed.

    This document will obsolete RFC 6831 as clearly marked in the header and abstract. 

20. Describe the document shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all aspects of the document requiring IANA assignments are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that each newly created IANA registry specifies its initial contents, allocations procedures, and a reasonable name (see RFC 8126).

    The IANA considerations section does not contain any action.

21. List any new IANA registries that require Designated Expert Review for future allocations. Are the instructions to the Designated Expert clear? Please include suggestions of designated experts, if appropriate.

    There is no new registries requiring Expert Review created in this document.