Subject: [manet] BFD Proxy Idea

From: "Snyder, Brian" <[email-masked]>
Date: Tue, 22 Jul 2014 23:35:01 +0000

Everyone,

As I presented , I think the main problems I had in adopting DLEP were:

*        Multicast support

*        VLAN support

*        Scalability

>From a radio point of view, I would like to get these issues addressed (or at least discussed) so they can work their way into the DLEP definition.

Ideally, I could use DLEP, as it does have some advantages over BFD, to solve the problem I described.

Further, I think it would be interesting if we considered defining an ability to use BFD to connect to a DLEP instance in order to manage the link up/down setting.  This could be useful if one was using DLEP over virtual interfaces.

Finally, as I didn't  quite get to finish my presentation due to time constraints, I also wanted to mention that I would be here all week and would be happy to have further conversation on my presentation if anyone was interested.  Please feel free to email me and we can pick a coffee spot to continue talking.

Thanks,
Brian

---

From: Thomas Clausen <[email-masked]>
Date: Tue, 22 Jul 2014 19:43:04 -0400

Dear Brian,

> On 22 Jul 2014, at 19:35, "Snyder, Brian" <[email-masked]> wrote:
> 
> Everyone,
>  
> ·        Multicast support
> ·        VLAN support
> ·        Scalability

I think that it would be a significant help if you could point out "how" -- for dummies like me, who do not understand satcom very well ;)

> Further, I think it would be interesting if we considered defining an ability to use BFD to connect to a DLEP instance in order to manage the link up/down setting.  This could be useful if one was…

OK, this makes sense to me.
 
> Finally, as I didn’t  quite get to finish my presentation due to time constraints, I also wanted to mention that I would be here all week and would be happy to have further conversation on my presentation if anyone was interested.  Please feel free to email me and we can pick a coffee spot to continue talking.

To mix up (at least, two) metaphors, I have no dogs in this race -- but I throughly enjoyed both your presentation and reading your I-D, which was particularly well written and easy to digest.

Cheers,

Thomas

>  
> Thanks,
> Brian
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Tue, 22 Jul 2014 23:54:09 +0000

Brian,

On Jul 22, 2014, at 7:35 PM, "Snyder, Brian" <[email-masked]<mailto:[email-masked]>>
 wrote:

Everyone,

•        Multicast support
•        VLAN support
•        Scalability

I wasn't able to remotely attend today's meeting. For that, my apologies. I'll take a look at your slides, and let's communicate as to what your adoption issues are.

>From a radio point of view, I would like to get these issues addressed (or at least discussed) so they can work their way into the DLEP definition.

I'd be happy to discuss DLEP issues. That's one of the things this forum is for… ;-)

Not sure I understand what you mean here. BFD and DLEP both manage the link up/down setting, but do so via different approaches. BFD relies on continuously sending packets over the link; DLEP relies on "smart modems" to tell the router about link status. How do you envision connecting the two?

I'm not in Toronto, and therefore can't pick a coffee spot, but as I said, I'm interested in talking about DLEP.

Regards,
Stan

Thanks,
Brian
_______________________________________________
manet mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/manet

---

From: "Snyder, Brian" <[email-masked]>
Date: Wed, 23 Jul 2014 03:21:22 +0000

Stan, Thomas, & All,

First let me try and explain my use case a bit better, as it's probably not the typical network designers had in mind...

I have been very involved with designing and prototyping a layer 2 sat based product offering.  As we transition away from "typical" L3 network architecture our next logical step has been for some time to get into RAR/DLEP/ETC to better optimize L3 routing convergence over the satellite for our customers.  The main idea being to allow them to tune down their L3 "HELLOS" and try and drive a more event driven model to conserver very expensive satellite bandwidth (while keeping decent convergence times).  We know there would be a ton of demand for this if we can solve this particular radio link - router optimization (faster convergence of Layer 3 CE devices behind the modems and hub), which is exactly what DLEP is for.. but my network architecture is hub and spoke, not mesh.  The scalability of the spokes is simple - they just need 1 DLEP and ROUTING peer - the hub.  However, the hub radio will terminate (and represent via DLEP to upstream router) potentially thousands of spokes.  

DLEP seems like a perfect match from everything I've read. but in many ways it seems more complicated than is necessary for my use case.    For instance, it would be ideal for me to simply be able to set interfaces logically down, yet NOT have to have a routing protocol specifically tied in (like BFD).  That way I don't have to force any particular network architecture on my customers.... afterall, the main reason we are going L2 is to be transparent. That ideal loses some steam if I then have to force very narrow routing options on them when in L3 mode they have more choices.  I don't want the congestion/route control features necessarily (for now that is overkill to me), but I would love to be able to easily set peers or links "down" to immediately converge routing tables as a Modem falls out (or reenters) the network.  Thus avoiding all L3 timers.  Essentially I'd like to pull a virtual Ethernet plug. 

The added functionality is great, and potentially useful down the road, but the downside then is that it requires OSPF or EIGRP.  Preferably, I wouldn't care if a customer wanted BGP or RIP, etc. if I could logically set the interface down via Radio control messages then all my timing/convergence problems would be solved.  Is there a simpler way of doing this within the confines of DLEP?  As stated above, the hub side has additional complexity as it will aggregate for potentially thousands of modems.  

So I fully admit, that I am not sure I'm understanding it all correctly, and I've only played with Cisco's implementation so I very well may (probably likely) have my lines blurred between the standard that DLEP defines and exactly what is practically implemented and available to use .. This is likely throwing my understanding of the standard off.. but when I looked at it a few months ago (before I ended up going down the BFD route) I was concerned that I would need thousands of virtual interfaces at the upstream router and I knew that wouldn't scale.   This sheer # of virtual of interfaces would also cascade into multicast issues (My hub link is a broadcast medium and I can't have packets replicated).  Also, AFAIK, supporting VLAN with this model is not an option.  Perhaps one could setup multiple neighbors to each router via DLEP using multiple interfaces per VLAN per modem - but that would just make the scaling even worse - by an order of magnitude (we expect 10 to 12 vlans per modem).  Alternatively, and ideally, we could support the notion of VLAN trunking into the DLEP interface but I don't think that's currently supported, (again though, that could just be a limitation of the VMI design in cisco's implementation).

BFD it turns out removes a lot of these concerns - but it's significantly chattier - which is why I came up with the proxy idea, since as Rick eloquently stated - I have some radio magic I can rely on for link state - I think because it works on interfaces and doesn't require all the VMI stuff, it just seems to scale better.  BUT (big but) it's very chatty in its own right and I can't have any link state information shared, which would be ideal...  

Primarily, I feel I have a MANET problem/use case - and that if we think about it (or I get more educated:) it should be solved within MANET technologies.....  I surprised myself at the end of this research to land on BFD... I think because I'm proxying it, I've essentially created a DLEP-light for router - radio link state notifications.
 
I hope that explains some of my concerns and design issues with what I currently have to work with.  I'm sure I've made some bad assumptions - so please have at me :)

Side note: My observations are what I had in hand to work with, not necessarily what the draft says. I'm guessing this is poor form for IETF conversations, so apologies if I've crossed a line... I'm new here ;)  Perhaps newer DLEP drafts address some of these issues, and I just have to stick with BFD until there are practical implementation I could try and integrate with.....  It's my understanding the sourceforge reference implementation is based on draft-0 which is quite out-of-date already.

Thanks for reading this far,
Brian

From: Thomas Clausen [mailto:[email-masked]] 
Sent: Tuesday, July 22, 2014 7:43 PM
To: Snyder, Brian
Cc: [email-masked]
Subject: Re: [manet] BFD Proxy Idea

Dear Brian,
 
. Multicast support
. VLAN support
. Scalability

Cheers,

Thomas

Thanks,
Brian

---

From: Henning Rogge <[email-masked]>
Date: Wed, 23 Jul 2014 12:44:18 +0200

On Wed, Jul 23, 2014 at 5:21 AM, Snyder, Brian <[email-masked]> wrote:
> I have been very involved with designing and prototyping a layer 2 sat based product offering.  As we transition away from "typical" L3 network architecture our next logical step has been for some time to get into RAR/DLEP/ETC to better optimize L3 routing convergence over the satellite for our customers.  The main idea being to allow them to tune down their L3 "HELLOS" and try and drive a more event driven model to conserver very expensive satellite bandwidth (while keeping decent convergence times).

In the "DLEP-model" this would be a modification of the routing
agent... because DLEP does not produce any traffic over the wireless
link, just locally between the radio and the router.

> We know there would be a ton of demand for this if we can solve this particular radio link - router optimization (faster convergence of Layer 3 CE devices behind the modems and hub), which is exactly what DLEP is for.. but my network architecture is hub and spoke, not mesh.  The scalability of the spokes is simple - they just need 1 DLEP and ROUTING peer - the hub.  However, the hub radio will terminate (and represent via DLEP to upstream router) potentially thousands of spokes.

I see no real trouble with this for DLEP... the "spoke" DLEP-radios
will just deliver a single detected neighbor (the hub) while the hub
will get all of the neighbors...

> DLEP seems like a perfect match from everything I've read. but in many ways it seems more complicated than is necessary for my use case.    For instance, it would be ideal for me to simply be able…

This should be exactly what DLEP is able to do... forward the layer-2
radio event to the router.

> The added functionality is great, and potentially useful down the road, but the downside then is that it requires OSPF or EIGRP.

Why?

> Preferably, I wouldn't care if a customer wanted BGP or RIP, etc. if I could logically set the interface down via Radio control messages then all my timing/convergence problems would be solved.  Is there a simpler way of doing this within the confines of DLEP?  As stated above, the hub side has additional complexity as it will aggregate for potentially thousands of modems.

The problem I see is that you cannot take the local interface on the
router down, because you would also loose your DLEP session. Maybe you
could setup a virtual interface on the router that just has the
user-traffic (without the DLEP session) which you can take up/down
controlled by the DLEP instance on the router?

> So I fully admit, that I am not sure I'm understanding it all correctly, and I've only played with Cisco's implementation so I very well may (probably likely) have my lines blurred between the standard that DLEP defines and exactly what is practically implemented and available to use .. This is likely throwing my understanding of the standard off.. but when I looked at it a few months ago (before I ended up going down the BFD route) I was concerned that I would need thousands of virtual interfaces at the upstream router and I knew that wouldn't scale.

I think you would only need one interface per radio interface, not one
per neighbor.

> This sheer # of virtual of interfaces would also cascade into multicast issues (My hub link is a broadcast medium and I can't have packets replicated).

DLEP allows the radio to announce a multicast target (both with
ethernet and IP address).

> Also, AFAIK, supporting VLAN with this model is not an option.  Perhaps one could setup multiple neighbors to each router via DLEP using multiple interfaces per VLAN per modem - but that would just make the scaling even worse - by an order of magnitude (we expect 10 to 12 vlans per modem).  Alternatively, and ideally, we could support the notion of VLAN trunking into the DLEP interface but I don't think that's currently supported, (again though, that could just be a limitation of the VMI design in cisco's implementation).

First time for me that I hear you need a VLAN for each neighbor seen
by a DLEP radio.

Henning Rogge

---

From: Abdussalam Baryun <[email-masked]>
Date: Wed, 23 Jul 2014 13:34:24 +0200

Hi Brian. I think your use case may be different than DLEP use case but can
use it. Comments below;

On Wed, Jul 23, 2014 at 5:21 AM, Snyder, Brian <[email-masked]> wrote:

> Stan, Thomas, & All,
>
> First let me try and explain my use case a bit better, as it's probably
> not the typical network designers had in mind...
>
> I have been very involved with designing and prototyping a layer 2 sat
> based product offering.  As we transition away from "typical" L3 network
> architecture our next logical step has been for some time to get into
> RAR/DLEP/ETC to better optimize L3 routing convergence over the satellite
> for our customers.

That is good for Sat Nets to use L2 products; and to use DLEP is suitable
which was discussed before by authors in previous meeting (I think in IETF
86 or 87).

>   The main idea being to allow them to tune down their L3 "HELLOS" and try
> and drive a more event driven model to conserver very expensive satellite
> bandwidth (while keeping decent convergence times).

Hellos/signallings can be reduced within the routing discovery or in the
NHDP as in Sat Nets usually the links are connected in longer times because
of large/LOS coverage. (Did I understand your use case).

>  We know there would be a ton of demand for this if we can solve this
> particular radio link - router optimization (faster convergence of Layer 3
> CE devices behind the modems and hub), which is exactly what DLEP is for..
> but my network architecture is hub and spoke, not mesh.  The scalability of
> the spokes is simple - they just need 1 DLEP and ROUTING peer - the hub.
>  However, the hub radio will terminate (and represent via DLEP to upstream
> router) potentially thousands of spokes.
>

The DLEP works fine with this I think but I am not sure with the problem of
termination; why terminated at hub.

>
> DLEP seems like a perfect match from everything I've read. but in many
> ways it seems more complicated than is necessary for my use case.    For
> instance, it would be ideal for me to simply be able to set interfaces
> logically down, yet NOT have to have a routing protocol specifically tied
> in (like BFD).

DLEP is not tied to one routing protocol otherwise it will not be flexible.

> That way I don't have to force any particular network architecture on my
> customers.... afterall, the main reason we are going L2 is to be
> transparent.

Yes DLEP is transparent too.

> That ideal loses some steam if I then have to force very narrow routing
> options on them when in L3 mode they have more choices.  I don't want the
> congestion/route control features necessarily (for now that is overkill to
> me), but I would love to be able to easily set peers or links "down" to
> immediately converge routing tables as a Modem falls out (or reenters) the
> network.  Thus avoiding all L3 timers.  Essentially I'd like to pull a
> virtual Ethernet plug.
>
> The added functionality is great, and potentially useful down the road,
> but the downside then is that it requires OSPF or EIGRP.  Preferably, I
> wouldn't care if a customer wanted BGP or RIP, etc. if I could logically
> set the interface down via Radio control messages then all my
> timing/convergence problems would be solved.  Is there a simpler way of
> doing this within the confines of DLEP?  As stated above, the hub side has
> additional complexity as it will aggregate for potentially thousands of
> modems.

In Sat Net hub does not need thousands modems it already has its multiple
access multiplexing should be solved by L2 not by DLEP or any other product.

>
>
> So I fully admit, that I am not sure I'm understanding it all correctly,
> and I've only played with Cisco's implementation so I very well may
> (probably likely) have my lines blurred between the standard that DLEP
> defines and exactly what is practically implemented and available to use ..
> This is likely throwing my understanding of the standard off.. but when I
> looked at it a few months ago (before I ended up going down the BFD route)
> I was concerned that I would need thousands of virtual interfaces at the
> upstream router and I knew that wouldn't scale.

The routers work for L3 not in L2 so your new product needs to stay in L2
as you first mentioned before. I still think DLEP is suitable for your case
may be DLEP authors can advise better than me.

> This sheer # of virtual of interfaces would also cascade into multicast
> issues (My hub link is a broadcast medium and I can't have packets
> replicated).

In Sat Net the broadcasting or multicasting using the hub interfaces
issues should be solved in the L2 and not in L3. Multicast between routers
are done in L3. However; the extension that Rick is doing for DLEP for L3
may help in your alternative solutions and that will mean you change your
choice to a L3 product.

>  Also, AFAIK, supporting VLAN with this model is not an option.  Perhaps
> one could setup multiple neighbors to each router via DLEP using multiple
> interfaces per VLAN per modem - but that would just make the scaling even
> worse - by an order of magnitude (we expect 10 to 12 vlans per modem).
>  Alternatively, and ideally, we could support the notion of VLAN trunking
> into the DLEP interface but I don't think that's currently supported,
> (again though, that could just be a limitation of the VMI design in cisco's
> implementation).
>
> BFD it turns out removes a lot of these concerns - but it's significantly
> chattier - which is why I came up with the proxy idea, since as Rick
> eloquently stated - I have some radio magic I can rely on for link state -
> I think because it works on interfaces and doesn't require all the VMI
> stuff, it just seems to scale better.  BUT (big but) it's very chatty in
> its own right and I can't have any link state information shared, which
> would be ideal...
>

IMHO the BFD does not work well in your case or for MANET cases.

>
> Primarily, I feel I have a MANET problem/use case - and that if we think
> about it (or I get more educated:) it should be solved within MANET
> technologies.....  I surprised myself at the end of this research to land
> on BFD... I think because I'm proxying it, I've essentially created a
> DLEP-light for router - radio link state notifications.
>

BFD is not for routing but DLEP is for routing. This WG is doing routing
use cases but your problem may include other issues.

>
> I hope that explains some of my concerns and design issues with what I
> currently have to work with.  I'm sure I've made some bad assumptions - so
> please have at me :)
>

I hope I undertood as well and I thank you for your presentation and ID
which I will do my best to read while our WG is adopting many drafts with
few reviews/discussions.

AB

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Wed, 23 Jul 2014 14:37:33 +0000

> I have been very involved with designing and prototyping a layer 2 sat based product offering.  As we transition away from "typical" L3 network architecture our next logical step has been for some…

I could see implementing this type of architecture this way - At the spoke modem, DLEP only reports the presence/absence of the hub. At the hub modem, it would need to report presence/absence of all of the spokes as they come and go. 

> The added functionality is great, and potentially useful down the road, but the downside then is that it requires OSPF or EIGRP.  Preferably, I wouldn't care if a customer wanted BGP or RIP, etc. i…

I think that's a case where you have crossed from the specification over to Cisco's implementation. The DLEP spec doesn't mention any routing protocol. From a DLEP perspective, we took the tack of saying "Let's figure out what data items are important for a router and modem to communicate, and then let's produce a protocol to fling them across the chasm between router and modem." The issues of what to do with said data items (and what protocol or protocols they should be fed into) is left to implementers. As for the current Cisco implementation, you are correct - BGP and RIP aren't supported. That's not a DLEP spec issue, however. 

> So I fully admit, that I am not sure I'm understanding it all correctly, and I've only played with Cisco's implementation so I very well may (probably likely) have my lines blurred between the stan…

This could be a problem. As you state up front, the hub may have "thousands of spokes". Again, it's not a DLEP specification issue - but from a DLEP perspective, you'll correspondingly have thousands of "Destinations" that are up in that network, *each* with the potential of having a varying amount of bandwidth. The question would be exactly how the attached router would go about dealing with that notion: would it do so using just a single interface? Or multiple virtual interfaces? That falls into a specific implementation's purview.

> 
> BFD it turns out removes a lot of these concerns - but it's significantly chattier - which is why I came up with the proxy idea, since as Rick eloquently stated - I have some radio magic I can rely on for link state - I think because it works on interfaces and doesn't require all the VMI stuff, it just seems to scale better.  BUT (big but) it's very chatty in its own right and I can't have any link state information shared, which would be ideal…  

Again, the "VMI stuff" you refer to is implementation-specific. I'd be happy to continue that part of the discussion with you (the implementation-specific part), but not on this list… ;-)

> Primarily, I feel I have a MANET problem/use case - and that if we think about it (or I get more educated:) it should be solved within MANET technologies.....  I surprised myself at the end of this…

FWIW, I agree that you have a MANET use case. And as a completely, unabashedly, totally *BIASED* observer, I think DLEP addresses most (if not all) of your needs… ;-) I think there are potentially some implementation issues with the code you have. If you'd like to continue that implementation-specific discussion, please let me know off-list.

Regards,
Stan

---

From: Rick Taylor <[email-masked]>
Date: Wed, 23 Jul 2014 15:38:34 +0000

Stan, Brian, et.al.

I had a long and very productive chat with Brian, and I hope I was able to help him differentiate between DLEP and Cisco's implementation.

>From my perspective, his BFD work seems to e his attempt to work around an issue he has with his selected implementation, and that Brian you should definitely take up with Stan!

I hope I have managed to bring him up to speed on some of the features that have come into DLEP since draft-00, allowing him to implement DLEP in his modems, including only the bits he can actually support given his use-case, but I will let Brian clarify...

Offline I discussed this problem with John Dowdell, and he raised the old issue with Satcom DAMA, Metrics and Link Characteristic Requests, so I'm really pleased that there is someone from the Satcom community who can speak from a position of authority on their use-cases.

In conclusion, I hope I have verbally convinced Brian that DLEP is the right way to go, and that his issues seem to be mostly with a specific implementation rather than the underlying protocol.  I'm not sure what Brian feels is the best way forwards with his draft, perhaps an information draft describing how BFD could be used as the 'radio magic' behind a DLEP implementation in not very MANET MANET (if that makes any sense).

As I have said before Brian, any non-Cisco questions concerning DLEP, please fire them onto the list and we will do our best to help!

Cheers,

Rick Taylor   
________________________________________
From: manet [[email-masked]] on behalf of Stan Ratliff (sratliff) [[email-masked]]
Sent: 23 July 2014 15:37
To: Snyder, Brian
Cc: [email-masked]; Thomas Clausen
Subject: Re: [manet] BFD Proxy Idea

Regards,
Stan