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

Reply via email to