Subject: Re: [babel] What to do if we don't know the next hop?

From: Ondrej Zajicek <[email-masked]>
Date: Mon, 11 Jun 2018 17:39:10 +0200

>> That's a tricky one.  In the case of BGP, RFC 5549 allows just that --
>> announcing an IPv4 route with an IPv6 next hop.  5549 is pretty vague, but
>> my understnading is that the forwarding plane would do an ND lookup for
>> the IPv6 address of the next hop, then send IPv4 packets to the MAC
>> address thus obtained.
>
> On the other hand, perhaps it would be better to explicitly require such
> routes to be dropped, in order to avoid confusion.  If the feature is ever
> required, we'll write an extension to that effect.
>
> So:
>
>   (1) leave it vague;
>   (2) explicitly MUST DROP;
>   (3) explicitly define meaning.
>
> I'm open to (1) and (2), I'm opposed to (3).  Opinions?

Hi

I am generally in favor of RFC_5549-like behavior, so i would prefer
this:

1) Loose the description in 4.4.9 Next hop such that the default next hop
is the source address for address families where such address is
applicable (instead of 'matching').

2) Explicitly MUST DROP silently for cases where there is no default next
hop (i.e. source address not applicable and no matching next hop TLV). [*]

3) Sending such updates is allowed.

What means by 'address is applicable' depends on whether platform
supports RFC_5549-style routes. Note that only the receiver ability to
use RFC_5549-style routes is relevant (as route announcer is able to
receive the packet regarless of how receiver resolved the MAC address),
so there is no need to signalize the ability. And the situation
is analogous to whether receiver support next hops is not in the
directly connected prefix.

Although it is true that for full RFC_5549-like support it would be
necessary to define a new TLV or a next hop sub-TLV to be able to send
explicit next hops of different address families, in most cases (esp.
when third-party next hops are discouraged) the above behavior would
be enough.

[*] Or perhaps the receiver could keep such routes and do not use and
propagate them, but it definitely should not handle such updates with
packet parse error.

-- 
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: [email-masked])
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Mon, 11 Jun 2018 21:40:34 +0200

> directly connected prefix.

Bit of a side note, but does Bird currently support his on Linux? And if
so, how does it interface with the kernel routing table?

> propagate them, but it definitely should not handle such updates with

Oohh... only just realised that it is returning a parse error for the
whole packet and not just ignoring the TLV. Oops. Can I trouble you to
change that to return _IGNORE instead, or do you want me to send a
patch? :)

-Toke

---

From: Ondrej Zajicek <[email-masked]>
Date: Mon, 11 Jun 2018 21:48:01 +0200

> so, how does it interface with the kernel routing table?

Bird supports that for BGP, but cannot export such routes to kernel
routing table because AFAIK Linux kernel does not support it yet.

> change that to return _IGNORE instead, or do you want me to send a

I will fix that.

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Mon, 11 Jun 2018 21:49:31 +0200

> routing table because AFAIK Linux kernel does not support it yet.

Right, didn't think so. Hmm, something to get the kernel people to fix
at some point I guess :)

>> change that to return _IGNORE instead, or do you want me to send a

Great, thanks!

-Toke