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

Robert,

Comments inlined #Keyur1

From: Robert Raszuk <[email protected]>
Date: Friday, October 18, 2019 at 2:00 AM
To: Keyur Patel <[email protected]>
Cc: "Rajiv Asati (rajiva)" <[email protected]>, Ondrej Zajicek <[email protected]>, "[email protected]" <[email protected]>, Linda Dunbar <[email protected]>, Srihari Sangli <[email protected]>, "[email protected]" <[email protected]>
Subject: Re: [Idr] 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 ?

#Keyur1:  This has been debated before afair. You don’t want different encapsulations to be handled in different ways. There is benefit in having them within a common placeholder (which is actually cheap and further solves any interdependencies if mandated).


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.

#Keyur1: Please note that the implementations are already there in various forms.

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 ?

#Keyur1: Agree. Then again section 5 does refer to reachability aspects of the tunnel endpoint. IMHO, the specifics of tracking of tunnel ip address is an implementation detail.

Then how to address similar "collisions" with Origin Validation results ?

#Keyur1: Collisions of origin validation result is usually a matter of network specific policies mandated by operators (They may permit or may deny making a specific tunnel ineligible).

Regards,
Keyur


Thx,
r.

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