Subject: Re: [pim] mankamana-pim-bdr adoption call. Was: RE: Sticky PIM DR, should it be added to PIM DR improvements or different draft

From: <[email-masked]>
Date: Tue, 29 Jun 2021 23:32:39 +0800 (CST)

Dear All,
I've read the draft and support its adoption by the PIM WG.
I have several non-blocking comments and a question:
- it seems that some additional references to RFC 7761 can be placed in the Abstract and Introduction section.
- the introduction of a BDR PIM-SM router improves the convergence and reduces the impact of the DR failure on the multicast service. However, the detection, except for the DR transmitting PIM Hello with Holdtime = 0 before going down, is in tens of seconds. Hence, it might be helpful to reference draft-ietf-pim-bfd-p2mp-use-case and describe the interworking aspects, if any.
- Section 4.4.1 (and 4.4.2 through the reference to 4.4.1) propose that a new PIM-SM router initially advertises its priority as 0. Hence my question, would it be beneficial if that new router switches to the configured value if the failure of DR or BDR is detected?

Regards,
Greg Mirsky
Sr. Standardization Expert
预研标准部/有线研究院/有线产品经营部  Standard Preresearch Dept./Wireline Product R&D Institute/Wireline Product Operation Division
E: [email-masked]
www.zte.com.cn
------------------Original Mail------------------
From: Michael McBride <[email-masked]>
Date: Mon, Jun 28, 2021 at 3:12 PM
Subject: Re: [pim] mankamana-pim-bdr adoption call. Was: RE: Sticky PIM DR, should it be added to PIM DR improvements or different draft
To: [email-masked] <[email-masked]>

Hello again,
It's been a week with no response to this adoption call. We will give it another week and if still no response we won't adopt at this time.
thanks,
mike
-----Original Message-----
From: pim <[email-masked]> On Behalf Of Michael McBride
Sent: Monday, June 21, 2021 6:11 PM
To: [email-masked]
Subject: [pim] mankamana-pim-bdr adoption call. Was: RE: Sticky PIM DR, should it be added to PIM DR improvements or different draft
Hello all,
We are picking back up on this thread and using it as a call for adoption. During IETF 110 we had 9 in favor and 2 against adoption. Please read the draft: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-mankamana-pim-bdr%2F&amp;data=04%7C01%7Cmmcbride%40futurewei.com%7C067e47a1b80941d12e0408d9351aa874%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637599210899942214%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=%2BdhjjMXC5bHiaYai9if7HSE0N%2BRlwdEFubLfz%2FlKODo%3D&amp;reserved=0 and indicate if you support adoption.
If you don't support adoption please indicate whether you would support merging with draft-ietf-pim-dr-improvement or have other suggestions. The minutes are included below to show the options with progressing this draft.
thanks,
mike
draft-mankamana-pim-bdr - Mankamana
Lenny - this concept of priority and preemption is not unique to pim: vrrp, rsvp with backup paths, etc. can we leverage from those? Was it protocol level stuff or vendor implementations, those could be good examples. leave it up to implementations?
Alvaro - what has me confused is talking about two solutions that are basically the same thing. A good argument has been made on how the previous draft isn't needed. It would be nice if all the solutions was considered in one draft. We seem to be circuling around implementations, first resolve if we want single or multiple solutions. And then understand how they interact.
Stig - I agree. We initially only had one sticky DR in other draft, now we have two proposals. Do we actually need two solutions? Are there different use cases where one is better then the other?
Alvaro - I'm not advocating for one or two, the wg to decide. maybe we define multiple use cases. Needs more coordination.
Stig - if the wg decides we only need one solution that covers all the use cases we probably only want to publish one of them.
Mike - some may want to have a hello option and others may not. And right now we only have one wg document. Let's say we do adopt this draft, should we hold off on progressing both documents until they are both progressed together?
Alvaro - That would be nice. they are not dependent on each other. they don't have to progress together. progressing close would be nice.
Stig - we shouldn't progress any document until we carefully decide what solution is best or if we want both solutions. Lets compare both options.
Mike - let's poll for adoption.
Stig - just because we adopt both documents doesn't mean we publish both documents.
Poll - 9 in favor and 2 against. Will take to the list.
-----Original Message-----
From: pim <[email-masked]> On Behalf Of Mankamana Mishra (mankamis)
Sent: Wednesday, January 06, 2021 11:29 AM
To: Alvaro Retana <[email-masked]>; zhang.zheng <[email-masked]>; Stig Venaas <[email-masked]>
Cc: Sridhar Santhanam (sridsant) <[email-masked]>; [email-masked]
Subject: Re: [pim] Sticky PIM DR, should it be added to PIM DR improvements or different draft
Thanks every one for input. So I would update Sticky PIM DR without capability option in draft-mankamana-pim-bdr. Will ask for adoption in coming IETF.
Mankamana
On 12/4/20, 9:04 AM, "Alvaro Retana" <[email-masked]> wrote:
On December 4, 2020 at 11:03:22 AM, Stig Venaas wrote:
Stig:
Hi!
> Thoughts? Do you see this differently?
I'm ok with whatever the WG decides, as long as the relationship and
interaction between multiple potential solutions is clear.
This is what I wrote in my review of draft-ietf-pim-dr-improvement-09:
===
(2) As far as I can see draft-mankamana-pim-bdr has not been adopted yet.
Assuming that is the plan, how would the two mechanisms interact?  Given
that draft-mankamana-pim-bdr doesn't add options, and §5 says that if no
options are received then the routers MUST use rfc7761, how does a router
implementing this specification tell the difference?
I realize that some of these questions may be better directed at
draft-mankamana-pim-bdr, but because the WG agreed that a statement
relating the two should be included in this document [1], then I'm
asking now.  I would really like to understand what the WG expects.
===
The WG is already aware of both drafts.  Assuming
draft-mankamana-pim-bdr is adopted, I would prefer it if both
solutions are progressed together (one or two documents is ok with
me).
Thanks!
Alvaro.
_______________________________________________
pim mailing list
[email-masked]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fpim&amp;data=04%7C01%7Cmmcbride%40futurewei.com%7C067e47a1b80941d12e0408d9351aa874%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637599210899942214%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=XRbjNZlVlm3isR%2F7NYbb7kOrAvy8Cv8%2BkpG7sDrE38I%3D&amp;reserved=0
_______________________________________________
pim mailing list
[email-masked]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fpim&amp;data=04%7C01%7Cmmcbride%40futurewei.com%7C067e47a1b80941d12e0408d9351aa874%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637599210899942214%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=XRbjNZlVlm3isR%2F7NYbb7kOrAvy8Cv8%2BkpG7sDrE38I%3D&amp;reserved=0
_______________________________________________
pim mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pim

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 29 Jun 2021 17:55:01 -0400

Hi Greg

Many thanks for your comments.

Thank you

Gyan

> the Abstract and Introduction section.

   Gyan> Ack.  We will add.

>
> - the introduction of a BDR PIM-SM router improves the convergence and
> reduces the impact of the DR failure on the multicast service. However, the
> detection, except for the DR transmitting PIM Hello with Holdtime = 0
> before going down, is in tens of seconds. Hence, it might be helpful to
> reference draft-ietf-pim-bfd-p2mp-use-case and describe the interworking
> aspects, if any.

   Gyan> The goal is trying to make it make before break to not disrupt the
multicast traffic so giving it 2 hello delay period before traffic switches
over to the alternate path.  We can still mention pim p2mp draft for
 faster convergence so the MBB happens quicker.

>
> - Section 4.4.1 (and 4.4.2 through the reference to 4.4.1) propose that a
> new PIM-SM router initially advertises its priority as 0. Hence my
> question, would it be beneficial if that new router switches to the
> configured value if the failure of DR or BDR is detected?

    Gyan> I agree for failure.  The priority 0 is for delay of preemptive
switchover to wait for MBB tree is built before switching traffic over.

Many Thanks,

> 预研标准部/有线研究院/有线产品经营部  Standard Preresearch Dept./Wireline Product R&D
> Institute/Wireline Product Operation Division
> Subject: Re: [pim] mankamana-pim-bdr adoption call. Was: RE: Sticky PIM
> DR, should it be added to PIM DR improvements or different draft
> It's been a week with no response to this adoption call. We will give it
> another week and if still no response we won't adopt at this time.
> thanks,
> mike
> Subject: [pim] mankamana-pim-bdr adoption call. Was: RE: Sticky PIM DR,
> should it be added to PIM DR improvements or different draft
> Hello all,
> We are picking back up on this thread and using it as a call for adoption.
> During IETF 110 we had 9 in favor and 2 against adoption. Please read the
> draft:
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-mankamana-pim-bdr%2F&amp;data=04%7C01%7Cmmcbride%40futurewei.com%7C067e47a1b80941d12e0408d9351aa874%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637599210899942214%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=%2BdhjjMXC5bHiaYai9if7HSE0N%2BRlwdEFubLfz%2FlKODo%3D&amp;reserved=0
> and indicate if you support adoption.
> If you don't support adoption please indicate whether you would support
> merging with draft-ietf-pim-dr-improvement or have other suggestions. The
> minutes are included below to show the options with progressing this draft.
> thanks,
> mike
> Lenny - this concept of priority and preemption is not unique to pim:
> vrrp, rsvp with backup paths, etc. can we leverage from those? Was it
> protocol level stuff or vendor implementations, those could be good
> examples. leave it up to implementations?
> Alvaro - what has me confused is talking about two solutions that are
> basically the same thing. A good argument has been made on how the previous
> draft isn't needed. It would be nice if all the solutions was considered in
> one draft. We seem to be circuling around implementations, first resolve if
> we want single or multiple solutions. And then understand how they interact.
> Stig - I agree. We initially only had one sticky DR in other draft, now we
> have two proposals. Do we actually need two solutions? Are there different
> use cases where one is better then the other?
> Alvaro - I'm not advocating for one or two, the wg to decide. maybe we
> define multiple use cases. Needs more coordination.
> Stig - if the wg decides we only need one solution that covers all the use
> cases we probably only want to publish one of them.
> Mike - some may want to have a hello option and others may not. And right
> now we only have one wg document. Let's say we do adopt this draft, should
> we hold off on progressing both documents until they are both progressed
> together?
> Alvaro - That would be nice. they are not dependent on each other. they
> don't have to progress together. progressing close would be nice.
> Stig - we shouldn't progress any document until we carefully decide what
> solution is best or if we want both solutions. Lets compare both options.
> To: Alvaro Retana <[email-masked]>; zhang.zheng <
> [email-masked]>; Stig Venaas <[email-masked]>
> Thanks every one for input. So I would update Sticky PIM DR without
> capability option in draft-mankamana-pim-bdr. Will ask for adoption in
> coming IETF.
> Mankamana
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*