Thank you Greg, I think that clarifies it very well. And I actually fully agree with all you just said below.
Kind regards, R. On Thu, Aug 6, 2020 at 3:46 AM Greg Skinner <[email protected]> wrote: > 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
