Hi Vengada Prasad, Thanks for your responses and the document updates. I've updated my ballot to reflect the outstanding points that remain to be addressed.
Thanks, Ketan On Tue, Sep 15, 2026 at 9:23 PM Vengada Prasad Govindan <venggovi= [email protected]> wrote: > Hello Ketan, > Thank you sincerely for your extensive review. Please see inline with > GVP1> Most comments have been addressed. I have submitted ver-08 in the > datatracker, and will address remaining comments in the next revision. > > - Prasad > -----Original Message----- > From: Ketan Talaulikar via Datatracker <[email protected]> > Sent: Thursday, September 10, 2026 11:07 PM > To: The IESG <[email protected]> > Cc: [email protected]; [email protected]; > [email protected]; [email protected] > Subject: Ketan Talaulikar's Discuss on draft-ietf-lisp-rfc6831bis-06: > (with DISCUSS and COMMENT) > > Ketan Talaulikar has entered the following ballot position for > draft-ietf-lisp-rfc6831bis-06: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6831bis/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > 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. > GVP1> Thank you, this work has been deployed in multiple installations. > > 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 > <EoRv06> > 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. > GVP1> MTRACE is now made out of scope of this document. BIDIR is another > example of loosely specified. Made it out of scope as well. > > 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. > GVP1> I believe you are talking about the normative reference to RFC9301. > Added this, please see responses further down in this email. > > <discuss-1> Gaps in the specification of the unicast underlay model > GVP1> Thank you for clearly articulating the inconsistency in specifying > unicast and multicast underlays. I have rewritten the entire section by > organizing the forwarding plane specification into three parts: Common to > multicast and unicast underlay, Multicast underlay specific, Unicast > underlay specific. This is because the two underlays do share the common > stuff and I did not want to duplicate any text. > 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. > > GVP1> This has been specifically broken down into the three parts: Common, > multicast. New text for unicast has now been added. > > 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. > GVP1> Same as above > > 681 There is no Data-Probe logic for ETRs as there can be in the > unicast > 682 forwarding case. > GVP1> This is common, hence retained > > 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. > GVP1> Fixed this, the ITR has the three separate sub-sections now. > > 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. > GVP1> Same as above > > 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. > GVP1> Since this is multicast underlay specific; this is now moved to the > 3rd level. Hence addressed. > > 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. > GVP1> Fixed, the dataplane has now three parts, this should address this > comment > > 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. > > > GVP1> Same as above > > 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. > GVP1> Agreed, No PIM machinery is invoked > > <discuss-2> 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? > GVP1> Agreed, this is now moved to the multicast sub-heading. The unicast > is treated as per your suggestion below > > 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. > GVP1> Done, the unicast section now reflects the RPF rules specific to > unicast underlay > > <discuss-3> 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]. > GVP1> The above text is removed > > 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]. > GVP1> I have made the Mtrace section as future work. This should take care > of the full comment above. Please let me know if I am still missing > something > > 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. > GVP1> Same as above > > <discuss-4> 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. > GVP1> Done, added references to RFC9301. > > ---------------------------------------------------------------------- > 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. > GVP1> I want to defer addressing this comment for now and revisit as one > of the last comments. > > 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. > GVP1> Addressed. RFC9301 is referenced. > > > 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. > GVP1> At this point RFC9301 text should suffice. RFC6831 is only an > informative reference, so I think the current back pointer from the > 6831-bis draft to RFC9301 is required. Added the following text The > definition and usage of the 2-tuple MUST be done in accordance to the > procedure defined in Sec 5.4 of <xref target="RFC9301"/> > > 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 > > <major-editorial> 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. > GVP1> Added. > > 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. > GVP1> Done > > 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. > > <major> 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? > > GVP1> BIDIR can be excluded from the Proposed Standard and made a > separate document. I have called it out explicitly and removed the BIDIR > specification. Only informative reference remains. > > 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. > > <minor> 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. > GVP1> These protocols are required to be referenced. TODO: > > 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. > > <major> 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. > > <major> 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. > GVP1> Removed references to mPITR except to say that it is out of scope > > 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. > > <major> 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. > GVP1> Added reference to draft-ietf-lisp-multicast-deploy that details the > deployment experience > > Some ways to address this: Cite some informative references, and attribute > the > claim to it. > GVP1> Yes, done as above. > > 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. > > <minor> 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? > GVP1> Used receiver ETR's RLOC for line 419. > > 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. > > <question> 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. > > <major> 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. > GVP1> Done, added the text verbatim as per the suggestion. > > 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. > > <minor> 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. > GVP1> Agreed > > 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. > > <minor> 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. > GVP1> Agreed, Made RFC5496 as informative > > 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. > > <minor> 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). > GVP1> Yes RFC8776 and RFC9777 are now cited instead of the old RFCs. > > 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. > GVP1> Agreed. Used 3 citations with only IGMPv3/ MLDv2 > > 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. > > <minor> "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. > > <minor> 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 > > <question> 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. > > <major> 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] > > <major> 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 < > https://datatracker.ietf.org/doc/html/draft-ietf-pim-jp- > 1328 extensions-lisp-09>. > > <minor> 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]. > GVP1> Fixed. > > 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. > GVP1> Fixed. > <EoRv06> > > > > _______________________________________________ > iesg mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ lisp mailing list -- [email protected] To unsubscribe send an email to [email protected]
