Rafał, Let me put this way - ABR insert ANH route to IGP conditionally - if > session is up and EoR have been received. > Note that multiple session may be tracked for given ANH, wit OR logic. >
OK - we all agree that this conditional injection is not a bad thing. And I guess you can do it today easily with some implementations (for example using object tracking). Each ASBR will propagate its best route to on-site RR > That is precisely the moment when I think we need to seriously consider consequences. point #1 - more and more stuff in BGP is opaque to BGP and plays no role in best path selection. So if someone really needs any of those information he must not use this solution and that should be spelled out very clearly as this information will be lost. point #2 - what is the real problem we are solving ? Full table takes depending on the implementation of BGP anywhere from 300-450 MB of RAM. Extra path would be another 150 MB. This is all control plane memory so pretty cheap and happily fits any x86 box to be placed to act as RR. Now you made two observations: -A- I have a weak router which is fine from bw pov but does not have steam to handle 5M paths - My take is - ok send him 1 or 2 paths from RRs and be done. -B- The withdraw of all BGP routes takes soo long - well let's observe that we can withdraw all routes from a given peer with single BGP message using techniques as described in https://tools.ietf.org/html/draft-raszuk-aggr-withdraw-00 Bottom line I think using Abstract Next Hop can help for specific SAFis in specific topologies to reduce the amount of control plane if that is ever an issue. Yes dealing with BGP control plane handling is implementation specific and some code does it more efficiently then other. Best, R.
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
