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

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 ?

None of those seems to be described in section 5 of the draft. How do you
even know on sender side that all remote BGP speakers will honor tunnel
encapsulation attribute and will actually use end-point from its mandatory
TLV instead of NLRI next hop ?

Linda,

Perhaps for your use case much cleaner solution would be to just
use Encapsulation Extended Community as defined in RFC 5512 section 4.5
instead of tunnel attribute ?

Thx,
R.




On Thu, Oct 17, 2019 at 10:08 AM Srihari Sangli <[email protected]> wrote:

> Hi Robert,
>
>
>
>
>
>
>
> My reading of Linda's point was a question regarding the case where for
> prefix A NLRI points to
>
> next hop NH_1 but tunnel endpoint says go to NH_2.
>
>
>
> Is such update still valid ?
>
>
>
> Has tunnel encapsulation attribute power to "overrule" BGP next hop from
> MP_REACH ?
>
>
>
>
>
> The draft in Section 5 explains this. If the update has a valid Tunnel
> Encapsulation attribute and if any of the tunnel(s) is considered to be
> feasible, then it MUST use the tunnel. That means in your example, such an
> update is valid and NH_2 should be used.
>
>
>
> Hope this helps. Thanks.
>
>
>
> srihari…
>
>
>
>
>
>

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