Subject: [babel] Thoughts on Other Use Cases

From: "Russ White" <[email-masked]>
Date: Wed, 12 Aug 2015 17:02:33 -0400

Y'all --

One thing that might be really nice is to have a brainstorm about alternate
use cases for BABEL. Two I can think of off the top of my head are:

1. Data center fabric underlay/overlay. I know we're all moving in the
BGP/eVPN direction on this right now, but I think BABEL could perform in
this space with a simpler/more tuned protocol. It would take adding some
things, such as some sort of "community" or policy support and some sort of
"any AF to any AF" sort of support, but this might be a solid use case for
fast convergences in a simple, pretty much self-configuring protocol.

 2. Much the same for something like DMVPNs, only with more support to get
closer to something like SD-WAN capabilities in a standards based setup.

3. A sort-of crazy idea, but one of the "bigger" problems with link state is
it's performance over large scale hub and spoke networks. One place EIGRP
has been really successful is in this space, actually. Perhaps some way of
doing large scale hub and spoke so the hub routers simply pull the
information as native link state protocol information. To put this another
way, to have BABEL serve as a "feeder" for a link state protocol, with no
redistribution. I'm not convinced this sort of thing is possible, but it
would be interesting to look at.

4. MANET -- as an alternative to the existing OSPF and other work.

Any more ideas? Thoughts on these ideas?

:-)

Russ

---

From: Margaret Cullen <[email-masked]>
Date: Wed, 12 Aug 2015 17:24:30 -0400

Interesting ideas, Russ.  I particularly like the idea of using babel as a data center underlay/overlay.

I am working on a transitive trust system for use with the IETF's abfab (GSS-EAP) security protocols.  The system deploys a number of "Trust Routers" that distribute information about "Trust Paths" to reach the AAA servers for target realms across a AAA fabric.  I have just started work on a dynamic "routing protocol" for this system.  I had been considering using a link-state algorithm, but I'm currently assessing the possibility of using a DV protocol based on babel, since it looks like it will be easier to implement and, perhaps more importantly, easier to test.

Margaret

On Aug 12, 2015, at 5:02 PM, "Russ White" <[email-masked]> wrote:

> _______________________________________________
> babel mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/babel

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 12 Aug 2015 23:47:19 +0200

Hi Russ,

> 1. Data center fabric underlay/overlay.
[...]
> It would take adding some things, such as some sort of "community" or
> policy support

As all DV protocols, Babel supports pretty much arbitrary filtering of
routes.  What is missing is the ability to attach opaque labels
("communities") to routes; while this could be added by an extension,
reliable filtering would require ensuring that all routers support the
extension.

Or is that not what you meant?

> some sort of "any AF to any AF" sort of support

Please clarify.

>  2. Much the same for something like DMVPNs

I'll pass on this one, not sure what's required from the routing protocol
for DMVPNs.  Is that not similar to your point (3) below?

> 3. A sort-of crazy idea, but one of the "bigger" problems with link
> state is it's performance over large scale hub and spoke networks.  One
> place EIGRP has been really successful is in this space

Agreed, with filtering and split-horizon processing, DV should scale
really well in this kind of topology.

> with no redistribution

Please clarify.

> 4. MANET -- as an alternative to the existing OSPF and other work.

(I think you meant OLSR.)

Actually, most of the deployment of Babel is happening in the community
mesh networking space and the proprietary MANET space.  While OLSRv2 is
a fine protocol, Babel has some properties that make it attractive in
large meshes:

 - much lower overhead on wired links and VPNs, especially if the
   frequency of periodic updates is tuned down;

 - ability to perform arbitrary route filtering and (manual) aggregation
   (OLSRv2 doesn't have areas, so it cannot perform filtering);

 - good support for dual-stack networks.

An interesting application is the Italian community mesh, where every
regional mesh uses its protocol of choice, and the meshes redistribute
into Babel and peer over VPNs.  I find it interesting that Babel has
filled the niche of BGP -- it's fairly natural to use DV for peering, due
to the filtering capabilities.

One feature that the community people find missing is the ability to find
out if two remote interfaces belong to the same router -- something you
get for free in link-state, but that you cannot determine at all in
distance vector.  I'm half tempted to implement an extension that allows
a router to announce its set of attached interfaces (e.g. within a sub-TLV
of the Hello TLV), unless somebody has a better idea.

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 12 Aug 2015 23:52:14 +0200

> The system deploys a number of "Trust Routers" that distribute
> information about "Trust Paths" to reach the AAA servers for target
> realms across a AAA fabric. [...]  I had been considering using
> a link-state algorithm, but I'm currently assessing the possibility of
> using a DV protocol based on babel

Note that if you're doing flat routing (host routes only), Babel can be
simplified a lot -- you don't need router-ids, just index everything by
addresses (the route table, the source table, the pending requests table,
the duplicate suppression table).  You can also get rid of the mechanism
in Section 3.5.5.

-- Juliusz

---

From: "Russ White" <[email-masked]>
Date: Wed, 12 Aug 2015 18:20:03 -0400

> As all DV protocols, Babel supports pretty much arbitrary filtering of
routes.
> What is missing is the ability to attach opaque labels

Right -- one of the points with a DC overlay is the ability to filter routes
using something like a route target, to reduce the number of devices that
need to hold specific routes in their table. You also need to have a route
distinguisher, which allows overlapping reachability information, and the
ability to differentiate multiple virtual topologies. All of these can be
solved with some sort of community system, or opaque tags.

> > some sort of "any AF to any AF" sort of support

One of the issues with overlay support would be the ability to have multiple
tunnel systems. For instance, you could have --

IPv4 over IPv6
IPv6 over IPv4
IPv4/IPv6 over MPLS
IPv4/IPv6 over VxLAN
Ethernet over MPLS
Ethernet over VxLAN

The idea here is just to have some sort of TLV that allows any address
family as a destination, and then any address family as the "next hop" for
this given destination. This would allow you to draw any traffic into any
sort of tunnel. BGP does this with a (possible more complex than necessary
for a DC fabric) address family system (originally designed for L3VPNs). We
could do something simpler in BABEL, I think for the DC fabric case. 

> I'll pass on this one, not sure what's required from the routing protocol
for
> DMVPNs.  Is that not similar to your point (3) below?

Yes, but combined with the AF above... DMVPNs are similar to an SD-WAN
solution, an tunneled overlay (virtual topology) on top of a straight IP
network. A lot of companies are working in this space right now with
proprietary systems; having an IETF standard that meets all the requirements
in a simpler protocol would make a lot of sense. Cisco uses EIGRP for this
function, BTW, so there's a close analog already out there we could draw
from in terms of system level design work.

> > state is it's performance over large scale hub and spoke networks.
> > One place EIGRP has been really successful is in this space
> 
really well
> in this kind of topology.
> 
> > with no redistribution
> 
> Please clarify.

In OSPF and IS-IS, you already have the concept of a flooding domain
boundary. What a lot of designers do is put the ABR (in OSPF terms) on the
hub router in a large scale hub and spoke network. Of course, you can use a
distance vector protocol, like EIGRP, in the hub and spoke, and then
redistribute the routes into the link state protocol, but it would actually
be a lot cleaner to have a way to simply pull the distance-vector routes in
so they look like they're internal to the link state protocol. 

As an example, look at the TTZ work going on in OSPF. Replace the TTZ
subzone running OSPF with a subzone running BABEL to get a general idea...
It would need more working out than that -- this is completely
brainstorming... :-)

> (I think you meant OLSR.)

OLSR and OSPF.

> mesh networking space and the proprietary MANET space.  While OLSRv2 is a
> fine protocol, Babel has some properties that make it attractive in large
> meshes:

Okay... So one thing we could do here is to level set against the
requirements there, to make certain everything is covered. It might be
interesting to see if there are overlaps between the different sets of
requirements for some potential use cases, to see what sorts of interesting
things could be done. For instance, the AF concept would be useful for an
SD-WAN solution, for a DC overlay, and even potentially for the MANET space.

> regional mesh uses its protocol of choice, and the meshes redistribute
into
> Babel and peer over VPNs.  I find it interesting that Babel has filled the
niche
> of BGP -- it's fairly natural to use DV for peering, due to the filtering
> capabilities.
> 
out
> if two remote interfaces belong to the same router -- something you get
for
> free in link-state, but that you cannot determine at all in distance
vector.  I'm
> half tempted to implement an extension that allows a router to announce
its
> set of attached interfaces (e.g. within a sub-TLV of the Hello TLV),
unless
> somebody has a better idea.

Interesting idea... If you included an interface id of some sort in each
origination of reachability information, then the router information
advertisement could just contain a list of interface id's, and everything
could be connected together. One problem is going to be when these should be
filtered... If you aggregate routing information at some point, do you
somehow summarize routers behind the aggregation point, or simply remove
this information, or... ??

:-)

Russ

---

From: "Russ White" <[email-masked]>
Date: Wed, 12 Aug 2015 18:21:06 -0400

> Interesting ideas, Russ.  I particularly like the idea of using babel as a
data
> center underlay/overlay.

I do, too, actually... We're using a lot of BGP in this space. Something
simpler might get some attention, particularly if it knows how to play nice
with overlay tunnels and programmability to manage policy.

> I am working on a transitive trust system for use with the IETF's abfab
(GSS-
> EAP) security protocols.  The system deploys a number of "Trust Routers"
> that distribute information about "Trust Paths" to reach the AAA servers
for
> target realms across a AAA fabric.  I have just started work on a dynamic
> "routing protocol" for this system.  I had been considering using a
link-state
> algorithm, but I'm currently assessing the possibility of using a DV
protocol
> based on babel, since it looks like it will be easier to implement and,
perhaps
> more importantly, easier to test.

This is interesting... Do you have docs?

:-)

Russ

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 13 Aug 2015 00:46:12 +0200

> All of these can be solved with some sort of community system, or
> opaquetags.

Yes.  That's something that's been repeatedly requested.  I'm not sure
what format the labels should have, though -- arbitrary length binary
blobs?  Triples (registry, tag-type, value)?  Obviously, this should be
redistributable into other routing protocols, so its format matters.

> Ethernet over VxLAN

Ah, I see.  RFC 6126 defines v4/v6 and v6/v4 operation, but the
implementation only supports v4/v6.  I know very little about MPLS, and
nothing about VxLAN.

> this given destination.

Yes, Babel supports that.  See Sections 4.1.3 and 4.4.8 of RFC 6126.

> could be connected together.

That was the design of Babel version 0 (current version is 2).  I decided
against it in the end, since as you justly note it prevents arbitrary
filtering, which is something that people really want, and since it
complicates the protocol somewhat.  I replaced that with prefix
compression (stolen from OLSRv2), which provides similar benefits without
the limitations and cleanly packages the complexity in the TLV parser.

The new extension is meant to be purely informational, and not used by the
core protocol -- the mesh communities are big on monitoring GUIs.

-- Juliusz

---

From: Margaret Cullen <[email-masked]>
Date: Wed, 12 Aug 2015 23:13:13 -0400

> the duplicate suppression table).  You can also get rid of the mechanism

Thanks, Juliusz.  I had it in my queue to look at the spec and figure out what parts of the babel protocol (and possibly the babel implementation) would/would not be needed for flat routing.  This advice will speed up that effort.

Margaret

---

From: Henning Rogge <[email-masked]>
Date: Thu, 13 Aug 2015 06:39:28 +0200

>> (I think you meant OLSR.)

Did you ever tried one of the OSPF Manet extensions? I have a few
co-workers that had a lot of problems with them...

Henning Rogge

---

From: Margaret Cullen <[email-masked]>
Date: Thu, 13 Aug 2015 00:48:25 -0400

> This is interesting... Do you have docs?

There were some old (expired) drafts on this subject named:

draft-mrw-abfab-multihop-fed-02, and
draft-mrw-abfab-trust-router-02.

However, things have moved along a bit since then.  The latest docs and code are being developed as part of the Moonshot open source project found here:  

https:/wiki.moonshot.ja.net/

We tried to bring the Trust Identity Protocol (the transitive trust protocol) and the Trust Router Protocol (the routing protocol that is used to choose a path of transitive trust across a federation) to the IETF a couple of years ago, but at that time we were only piloting the technology in the UK and there wasn't much interested from anyone but European universities and associated entities.  Stephen Farrell didn't want to charter the work without interest from the commercial sector, so we have been working on this outside of the IETF since then.

The work has matured significantly since the drafts were last updated.  We have an operational Moonshot federation among universities in the UK (using a single Trust Router), and we are piloting a European-wide federation with multiple Trust Routers over the next year.  Once we have a multi-Trust Router federation operational, we may come back to the IETF to see if there is greater interest in standardizing this work.

If you might be interested in following this work, let me know, and I will find out how you can joint he associated mailing lists.

Margaret