Resolve a BGP next-hop with another BGP route

[Ondrej Zajicek]

On Mon, Sep 30, 2019 at 07:28:22PM +0200, mikma.bird at 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 at 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."