Re: Can one Destination Address appear in both Tunnel Encap Attribute and in MP_REACH_NLRI ?

Robert Raszuk <[email protected]> Thu, 17 Oct 2019 06:30:54 -0400
Newsgroups gmane.ietf.idr
Message-ID <CAOj+MMFs=StpLvK1dZO+ChBUN5i2AYq+CrhHMfMxifpxqegwiw@mail.gmail.com>
Well indeed the draft is very underspecified in this space.

The fun starts when next hop from NLRI is unreachable while tunnel end
point is. Does it mean that given path is not going to be considered for
best path selection ?

And we can go further ... say bgp uses selective next hops and is set to
only consider /24 and higher and NH from NLRI does not meet those criteria
.... but tunnel endpoint is reachable over default route - what happens then
?

See what strikes me the most is the mandatory nature of endpoint TLV and no
good description of various cases when NH in NLRI != Tunnel endpoint
address. If there are equal tunnel endpoint may be optional.

Thx,
R.

On Thu, Oct 17, 2019 at 5:33 AM Ondrej Zajicek <[email protected]>
wrote:

> On Thu, Oct 17, 2019 at 10:25:13AM +0200, Robert Raszuk wrote:
> > Srihari,
> >
> > Can you comment on the expected BGP next hop validation behaviour ?
> >
> > Can you also comment on the next hop BGP is installing the prefixes to
> RIB
> > with ?
> >
> > Is tunnel endpoint now the NH BGP is asking RIB to track ?
>
> My impression of the draft is that handling of BGP NH and address from
> Tunnel Encap attribute is different. BGP NH is tracked in RIB and
> recursivery resolved, could be used to daisy-chain encapsulation in RIB
> (section 7). In contrast, the address from the Tunnel attribute is just
> passed to FIB as encapsulation action argument.
>
> But it is true that this part of the draft is a bit blurry and would
> definitely need more clear wording.
>
> --
> Ondrej 'Santiago' Zajicek (email: [email protected])
>

_______________________________________________
Idr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/idr