Re: [GROW] AS_Path prepend BCP

[Jakob Heitz (jheitz)]

Consider a common problem

[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
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] AS_Path prepend BCP

[Greg Skinner]

Hi Robert,

> On Aug 2, 2020, at 3:22 AM, Robert Raszuk  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 
) 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
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow