Subject: [pim] Publishing draft-ietf-pim-dr-improvement-08

From: Stig Venaas <[email-masked]>
Date: Tue, 1 Oct 2019 11:18:20 -0700

Hi

An earlier version of this draft passed WGLC many months ago. However,
as discussed in the WG we agreed it should have some text pointing out
how it relates to draft-mankamana-pim-bdr-02 that we are considering
for adoption. This text has now been added, as well as some other
minor changes.

Please look at revision 08 and speak up if you have any concerns.

Authors, and others, please let us know if you are aware of any other
IPR claims than the one that already has been filed.

I'll wait a week or so to give people a chance to respond. We need at
least all the authors to respond regarding IPR before proceeding
though.

Thanks,
Stig

---

From: Stig Venaas <[email-masked]>
Date: Tue, 8 Oct 2019 15:05:41 -0700

Hi

Looks that there are no concerns moving ahead with publication. Can
the authors, and any others that might know
anything about IPR, let us know if they are aware of any other IPR
claims than what has been filed already?

Stig

---

From: "Mankamana Mishra (mankamis)" <[email-masked]>
Date: Tue, 8 Oct 2019 22:53:42 +0000

Not aware of any IPR to this draft. 

> On Oct 8, 2019, at 3:05 PM, Stig Venaas <[email-masked]> wrote:
> 
> Hi
>

---

From: <[email-masked]>
Date: Wed, 9 Oct 2019 08:45:34 +0800 (CST)

Hi Stig,

Very sorry for the late response because of the National Day holiday.

As co-author, I think this draft is ready to move ahead, and I don't know any other undisclosed IPR.

Thanks,

Sandy

原始邮件

发件人：StigVenaas <[email-masked]>
收件人：[email-masked] <[email-masked]>;[email-masked] <[email-masked]>;
日 期 ：2019年10月09日 06:06
主 题 ：Re: Publishing draft-ietf-pim-dr-improvement-08

Hi

Stig

---

From: 胡方伟 <[email-masked]>
Date: Wed, 9 Oct 2019 09:16:59 +0800

Hi，Stig
Sorry for the late reply.
I am not aware of any IPR to this document.

Fangwei Hu.
Best Regards.

<[email-masked]> 于2019年10月9日周三 上午8:45写道：

> *发件人：*StigVenaas <[email-masked]>
> *收件人：[email-masked] <[email-masked]>;[email-masked] <
> [email-masked]>;
> *日 期 ：*2019年10月09日 06:06
> *主 题 ：**Re: Publishing draft-ietf-pim-dr-improvement-08*
> Hi
>

---

From: <[email-masked]>
Date: Wed, 9 Oct 2019 11:39:25 +0800 (CST)

Hi, Stig

I don't know any other undisclosed IPR.

Thanks

Benchong Xu

原始邮件

Hi

Stig

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 11 Oct 2019 20:58:59 -0400

I agree that PIM SM DR process and failover does need improvements of which I would like to bring to everyone’s attention the BFD WG draft for PIM BFD for fast hitless convergence.

https://tools.ietf.org/html/draft-mirsky-pim-bfd-p2mp-use-case-02

Gyan Mishra
Verizon Communications 
Cell 301 502-1347

Sent from my iPhone

> On Oct 8, 2019, at 11:39 PM, <[email-masked]> <[email-masked]> wrote:
> 
> 
> Hi, Stig
> 
> _______________________________________________
> pim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pim

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 12 Oct 2019 10:40:15 -0400

PIM WG

In reviewing the draft I agree this is a much needed for PIM stability to prevent preemption from occurring when a PIM neighbor comes up with a higher priority.

I have seen this scenario come up many times and had caused many multicast outages over the years with PIM being enabled accidentally on a terminal server or L2 switch for a vlan and had a higher IP address and became the DR or had a higher priority configured and became the DR.

Is there a way to have a DR priority 0 to make the device non DR eligible similar to ospf DR priority 0.

I had posted PIM BFD spec from the BFD WG which helps tune down PIM timers to sub millisecond convergence which helps to get hitless convergence for LAN multipoint scenario and for MVPN, however this draft is critical to provide LHR DR stability and prevent DR preemption from occurring.  Also adding the role priority DR/BDR state I think also adds to faster convergence when the DR goes down.

In environments where MLAG or like Cisco proprietary vPC is used forwarding happens to both DR and BDR active/active state which is very common have PIM MRIB MFIB state on both routers so is that addressed how that would work in the draft. 

Also was wondering in the case of active backup for faster convergence is it possible for both DR and BDR to have their MRIB MFIB state table built for ASM SPT tree and with PIM BFD tuned down timers so that convergence becomes hitless.

Thank you 

Gyan Mishra 
Verizon Communications 
Cell 301 502-1347

Sent from my iPhone

> On Oct 11, 2019, at 8:58 PM, Gyan Mishra <[email-masked]> wrote:
> 
>

---

From: <[email-masked]>
Date: Mon, 14 Oct 2019 15:37:11 +0800 (CST)

Hi Gyan,

As co-author, thank you very much for your review! :-)

The motivation of this draft is from the actual PIM deployment of our customers. And the solution works well.

From RFC7761, the default value of DR priority is 1. For the interface which never becomes DR you may set the DR priority to 0 by configuration.

Thanks,

Sandy

原始邮件

发件人：GyanMishra <[email-masked]>
收件人：Gyan Mishra <[email-masked]>;
抄送人：徐本崇10065053;[email-masked] <[email-masked]>;[email-masked] <[email-masked]>;[email-masked] <[email-masked]>;[email-masked] <[email-masked]>;
日 期 ：2019年10月12日 22:40
主 题 ：Re: [pim] Publishing draft-ietf-pim-dr-improvement-08

PIM WG

Thank you 

Gyan Mishra 
Verizon Communications 
Cell 301 502-1347

Sent from my iPhone

Gyan Mishra
Verizon Communications 
Cell 301 502-1347

Sent from my iPhone

Hi, Stig

Thanks

Benchong Xu

Hi

Stig

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 14 Oct 2019 15:35:17 -0400

Thanks Sandy!!

In an DR/BDR scenario Active/Backup DR would you then have MRIB/MFIB state
on both the DR & BDR which is how you achieve fast convergence or would the
state only be on both in MLAG scenario.

Thanks

Gyan

On Mon, Oct 14, 2019 at 3:39 AM <[email-masked]> wrote:

> From RFC7761, the default value of DR priority is 1. For the interface
> which never becomes DR you may set the DR priority to 0 by configuration.
>
>
> Thanks,
>
> Sandy
>
>
> 原始邮件
> *发件人：*GyanMishra <[email-masked]>
> *收件人：*Gyan Mishra <[email-masked]>;
> *抄送人：*徐本崇10065053;[email-masked] <[email-masked]>;
> [email-masked] <
> [email-masked]>;[email-masked] <[email-masked]>;
> [email-masked] <[email-masked]>;
> *日 期 ：*2019年10月12日 22:40
> *主 题 ：**Re: [pim] Publishing draft-ietf-pim-dr-improvement-08*
> PIM WG
>
> In reviewing the draft I agree this is a much needed for PIM stability to
> prevent preemption from occurring when a PIM neighbor comes up with a
> higher priority.
>
> I have seen this scenario come up many times and had caused many multicast
> outages over the years with PIM being enabled accidentally on a terminal
> server or L2 switch for a vlan and had a higher IP address and became the
> DR or had a higher priority configured and became the DR.
>
> I had posted PIM BFD spec from the BFD WG which helps tune down PIM timers
> to sub millisecond convergence which helps to get hitless convergence for
> LAN multipoint scenario and for MVPN, however this draft is critical to
> provide LHR DR stability and prevent DR preemption from occurring.  Also
> adding the role priority DR/BDR state I think also adds to faster
> convergence when the DR goes down.
>
> In environments where MLAG or like Cisco proprietary vPC is used
> forwarding happens to both DR and BDR active/active state which is very
> common have PIM MRIB MFIB state on both routers so is that addressed how
> that would work in the draft.
>
> Also was wondering in the case of active backup for faster convergence is
> it possible for both DR and BDR to have their MRIB MFIB state table built
> for ASM SPT tree and with PIM BFD tuned down timers so that convergence
> becomes hitless.
>
> Thank you
>
> Gyan Mishra
> Verizon Communications
> Cell 301 502-1347
>
> Sent from my iPhone
>
> I agree that PIM SM DR process and failover does need improvements of
> which I would like to bring to everyone’s attention the BFD WG draft for
> PIM BFD for fast hitless convergence.
>

-- 

Gyan S. Mishra

IT Network Engineering & Technology

Verizon Communications Inc. (VZ)

13101 Columbia Pike FDC1 3rd Floor

Silver Spring, MD 20904

United States

Phone: 301 502-1347

Email: [email-masked]

www.linkedin.com/in/networking-technologies-consultant

---

From: Stig Venaas <[email-masked]>
Date: Mon, 14 Oct 2019 13:37:57 -0700

Hi

Gyan, are you OK with this draft being published as is, or do you
think there are any issues that need to be addressed?

Regarding BFD, it might be worth having a document specifically
discussing how BFD may be used with pim. There are many
implementations using BFD with pim, but I don't think we have any
documents explaining exactly how that is done, except for
draft-ietf-pim-bfd-p2mp-use-case, but it doesn't go into detail on the
pim behavior, and it is discussed in the context of p2mp BFD.

Regards,
Stig

---

From: "Mankamana Mishra (mankamis)" <[email-masked]>
Date: Mon, 14 Oct 2019 20:53:38 +0000

Hi Gyan 
As working group member I think we should still going ahead with publishing this document . Any subsequent behavior can be covered in independent document . We can work offline on that . 

Sent from my iPhone

> On Oct 14, 2019, at 13:38, Stig Venaas <[email-masked]> wrote:
> 
> Hi
>

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 14 Oct 2019 17:02:50 -0400

In-line response 

Sent from my iPhone

> On Oct 14, 2019, at 4:37 PM, Stig Venaas <[email-masked]> wrote:
> 
> Hi
> 

[Gyan] I am good with moving forward with publishing the document.  I agree we definitely need a document that describes PIM usage with BFD.  I am a member of both PIM and BFD WG so I can work with you on that draft.

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 14 Oct 2019 17:05:16 -0400

Mankamana 

I agree we can move forward with publishing this document and I can work with you on a PIM BFD Draft.

Thank you 

Gyan
Sent from my iPhone

> On Oct 14, 2019, at 4:53 PM, Mankamana Mishra (mankamis) <[email-masked]> wrote:
> 
> Hi Gyan

---

From: <[email-masked]>
Date: Tue, 15 Oct 2019 11:32:44 +0800 (CST)

Hi Gyan

According to the actual situation encountered before, the last hop of PIM quickly switching, the following scenarios need to be considered.

Source network

|          |

R1        R2

|          |

------------

     |

    Host

1.R1 is DR, When R1 or interface of R1 to R2 get down, R2 should forward stream as quickly as posible.

This can be down in help of bfd.

If we do this in forwarding plane， packet loss time depends on bfd detection time.

And if we do this in control plane， packet loss time will be longer due to the time of sending join to upstream and updating the device entries.

2.Then R1 up again, DR change back to R1，but there is no mechanism to ensure that igmp members can learn synchronously. 

This draft will help to keep R2 foward stream，and there is no packet loss.

Or DR changing back delay, which will result in packet loss or double stream, and we do not recommend.

Source network

|    |     |

R1   R2    R3

|    |     |

------------

     |

    Host

3.A new pim router R3 joins the network. There is the same problem as above 2, the solution is the same.

Source network

|          |

R1         R2

|          |

L2-SW1     L2-SW4

|          |

L2-SW2-----L2-SW3

|          |

Host       Host

4.L3 PIM routers R1(DR) R2 connected by lots of L2 switchs L2-SW, and every L2-SW has igmp members. 

a. R1 to L2-SW1 Link down, R2 should forward stream quickly.Same solution as 1.

b. R1 to L2-SW1 Link up again. Same solution as 2.

c. L2-SW2 to L2-SW3 link down. R1 keep forward stream to L2-SW1 L2-SW2, and R2 forward stream to L2-SW4 L2-SW3. Same solution as 1.

d. L2-SW2 to L2-SW3 link up again. We should try to ensure that neighbors are established and igmp members learn to synchronize no matter who takes over the forwarding. R1 and R2 should build peer BFD when there are pim NBR at the beginning, and perceive remote link up according to bfd up event, trigger pim hello and igmp query to send synchronously.

Thank you！

Benchong

原始邮件

发件人：GyanMishra <[email-masked]>
收件人：Mankamana Mishra (mankamis) <[email-masked]>;
抄送人：Stig Venaas <[email-masked]>;张征00007940;徐本崇10065053;[email-masked] <[email-masked]>;[email-masked] <[email-masked]>;Greg Mirsky <[email-masked]>;
日 期 ：2019年10月15日 05:05
主 题 ：Re: [pim] Publishing draft-ietf-pim-dr-improvement-08

Mankamana 

Thank you 

Gyan
Sent from my iPhone

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 14 Oct 2019 23:56:05 -0400

Hi Benchong

I agree that we should implement in the forwarding plane and not control plane where we can tune the pim timers down with BFD to ms for close to hitless convergence and also not dependent on sending joins upstream SPT tree MRIB/MFIB status to start forwarding.

Also agree that with this draft it helps with preemptions with higher priority router taking over as DR instability.  So this draft along with PIM BFD we can optimize convergence.

With the IGMP querier state table since that is depending on control plane responses to general query is there any way BFD can speed up that process if we put in the forwarding plane in hardware.  

Also was wondering an idea if we made the DR a floating Service IP like an anycast IP that is active on both routes allowing traffic to be forwarded load shared to both DR/BDR running active/active similar to an MLAG or Cisco Nexus vPC scenario load balancing so that traffic convergence is eliminated since we are now forwarding joins to both DR and BDR for ASM tree and 2 SPT trees get build on both last hop routers DR and BDR to the source.  That would I think make convergence hitless.

Gyan

Sent from my iPhone

> On Oct 14, 2019, at 11:32 PM, <[email-masked]> <[email-masked]> wrote:
> 
> Hi Gyan
>

---

From: <[email-masked]>
Date: Tue, 15 Oct 2019 14:56:44 +0800 (CST)

Hi GyanIt is a good solution to construct two SPT trees by DR and BDR. The fast switching on the forwarding plane can effectively solve the DR fault convergence speed.

4.d scene still has problems (mail is not a monospace character by default, the figure is somewhat deformed), because the states of both R1 and R2 are DR, using the previous method may not get ms level convergence. The best solution is to establish a neighbor in time through the peer bfd aware link up, and then the BDR continues to forward until the interface receives the traffic of the group and then modifies the forwarding state of the out interface of the sg/xg.

Thank you！

Benchong

原始邮件

发件人：GyanMishra <[email-masked]>
收件人：徐本崇10065053;
抄送人：[email-masked] <[email-masked]>;[email-masked] <[email-masked]>;张征00007940;[email-masked] <[email-masked]>;[email-masked] <[email-masked]>;[email-masked] <[email-masked]>;
日 期 ：2019年10月15日 11:56
主 题 ：Re: [pim] Publishing draft-ietf-pim-dr-improvement-08

Hi Benchong

Gyan

Sent from my iPhone

Hi Gyan

Source network

|          |

R1        R2

|          |

------------

     |

    Host

Source network

|    |     |

R1   R2    R3

|    |     |

------------

     |

    Host

Source network

|          |

R1         R2

|          |

L2-SW1     L2-SW4

|          |

L2-SW2-----L2-SW3

|          |

Host       Host

Thank you！

Benchong

Mankamana 

Thank you 

Gyan
Sent from my iPhone

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 15 Oct 2019 10:13:28 -0400

This draft addresses and is exactly what I was looking for as far a PIM DR LB capability 

https://tools.ietf.org/html/draft-ietf-pim-drlb-11

So I think from a multicast resiliency and failover perspective for close to hitless convergence the DR preemptions issue is resolved with the DR role priority DR/BDR start in the improvements draft and the DR LB is addressed in the DRLB draft above and now if I work with someone on drafting the PIM BFD draft I think we have a pretty solid PIM SM architecture.

Gyan

Sent from my iPhone

> On Oct 15, 2019, at 2:56 AM, <[email-masked]> <[email-masked]> wrote:
> 
> 
> Hi Gyan
> It is a good solution to construct two SPT trees by DR and BDR. The fast switching on the forwarding plane can effectively solve the DR fault convergence speed.
>

---

From: Stig Venaas <[email-masked]>
Date: Fri, 25 Oct 2019 16:17:36 -0700

Hi

I've requested publication now and there is a shepherd's writeup at
https://datatracker.ietf.org/doc/draft-ietf-pim-dr-improvement/shepherdwriteup/

I found some issues I hope the authors can try to address right away.
I should perhaps have waited with publication.

Please check https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-pim-dr-improvement-07.txt
You will see a few things that should be fixed.

Also, the IANA considerations should be fixed. From the writeup:

It is pretty obvious what is needed, but I think the IANA
considerations should have specified the names of the new hello
options, so that IANA doesn't need to look through the rest of the
document to try to figure it out. Section 3.1 is titled "DR Address
Option format" and the option name is "DR Address". Likewise section
3.2 is titled "BDR Address Option format".
It could also be stated clearly that it is for the "PIM Hello Options" registry.

Are the authors aware of any implementations? I should state that in
the writeup.

Thanks,
Stig

---

From: <[email-masked]>
Date: Sat, 26 Oct 2019 10:29:06 +0800 (CST)

Hi Stig,

Thank you very much for your careful review!

A new version-09 of this draft has been submitted. 

The IANA part is modified, and the unused reference to RFC2362 has been removed.

About the implementation, ZTE has implemented this function in our product, and it has been deployed.

Thanks,

Sandy

原始邮件

发件人：StigVenaas <[email-masked]>
收件人：
抄送人：[email-masked] <[email-masked]>;[email-masked] <[email-masked]>;
日 期 ：2019年10月26日 07:18
主 题 ：Re: [pim] Publishing draft-ietf-pim-dr-improvement-08

Hi

Thanks,
Stig

---

From: Stig Venaas <[email-masked]>
Date: Sun, 27 Oct 2019 12:05:29 -0700

Hi, thanks for the quick response! I've updated the shepherd's writeup
now. Next we'll get AD's review.

Stig