Hi, thanks for the new revision of the document, which solves the majority of my comments.
My residual comments are inline marked as “LI>” ( I trimmed the parts on which I have no further comments). The document lacks an IANA section. Even without requests to IANA the section should be there, see: https://authors.ietf.org/en/required-content Ciao L. > On 30 Jan 2025, at 08:26, Michael McBride <michael.mcbr...@futurewei.com> > wrote: > [snip] > > > Also, the current version of this specification does not describe > multicast-based Traffic Engineering (TE) relative to the TE-ITR > (TE-based Ingress Tunnel Router) and TE-ETR (TE-based Egress Tunnel > Router) descriptions in [RFC9300]. Further work is also needed to > determine the detailed behavior for multicast Proxy-ITRs (mPITRs) > (Section 9.1.3), mtrace (Section 12), and locator reachability > (Section 6). Finally, further deployment and experimentation would > be useful to understand the real-life performance of the LISP- > Multicast solution. For instance, the design optimizes for minimal > state and control traffic in the core, but can in some cases cause > extra multicast traffic to be sent Section 8.1.2. > > This is a prposed standard document…. is the above been done? Is there > deplyment experience that allow to make an assesment on the above points? > > There is deployment experience and will be presented by cisco in a separate > document (per Prasad/Luigi). > > MM: No changes. LI> Good that you have deployment experience on the above points, but the paragraph still needs to be revised because it states that there is “further work” and "further deployment and experimentation” to be done. IMO, if the result of experimentation will be in Prasad’s document then here you can drop the whole text. > > > Issues and concerns about the deployment of LISP for Internet traffic > are discussed in [RFC9300]. Section 12 of that document provides > additional issues and concerns raised by this document. > > Section 12 in 9300 is about RLOC hashing… May be drop the paragrapgh above > altogether? > > RFC 9300 hash description is for unicast packets. We need a specification for > multicast packets which this document owns. > > MM: No changes. LI> I think my point wasn’t clear. Section 12 in RFC9300 is about RLOC hashing not about "issues and concerns raised by this document” You have to fix the reference. [snip] > 3. Definition of Terms > > The terminology in this section is consistent with the definitions in > [RFC9300] but is extended specifically to deal with the application > of the terminology to multicast routing. > > LISP-Multicast: a reference to the design in this specification. > That is, when any site that is participating in multicast > communication has been upgraded to be a LISP site, the operation > of control-plane and data-plane protocols is considered part of > the LISP-Multicast architecture. > > Could be simplified to “A LISP site that supports the specifications in this > document”? > > No, we can't. A LISP site is a site that has xTRs that support both 9300 and > this document. And hence why we defined "uLISP" to describe a LISP site with > only unicast xTRs. > > MM: No changes. LI> MY comment was not about uLISP, was about the LISP-Multicast definition. The “That is, ….” part can be dropped it does not add anything. > > > > Egress Tunnel Router (ETR): a router that is on the path from a > multicast source host in another site to a multicast receiver in > its own site. An ETR accepts a PIM Join/Prune message from a > site-internal PIM router destined for the source's EID in the > multicast source site. The ETR maps the source EID in the Join/ > Prune message to an RLOC address based on the EID-to-RLOC mapping. > This sets up the ETR to accept multicast encapsulated packets from > the ITR in the source multicast site. A multicast ETR > decapsulates multicast encapsulated packets and replicates them on > interfaces leading to internal receivers. > > xTR: is a reference to an ITR or ETR when direction of data flow is > not part of the context description. xTR refers to the router > that is the tunnel endpoint; it is used synonymously with the term > "tunnel router". For example, "an xTR can be located at the > Customer Edge (CE) router" means that both ITR and ETR > functionality can be at the CE router. > > In the above definitions there are parts that are not needed because they > come from 9300. Can shrink the text only to multicast extensions and start > each definition with a reference to the original definition. > > I would like to keep the text so it is complete in addition to adding > specificity to multicast xTRs. > > MM: No changes. LI> I was suggesting to keep the specificity of multicast part but drop the rest 9300 and 9301 are the reference. [snip] > > > mPETR: this is a multicast proxy-ETR that is responsible for > advertising a very coarse EID-Prefix to which non-LISP and uLISP > sites can target their (S-EID,G) PIM Join/Prune messages. mPETRs > are used so LISP source multicast sites can send multicast packets > using source addresses from the EID namespace. mPETRs act as > Proxy-ETRs for supporting multicast routing in a LISP > infrastructure. It is likely a uPITR [RFC6832] and an mPETR will > > “uPITR” are not defined in 6832. Just state unicast PITR…. > > We use it to be specific to referenec a PxTR that only does unicast > encapsulation and a MxPTR that does multicast replication. Keep text. It is > really important. > > MM: No changes. LI> It is fine to use uPITR terminology; but must be defined here. The text above is misleading as the term “uPITR” does not exist in 6832. [snip] > This message is sent periodically as > long as there are interfaces in the OIF-list for the (S-EID,G) > entry for which the ETR is joining. > > May be the correct term to use is “Unicast LISP encapsulated PIM…." > > Well PIM join messages go to one place. So it is implied its unicast > encapsulated. LI> Yes it is implied but make it explicit would be better. [snip] > > At this point in time, there is no requirement for different Locator- > Sets, priority, and weight policies for multicast than there is for > unicast. However, when Traffic Engineering policies are different > for unicast versus multicast flows, it will be desirable to use > multicast-based priority and weight values in Map-Reply messages. > > This is not clear to me. Multicast priority and weights MUST be used for > multicast flows. The lack of them means no multicast support….. > > The point is that if you want non-congruent topologies, you'd set the > priorities differently. LI> Please state so. [snip] > 2. The ETR does a mapping database lookup for S-EID. If the > mapping is cached from a previous lookup (from either a previous > Join/Prune for the source multicast site or a unicast packet > that went to the site), it will use the RLOC information from > the mapping. The ETR will use the same priority and weighting > mechanism as for unicast. So, the source site can decide which > way multicast packets egress. > > Last two sentences are unclear. Do you mean that the source site will choose > the egress according to multicast priority and weight? > > Yes, just like in the unicast case. > LI> PLease state it explicitly. [snip] > > > > 11. For the multicast underlay, the ITR copies the group address to > the outer destination address field, the ITR inserts its own > locator address in the outer source address field. The ITR will > look at its (S-RLOC,G) state, where S-RLOC is its own locator > address, and replicate the packet on each interface on which an > (S-RLOC,G) join was received. The core has (S-RLOC,G) so where > fan-out occurs to multiple sites, a core router will do packet > replication. > > 12. When either the source site or the core replicates the packet, > the ETR will receive a LISP packet with a destination group > address. It will decapsulate packets because it has receivers > for the group. Otherwise, it would not have received the > packets because it would not have joined. > This last sentence is not always true. Just delete it. It is anyway detailed > later on. > > It is true and we suggest using PIM-SSM or PIM-ASM (not dense-mode). And we > don't want to bring up the multi-access layer-2 case. Keep the sentence. LI> In section 13 you state that there are cases where an ETR receives traffic that it did not ask for, hence it is not always true. [snip] > The following scenarios exist to make LISP-Multicast sites interwork > with non-LISP-Multicast sites: > > 1. A LISP site must be able to send multicast packets to receiver > sites that are a mix of non-LISP sites and uLISP sites. > > 2. A non-LISP site must be able to send multicast packets to > receiver sites that are a mix of non-LISP sites and uLISP sites. > > 3. A non-LISP site must be able to send multicast packets to > receiver sites that are a mix of LISP sites, uLISP sites, and > non-LISP sites. > > Doesn’t point 3 include point 2? > > No, the last case adds LISP sites, which have xTRs deployed that do both > unicast and multicast LISP. LI> But technically they are the same as described in 9.1.3, so you can use only point 3 that covers all cases. > > MM: No changes. > > 4. A uLISP site must be able to send multicast packets to receiver > sites that are a mix of LISP sites, uLISP sites, and non-LISP > sites. > > > > > > Farinacci, et al. Expires 27 February 2025 [Page 18] > > Internet-Draft LISP for Multicast Environments August 2024 > > > 5. A LISP site must be able to send multicast packets to receiver > sites which are a mix of LISP sites, uLISP sites, and non-LISP > sites. > > Doesn’t point 5 include point 1? > > No, because 3, 4, and 5 are describing the type of site a source site is. > LI> I was referring only to 5 and 1. They are technically the same as described in section 9.1.4. Enumerating all possible combination is not usefull if technically they are solved in the same way. [snip] > 9.1.2. Non-LISP Source Site to Non-LISP Receiver Sites > > Change title to "Non-LISP Source Site to uLISP Receiver Sites” and drop the > first paragraph. > > Then you change the meaning. A non-LISP source site is a multicast site that > is running in the underlay. It is different than a uLISP site. > LI> But in the text below you talk about uLISP sites…. please clarify the scenario. > MM: No changes > > > > Clearly non-LISP-Multicast sites can send multicast packets to non- > LISP receiver multicast sites. That is what they do today. However, > discussion is required to show how non-LISP-Multicast sites send > multicast packets to uLISP receiver multicast sites. > > Since uLISP receiver multicast sites are not targets of any (S,G) > state, they simply send (S,G) PIM Join/Prune messages toward the non- > LISP source multicast site. Since the source multicast site in this > case has not been upgraded to LISP, all multicast source host > addresses are routable. So, this case is simplified to where a uLISP > receiver multicast site appears to the source multicast site to be a > non-LISP receiver multicast site. > [snip] > 3. LISP-Multicast Dual-Stack Site > > 4. uLISP IPv4 Site > > 5. uLISP IPv6 Site > > 6. uLISP Dual-Stack Site > > 7. non-LISP IPv4 Site > > 8. non-LISP IPv6 Site > > 9. non-LISP Dual-Stack Site > > Let's define (m n) = m!/(n!*(m-n)!), pronounced "m choose n" to > illustrate some combinatorial math below. > > When 1 site talks to another site, the combinatorial is (9 2), when 1 > site talks to another 2 sites, the combinatorial is (9 3). If we sum > this up to (9 9), then: > > > (9 2) + (9 3) + (9 4) + (9 5) + (9 6) + (9 7) + (9 8) + (9 9) = > > 36 + 84 + 126 + 126 + 84 + 36 + 9 + 1 > > > which results in 502 as the total number of cases to be considered. > > > The calculation is no accurate because includes combinations that are not > possible, for instance > uLISP IPv4 cannot communicate with uLISP IPv6, hence (9 2) cannot be 36. > > It is accurate. LI> Please provide proof. > > MM: No changes > > > I would drop the calculation and just state that the number of case when > combining the 9 site profiles and mixing EID and RLOC of different address > family may lead to complex situations. > > We will not drop the calculations. It demonstrates how complex all these > combinations are. And a lot of work was put in to create them!!! LI> In this case prove that the calculations are correct. > > MM: No changes. > > > * All LISP sites on a multicast distribution tree must share a > common address family that is determined by the source site's > Locator-Set in its LISP database mapping entry. All receiver > multicast sites will use the best RLOC priority controlled by the > source multicast site. This is true when the source site is > either LISP-Multicast or uLISP enabled. This means that priority- > based policy modification is prohibited. > > What kind of modifications are you referring to? > Instead of prohibited you may use “MUST NOT be used" > > It means if an ITR uses an RLOC because the priority says so but it doesn't > have underlay connectivity in that address-family, it should not use the > RLOC. So address-family is searched first and then priority within that > subset. LI> THanks for the clarification. You still need to fix RFC2119 terminology. > > MM: No changes. > > > When a receiver > multicast site ETR receives an (S-EID,G) join, it must select a > S-RLOC for the same address family as S-EID. > > * When a multicast Locator-Set has more than one locator, only > locators from the same address family MUST be set to the same best > priority value. A mixed Locator-Set can exist (for unicast use), > but the multicast priorities MUST be the set for the same address > family locators. > > Are you basically stating that mixed locator set are not allowed for > multicast ? > If mixed locator set exist only one address family can be used for multicast > and the choice is out of the scope of this document. > > What I said in the last comment response. LI> Add you clarification to the text. It is helpful. [snip] > > MM: No changes. > > > > * When the source site is not LISP enabled, determining the address > family for the flow is up to how receivers find the source and > group information for a multicast flow. > > 9.3. Making a Multicast Interworking Decision > > Thus far, Section 9 has shown all combinations of multicast > connectivity that could occur. As already concluded, this can be > quite complicated, and, if the design is too ambitious, the dynamics > of the protocol could cause a lot of instability. > > The trade-off decisions are hard to make, and so the same single > solution is desirable to work for both IPv4 and IPv6 multicast. It > is imperative to have an incrementally deployable solution for all of > IPv4 unicast and multicast and IPv6 unicast and multicast while > minimizing (or eliminating) both unicast and multicast EID namespace > state. > > Therefore, the design decision to go with uPITRs [RFC6832] for > unicast routing and mPETRs for multicast routing seems to be the > sweet spot in the solution space in order to optimize state > requirements and avoid head-end data replication at ITRs. > > Has this been confirmed by deployments? Can you change the parapgraph to be > more assertive? > > Yield to Prasad/Stig. LI> The text is still hypothetical. I am not asking details, just replace “seems” with “is”. [snip] > > > There may be a security concern with respect to unicast PIM messages. > When multiple receiver sites are joining an (S-EID1,G) distribution > tree that maps to a (RLOC1,G) core distribution tree, and a malicious > receiver site joins an (S-EID2,G) distribution tree that also maps to > the (RLOC1,G) core distribution tree, the legitimate sites will > receive data from S-EID2 when they did not ask for it. > > Other than as noted above, there are currently no known security > differences between multicast with LISP and multicast without LISP. > However, this has not been a topic that has been investigated deeply > so far; therefore, additional issues might arise in future. > > Has deployment experience shown any additional risk? if not drop the last > sentence. > > Prasad/Stig to answer. LI> You are basically stating that you are unsure about security aspects of these specifications. Not sure this will pass SECDIR review.
_______________________________________________ lisp mailing list -- lisp@ietf.org To unsubscribe send an email to lisp-le...@ietf.org
