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

Gyan Mishra <hayabusagsm@gmail.com> Tue, 15 October 2019 14:13 UTC

Return-Path: <hayabusagsm@gmail.com>
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 946FC120124; Tue, 15 Oct 2019 07:13:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 PBrMzRV3_Rnr; Tue, 15 Oct 2019 07:13:31 -0700 (PDT)
Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8ACDE120119; Tue, 15 Oct 2019 07:13:31 -0700 (PDT)
Received: by mail-qk1-x735.google.com with SMTP id h126so19276429qke.10; Tue, 15 Oct 2019 07:13:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=1v2wbFHgIGMslW5H66fPzqVTc2UVMpPZgFEnXTimvUg=; b=kU3GQcLgvqdGuftATfB6NSV6gLy4vrgTzLM1Jq+PYA/cpdfcU2SeVqh3p00tWhvRt2 pfENBZKH3toq0RZFSfvrbuV9QNDDfSSTzjoMnTXXzx0HbTYA7o3hRT+718u+JqXSmRHV 3RgQzfcFwnuymqPg7c8l62aQBSzC2cV9MN4bn/m9vb8/ZKxfosc7Qq1Z26AMXDNfnXFx pJ9ijn0NL1BXRWVUxZOFX9e7Ac0TYOkvMvzVzgnRUc04UU2IXzl28hXmdH36ixH9SL3k dH8TnqknwY2JqdXgbGA7E34LZ8hEdvyX40ynb/FZnC2RkyYvTrnsWo/hQKtnQVgg6YD3 SkQw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=1v2wbFHgIGMslW5H66fPzqVTc2UVMpPZgFEnXTimvUg=; b=qtwh33W+Fe7uVHhHWpF5GkDcS1PtP/UuT3hHWMUXFAlbwl4ug9OzsVUMgs51p/6STJ tJM4QGOHIuICtFnxRjklJ0frKDzw7lS6CxvDU9gmHG/IAMQVToygJw7jfiTN9la4i4KE FkaSRpQ7mdXzlbx2y9S/aYdqZxZu6s6DUQJ9MPO/pVKPF44c9rzET3c3NMyOynvMesXS N+0k4gyEes+znk7rbqB5/J7Hc5Vu+fQoNsF/Un2M3JgEo4+psRoeCyVSypZaVjccKPrl Q8yhRvtWap1Gjr6F8SYN9zBC8/WGnOXBREEMdn8e1KUoksPteCC1FW/ev/mVE/5qTCyn rJSg==
X-Gm-Message-State: APjAAAXutlfS1CVwtbdDtIV5t1d8TLQYjvAw1uSxNWC4rbM7JJ76UHUe qRpxVtkCvBmK9u44y2FnlCRgp6dNzYE=
X-Google-Smtp-Source: APXvYqxL5pK/r60RpBZogkijeHwDDCtlEVkf2NkhaDrZIvwvql+kTCXlwVrE/gPLMe3BJtAm2wNRXQ==
X-Received: by 2002:a05:620a:20de:: with SMTP id f30mr35764296qka.333.1571148810016; Tue, 15 Oct 2019 07:13:30 -0700 (PDT)
Received: from [192.168.1.213] (pool-72-83-194-140.washdc.fios.verizon.net. [72.83.194.140]) by smtp.gmail.com with ESMTPSA id h29sm12506964qtb.46.2019.10.15.07.13.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 Oct 2019 07:13:29 -0700 (PDT)
From: Gyan Mishra <hayabusagsm@gmail.com>
X-Google-Original-From: Gyan Mishra <hayabusaGSM@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail-886E671E-FEFE-4536-A3D2-30095DF9077A"
Mime-Version: 1.0 (1.0)
X-Mailer: iPhone Mail (16G102)
In-Reply-To: <201910151456443743196@zte.com.cn>
Date: Tue, 15 Oct 2019 10:13:28 -0400
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-Transfer-Encoding: 7bit
Message-Id: <859C8095-9B16-4C6D-996C-325477274C12@gmail.com>
References: <201910151456443743196@zte.com.cn>
To: xu.benchong@zte.com.cn
Archived-At: <https://mailarchive.ietf.org/arch/msg/pim/tZGw4O7T0-NW2JYtimPfi0B3IIk>
Subject: Re: [pim] 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 14:13:36 -0000

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, <xu.benchong@zte.com.cn> <xu.benchong@zte.com.cn> 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.
> 
> 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 <hayabusagsm@gmail.com>
> 收件人:徐本崇10065053;
> 抄送人:mankamis@cisco.com <mankamis@cisco.com>;stig@venaas.com <stig@venaas.com>;张征00007940;draft-ietf-pim-dr-improvement@ietf.org <draft-ietf-pim-dr-improvement@ietf.org>;pim@ietf.org <pim@ietf.org>;gregimirsky@gmail.com <gregimirsky@gmail.com>;
> 日 期 :2019年10月15日 11:56
> 主 题 :Re: [pim] Publishing draft-ietf-pim-dr-improvement-08
> 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, <xu.benchong@zte.com.cn> <xu.benchong@zte.com.cn> wrote:
>> 
>> 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>;
> 抄送人: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>;
> 日 期 :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
>