Subject: Re: [babel] Babel filtering: routing policies

From: Mahesh Jethanandani <[email-masked]>
Date: Thu, 22 Aug 2019 19:05:42 -0700

Hi Juliusz,

Following up on this e-mail to understand how to implement the routing policies for Babel.

> On Jul 24, 2019, at 2:36 PM, Juliusz Chroboczek <[email-masked]> wrote:
> 
> Dear Barbara, dear Mahesh,
> 
> All distance-vector routing protocols, including BGP and Babel,
> intrinsically support flexible routing policies.  In the Babel community,
> we consider the way of defining such policies as an implementation
> feature, and they are not part of the protocol definition.
> 
> The following therefore applies to babeld, the "reference" implementation.
> 
> In babeld, we speak about filter chains.  A route goes through each filter
> in a filter chain at four points in Babel:
> 
>  "in" chain, when the route is learnt from a neighbour;
>  "install" chain, when the route is installed in the kernel;
>  "redistribute" chain, when the route is learnt from the kernel;
>  "out" chain, when the route is announced to a neighbour.

In order to make sure we are talking the same language, would you say a given chain is equivalent of a “defined set” as defined by draft-ietf-rtgwg-policy-model <https://tools.ietf.org/html/draft-ietf-rtgwg-policy-model-06>? I understand that these are babel specific, so I will extend the policy model to add these chains as “defined sets". I am also assuming that there is one instance of each chain (or defined set). In other words, we are not looking at multiple “in” chains, as an example.

> 
> When a filter chain is applied, the individual filters in a chain are
> checked, and the first filter that applies to the route is executed.
> A filter can perfrom the following actions:
> 
>  "allow" -- pass the route unchanged, equivalent to "metric 0";
>  "deny" -- drop the route;
>  "metric nnn" -- add nnn to the metric value.
> 
> There exist other actions, more specialised -- see the manual page for
> details.

I see two more, src-prefix and table. Is there more?

> 
> Babeld implements a rich language for matching routes -- it can match on
> next-hop address, on destination prefix, on destination prefix length, on
> the router-id of the originating router, etc.  Again, see the manual page
> for details.

I am looking at the following conditions (in the routing policy model language) specified in the man page.

       ip prefix
              This entry only applies to routes in the given prefix.

       eq plen
              This entry only applies to routes with a prefix length equal to plen.

       le plen
              This entry only applies to routes with a prefix length less or equal to plen.

       ge plen
              This entry only applies to routes with a prefix length greater or equal to plen.

       src-ip prefix
              This entry only applies to routes with a source prefix in the given prefix.

       src-eq plen
              This entry only applies to routes with a source prefix length equal to plen.

       src-le plen
              This  entry  only  applies  to  routes with a source prefix length less or equal to
              plen.

       src-ge plen
              This entry only applies to routes with a source prefix length greater or  equal  to
              plen.

       neigh address
              This  entry only applies to routes learned from a neighbour with link-local address
              address.

       id id  This entry only applies to routes originated by a router with router-id id.

       proto p
              This entry only applies to kernel routes with kernel protocol number p.  If neither
              proto  nor  local  is  specified, this entry applies to all non-local kernel routes
              with a protocol different from "boot".

       local  This entry only applies to local addresses.

       if interface
              For an input filter, this specifies the interface over which the route is  learned.
              For  an  output  filter,  this  specifies  the  interface  over which this route is
              advertised.  For a redistribute statement, this specifies the interface over  which
              the route forwards packets.
Note, the policy module defines a default set of conditions like prefix sets, so some of your examples should be take care of with them.

Anything else that I am missing?

> 
> Examples
> ========
> 
> ## Default filters
> 
>    in allow
> 
>    out allow
> 
>    redistribute local allow
>    redistribute deny
> 
>    install allow
> 
> These are the default chains if no filters are defined, and are suitable
> for a mesh node with no attached prefixes.  They say that babeld is
> promiscuous (it learns all routes and announces all routes), it only
> redistributes local node addresses, and installs any routes that it learns
> unchanged.
> 
> ## Traditional router
> 
>  redistribute proto 2 allow
>  redistribute deny
> 
> This overrides the default to not redistribute any local addresses, but to
> redistribute any locally attached prefixes.  This is the default behaviour
> or a traditional router.
> 
> ## Traditional router with redistribution
> 
>  redistribute proto 2 allow
>  redistribute proto 11 metric 32384
>  redistribute deny
> 
> This says to additionally redistribute any routes learned from
> Zebra/Quagga/FRR, but to attach them with a higher metric -- Babel routes
> will thus be preferred to FRR routes.
> 
> ## Stub router
> 
>  redistribute proto 2 allow
>  redistribute deny
> 
>  out ip 192.168.42.0/24 allow
>  out ip 2001:db8:4242::/48 allow
>  out deny
> 
> This says to learn routes promiscuously, but to only reannounce routes in
> the given prefixes.  This is typical of a stub router, that only announces
> routes in the local prefixes.
> 
> ## Default router
> 
>  out ip 0.0.0.0/0 le 0 allow
>  out ip ::/0 le 0 allow
>  out deny
> 
> This router only announces default routes.
> 
> ## IPv6 border router
> 
>  in ip ::/0 allow
>  in deny
> 
>  out if eth0 ip 2001:db8:4242::/48 le 48 allow
>  out if eth0 deny
> 
>  out if eth1 ip 2001:db8:5757::/48 le 48 allow
>  out if eth1 deny
> 
> This router sits at the interface between two networks, and only announces
> a route summarising a whole network to the other network.  This reduces
> the amount of traffic, at the cost of non-optimal routing.
> 
> ## Ignoring bad routers
> 
>  in if eth0 nh fe80::1 deny
>  in router-id 12:34:56:78:9a:bc deny
>  in allow
> 
> This router ignores routes from a given next hop as well as routes
> originated by a given router-id.  This can be used to temporarily
> blackhole a mis-configured router, before it is fixed.
> 
> -- Juliusz
> 
> 
> 
> 

Mahesh Jethanandani
[email-masked]

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sat, 24 Aug 2019 00:27:01 +0200

> In order to make sure we are talking the same language, would you say a given
> chain is equivalent of a “defined set” as defined by
> draft-ietf-rtgwg-policy-model?

No.  A chain would correspond to a sequence of policy statements, if
I read this document right.

> I understand that these are babel specific,

I think that only matching on router-id is Babel-specific, all the others
are fairly generic.

> will extend the policy model to add these chains as “defined sets".

I don't think you need to extend anything.  Matching on router-id is not
essential.

On the other hand, it looks to me like it's more expressive than anything
that any implementation of Babel known to me has ever implemented.  Since
I'm still not sure what's the purpose of the YANG model, I don't know if
that's a problem or not.

> I see two more, src-prefix and table. Is there more?

Not in babeld.  I haven't checked BIRD.

-- Juliusz

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Sat, 24 Aug 2019 02:53:11 +0000

In looking at https://tools.ietf.org/html/draft-ietf-rtgwg-policy-model-06, I'm left wondering if any of this is useful wrt Babel. I can't see anyone implementing the hooks to make such policy configurable in Babel (because it doesn't seem to be needed). If someone really wants something like this in the future, maybe they can do it then?
Barbara

> > In order to make sure we are talking the same language, would you say
> > a given chain is equivalent of a “defined set” as defined by
> No.  A chain would correspond to a sequence of policy statements, if I read
> this document right.
> 
> I think that only matching on router-id is Babel-specific, all the others are
> fairly generic.
> 
> On the other hand, it looks to me like it's more expressive than anything that
> any implementation of Babel known to me has ever implemented.  Since I'm
> still not sure what's the purpose of the YANG model, I don't know if that's a
> problem or not.
>

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sat, 24 Aug 2019 11:53:16 +0200

> In looking at https://tools.ietf.org/html/draft-ietf-rtgwg-policy-model-06,
> I'm left wondering if any of this is useful wrt Babel. I can't see
> anyone implementing the hooks to make such policy configurable in Babel
> (because it doesn't seem to be needed).

Babeld implements quite a bit of this already, see the section "filtering
rules" in the babeld documentation.  BIRD uses an even richer language, see

  https://bird.network.cz/?get_doc&v=20&f=bird-5.html

There's a human-readable description here:

  https://tools.ietf.org/html/draft-ietf-babel-rfc6126bis-14#appendix-C

(Which it's not too late to proof-read, by the way.)

The question, of course, is whether we want to model that in a unusual
object model encoded over XML, or whether it can remain an implementation
detail.  I'm not going to bore you with my opinion (since you already know
my take on unusual object models encoded in XML).

-- Juliusz

---

From: Mahesh Jethanandani <[email-masked]>
Date: Sat, 24 Aug 2019 18:19:15 -0700

Hi Juliusz,

> On Aug 24, 2019, at 2:53 AM, Juliusz Chroboczek <[email-masked]> wrote:
> 

If you rewind back a few meetings (103 to be precise), I did ask this question to the WG. Martin, our AD was the one to respond in the affirmative. 

This is something that is bound to come up when this document goes through IESG LC, so I am being proactive by addressing it now.

Cheers.

Mahesh Jethanandani
[email-masked]

---

From: Mahesh Jethanandani <[email-masked]>
Date: Sun, 25 Aug 2019 21:52:39 -0700

> On Aug 23, 2019, at 3:27 PM, Juliusz Chroboczek <[email-masked]> wrote:
> 

According to the routing policy draft.

   Policy statements in turn consist of simple condition-action tuples.

but what you seem to be defining by “install”, “redistribute” and “out” are ...

   The models provides a set of generic sets that can be used for
   matching in policy conditions.  These sets are applicable for route
   selection across multiple routing protocols.  They may be further
   augmented by protocol-specific models which have their own defined
   sets. 

If not, how would you define your sets?
 
> I'm still not sure what's the purpose of the YANG model, I don't know if

If any particular implementation does not support the more expressive policy statement, they can choose to deviate (not support) these policies. It can choose to support only the policies it defines.

Thanks.

---

From: Mahesh Jethanandani <[email-masked]>
Date: Tue, 27 Aug 2019 11:50:08 -0700

> I'm still not sure what's the purpose of the YANG model, I don't know if

After reviewing the man page on babeld, and draft-ietf-rtgwg-policy-model, I have to agree with Juliusz that draft-ietf-rtgwg-policy-model does more than what is expressed in the babeld man page. There are a few things like router-id that the routing policy module does not model, which Juliusz says is not necessary.

Therefore I am inclined not to try to define a module to extend the routing policy for babeld. If anyone disagrees, please speak up now.

Thanks.

Mahesh Jethanandani
[email-masked]

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 27 Aug 2019 19:14:18 +0000

I’m speaking up to agree with Mahesh’s assessment.
+1
Barbara

On Aug 27, 2019, at 2:50 PM, Mahesh Jethanandani <[email-masked]<mailto:[email-masked]>> wrote:

On Aug 23, 2019, at 3:27 PM, Juliusz Chroboczek <[email-masked]<mailto:[email-masked]>> wrote:

Thanks.

Mahesh Jethanandani
[email-masked]<mailto:[email-masked]>