Hey Igor,
> [IM] Agree. I understood it well before I started drafting. My goal was as > less as possible touch to VPN and other mechanics. BGP NH tracking allows > us to implement changes (update boxes) only for MH PEs. > Some deployments have up to 5000 CEs hanging off the PEs. And those networks have 1000s PEs. We just can not propose a solution which would melt one's underlay. Sure you may just state oh well "use with caution" - my take we can do better. > they do from day one. You can easily remove all routes in a given VRF by >> withdrawing the RD/64 prefix. Single BGP message. >> > [IM] Well, actually I totally missed this mechanic. It sounds really good > and I'm surprised that it isn't widely used (at least I haven't encountered > it). A careful reading of 4365/4659 didn't show me anything about it, from > my understating, RD`s task is just to distinguish routes and nothing more. > Maybe it is described anywhere else? > Well it came as part of discussions we have had 18 years ago about aggregate withdraws: https://www.ietf.org/archive/id/draft-raszuk-aggr-withdraw-00.txt I actually have built some images to test it in IOS :) But if you want to refocus your draft and use RD based aggregation for withdrawals I am all game to help. Within the last few months I have been approached with at least three cases for such functionality :) It does however touch on base BGP behaviour ... which is the ability to withdraw more specific routes by less specific prefix. So it has to be properly scoped to make it safe. Say only for SAFI 128. > So in your case (Internet in a VRF) there is simple solution: >> >> Option I ) Put each CE into a separate VRF - when CE goes down - just >> withdraw the /64 RD. >> > [IM] This is obviously not the way, especially for brownfields. > Not sure about that. > Option II) Alternatively you may ask your favourite vendor to allow >> multiple RDs in a VRF - one per each CE. Withdraw mechanism will be the >> same /64 per CE however no impact to the underlay .. still single next hop, >> single forwarding label etc ... In this option in the case both CEs >> advertise the same nets you would still advertise the single best path only >> out of this VRF. Keep in mind however that paths will be different from >> each CE so upon a CE failure while you can quickly remove the previously >> advertised routes you need to announce all of them again anyway with >> different CE paths. So the solutions is not much better then smart >> implementations and Option I. >> > [IM] This is more interesting. And I believe the described problem with a > couple of CEs can be addressed by Add-Paths for VPNs. > See Add-paths for VPNs was never needed as good multihoming is done across different PEs (where RDs would be unique). On the other hand advertising multiple paths from a given VRF is not that wise as repair is local and we have no interest to spray all the paths everywhere ...note that what we care about is not control plane, but connectivity for customer packets (connectivity restoration). Best, Robert
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
