Re: PIM BFD RFC

Gyan Mishra <hayabusagsm@gmail.com> Thu, 17 October 2019 14:10 UTC

Return-Path: <hayabusagsm@gmail.com>
X-Original-To: rtg-bfd@ietfa.amsl.com
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F01C12086C for <rtg-bfd@ietfa.amsl.com>; Thu, 17 Oct 2019 07:10:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.496
X-Spam-Level:
X-Spam-Status: No, score=-1.496 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, SUBJ_ALL_CAPS=0.5, URIBL_BLOCKED=0.001] autolearn=no 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 XQ-l9xuUPqOp for <rtg-bfd@ietfa.amsl.com>; Thu, 17 Oct 2019 07:10:56 -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 1AC2C1208BC for <rtg-bfd@ietf.org>; Thu, 17 Oct 2019 07:10:54 -0700 (PDT)
Received: by mail-qk1-x735.google.com with SMTP id e66so1935077qkf.13 for <rtg-bfd@ietf.org>; Thu, 17 Oct 2019 07:10:54 -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=TM3Z1I+y7Sg5T6+AxR62/mK+WDobpSTwpynu8miK0v0=; b=qL8TUo0zP18qnwR/uAObAghMyqnJVmdg82a9IRraB+N9eh2507caEZnhVlsbT6Fj9X RQvuO2ZDWZ72FNvuQAD8zGWUyKjZyojQvBcCAPn83MKfFGPjPzUK4+Drd/eZPbUhQAh8 NxvyenZ8DarjKJy5LR3HlYWSbQ9dJ2WZROIVPFwlEBacWFiIB+Nt9qK09lIszd1S0aTG prq5RE1kwD8oDw63s09pJqiB9k/60vhtnt+GS/PH+f20hyI7VXUmSH9NznuANpEcLqzk 1P0WcaUFycmSicgqSvE3dRuahErgmemMM7HNFn+MElEpySzBZL7Qzv8ICbZrrDMH3mPz TApA==
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=TM3Z1I+y7Sg5T6+AxR62/mK+WDobpSTwpynu8miK0v0=; b=lmZf+PO/Ev4HrlxWO7tQ5yt9Wfa+HeCqkmweIntnzsxFJurvZiEw+0vNVdSAH+76qo JuxwhuXifSwIkXS6u6UCMKJ9MoOac7tIRACvRnIJ4suEgVGBr2Xiz1HQ/JuPSz/4KeDQ H1gr9UqOD/yj8lPZcUnIqr4AF+TP1C4J0jwZ5y1cqOG4eKmzjr/rEifufN+it9plusAR RyzRio2JieCdTdLpOZRleIcHkNi+bF5Lx/NVgDsjY1e45LFCa6oeqzBuPKR6wyfEw5dH mzNzsbc7FeqKb40YjCg4qWfL5PkldFNS29kI8itIXzXfq0SzDvpTZIFamCSb0CEbov1A AcgA==
X-Gm-Message-State: APjAAAVRtz5PRCexQ290ObJ9xBmCov25n11jYuMwwx648E++DLd+VZS+ /+WjelWzTH1Yc1yOfFy1tAE=
X-Google-Smtp-Source: APXvYqwK2SSKxrCZdRcXrBHqzRDhNsGumScNl9W5j2O7RjHyzV7ZE8yu+bXB1D//D/hUKLk/XP8uRQ==
X-Received: by 2002:a37:348:: with SMTP id 69mr3444228qkd.28.1571321452835; Thu, 17 Oct 2019 07:10:52 -0700 (PDT)
Received: from ?IPv6:2600:1003:b108:7d8c:c85:6e23:cdbc:b01? ([2600:1003:b108:7d8c:c85:6e23:cdbc:b01]) by smtp.gmail.com with ESMTPSA id t63sm1602531qkf.48.2019.10.17.07.10.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 17 Oct 2019 07:10:50 -0700 (PDT)
From: Gyan Mishra <hayabusagsm@gmail.com>
X-Google-Original-From: Gyan Mishra <hayabusaGSM@gmail.com>
Content-Type: multipart/alternative; boundary=Apple-Mail-C6B1FF28-D82C-4018-8AA9-6E23F07199F2
Mime-Version: 1.0 (1.0)
Subject: Re: PIM BFD RFC
X-Mailer: iPhone Mail (16G102)
In-Reply-To: <CA+RyBmW+E4XGrUv4bEH2Psx7o4bVuk=pG7oCY6x_LQ_MPgXyhg@mail.gmail.com>
Date: Thu, 17 Oct 2019 10:10:49 -0400
Cc: rtg-bfd WG <rtg-bfd@ietf.org>, xu.benchong@zte.com.cn, "Mankamana Mishra (mankamis)" <mankamis@cisco.com>
Content-Transfer-Encoding: 7bit
Message-Id: <6688ABC1-BF0C-42EC-B2B3-8CE93C870538@gmail.com>
References: <37FED5C8-F400-4C72-B72E-0552AD398895@gmail.com> <F4C0E27E-A90D-450D-99F1-FD985E9639D8@gmail.com> <CA+RyBmXZYTaZWQf0VLBTPKM+ZXEvWEOucGHUeQs9pEb5E3shGg@mail.gmail.com> <F8DFF05F-AB75-42B1-8112-7B5E00A86A18@gmail.com> <CA+RyBmW+E4XGrUv4bEH2Psx7o4bVuk=pG7oCY6x_LQ_MPgXyhg@mail.gmail.com>
To: Greg Mirsky <gregimirsky@gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/TFjXH4SraRx3DKj4GtBMp6UDzUc>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-bfd/>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Oct 2019 14:10:59 -0000

Greg 

That is true that there can be more GDR candidates but with the modulo hashing algorithm the load balancing becomes less even with odd number of routers similar to XOR bitwise source/destination hash. 

So the issue is that with even routers you do achieve close to 100% load balancing which means a very close 50/50 split between the two routers with the hashing algorithm.  So even in that scenario if one of the 2 routers doing down instead of having to reconverge 100% of all of you traffic you reconverge only 50% so the impact is only 50% of your traffic volume.  As you increase the number of routers the load is split between routers however and so the impact is diminished but not eliminated and of course with odd number routers 3  5 7 etc you have uneven load balancing so more impact and with even 2 4 6 close to perfect split of load balancing.

So bottom line is that traffic is on the router that went down has to reconverge be taken over or split hashed onto the other remaining routers so the from my point of view their is still definitely improvements gains with tight PIM timers with BFD single hop asynchronous mode to get as close to hitless convergence.  The P2MP RFCs are strictly for labels switched multicast multipoint LSP with mLDP or P2MP TE P2MP or MP2MP MDT strictly for MVPN scenarios and cannot be applied to LAN.

Gyan

Sent from my iPhone

> On Oct 16, 2019, at 10:23 PM, Greg Mirsky <gregimirsky@gmail.com> wrote:
> 
> Hi Gyan,
> thank you for bringing draft-ietf-pim-drlb to my attention (I'm following discussions in PIM WG but was not aware of this use case). Also, I appreciate you sharing your thoughts on the applicability of RFCs 8562 and 8563 to the GDR use case. With the current scenario, as I understand it, there could be more than two GDR Candidates on the given LAN segment. Let us assume that there three such routers. If one is elected as GDR and another as GBDR, then third is GDROther. If that is the case, then the mechanism described for DR/BDR/DROther in draft-ietf-pim-bfd-p2mp-use-case can be used for expedited convergence of GDR/GDBR/GDROther. Would you agree?
> 
> Regards,
> Greg
> 
>> On Tue, Oct 15, 2019 at 9:10 PM Gyan Mishra <hayabusagsm@gmail.com> wrote:
>> 
>> Greg 
>> 
>> + Mankamana and Benchon 
>> 
>> ...from PIM WG & BESS which owns LSM MVPN mLDP / P2MP TE S-PMSI and MI-PMSI.
>> 
>> We were discussing PIM BFD use case on this BFD WG thread  and  RFC 8562 and RFC 8563 covers strictly L3 VPN LSM ( label switched Multicast) LMDT (labeled multicast distribution tree) mLDP / P2MP p-tree S-PMSI ( selective constrained MDT / Cisco data MDT) MI-PMSI(inclusive MDT for all VRFs) and not Ethernet switching LAN based PIM SM BFD.
>> 
>> We have a new draft in the PIM WG PIM DRLB load balancing GDR capability and the draft of hashing of ASM PIM RP hash and ASM and SSM S,G hash load balancing of traffic across both PIM DR/BDR does significantly help with convergence as 50/50 LB split but during failover you still have 50% of the traffic that still has to reconverge and SPT tree MRIB/MFIB state has to rebuild.  
>> 
>> 
>> https://tools.ietf.org/html/draft-ietf-pim-drlb-11
>> 
>> 
>> So the BFD PIM Draft would register the PIM protocol and in asynchronous mode with echo disabled we can achieve sub millisecond detection time and convergence during failover.
>> 
>> So I do think we need a PIM BFD Draft. 
>> 
>> Since this falls between multiple WG but since BFD related this would be under the BFD WG.
>> 
>> I am part of the BFD WG as well as part of PIM and BESS so I can assist in writing the draft if we are all in agreement that this is needed and can work with Mankamana and Benchon as well in creating the draft.
>> 
>> Gyan
>> 
>> Sent from my iPhone
>> 
>>> On Oct 12, 2019, at 12:07 AM, Greg Mirsky <gregimirsky@gmail.com> wrote:
>>> 
>>> Hi Gyan,
>>> thank you for your interest in this draft. We've described how RFC 8562 BFD for Multipoint Networks can be used to shorten convergence in PIM-SM. The similar scenario discussed in draft-ietf-bess-mvpn-fast-failover where p2mp BFD is used by tails to detect the failure of the head/root or the multicast tree. If it is required for the head/root to detect a defect of the multicast tree toward a tail, we'll turn to RFC 8563 BFD for Multipoint  Active Tails as in draft-hu-bier-bfd.
>>> Hope this information would be helpful to you. I always welcome your questions.
>>> 
>>> Regards,
>>> Greg
>>> 
>>>> On Fri, Oct 11, 2019 at 7:40 PM Gyan Mishra <hayabusagsm@gmail.com> wrote:
>>>> Greg 
>>>> 
>>>> I saw your draft on PIM BFD use cases but could not find the RFC on PIM BFD.
>>>> 
>>>> 
>>>> https://tools.ietf.org/id/draft-mirsky-pim-bfd-p2mp-use-case-02.html
>>>> 
>>>> Thanks 
>>>> 
>>>> Gyan
>>>> Verizon Communications 
>>>> Cell-301 502-1347
>>>> 
>>>> 
>>>> Sent from my iPhone
>>>> 
>>>>> On Oct 11, 2019, at 9:53 PM, Gyan Mishra <hayabusagsm@gmail.com> wrote:
>>>>> 
>>>>> 
>>>>> BFD WG
>>>>> 
>>>>> Anyone know what the RFC or draft for PIM BFD support.
>>>>> 
>>>>> Thank you
>>>>> 
>>>>> Gyan 
>>>>> Verizon Communications 
>>>>> 
>>>>> 
>>>>> 
>>>>> Sent from my iPhone