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. 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. 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. <discuss-1> 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. <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? 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. <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]. 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. <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. ---------------------------------------------------------------------- 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 <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. 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. <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? 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. 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. 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. 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. <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? 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. 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. 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. 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). 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. <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]. 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. <EoRv06> _______________________________________________ lisp mailing list -- [email protected] To unsubscribe send an email to [email protected]
