Hi Robert, > On Aug 2, 2020, at 3: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
Actually, I meant that EGP protocol speakers (implemented according to RFC 904 <https://www.rfc-editor.org/rfc/rfc904.html>) are rarely if ever used anymore. I’m sorry if I was unclear. > 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 :) Agreed. > > 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 ? Perhaps a better way for me to express my concern is (ideally), any mention of "origin egp" in future RFCs should not recommend its use unless the Historic EGP protocol is used. I hope that is more clear. That would at least be consistent with the original, intended use of “origin egp”. > 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’m thinking along the lines that (excessive) prepending is used because there isn’t an alternative that more clearly expresses the intent of the operator. If specifying a new attribute would facilitate that, I would be in favor of it. Regards, Greg
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
