Suggest text for the paragraphs you think need improvement. Dino
> On Feb 12, 2025, at 2:46 AM, Luigi Iannone <g...@gigix.net> wrote: > > 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