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

Hey Keyur,


> Why don't we use basic BGP recursion (in any AFI/SAFI required) and simply
> advertise within each applicable SAFI an NLRI = NH of endpoint/customer
> routes with NH = Tunnel Endpoint while attaching to such
> UPDATE  Encapsulation Extended Community indicating type of tunnels and
> parameters required ?
>
>
>
> #Keyur: You can still announce the tunnel endpoint (underlay) route using
> tunnel endpoint attribute. The attribute gives you a common placeholder to
> carry tunnel parameters (including endpoint) and specifically as and when
> parameters grow beyond size of community/ext community/large community.
>

Size is a fair point .. while type of the encap will easily fit in
communities some other associated info may not.

But in the case I described there is no need to put tunnel endpoint address
in the tunnel attribute. How about you update the draft and make tunnel
endpoint address TLV optional - and if not present next hop is used as
tunnel endpoint ?

Of course most if not all of other observations still apply :)  And the
point here is that to get consistent implementations draft should add
perhaps even a new paragraph on how to handle difference in next hop
validation vs tunnel endpoint validation. Is in the case of presence of
reachable (or poor man's check existing in the RIB) tunnel endpoint address
BGP next hop validation and tracking still making sense ? Then how to
address similar "collisions" with Origin Validation results ?

Thx,
r.

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