Re: PIM BFD RFC

[Gyan Mishra <[e-mail]>]

Sent from my iPhone

> On Oct 17, 2019, at 10:46 AM, Greg Mirsky <[e-mail]> wrote:
> 
> 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

I think the big difference is physical medium that in the “on demand” mode the head is detecting the active rails sending the control packets however the medium is limited as the number of tails is limited to the number of egress PEs for the LMDT where on a multiaccess media the numbers can be very large infinite like but also is an always ON scenario as a LAN the medium is always present to send single hop BFD asynchronous or echo to as many PIM routers that exist on that shared media where with an LMDT the medium is a temporary state and only when traffic is flowing is the M2MP or P2MP label switched path created and then its torn down once the flow has ended which is why multi hop on demand is perfect for label switched multicast where it just won’t work with a LAN based multiaccess bridge domain medium lan switch.

Gyan
> 
>> 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 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 <[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