Hi Dino, answering a couple of your questions inline...
> On 11 Feb 2025, at 22:07, Dino Farinacci <farina...@gmail.com> wrote: > > Here are my responses (Mike and Stig) have not seen them yet. > >>> >>> 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. > > We will change. > >>> >>> 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. > > Your comment isn't clear. Can you be more specific. The paragraph: >>> >>> 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. States that Section 12 in RFC9300 provides additional issues and concerns raised by this document. But, Section 12 in RFC9300 is not about multicast neither about security. The reference points to the wrong section. > >> >> [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. > > Then I don't understand your comment. Be more clear. The paragraph: >>> 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. Does not add anything to the definition. Can be dropped IMO. > >> >>> 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] > > We can't do that, because much of the forwarding procedure for multicast > packets follow rules from 9300, and the control-plane as well. The only > different is what EID is used for the lookup and registration. Hence you do not need to repeat the text that is in 9300 and 9301 in this document. Keep only the multicast speciic parts. Thanks Ciao L. > >>> >>> >>> 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. > > We will change to from "uPITR" to PITR". And where we refer to multicast > PITRs or PETRs we will use "mPITR" and "mPETR". > >> >> [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. > > We will change to add word "unicast". > > Thanks, > Dino/Mike/Stig > > _______________________________________________ lisp mailing list -- lisp@ietf.org To unsubscribe send an email to lisp-le...@ietf.org
