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

["Bidgoli, Hooman (Nokia - CA/Ottawa)" <[e-mail]>]

Inline HB2>

I like to get the WG and co-authors opinion on point 1 and 2 as well. If every body feels that we need to list every single state and feature that PIM light won't support then we can start adding these. Again as of now the idea is to say pim light doesn't support hello messages over the interface and any function that needs hello message will not function with pim light, with the exception of join/prune/assert.

Regards
Hooman

-----Original Message-----
From: [e-mail] <[e-mail]> 
Sent: Wednesday, November 17, 2021 10:06 PM
To: Bidgoli, Hooman (Nokia - CA/Ottawa) <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Re:[pim] comments about draft-hb-pim-light

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?

HB2> The draft is clear that PIM light only to be used when an interface or network segment is not suitable for PIM. In short there is no mix and match either PIM works or if it doesn't then PIM light can 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?

HB2> Yes, this has been said explicitly in the draft, for security reasons pim-light should be configured on a interface to accept j/p.
HB2> but in some cases PIM light is auto configured like in the case of BIER where there is no real interface.



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.

HB2> here is an example the host is connected to 2 EBBR in a PIM network, both EBBRs forward the <S1,G1> to IBBR1 and IBBR2. So I am thinking of a BIER network like a LAN. So in this case since the IBBR and EBBR have PIM domain on them they could detect duplicate traffic and use assert message.

Source --PIM-domain- IBBR1---BIER-Domain----EBBR-----PIM-domain---host
                       |-----------IBBR2----BIER-Domain----EBBR----PIM-domain-----|

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