Re: PIM BFD RFC

[Greg Mirsky <[e-mail]>]

Hi Gyan,
many thanks for adding more details to the scenario you're discussing. As
you know, p2mp BFD, as defined in RFC 8562 and RFC 8563, operates in the
Demand mode. What are the advantages of using the Asynchronous mode, and I
assume that implies using p2p BFD sessions, as in RFC 5881 for single-hop
BFD?

Regards,
Greg

On Thu, Oct 17, 2019 at 7:10 AM Gyan Mishra <[e-mail]> wrote:

> 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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> wrote:
>>
>> Hi Gyan,
>> thank you for your interest in this draft. We've described how RFC 8562
>> BFD for Multipoint Networks <https://datatracker.ietf.org/doc/rfc8562/> can
>> be used to shorten convergence in PIM-SM. The similar scenario discussed in
>> draft-ietf-bess-mvpn-fast-failover
>> <https://datatracker.ietf.org/doc/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 <https://datatracker.ietf.org/doc/rfc8563/> as
>> in draft-hu-bier-bfd
>> <https://datatracker.ietf.org/doc/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 <[e-mail]>
>> 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 <[e-mail]> wrote:
>>>
>>>
>>> BFD WG
>>>
>>> Anyone know what the RFC or draft for PIM BFD support.
>>>
>>> Thank you
>>>
>>> Gyan
>>> Verizon Communications
>>>
>>>
>>>
>>> Sent from my iPhone
>>>
>>>