On Mon, Sep 30, 2019 at 07:28:22PM +0200, mikma.bird@lists.m7n.se wrote:
On 30 September 2019 01:52:22 CEST, Ondrej Zajicek
Yes. Technically it is not because the other route is also BGP, but because the other route is also recursive / also has indirect next hop. BIRD implements only one level of indirection.
Is this a problem? Which use cases require more levels of indirections?
"The BGP Tunnel Encapsulation Attribute" is one example:
https://tools.ietf.org/html/draft-ietf-idr-tunnel-encaps-13#section-7
Hi That is an interesting draft, thanks. I read the old RFC 5512 and the sparate SAFI seemed to me as overengineered. It is true that applying and merging encapsulation attributes when recursive next hops are resolved would be another complexity to next hop resolution. We already have there code for MPLS, so some generic mechanism would be needed. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."