Hi Robert, Thanks for the comments, my inline is below.
ср, 24 авг. 2022 г. в 22:46, Robert Raszuk <rob...@raszuk.net>: > 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. > [IM] If we can do better, we need to do it better. My goal is to solve the problem. But also I want to consider the complicity of the future solution (more specifically, the probability of deployment). > > >> 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 > [IM] Thank you for the reference! > > 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 :) > [IM] There is no problem to refocus. Maybe there is a way to revive your draft? I doubt I can do better :) > 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. > [IM] Agreed. Maybe also SAFI 129 would receive some benefits. It is also used sometimes for tons of prefixes. > > 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. > [IM] I believe it is design-dependent. Maybe some folks would find it suitable, who knows? > > >> 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). > [IM] Agreed. > > 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). > [IM] Yes. Agreed here too. > > Best, > Robert >
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
