Hi Jakob, The situation in reality is much more complex then your illustration.
Imagine that in your picture what you call "content" is coming from all over the world and not one network location. And all of that is coming to same /24. Imagine customer already advertises few /24s (some with short some with long AS-PATH) so at this point IMHO solution 1 is very good and till we have a better one becomes IMO best one. The fact that for backup he will instead of /24s with long AS-PATH advertise /22 will not make any one's FIB bigger ... Best, R. PS. Of course if someone advertises /22 and we ask to advertise in addition to this /24s that would be growing RIBs and FIBs everywhere. But that is not the current situation in many networks. On Thu, Aug 6, 2020 at 5:50 AM Jakob Heitz (jheitz) <jheitz= [email protected]> wrote: > Consider a common problem > > > > [image: An Ink Drawing] > > Tier1-B sets local-preference for its customer to 120 > > and for its peer to 100. > > > > > > How does Customer cause Tier1-B to prefer the path: > > Content -> Tier1-B -> Tier1-A -> Regular-Provider -> Customer > > instead of its default path: > > Content -> Tier1-B -> Backup-Provider -> Customer > > ? > > > > Solution 1 > > -------------- > > Customer advertises split prefixes to Regular-Provider. > > Eg., 10.0.2.0/24 and 10.0.3/24 rather than 10.0.2/23. > > This works, but causes bigger FIBs for everybody. > > > > Solution 2 > > -------------- > > Customer advertises its routes with communities published by > > Tier1-B to lower its local-preference to Backup-Provider. > > This requires Backup-Provider to pass communities through > > and for Customer to know what Backup-Provider's upstreams are. > > It is operationally cumbersome. > > > > Solution 3 > > -------------- > > Tier1-B implements a route-policy like: > > if as-path length ge 15 then > > set local-preference 80 > > endif > > Then Customer can add lots of AS prepends that will actually work!! > > > > Regards, > > Jakob. > > > _______________________________________________ > GROW mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/grow >
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
