Subject: Hello, use case question about BFD

From: "Snyder, Brian" <[email-masked]>
Date: Wed, 5 Mar 2014 22:02:19 +0000

Hello all,

I have just started researching BFD and am not sure it is a viable solution to my networking problem.  If someone would be so kind as to comment on below I would greatly appreciate it!

I am interested in determining if one could use BFD in place of a radio aware routing methodology (like DLEP).  My problem with DLEP is that it is not a standard yet and is therefore hard to build anything against.

I'm thinking BFD could take the place, with a few caveats.

It seems to me that BFD can't operate in an event driven mode, IE: Sending a DOWN control packet.  Therefore it is very chatty, even more-so then the L3 hello's I'm hoping to minimize.  Since the main purpose is to give quicker convergence then I am willing to configure all the L3 HELLOs (bandwidth is expensive in my environment), I was wondering if 'proxy-ing' the BFD connections is a viable solution (of course assuming no authentication).

IE:

RTR-H -----    HUB-MDM                          <->  MDM-A ---  RTR-A
                                                                              MDM-B ---  RTR-B

So I'm curious if I could have HUB-MDM "proxy/spoof" the BFD control packets for RTR A and B and have MDM -A/B proxy for Rtr -A/b respectively.

Is there any reason why this couldn't work?  If any MDM dropped out of network, then HUB-MDM would simply stop proxying on his behalf, and RTR-H should figure it out and kill the peer at BFD speeds.

Assuming I am on the correct track, would it be further possible to aggregate with the descrimitor field at HUB-MDM to only have one BFD session going for all Modems.  There could be thousands of MDM in one network and I would envision this could be a scale problem for RTR-H to manage all this, as well as pps scale issue processing all those for both RTR-H and HUB-MDM.

Any thoughts? I am new too this and wondering if I am on the right track or wasting my time considering BFD for this purpose....

Thanks,
Brian Snyder
Snr. Applied Researcher

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Thu, 6 Mar 2014 01:42:07 +0000

+ MANET WG

Hi Brian,

I agree that no existing BFD would fit well into MANET scenario. Instead of a proxy approach, I would see variant of multipoint BFD or broadcast-style BFD may be simpler and more fitting, where each MANET interface would periodically broadcast BFD packets and remote state is maintained by reception of received BFD packets from remote MANET interfaces.

If MANET WG thinks, in addition to DLEP, having an efficient hello mechanism will be useful and at layer 3, then this would be a technically interesting problem to discuss further.

-Nobo

> -----Original Message-----
> From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Snyder, Brian
> Sent: Wednesday, March 05, 2014 5:02 PM
> To: [email-masked]
> Subject: Hello, use case question about BFD
> 
> Hello all,
> 
> I have just started researching BFD and am not sure it is a viable solution to
> my networking problem.  If someone would be so kind as to comment on
> below I would greatly appreciate it!
> 
> I am interested in determining if one could use BFD in place of a radio aware
> routing methodology (like DLEP).  My problem with DLEP is that it is not a
> standard yet and is therefore hard to build anything against.
> 
> It seems to me that BFD can't operate in an event driven mode, IE: Sending
> a DOWN control packet.  Therefore it is very chatty, even more-so then the
> L3 hello's I'm hoping to minimize.  Since the main purpose is to give quicker
> convergence then I am willing to configure all the L3 HELLOs (bandwidth is
> expensive in my environment), I was wondering if 'proxy-ing' the BFD
> connections is a viable solution (of course assuming no authentication).
> 
> IE:
> 
> So I'm curious if I could have HUB-MDM "proxy/spoof" the BFD control
> packets for RTR A and B and have MDM -A/B proxy for Rtr -A/b
> respectively.
> 
> Is there any reason why this couldn't work?  If any MDM dropped out of
> network, then HUB-MDM would simply stop proxying on his behalf, and
> RTR-H should figure it out and kill the peer at BFD speeds.
> 
> Assuming I am on the correct track, would it be further possible to
> aggregate with the descrimitor field at HUB-MDM to only have one BFD
> session going for all Modems.  There could be thousands of MDM in one
> network and I would envision this could be a scale problem for RTR-H to
> manage all this, as well as pps scale issue processing all those for both RTR-
> H and HUB-MDM.
> 
> Any thoughts? I am new too this and wondering if I am on the right track or
> wasting my time considering BFD for this purpose..
> 
> Thanks,
> Brian Snyder
> Snr. Applied Researcher

---

From: Abdussalam Baryun <[email-masked]>
Date: Thu, 6 Mar 2014 07:39:49 +0100

Hi Nobo and Brian,

You discussion is not easy for me to find your theory in IETF or in MANET.
However, I never say no to reasonable discuss because it is why the list is
created.  Comments below,

On Thursday, March 6, 2014, Nobo Akiya (nobo) wrote:

> + MANET WG
>
> Hi Brian,
>
> I agree that no existing BFD would fit well into MANET scenario. Instead
> of a proxy approach, I would see variant of multipoint BFD or
> broadcast-style BFD may be simpler and more fitting, where each MANET
> interface would periodically broadcast BFD packets and remote state is
> maintained by reception of received BFD packets from remote MANET
> interfaces.

Was this MANET method BFD documented/published before in or out IETF?
Please give link

>
> If MANET WG thinks, in addition to DLEP, having an efficient hello
> mechanism will be useful and at layer 3, then this would be a technically
> interesting problem to discuss further.

I cannot think about it only if I can understand the purpose problem and
solution. I did not understand your points.

> > From: Rtg-bfd [mailto:[email-masked] <javascript:;>] On
> Behalf Of Snyder, Brian
> > To: [email-masked] <javascript:;>

Yes not standard, but it is published, adopted technology by some companies
and adopted by IETF MANET WG. Why you use BFD which still not published or
used for MANET in community. It may be good but not clear yet, and you did
not compare yet between performance of DLEP and BFD performance in MANET so
how you decided.

> > I'm thinking BFD could take the place, with a few caveats.

I don't think you convinced and your argument is weak. You replacing DLEP
by BFD in a MANET scenario, why?

> > connections is a viable solution (of course assuming no authentication).

How do you compare between both DLEP and BDF solutions for the problem,
then we can think clear of if BDF is viable.

 I don't think of new solution if I have better one published. I don't know
if viable only after comparing popular practice solution with new theory
solution.

Best regards
AB

---

From: "Snyder, Brian" <[email-masked]>
Date: Thu, 6 Mar 2014 13:59:19 +0000

Nobo,

Thank you for your advice.  My problem with periodic anything really would be the cost of bandwidth (even 1 small packet every second) would become very costly at scale. There could be thousands of modems in one network and inroute bandwidth is very expensive.  My space is very unique compared to terrestrial architectures given how precious bandwidth is (in both directions, but especially the inroute).   With this goal in mind I think proxying might be better.  I could still look into multipoint/broadcast BFD (I actually didn't realize those existed, I was just reading the original RFC I guess).  Maybe that could help me optimize the hub proxying on behalf of all these modems... but my goal still needs to be protect the satellite bandwidth  at all costs.

Quesiton: Could BFD allow for an actual proxying node on someone's behalf. Like is it possible to associate say 1000 different bgp peers/ospf  neighbors to the same IPADDR but with different discriminators.  So the hub equipment could track a MDM to Discriminator 'session'.  Therefore the upstream router implementation would need the ability to demultiplex that discriminator to different sessions - with the notion that the IP address you're connecting too is explicitly not the actual peer?  From my intpretation of RFC5880 that's not possible.      (But hopefully I'm wrong ;))

That being the case, is there any other way but to proxy (man-in-the-middle attack) the BFD flow?  That should be possible assuming no authentication -- but clearly less than ideal.

Regards,
Brian

-----Original Message-----
From: Nobo Akiya (nobo) [mailto:[email-masked]] 
Sent: Wednesday, March 05, 2014 8:42 PM
To: Snyder, Brian; [email-masked]; [email-masked]
Subject: RE: Hello, use case question about BFD

+ MANET WG

Hi Brian,

-Nobo

> I have just started researching BFD and am not sure it is a viable 
> solution to my networking problem.  If someone would be so kind as to 
> comment on below I would greatly appreciate it!
> 
> I am interested in determining if one could use BFD in place of a 
> radio aware routing methodology (like DLEP).  My problem with DLEP is 
> that it is not a standard yet and is therefore hard to build anything against.
> 
> It seems to me that BFD can't operate in an event driven mode, IE: 
> Sending a DOWN control packet.  Therefore it is very chatty, even 
> more-so then the
> L3 hello's I'm hoping to minimize.  Since the main purpose is to give 
> quicker convergence then I am willing to configure all the L3 HELLOs 
> (bandwidth is expensive in my environment), I was wondering if 
> 'proxy-ing' the BFD connections is a viable solution (of course assuming no authentication).
> 
> IE:
> 
> network and I would envision this could be a scale problem for RTR-H 
> to manage all this, as well as pps scale issue processing all those 
> for both RTR- H and HUB-MDM.
> 
> Any thoughts? I am new too this and wondering if I am on the right 
> track or wasting my time considering BFD for this purpose..
> 
> Thanks,
> Brian Snyder
> Snr. Applied Researcher

---

From: "Snyder, Brian" <[email-masked]>
Date: Thu, 6 Mar 2014 14:13:03 +0000

Baryun/Nobo, Thank you for your insight ... I appreciate the conversation.... My comments are embedded below --- Brian

From: Abdussalam Baryun [mailto:[email-masked]]
Sent: Thursday, March 06, 2014 1:40 AM
To: Nobo Akiya (nobo)
Cc: Snyder, Brian; [email-masked]; [email-masked]
Subject: Re: [manet] Hello, use case question about BFD

Hi Nobo and Brian,

You discussion is not easy for me to find your theory in IETF or in MANET. However, I never say no to reasonable discuss because it is why the list is created.  Comments below,

Hi Brian,

Was this MANET method BFD documented/published before in or out IETF? Please give link

[BS] - Not that I know of, this idea was a product of my own brainstorming (though others may have gone down this road and I am not aware - as I just joined both email lists recently).

I cannot think about it only if I can understand the purpose problem and solution. I did not understand your points.

-Nobo

> From: Rtg-bfd [mailto:[email-masked]<javascript:;>] On Behalf Of Snyder, Brian
> To: [email-masked]<javascript:;>

Yes not standard, but it is published, adopted technology by some companies and adopted by IETF MANET WG. Why you use BFD which still not published or used for MANET in community. It may be good but not clear yet, and you did not compare yet between performance of DLEP and BFD performance in MANET so how you decided.

[BS] - So for a few reasons I thought BFD actually solved my particular problem more elegantly.  DLEP would do what I am attempting to do but I have some technical and political concerns.

Technically, It seems much heavier then what I require. I have no need for all the flow control / qos stuff. I simply want to propagate link state for much faster L3 routing convergence.  So aside from all the extra complications DLEP brings to the solution, it is also more limiting.  There are no extensions (that I know of) for having DLEP work with BGP, which is the target routing method of a lot of my customers....

Which brings me to political issues... I feel I'll have very little say or ability to affect their decisions. If I tell them they must use OSPF for instance, I don't think they will agree.  Furthermore my second political concern, is it seems like one needs a less mainstream cisco build (The 'GC' line) in order to get DLEP functionality on the router.  I think it will be as big a battle to get folks to change their builds from their already approved and tested rollouts (similar to asking them to change routing protocols).  I think both these issues will make a DLEP solution very limiting to our audience.  Perhaps when DLEP is standardized and therefore promoted into mainstream routing builds, this political argument will disappear.... I would love for that to happen, but it's not there yet.

However, from what I can tell BFD has none of these issues.  It seems to be in standard cisco builds, it can be used with any higher level routing protocol as it's more 'interface scoped'.  This I felt just maps to my problem better.... with the caveat that it is very chatty and I need to cut that down.  So BFD has this DEMAND mode that can shut down the chattiness and if I can proxy it and send an ADMIN_DOWN to shut down routing peers/neighbors on behalf of modem link state, then I have solved all my problems without needing any OTA chatter - which is the only natural advantage to DLEP, in my use case.

> I'm thinking BFD could take the place, with a few caveats.

I don't think you convinced and your argument is weak. You replacing DLEP by BFD in a MANET scenario, why?

[BS] - I think I answered this above, please let me know if it's not clear.

> connections is a viable solution (of course assuming no authentication).

How do you compare between both DLEP and BDF solutions for the problem, then we can think clear of if BDF is viable.

[BS]  - Also I think explained above....

 I don't think of new solution if I have better one published. I don't know if viable only after comparing popular practice solution with new theory solution.

[BS] - I would agree with you but in this case it seems BFD is actually more mainstream then DLEP, which is a factor in my decision.

Best regards
AB