On Sun, Aug 2, 2020 at 6:22 AM Robert Raszuk <[email protected]> wrote: > > Hi Greg, > >> >> > Have anyone tried to document that instead of doing AS-PATH prepend across >> > set of upstreams (for whatever valid reason that may be) the preferred >> > entrance should advertise the paths with IGP or EGP origin while the other >> > ASBRs (which would otherwise prepend N times) with INCOMPLETE ? BGP best >> > path should automatically across most implementations do the right path >> > selection. >> >> Offhand, I don’t know of anyone who has tried to document this. But why EGP >> origin? EGP is a Historic protocol that is rarely if ever used. IMO, >> although this technique could work, it is misleading. > > > I thought it is not used too but looking at the BGP table it is there: > > cto-asr1x-ny1#sh ip bgp detail | count .*EGP.*external, best.* > Number of lines which match regexp = 826 > > cto-asr1x-ny1#sh ip bgp detail | count .*EGP.* > Number of lines which match regexp = 2345 > > Then looking at some vendor's docs I see that they apply it if the advertised > route was learned via different ASN (many folks run more then one AS > globally) bit of surprise as RFC4271 never mentioned such use case. > > origin egp—(Optional) BGP origin attribute that indicates that the path > information originated in another AS. > > So one could argue that it is misleading already today :) > >> > If not maybe we should think about a new attribute along the lines of cost >> > community to be more widely used in a transitive manner and to have single >> > meaning to allow to deprefer a prefix originated by given AS across number >> > of ISP uplinks with a numeric value (just like MED or Local Pref are used >> > locally). >> >> IMO, this is a better idea. > > > Well sure, but you know the time we take to define it, the time vendors take > to implement it, the time it takes to deploy it then the time it takes for > folks to actually start using it we are talking years ... > > Sure if we never start we will never get there but in the mean time perhaps > we could use what's deployed everywhere to trim size of AS-PATHs yet get all > the benefits of AS-PATH prepends ? > > Clearly I am here just trying to probe the WG list on three questions .... > > Is it worth to try it - ie. do we have a problem, > Is this a good idea - ie. do we break anything, > Should this option be added to draft-mcbride-grow-as-path-prepend as > something to consider instead of doing N times AS-PATH prepend (often N > 5 > or N> 10 ....) > > See at the end of the day the best thing about this is that anyone can try to > advertise his paths with different origin even today and it should just work > - without anyone else doing anything configuration wise in the upstream ASNs. > > Thx, > R. >
I would not want to use Origin for anything new or out of scope of its original intention as it's usually overwritten by intermediaries anyway. My usual recommendation was to set Origin on all EBGP sessions that were not customers (peering/transit) to E to flatten them out as some transit networks appear to modify this value in order to attract more traffic through them. Something I would ask is what problem exactly is being solved with prepending and can we attempt to solve this in another fashion, either with best practices guidance or with a new protocol spec that covers the use case. Here the problem seems to be not very well defined because I believe there are multiple use cases for various levels of prepending. For example one case is to attempt to utilize one path exclusively and another solely as a backup. Another might be a signal to indicate that one path may have a different amount of capacity than another where the lower capacity link still takes traffic. Do we need to further define these use cases and work to identify clear solutions for each as part of this WG? Actually solving these problems might be cart before horse but something to consider is that some things are immutable in flight and others are not and perhaps an immutable and authenticated solution would be preferable on today's Internet. > _______________________________________________ > GROW mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/grow -- [[email protected] ~]$ cat .signature cat: .signature: No such file or directory [[email protected] ~]$ cat all-opinions-are-my-own All opinions are my own and do not represent any of my employer. _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
