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

<xu.benchong@zte.com.cn> Tue, 15 October 2019 03:33 UTC

Return-Path: <xu.benchong@zte.com.cn>
X-Original-To: pim@ietfa.amsl.com
Delivered-To: pim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 183141208E3; Mon, 14 Oct 2019 20:33:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level:
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9tpUScBR7w68; Mon, 14 Oct 2019 20:33:47 -0700 (PDT)
Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.217.80.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C77A61208C6; Mon, 14 Oct 2019 20:33:46 -0700 (PDT)
Received: from mse-fl1.zte.com.cn (unknown [10.30.14.238]) by Forcepoint Email with ESMTPS id 78AB729BA37601A7609D; Tue, 15 Oct 2019 11:33:44 +0800 (CST)
Received: from njxapp05.zte.com.cn ([10.41.132.204]) by mse-fl1.zte.com.cn with SMTP id x9F3WiU2043634; Tue, 15 Oct 2019 11:32:44 +0800 (GMT-8) (envelope-from xu.benchong@zte.com.cn)
Received: from mapi (njxapp03[null]) by mapi (Zmail) with MAPI id mid201; Tue, 15 Oct 2019 11:32:44 +0800 (CST)
Date: Tue, 15 Oct 2019 11:32:44 +0800 (CST)
X-Zmail-TransId: 2afb5da53ddcc56ee91f
X-Mailer: Zmail v1.0
Message-ID: <201910151132440908971@zte.com.cn>
In-Reply-To: <7F5345CC-B4B8-4008-AF7B-EE3CC528523B@gmail.com>
References: CAHANBtJBk1CDtOnBDmjXPU4x-BZJSs93OYj6b07aAGSggg5mAw@mail.gmail.com, 7F5345CC-B4B8-4008-AF7B-EE3CC528523B@gmail.com
Mime-Version: 1.0
From: <xu.benchong@zte.com.cn>
To: <hayabusagsm@gmail.com>
Cc: <mankamis@cisco.com>, <stig@venaas.com>, <zhang.zheng@zte.com.cn>, <draft-ietf-pim-dr-improvement@ietf.org>, <pim@ietf.org>, <gregimirsky@gmail.com>
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-fl1.zte.com.cn x9F3WiU2043634
Archived-At: <https://mailarchive.ietf.org/arch/msg/pim/hGPKD6adQ4xmGUX-Noxb-hJM96s>
Subject: Re: [pim] =?utf-8?q?Publishing_draft-ietf-pim-dr-improvement-08?=
X-BeenThere: pim@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Protocol Independent Multicast <pim.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pim>, <mailto:pim-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pim/>
List-Post: <mailto:pim@ietf.org>
List-Help: <mailto:pim-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pim>, <mailto:pim-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Oct 2019 03:34:02 -0000

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 <hayabusagsm@gmail.com>
收件人:Mankamana Mishra (mankamis) <mankamis@cisco.com>om>;
抄送人:Stig Venaas <stig@venaas.com>;张征00007940;徐本崇10065053;draft-ietf-pim-dr-improvement@ietf.org <draft-ietf-pim-dr-improvement@ietf.org>;pim@ietf.org <pim@ietf.org>;Greg Mirsky <gregimirsky@gmail.com>om>;
日 期 :2019年10月15日 05:05
主 题 :Re: [pim] Publishing draft-ietf-pim-dr-improvement-08



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) <mankamis@cisco.com> wrote:
> 
> 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 <stig@venaas.com> wrote:
>> 
>> 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