I disagree. Origin is tremendously useful as a multi-AS weighting tool, and isn't the blunt hammer that AS_PATH is.

If you think of AS_PATH as a blunt hammer, how would you describe localpref? We use AS_PATH in many cases *precisely* because we don't consider it to be a blunt hammer... Steinar Haug, Nethelp consulting, sthaug@nethelp.no

On 31/05/2012 12:55, David Barak wrote:

I disagree. Origin is tremendously useful as a multi-AS weighting tool, and isn't the blunt hammer that AS_PATH is. The place where I've gotten the most benefit is large internal networks, where there may be multiple MPLS clouds along with sites cascaded off of them - it provides a way of sending "soft" preferences down the transitive chain. Also useful is "set origin egp XX" - on a route injector, that can post-pend an ASN and limit the spread of a route while still allowing the same transitive properties.

We're not talking about the same thing here: configuring a policy to use an interior-generated origin is completely different to depending on what your upstreams configure their announcements to look like. If you don't rewrite your transit providers' origin, then you are telling them that they can directly influence your exit discrimination policy on the basis of a purely advisory flag which has no real meaning. I.e. if one of them tweaks origin to be IGP and another leaves everything set at EGP or incomplete, then the tweaker will end up taking more of your traffic on no basis whatsoever, other than the fact that they bent the rules of what some might consider as pair play. This is broken and harmful. Rewriting the origin on ingress stops this particular line of network abuse. Nick

  From: Nick Hilliard <nick@foobar.org>

If you don't rewrite your transit providers' origin, then you are telling them that they can directly influence your exit discrimination policy on the basis of a purely advisory flag which has no real meaning. 

On what precisely do you base the idea that a mandatory transitive attribute of a BGP prefix is a "purely advisory flag which has no real meaning"?  I encourage you to reconsider that opinion - it's actually a useful attribute, much the way that MED is a useful attribute.  Many providers re-write MED, and apparently some re-write ORIGIN.  Neither of those is "network abuse" - it's more accurately described as "network routing policy."  As has been stated here before: your network, your rules.   David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com

On Thu, May 31, 2012 at 12:21:12PM -0400, Keegan Holley wrote:

The internet by definition is a network of network so no one entity can keep traffic segregated to their network. Modifying someone else routing advertisements without their consent is just as bad as filtering them in my opinion. Doing so to move traffic into your AS in order to gain an advantage in peering arrangements and make more money off of the end user is just dastardly.

There was one particularly (in)famous network *coughpeer1cough* which was well known for selectively rewriting the origin codes towards their peers a few years back. For example, if traffic was going to New York, they would advertise the prefix with IGP in New York, and Incomplete everywhere else, forcing other networks to haul the traffic to New York. This is a violation of most peering agreements, which require consistent advertisements unless otherwise agreed, but it was just sneaky enough that it flew under the radar of most folks for quite a while. When it was finally noticed and they refused to stop doing it when asked, a few folks just depeered them, but a bunch of others just "solved the problem" by rewriting the origin codes. This is why you still see a lot of rewriting happening today by default, to avoid a repeat of the same issue. Personally I was of the opinion that the correct solution to this particular problem was just to terminate the peering relationship, but honestly Origin code is a pretty useless attribute in the modern Internet, and it exists today only because it's impossible to take it out of the protocol. I don't see anyone complaining when we rewrite someone else's MEDs, sometimes as a trick to move traffic onto your network (*), or even that big of a complaint when we remove another networks' communities, so I don't see why anyone cares about this one. Maybe a "better" fix would be a local knob to ignore Origin code in the best path decision without having to modify it. Start asking your vendors for it now, maybe it'll show up around 2017... :) (*) I've seen a lot of inexperienced BGP speaking customers be very upset that they can't "send any traffic using natural bgp" (yes, there appears to be some kind of delusion running around that modifying BGP attributes to influence path selection is bad... What's next, "organic routes, not from concentrate"? :P), which in the end turned out to be us sending the customer MEDs based on our IGP cost, other networks sending them MEDs of 0, and them not knowing enough to do something useful with the data or else rewrite it to 0. -- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

On Thu, May 31, 2012 at 12:21:12PM -0400, Keegan Holley wrote:

...

The internet by definition is a network of network so no one entity can keep traffic segregated to their network. Modifying someone else routing advertisements without their consent is just as bad as filtering them in my opinion. Doing so to move traffic into your AS in order to gain an advantage in peering arrangements and make more money off of the end user is just dastardly.

There was one particularly (in)famous network *coughpeer1cough* which was well known for selectively rewriting the origin codes towards their peers a few years back. For example, if traffic was going to New York, they would advertise the prefix with IGP in New York, and Incomplete everywhere else, forcing other networks to haul the traffic to New York. This is a violation of most peering agreements, which require consistent advertisements unless otherwise agreed, but it was just sneaky enough that it flew under the radar of most folks for quite a while. When it was finally noticed and they refused to stop doing it when asked, a few folks just depeered them, but a bunch of others just "solved the problem" by rewriting the origin codes. This is why you still see a lot of rewriting happening today by default, to avoid a repeat of the same issue.

Personally I was of the opinion that the correct solution to this particular problem was just to terminate the peering relationship, but honestly Origin code is a pretty useless attribute in the modern Internet, and it exists today only because it's impossible to take it out of the protocol. I don't see anyone complaining when we rewrite someone else's MEDs, sometimes as a trick to move traffic onto your network (*), or even that big of a complaint when we remove another networks' communities, so I don't see why anyone cares about this one.

It's hard to catch when someone is modifying your advertisements. Also, I don't expect MED to be compared globally since different networks will handle it differently so chances are I'm just using it to contol traffic to and from a directly connected ISP. If you rewrite it to do the same thing with your upstreams I probably won't care as long as latency and hop count remain reasonable. That being said I've seen an upstream mess with local-pref in their AS and then again upstream from them and began pulling

2012/5/31 Richard A Steenbergen <ras@e-gerbil.net> traffic literally into a different country. That IMHO is egregious.

Maybe a "better" fix would be a local knob to ignore Origin code in the best path decision without having to modify it. Start asking your vendors for it now, maybe it'll show up around 2017... :)

I still think it would cool if BGP had an AS topology database of some sort, but that's too expensive. Most BGP policies are not very deterministic in my experience.

(*) I've seen a lot of inexperienced BGP speaking customers be very upset that they can't "send any traffic using natural bgp" (yes, there appears to be some kind of delusion running around that modifying BGP attributes to influence path selection is bad... What's next, "organic routes, not from concentrate"? :P), which in the end turned out to be us sending the customer MEDs based on our IGP cost, other networks sending them MEDs of 0, and them not knowing enough to do something useful with the data or else rewrite it to 0.

Well less than ten years ago I remember hearing that BGP was only for ISP's or very large enterprises and most people should try to run an IGP only. I still hear from companies who are nervous about running BGP with a private MPLS provider. Old habits die hard I guess..

2012/5/31 Steve Meuse <smeuse@mara.org>

On Thu, May 31, 2012 at 12:21 PM, Keegan Holley <keegan.holley@sungard.com

...

wrote:

...

The internet by definition is a network of network so no one entity can keep traffic segregated to their network. Modifying someone else routing advertisements without their consent is just as bad as filtering them in my opinion. Doing so to move traffic into your AS in order to gain an advantage in peering arrangements and make more money off of the end user is just dastardly.

While this is a nice thought, it's not practical in reality. If you give someone a knob, they are going to turn it. Someone will look to take advantage of it.

If you pay me, fine. If you don't pay me, I'm not going to allow you to potentially cost me significant dollars in infrastructure costs just to preserve the notion of free love and peering :)

If you consider not mucking with my advertisements and those of my customers "free love" then I hope you don't work for one of my upstreams. Likewise, if you consider not hijacking my traffic to drive up revenue as "cost". Anything to make a buck I suppose. sigh..

On 31/05/2012 16:46, David Barak wrote:

On what precisely do you base the idea that a mandatory transitive attribute of a BGP prefix is a "purely advisory flag which has no real meaning"?

Let's say network A uses cisco kit and injects prefixes into their ibgp tables using network statements. The default for this is to set origin=igp. On the other hand, network B also uses cisco kit and uses "redistribute" to inject static routes from their route reflectors. By default, these prefixes will have origin=incomplete. Network C uses juniper kit, which sets origin=igp for all injected prefixes, regardless of whether it's via an IGP or some other means. So, the default origin policy is that unless the originator of an prefix manually tweaks the origin to be consistent with something that is actually consistent (with what, I don't know - because there is no good definition of the difference between, say, igp and incomplete), then different _syntactic_ network configurations will set the parameter differently, even if there is no _semantic_ difference in those configs. This is a pretty random mess. I do not wish to operate the networks which I manage on the basis of a parameter which is basically arbitrary and which can be tuned by an upstream connectivity provider to their advantage based on their whims.

I encourage you to reconsider that opinion - it's actually a useful attribute, much the way that MED is a useful attribute. Many providers re-write MED, and apparently some re-write ORIGIN. Neither of those is "network abuse" - it's more accurately described as "network routing policy."

med is useful in an inter-asn context if you have multiple links into a specific asn and wish to discriminate between them on the basis of what that ASN suggests. Same for origin if you trust that the other ASN has configured origin in a sensible manner. MED can be trusted in situations where you have a prescribed policy for trusting med, preferably backed by a contract which defines the MEDs. Otherwise, thanks but no thanks.

As has been stated here before: your network, your rules.

yep, definitely! :-) Nick

On 05/31/2012 07:06 PM, Saku Ytti wrote:

On (2012-05-31 08:46 -0700), David Barak wrote:

...

On what precisely do you base the idea that a mandatory transitive attribute of a BGP prefix is a "purely advisory flag which has no real meaning"? I encourage you to reconsider that opinion - it's actually a useful attribute, much the way that MED is a useful attribute. Many providers re-write MED, and apparently some re-write ORIGIN. Neither of those is "network abuse" - it's more accurately described as "network routing policy." As has been stated here before: your network, your rules.

When provider rewrites MED, they do it, because they don't want peer to cause them to cold-potato, to which they may have compelling reason. Then some clever people realise they forgot to rewrite origin, working around the implicit agreement you had with them.

You CAN rewrite MED, as stated in RFC 4271, section 5.1.4 - but you SHOULD NOT change origin attribute, as stated in section 5.1.1. So, in terms of rewriting, MED is not comparable to origin. I think RFC 4271 (http://tools.ietf.org/html/rfc4271) is very clear here. Back to the standard, why condone it's violation? Yes, statement about origin is here since January 2006 - older RFC 1771 didn't contain similar rule. But 6 years after publishing I think everyone had enough time to implement this correctly. I still think, that professionals shoult follow RFC and not insert their own creativity to places, where's not expected - just because they decide that as a "cool" idea. For local routing policy - there're still lot of knobs, which can be used internally (typically MED, LOCPREF) to enforce expected policy and there's technically no reason to change origin. -- Daniel

On Jun 1, 2012, at 4:28 AM, Saku Ytti wrote:

It's extremely hard to find RFC which does not contain incorrect information or practically undeployable data.

Actual errors in RFC's (typos, incorrect references, etc.) - <http://www.rfc-editor.org/errata.php> Differing views regarding RFC subject material; feel free to work with others of similar to write up your perspective - <http://www.rfc-editor.org/rfc/rfc2223.txt> The RFC series is an Internet-wide community effort. Thanks! /John

On 06/01/2012 07:38 PM, Joe Provo wrote:

You clearly did not read the previous posts involving actual historical evidence [and apparently ongoing] of remote networks attempting action at a distance knowing that many overlook this part of the decision tree. Preventing your company from bleeding money or degrading performance at whim of remote parties certainly is "cool" but also just good business and proper network hygiene.

By overwriting origin field, there's no warranty that someone improves performance at all - it's just imagination. In extreme cases, performance can be degraded when someone in the middle plays with origin field and doesn't know reasons, why originating network uses something else than IGP origin. In RFC 2119 words, full implications were not understanded - when this overwriting is done generally. Also, there must be some historical reason, why origin should not be rewritten (this changed in January 2006). For internal reasons within the network operator still haves enough knobs to enforce own policy (by setting localpref, med on his network). Daniel

On 06/02/2012 02:42 AM, Richard A Steenbergen wrote:

On Fri, Jun 01, 2012 at 08:03:50PM +0200, Daniel Suchy wrote:

...

By overwriting origin field, there's no warranty that someone improves performance at all - it's just imagination. In extreme cases, performance can be degraded when someone in the middle plays with origin field and doesn't know reasons, why originating network uses something else than IGP origin. In RFC 2119 words, full implications were not understanded - when this overwriting is done generally.

Uh, what part of "to prevent remote networks from improperly forcing a cold potato routing behavior on you" sounds imaginary?

It depends, not everything looking as proper from single network operator in the middle can be proper in end-to-end user experience, where multiple networks are traversed.

...

Also, there must be some historical reason, why origin should not be rewritten (this changed in January 2006). For internal reasons within the network operator still haves enough knobs to enforce own policy (by setting localpref, med on his network).

Not really, no. Not every RFC is 100% correct, and they're often written by people who are not operators (because operators are too busy running real networks :P). Besides, "SHOULD NOT" means "you probably don't want to do this, unless you have a really good reason", and enforcing such an important point in a peering policy is a pretty good reason.

If someone comes with some implementation overwriting ASPATH (even it may not) and excuses this by RFC incorrectness from his perspective, you'll understand it? Probably not. It's relative.

You also clearly don't understand the practical use of localpref. When you're trying to implement a simple and relatively common policy like "closest exit routing to a peer with multiple exits", you set the localprefs the same (localpref is usually used to determine WHICH peer you'll be sending to), you set the MEDs the same (if you don't want to artifically select which EXIT to use), AS-PATH lengths are obviously the same if you have multiple exits, and then the next one down is origin code. If you can't reset origin code, you run the risk of a remote network being able to force your network to do something you probably don't want to do (or at least probably wouldn't want to do, if you had any idea what you were doing :P).

Well, this matches situatios, where two networks have more than single interconnection and still for prefixes originated from that particular network. But when there's only one interconnection, there's no such reason. Intermediate networks, even having multiple peers will probably see similar origin on all their peers.

Please see the previous commentary from Joe Provo, Saku Ytti, etc, they are quite correct.

I don't think they admits all consequences. When some knob (origin) is not disabled by policy for single prefix visible at multiple points, some "creative" operators should come with other methods to achieve what they wants. Prefix deagregation is first thing, that comes to mind. Even they'll also slightly violate RFC (having not single policy - well, they assume RFC is not correct), they simply start to announce deagregated prefixes next to aggregate one. But deaggregated prefixes are announced only to specific peers - and yes, this works. Then, you can have any policy, have everything normalized at all peers - but most specific prefix in your table visible over particular path simply wins over everything. And this is not a imaginary case - this is clearly visible in real routing table - 41% of address space (in IPv4) is deaggreated, in my experience mainly due to "traffic engineering" purposes - smaller end networks are simply enforced to do this, and some people here confirmed this in this discussion... - Daniel

On 06/02/2012 02:53 AM, Joe Provo wrote:

Cost and performance were merely two reasons someone may wish to prevent remote parties from using origin to influence outbound traffic from my network. As I mentioned already, it will influence that by another way. And this costs *you* more money - you have to pay for router with larger TCAMs, more memory, faster CPUs... and yes, deaggregation is very simple task for originating network - much easier than playing with the origin flag, which is not understanded widely.

I can state it is not imagination when I encountered networks doing this in the past for prefixes they were sourcing. To be clear - these were prefixes being sourced by a neighbor who was providing different origin codes on different sessions. Either they were [to Nick Hilliard's point] using different kit and unaware of the differnt implementations or [as evidence bore out] purposefully shifting traffic without arrangement on links that were worse for me and in violation of the agreement we entered into when peering.

More specific prefix in addition to aggregate one visible only over specific peers will do the job, too. And will do that job better... but for what cost (not only to you)...?

There certainly were historical reasons for treating origin as sacrosanct. Time has marched on and those reasons are now *historical*, hence the quite reasonable updat eto the RFC. You seem to fail to understand that MED comes after origin on the decision tree, and therefore someone can influence traffic carriage without agreement.

You seem to fail realize other (easier) ways to influence traffic carriage. Deaggregation with selective route announcement is quite common way, many networks do that. - Daniel

On 06/02/2012 12:43 PM, Joe Provo wrote:

Last post on this topic for me. You seem to wish to argue against the lessons of history and the reality of running a network on the global Internet.

Based on observations from routeviews / RIPE RIS / other public sources, overwriting BGP origin isn't a common practice. I did some analysis before I opened this topic.

From tier-1 networks, only Level3 seems to do this, from other major networks only HE. Based on network listed at http://en.wikipedia.org/wiki/Tier_1_network, there're 2 of 22 major (and only 11 tier-1) worldwide networks performing origin overwritting.

That's really not a representation of common and widely used practice. I'm not arguing with common practice on the internet. Majority doesn't touch origin attribute... (and yes, basically I don't care about pure tier-2/3 networks, their impact isn't peremptory in terms of their global impact)

The two issues are orthogonal. Deaggregating sources have been cost-shifting [in a highly visible and easily examined and often trivially-filtered] manner for ages.

In global table, there's 41% overhead, in terms of prefixes announced. I don't think it's trivial to filter this overhead. If you're correct (I don't think so), why there's this huge ammount of unfiltered deaggregated prefixes in global table? Because it's easier to buy new hardware.

A midspan network deaggregating someone else's prefixes is broken and gets called out, generally by the originator if they have a clue.

This is bad at all - but sometimes also happens with huge impact and this is historically documented on some cases like Pakistan Telecom/Youtube. And this happened, even you said that filtering is trivial... - Daniel