Re: [pim] comments about draft-hb-pim-light

[[e-mail]]

Hi Hooman, 
Please see my comments with Sandy>. 

------------------原始邮件------------------
发件人：Bidgoli,Hooman(Nokia-CA/Ottawa)
收件人：张征00007940;[e-mail];[e-mail];[e-mail];[e-mail];
抄送人：[e-mail];
日 期 ：2021年11月18日 06:04
主 题 ：RE: [pim] comments about draft-hb-pim-light
Hi Sandy
Thanks for comments and keeping the conversation going...
Inline
Regards
Hooman
-----Original Message-----
From: [e-mail] <[e-mail]>
Sent: Tuesday, November 16, 2021 9:09 PM
To: Bidgoli, Hooman (Nokia - CA/Ottawa) <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Cc: [e-mail]
Subject: [pim] comments about draft-hb-pim-light
Hi Hooman and co-author,
After reading draft-hb-pim-light, IMO this is a WG work we should do. But many details need to be added for specification and clarification.
1. The affection for states on the interface needs to be specified, such as (*, G), (S, G), and so on.
HB> Ok do we want to limit ourselves to spelling out the states? A multicast state is a well known combination.
Sandy> In case we think that there is no change for these states, we still need to clarify it. 
2. The affection for BSM (RFC5059) needs to be specified.
HB> So in section of 3.1.3 of rfc 5059 it has mentioned the checks that need to be done for BSM to become operational and one point is "no hello state".
Sandy> In section of 3.1.3 of RFC5059, if there is no hello state for the source IP address of the BSM message, the BSM message is dropped silently. It means that BSM function can't work in PIM light. 

HB> so again the question is do we want to start saying one by one which multicast messages work with pim light and which don't work, or just the statement that PIM light doesn't support hello messages is sufficient enough to make the reader understand that any extension that needs the PIM hello message will not be functional. I think this is a better way forward, and we should only list the exceptions to the rule in the draft, that should work without PIM Hello messages.
Sandy> If we don't clariry all the affection to the existed PIM-SM protocol, the implementor may may guess what will be changed with the exist implementation,  which may lead to some interoperable error. It good that if we can list the exceptions to make the statement more clear.
3. Though I know this draft is used for PIM-SM, not PIM-DM, the clarification is still needed since the title of this draft is PIM light, not PIM-SM light.
HB> it is really PIM SM and SSM. Sure I can put this in.
4. If this function can still be used in case of some of the ingress/egress nodes don't support it.
HB> not sure if I understand this point? If ingress/egress nodes don't support what?
Sandy> I mean that in case some of the edge routers can't support PIM light, some of them support PIM light, if PIM light can still be used?
5. White list or other something is needed for the source verification, only the j/p packet comes from the BGP neighbors (For MVPN, GTM, etc.), or the static configured neighbors, can be accepted.
HB> Not sure if I understand this point, if there is a static join then that usually gets pushed into the pim as a multicast state (i.e. static entries usually get translated to a pim join/prune upstream. So not sure if there is anything here special that we need to spell out?
Sandy> If a router receives the PIM j/p message directly, how does the router know if it should accept the message and parse it or not? The neighbor relationship is built by hello message, but now there is no hello message any more. Do you mean that all the neighbors need to be configured statically? If dynamic neighbor can be supported?
6. Since there is no hello packet any more, the DR election is not necessary, so if there is no DR at all?
HB> yes all the DR selections need to be done in the PIM domain not in the PIM light domain. The PIM light domain is only for propagating multicast states and needs to be design as such.
7. PIM overlay permits different IBBR to select different EBBR, does PIM light permit it? If PIM light permit it, if assert message is unnecessary? What's the use case of keeping assert message in PIM light?
HB> so the idea was if 2 bier routers are connected to the same PIM domain (for redundancy) and they would get the multicast join from the same host it might be beneficial to use the Assert to avoid the upstream IBBR to send traffic to both EBBRs. I personally think this is useful, and RFC 7761 as explicitly said that Assert should not be process without a Hello, hence why the inclusion.
Sandy> Assert message is sent when a router receives a multicast  data packet on an interface on which the router would normally have forwarded that packet. But in BIER depolyment, even if the IBBR sends join messages to both of the EBBRs, the EBBRs will not receive the data message from each other, because the message with BIER encapsulation is sent to the IBBR directly. So I am still confused with this situation. And yes there is an exception in RFC7761 for assert message process w/o hello when it is used in point-to-point interface.
Best regards,
Sandy
>From my personal perspective, "PIM-SM light interface" is better for titling.
HB> ok if the WG feels the same I am ok with it.
BTW, if the reference for draft-hfa-bier-pim-signaling should be draft-ietf-bier-pim-signaling? And seems like there should be no IANA registry.
HB> thanks! will correct.
Thanks,
Sandy