Subject: PIM BFD RFC

From: Gyan Mishra <[email-masked]>
Date: Fri, 11 Oct 2019 21:53:01 -0400

BFD WG

Anyone know what the RFC or draft for PIM BFD support.

Thank you

Gyan 
Verizon Communications 

Sent from my iPhone

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 11 Oct 2019 22:40:30 -0400

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 <[email-masked]> wrote:
> 
> 
> BFD WG
>

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 11 Oct 2019 21:07:03 -0700

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

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 16 Oct 2019 00:10:25 -0400

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 <[email-masked]> 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
>

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 16 Oct 2019 19:23:50 -0700

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 <[email-masked]> wrote:

> 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.
>
>
> 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.
>
> 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
>
> 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
> Multipoint  Active Tails <https://datatracker.ietf.org/doc/rfc8563/> as
> in draft-hu-bier-bfd <https://datatracker.ietf.org/doc/draft-hu-bier-bfd/>
> .

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 17 Oct 2019 10:10:49 -0400

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 <[email-masked]> 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
>

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 17 Oct 2019 07:46:43 -0700

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 <[email-masked]> 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
>
>> 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
>> in draft-hu-bier-bfd
>> <https://datatracker.ietf.org/doc/draft-hu-bier-bfd/>.

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 17 Oct 2019 11:38:29 -0400

Sent from my iPhone

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

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 18 Oct 2019 12:43:20 -0400

Gyan,

> Since this falls between multiple WG but since BFD related this would be under the BFD WG.

Generally, when we're talking about whether a draft that utilizes BFD
belongs in BFD or not, the deciding criteria is usually whether there's
changes to the BFD protocol itself.

I believe in these cases we'd be making use of existing p2mp BFD procedures
rather than extending them.  In that case, we'd normally suggest the work
live in the related protocol Working Group.

Part of BFD's charter is to help review uses of BFD in such protocols, so
even if the work was happening in the related multicast working groups, the
chairs of those groups are welcome to request simultaneous review in BFD
during last call.

-- Jeff

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 18 Oct 2019 22:26:32 -0400

Thank you 

Thank you for clarification on which WG should initiate the draft.

I will work with the PIM WG and engage BFD WG as necessary during Last Call.

Gyan

Sent from my iPhone

> On Oct 18, 2019, at 12:43 PM, Jeffrey Haas <[email-masked]> wrote:
> 
> Gyan,
>