Re: Upstream BGP community support
Has anyone seen movement from HE on community support yet? I've heard rumblings that they are looking to do something Q3/Q4 but my sales guy is telling me that they will only support it if I go to a full 10Gb pipe. Sounds more like an aggressive sales tactic, but was curious what others are seeing. On Fri, Nov 6, 2009 at 4:34 PM, Richard A Steenbergen r...@e-gerbil.netwrote: On Fri, Nov 06, 2009 at 04:50:10PM +0100, Daniel Roesen wrote: On Thu, Nov 05, 2009 at 11:06:56PM -0600, Richard A Steenbergen wrote: Definitely a problem. The point of using 65123:45678 in the first place (with a private ASN field in the AS part) is to avoid stepping on anyone else's ASN with your internal use community. Actually, as far as I have seen yet, it's more like being able to derrive/describe community from ASN-to-act-on, e.g. 61234 meaning prepend 3 times 45678 meaning this is the neighbor AS I want this to be applied to No I'm not saying otherwise. My point was that the reason it is 65123:45678 instead of 45678:65123 is that they're using a value from the private ASN range for the action tag, thus eliminating the potential for collisions with anyone else's real ASNs. As you pointed out, the ASN and Data fields are no longer going to be the same bit size, so the flipping the fields trick will no longer work. The only solution will be to add a non-transitive target type and do localtarget:45678:65123. -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: Upstream BGP community support
Randy Bush expunged (ra...@psg.com): i try to complicate the internals of my network as little as possible, after all, complexity == opex and i value my time, it is a non-renewable resource. I'm guessing you don't have the same financial constraints that others on this list have. When you have lots of traffic(tm) to move around, and some paths are more 'spensive than others, you often don't have a choise but to muck with communities, or so I've heard -Steve
Re: Upstream BGP community support
Jack Bates expunged (jba...@brightok.net): I think creating a standard or at least a template might push more people to adopt communities support and to use them. I put this up there with trynig to define inter-provider QoS. You are never going to get two business to agree to the same model.and after all, community support is basically a business tool. I know from experience that some providers deliberately constrain their community support for business purposes, this goes back 10+ years. -Steve
Re: Upstream BGP community support
Steve Meuse wrote: I put this up there with trynig to define inter-provider QoS. You are never going to get two business to agree to the same model.and after all, community support is basically a business tool. I know from experience that some providers deliberately constrain their community support for business purposes, this goes back 10+ years. While I agree, I was thinking more along the lines of easy tools to provide the clueless with ways to do nifty things. Jack
Re: Upstream BGP community support
On Mon, Nov 02, 2009 at 02:13:38PM -0600, Richard A Steenbergen wrote: Rather than simply double the size and break it up into 32:32, the designers reserved the top 16 bits for type and subtype attributes, leaving you only 48 bits to work with. Clearly the only suitable mapping for support of 32-bit ASNs on the Internet is 32:16, leaving us with exactly the same range of data values that we have today. ... which breaks schemes such as 65123:45678 where 45678 is the neighboring AS to apply the action defined by 65123 to. Seen those multiple times. Of course using anything else then your own ASN in the AS part of TE communities is certainly debatable. Best regards, Daniel -- CLUE-RIPE -- Jabber: d...@cluenet.de -- d...@ircnet -- PGP: 0xA85C8AA0
Re: Upstream BGP community support
On Fri, Nov 06, 2009 at 12:04:18AM +0100, Daniel Roesen wrote: On Mon, Nov 02, 2009 at 02:13:38PM -0600, Richard A Steenbergen wrote: Rather than simply double the size and break it up into 32:32, the designers reserved the top 16 bits for type and subtype attributes, leaving you only 48 bits to work with. Clearly the only suitable mapping for support of 32-bit ASNs on the Internet is 32:16, leaving us with exactly the same range of data values that we have today. ... which breaks schemes such as 65123:45678 where 45678 is the neighboring AS to apply the action defined by 65123 to. Seen those multiple times. Of course using anything else then your own ASN in the AS part of TE communities is certainly debatable. Definitely a problem. The point of using 65123:45678 in the first place (with a private ASN field in the AS part) is to avoid stepping on anyone else's ASN with your internal use community. Clearly we won't be able to continue implementing this pattern AND fully support 32 bit ASNs, so the type field is going to have to come to the rescue here. Fortunately there is a transitive bit on the extended community type that could be used to signal a behavior to your upstream network without allowing that community to leak any further, so in theory one could use something like that to do a localtarget:45678:actiondata tag without poluting the namespace. Uou would lose the ability to send a community to your upstream's upstream, but that is probably of questionable legitimacy anyhow. But the way I read RFC5668 and the IANA extended community registry it doesn't look like there is an explicit definition of a non-transitive target type, and the way I read RFC4360 it doesn't look like the non-transitive value gets automatically reserved. So I guess someone will need to request 0x4002 and 0x4202 non-transitive target types for this purpose. Unless someone has a better idea of how to handle the problem stated above? -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: Upstream BGP community support
Joel Jaeggli wrote: So this questions we have approached from time to time. Is there some worth to be had in finding some consensus (assuming such a thing is possible) on a subset of the features that people use communities for that could be standardized? particularly in the context of source based remote triggered blackholing this seemed a like a worthwhile effort. A standardized set means it can be cooked into documentation, training, and potentially even products. it doesn't mean that everyone will enable it, but if they do it would be nice to agree on some basi grounds rules. it should also be understood that many if not most localized community signaling uses would remain localized in terms of their documentation and use. joel It might be a holy grail to have it completely automatable, but it would seriously help just to have a couple standard ways to do things published, product support could follow that. I dont know if communities is really the best thing to keep overloading this way. Whats wrong with dedicating a new attribute for automating policy?
Re: Upstream BGP community support
Joe Maimon wrote: I dont know if communities is really the best thing to keep overloading this way. Whats wrong with dedicating a new attribute for automating policy? Well there's always flowspec, as an example...
Re: Upstream BGP community support
i would rather earn it by designing things, not by cleaning up messes made by kiddies needing to show off. For those who try their best, given your comment, what in the fsck is one to do? [ i prefer to speak in the first person, not tell you what you should do. ] i try to use as few tricks, knobs, and clever things as possible and still get my job done. i try to be extremely conscious of, and minimal, when what i am doing effects or is visible to my neighbors and/or the global net. i try to complicate the internals of my network as little as possible, after all, complexity == opex and i value my time, it is a non-renewable resource. i prefer to be seen as an old and lazy minimalist, not a clever person. clever was a pejorative where/when i was brought up. randy
Re: Upstream BGP community support
On Mon, Nov 02, 2009 at 05:19:32AM -0500, Randy Bush wrote: i try to use as few tricks, knobs, and clever things as possible and still get my job done. i try to be extremely conscious of, and minimal, when what i am doing effects or is visible to my neighbors and/or the global net. i try to complicate the internals of my network as little as possible, after all, complexity == opex and i value my time, it is a non-renewable resource. i prefer to be seen as an old and lazy minimalist, not a clever person. clever was a pejorative where/when i was brought up. Translation: randybush You damn kids! Get off my lawn! But seriously now, the reason we have these squishy things taking up space between our ears in the first place is so we can come up with new ideas and better ways to solve our problems. Obviously you can take it too far, I'm sure we've all seen examples of absurdly over-complicated designs which existed only for the edification of someone's ego, but I have never seen a intelligent and well thought out BGP community system do anything other than make everyone's life easier. I don't know who these people are who you claim are busy breaking things with communities, but I've never seen them. Being clever is a good thing when it helps you find new ways to do more with less, and those who can't innovate in this industry are dooming themselves to obsolescence. -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: Upstream BGP community support
On Mon, Nov 2, 2009 at 11:56 AM, Richard A Steenbergen r...@e-gerbil.net wrote: But seriously now, the reason we have these squishy things taking up space between our ears in the first place is so we can come up with new ideas and better ways to solve our problems. Obviously you can take it too far, I'm sure we've all seen examples of absurdly over-complicated designs which existed only for the edification of someone's ego, but I have never seen a intelligent and well thought out BGP community system do anything other than make everyone's life easier. I don't know who these people are who you claim are busy breaking things with communities, but I've never seen them. Being clever is a good thing when it helps you find new ways to do more with less, and those who can't innovate in this industry are dooming themselves to obsolescence. That being said, how can we (me, my company, nanog, ...) possibly do to convince someone like HE, who wants to be a global player, to support BGP communities? I'm not that good at baking cakes, but HE seems to be doing pretty well at that. I know that some engineers from HE are in this list; maybe they can give us some insight as to why they believe communities are worthless. Andy
Re: Upstream BGP community support
Richard A Steenbergen wrote: On Mon, Nov 02, 2009 at 05:19:32AM -0500, Randy Bush wrote: i try to use as few tricks, knobs, and clever things as possible and still get my job done. i try to be extremely conscious of, and minimal, when what i am doing effects or is visible to my neighbors and/or the global net. i try to complicate the internals of my network as little as possible, after all, complexity == opex and i value my time, it is a non-renewable resource. i prefer to be seen as an old and lazy minimalist, not a clever person. clever was a pejorative where/when i was brought up. Translation: randybush You damn kids! Get off my lawn! bullshit But seriously now, the reason we have these squishy things taking up space between our ears in the first place is so we can come up with new ideas and better ways to solve our problems. and they need not be cute, clever, or complex. unless we did not get enough strokes as a kid. randy
Re: Upstream BGP community support
As Louis Mamakos pointed out back in 1992 or so, it's hard to conceal the existence of said peering: g2 is raising the cost of gaining info. you can not prevent it absolutely. randy
Re: Upstream BGP community support
On Nov 2, 2009, at 6:46 AM, Randy Bush wrote: But seriously now, the reason we have these squishy things taking up space between our ears in the first place is so we can come up with new ideas and better ways to solve our problems. and they need not be cute, clever, or complex. unless we did not get enough strokes as a kid. I think you two are speaking ever so slightly past each other. Specifically, you are using the term 'clever' in different ways. Also, Randy, complexity is not always bad. More transistors on a chip can absolutely make it more complex, but it can be useful if you know where to put them and how they interact. Complexity is not the enemy. Poorly understood complexity, complexity for the sake of complexity, complexity with no goal, these are bad. Saying complexity itself is bad is just as silly as adding complexity for no gain. You want to lower opex. A fine goal. Richard claims implementing a community-signaling product on his network lowers his opex. You say breaking things in ways that hurt your neighbors is bad. Richard has years of running his network in this way without harming his neighbors. Etc., etc. It sounds to me like you two agree. So why don't you shake hands and go back to your corners? Unless you'd rather talk past each other and argue semantics in front of 10K+ of your not-so-closest friends? -- TTFN, patrick
Re: Upstream BGP community support
On Mon, Nov 2, 2009 at 6:36 AM, Randy Bush ra...@psg.com wrote: As Louis Mamakos pointed out back in 1992 or so, it's hard to conceal the existence of said peering: g2 is raising the cost of gaining info. you can not prevent it absolutely. No kidding--the traffic backlog on it this morning was horrible; must have cost at least twice as much gas as normal![1] (it actually took a bit of digging for me to find a working definition of G2 that made sense in this context; is this a commonly used term that I've just managed to remain ignorant of, or is it really as archaic and esoteric as the lack of definitions in search engines would seem to indicate? Is there a commonly-referred-to network glossary where people go to look up random acronyms and terms like this, or does everybody just do their own digging when terms are tossed out like this with no definition associated with it?) randy Thanks! Matt [1]http://en.wikipedia.org/wiki/County_Route_G2_%28California%29
Re: Upstream BGP community support
So this questions we have approached from time to time. Is there some worth to be had in finding some consensus (assuming such a thing is possible) on a subset of the features that people use communities for that could be standardized? particularly in the context of source based remote triggered blackholing this seemed a like a worthwhile effort. A standardized set means it can be cooked into documentation, training, and potentially even products. it doesn't mean that everyone will enable it, but if they do it would be nice to agree on some basi grounds rules. it should also be understood that many if not most localized community signaling uses would remain localized in terms of their documentation and use. joel jim deleskie wrote: Here is the problem as I see it. Sure some % fo the people using BGP are bright nuff to use some upstreams communities, but sadly many are not. So this ends up breaking one or more networks, who in turn twist more dials causing other changes.. rinse, wash and repeat. But like Randy said who am I to stop anyone from playing... just means those of us with clue will be able to continue to earn a pay check for a very long time still :) -jim On Sat, Oct 31, 2009 at 9:25 PM, Randy Bush ra...@psg.com wrote: while i can understand folk's wanting to signal upstream using communities, and i know it's all the rage. one issue needs to be raised. bgp is a brilliant information hiding protocol. policy is horribly opaque. complexity abounds. and it has unfun consequences, e.g. see tim on wedgies etc. and this just adds to the complexity and opacity. so i ain't sayin' don't do it. after all, who would deny you the ability to show off your bgp macho? just try to minimize its use to only when you *really* need it. randy
Re: Upstream BGP community support
Joel Jaeggli wrote: A standardized set means it can be cooked into documentation, training, and potentially even products. Communities (except the standardized well known ones) are extremely diverse. For those that support even more granular traffic engineering by limiting which of their peers your routes might be transiting, I believe there are 2 distinct methods of using communities. The nature of communities, and the different levels of support and traffic engineering capabilities makes it difficult for it to be standardized. It would take even longer for anyone to adopt such a standard due to the sheer volume of routers and customers who would have to adapt from long term established policies. Jack Bates
Re: Upstream BGP community support
Jack Bates wrote: Joel Jaeggli wrote: A standardized set means it can be cooked into documentation, training, and potentially even products. Communities (except the standardized well known ones) are extremely diverse. For those that support even more granular traffic engineering by limiting which of their peers your routes might be transiting, I believe there are 2 distinct methods of using communities. The nature of communities, and the different levels of support and traffic engineering capabilities makes it difficult for it to be standardized. It would take even longer for anyone to adopt such a standard due to the sheer volume of routers and customers who would have to adapt from long term established policies. You're not going to get any argument from me about the diversity of implmentations or the needs arising out of network specific optimization. That said, our previous conclusion was also that we couldn't reasonably do this for a subset of them so I don't have to go very far to be convinced. That said standardization would likely make some features more accessible and therefore more likely to be used, I don't think traffic engineering is something I particularly want to encourage to excess but RTBH is a know that more people need access to quite frankly. joel Jack Bates
Re: Upstream BGP community support
Joel Jaeggli wrote: more accessible and therefore more likely to be used, I don't think traffic engineering is something I particularly want to encourage to excess but RTBH is a know that more people need access to quite frankly. I think creating a standard or at least a template might push more people to adopt communities support and to use them. There are definitely times it is useful to redirect traffic 2 ASN's away through a longer route. In some cases (like my small self, I try to adopt policies that allow communities to me to also be rewritten to the corresponding peers communities to alter things as far as 3 ASN's away from my customer. Jack
Re: Upstream BGP community support
On Mon, Nov 02, 2009 at 01:38:00PM -0600, Jack Bates wrote: Communities (except the standardized well known ones) are extremely diverse. For those that support even more granular traffic engineering by limiting which of their peers your routes might be transiting, I believe there are 2 distinct methods of using communities. Even the standardized ones aren't guaranteed to be useful. For example RFC3765 defines a NOPEER community, i.e. a standardized way to say do not export this route to peers (in the settlement free bilateral sense of the word). But there is no possible way for the router to know what is or isn't a peer, so it's up to the operator to implement the matching for this supposedly standard community. But guess what, most people don't, and those that do implement the functionality end up writing their own network specific version anyways (either because they want to keep it secret, or because they need to implement far more powerful version anyways). If we want to turn this into a discussion on useful things to do with communities (to try and recover some value from this otherwise brain rotting thread), how about this one. We as network operators are currently facing a problem with BGP communities, and that problem is called 32 bit ASNs. Quite simply, 32 bit ASNs don't fit into the existing 16:16 scheme. There are new 64 bit communities (extended communities) out there, but they aren't a 1:1 mapping of the way communities work today. Rather than simply double the size and break it up into 32:32, the designers reserved the top 16 bits for type and subtype attributes, leaving you only 48 bits to work with. Clearly the only suitable mapping for support of 32-bit ASNs on the Internet is 32:16, leaving us with exactly the same range of data values that we have today. So why do I bring this up? Because of those top 16 bits for type and subtype. Two of the type fields that are newly introduced in extended communities are target and origin, which specifically mean this tag is trying to tell $ASN something, vs this $ASN is trying to tell you something. This actually has the benefit of addressing one of the most common problems with communities today, namespace collision between folks trying to both send instructions and receive data within the same ASN:x tag. Since we're all going to need to start updating our routing policies to support 32 bit ASNs soon anyways (unless you want to tell people getting them that they aren't allowed to use communities :P), now is a good time to start thinking about taking advantage of these new features to resolve age-old problems in your new community design. Another feature I think would be beneficial for router vendors to consider implementing is a way to map between regular and extended communities. For example, I might be able to apply a policy at the edge of my network which imports regular communities from my neighbor, and turns them into origin: tags of extended communities. I might then be able to update my internal network to work on extended communities, and translate them back again to regular for backwards compatibility at the edge. Also, now is a good time to find out if your router vendor ACTUALLY supports extended communities in all of their features (for example, regexp support), or if they only exist for l3vpn support and are not actually prepared to use them to work with 32-bit ASNs. Hint: Some vendors still fall into this category last I looked. Apologies if this post contained too much clever and made Randy's head explode. -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
RE: Upstream BGP community support
(Apologies for top-replying, but hey, it makes it easier to ignore stuff you've already read.) I think the main things to consider in identifying what things belong in a standardized community are: - is it something that is really global, and not local, in behaviour and scope? - is it something that is mostly a signalling-of-intent flag, and not a modification of path-selection? -- (because) It should not require universal adoption to be useful - if it is ignored by A, and passed to B, will it still be useful/semantically correct? - is it something that will either be applied by the originator to all instances of a given prefix (i.e. sending X to neighbour A and neighbour B, with community M); - or something that will be applied by the originator to some instances of a given prefix (i.e. sending X to A with N, and X to B without N) - is the intent being signalled easily understood, ideally in an absolute sense? The two things I can think of, which would benefit from such a community, and where nearly-universal adoption would be of significant benefit, are: (1) Blackhole this prefix, and; (2) Use this prefix as a last resort only. (Please add to this list if you think of any other cases meeting the above criteria). Comments on particular proposed-standard-community cases follows... I bring up (2) because it is otherwise *very* difficult to signal (or achieve), and often leads to potential wedgies. The existing mechanisms to achieve (2) are often indistinguishable from Traffic Engineering - but this is very much not TE. TE is reduce load on this instance. (2) is Don't use this for traffic unless you have no paths not marked with this community. TE will typically be observed with small numbers of AS-prepending. (2) will be observed with large numbers of AS-prepending. And, my guess would be, 80% of the prepending would not be needed if (2) were standardized and in use. It might even reduce significantly the observed instances of wedgies and/or persistent oscillations in the wild. Brian -Original Message- From: Jack Bates [mailto:jba...@brightok.net] Sent: November-02-09 4:03 PM To: Joel Jaeggli Cc: nanog@nanog.org Subject: Re: Upstream BGP community support Joel Jaeggli wrote: more accessible and therefore more likely to be used, I don't think traffic engineering is something I particularly want to encourage to excess but RTBH is a know that more people need access to quite frankly. I think creating a standard or at least a template might push more people to adopt communities support and to use them. There are definitely times it is useful to redirect traffic 2 ASN's away through a longer route. In some cases (like my small self, I try to adopt policies that allow communities to me to also be rewritten to the corresponding peers communities to alter things as far as 3 ASN's away from my customer. Jack
Re: Upstream BGP community support
The answer is fairly simple. Does your business benefit by having the ability to modify routing strategy as you see fit? hint: we live in a commons
Re: Upstream BGP community support
On Sun, 2009-11-01 at 17:06 +0900, Randy Bush wrote: The answer is fairly simple. Does your business benefit by having the ability to modify routing strategy as you see fit? hint: we live in a commons Yes. I was about to ask Tony what if *their* business benefits by NOT giving you the ability to modify routing strategy as you see fit? What's the answer then? Regards, K. -- ~~~ Karl Auer (ka...@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) GPG fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF signature.asc Description: This is a digitally signed message part
Re: Upstream BGP community support
There is always a peering policy in place and I am sure you have a few requirements in mind and you will be evaluating costs carefully as well as options thoroughly before making a decision on which SP to go for. I am sure technical teams are flexifle to accomodate some bespoke private peering connections and have defined transit products in place so you can always negotiate your timescales w/ them as well as your technical needs. - Original Message From: Paul Wall pauldotw...@gmail.com To: Randy Bush ra...@psg.com Cc: nanog@nanog.org Sent: Sun, November 1, 2009 2:03:26 AM Subject: Re: Upstream BGP community support On Sat, Oct 31, 2009 at 8:25 PM, Randy Bush ra...@psg.com wrote: while i can understand folk's wanting to signal upstream using communities, and i know it's all the rage. one issue needs to be raised. BGP communities are all the rage? I don't think this is new concept or fad. Signaling behaviors as well as informing users of types of routes have been around for awhile. For example, RFC1998 (Aug 1996) outlines some of these behaviors with modifying local preference. Even Sprint was advertising the ability to not advertise or prepend to individual peers back in 2002 (http://web.archive.org/web/20020607092619/www.sprintlink.net/policy/bgp.html). so i ain't sayin' don't do it. after all, who would deny you the ability to show off your bgp macho? How is providing better capabilities for your customers macho? People have been using these knobs 10 years ago and it worked then (just as well as it works now). Drive Slow (as there are trick-or-treaters out tonight)
Re: Upstream BGP community support
On Sat, 31 Oct 2009 19:33:52 CDT, Dorian Kim said: Fact is, regardless of whether you or I think it makes any sense or not is that some peering agreements preclude disclosure of the locations of peering, and in some extreme cases even the disclosure of the existance of said peering. As Louis Mamakos pointed out back in 1992 or so, it's hard to conceal the existence of said peering: http://www-cs-students.stanford.edu/~hansell/humor/wormholes (Unfortunately, this is the only copy online I was able to find, and it's missing the e-mail headers. The one I had has gone astray. Gene Spafford used to have a copy online for a class, but it too appears to have evaporated. Anybody got a pointer to the original? pgpKBgpcvq5Qa.pgp Description: PGP signature
Re: Upstream BGP community support
Andy B. wrote: Hi, Quick question: Would you buy transit from someone who does not support BGP communities? Without reading any more of your post, or any of the replies: - because leadership has a better bandwidth deal - cuz even though shit in one hand is heavier than hope in the other, you can't convince anyone What sucks: - having to deal with transit from someone who performs no filtering whatsoever - dealing with transit who DOESN'T RESPOND TO REQUESTS FOR BGP PEERING - dealing with transits who don't know what v6 is, or won't respond to requests (at all), even though the network who is purchasing their transport has better v6 redundancy than v4. I am AS14270. BGP with me... its been two years... you've got to have an engineer who can set up a session by now, no? Steve
Re: Upstream BGP community support
On Sun, Nov 01, 2009 at 08:09:40PM -0500, Steve Bertrand wrote: I am AS14270. BGP with me... its been two years... you've got to have an engineer who can set up a session by now, no? Sounds like someone needs to send you a copy of They Just Don't Want To Peer With You. :) -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: Upstream BGP community support
Richard A Steenbergen wrote: On Sun, Nov 01, 2009 at 08:09:40PM -0500, Steve Bertrand wrote: I am AS14270. BGP with me... its been two years... you've got to have an engineer who can set up a session by now, no? Sounds like someone needs to send you a copy of They Just Don't Want To Peer With You. :) Well, send it over... I'd like to see a copy of Here's why ...first. Steve
Re: Upstream BGP community support
Richard A Steenbergen wrote: On Sun, Nov 01, 2009 at 08:09:40PM -0500, Steve Bertrand wrote: I am AS14270. BGP with me... its been two years... you've got to have an engineer who can set up a session by now, no? Sounds like someone needs to send you a copy of They Just Don't Want To Peer With You. :) ...and directly to your statement: send the book along. I'm not looking for a 'peer'. This is a situation that my PROVIDER won't set up a BGP SESSION with me, and they continue to STATICALLY ROUTE my ARIN ALLOCATED block to me. They advertise it from their AS. Their AS advertises known bad space to me (which I've complained about). Their AS, In my humble opinion, is completely unreliable and non-trustworthy. My ARIN block is advertised by them, and I HATE it. They will not respond to me when I ask them to allow me to advertise my own space to them. Of course, having them 'listen' for my space, it would also allow me to advertise to other 'providers' which would allow for redundancy Note...I have a /21. It's not like I'm advertising a /24, nor am I trying to do something that isn't in the best interest of my community. Steve
Re: Upstream BGP community support
On Sun, Nov 1, 2009 at 9:43 PM, Steve Bertrand st...@ibctech.ca wrote: Richard A Steenbergen wrote: On Sun, Nov 01, 2009 at 08:09:40PM -0500, Steve Bertrand wrote: I am AS14270. BGP with me... its been two years... you've got to have an engineer who can set up a session by now, no? Sounds like someone needs to send you a copy of They Just Don't Want To Peer With You. :) ...and directly to your statement: send the book along. I'm not looking for a 'peer'. This is a situation that my PROVIDER won't set up a BGP SESSION with me, and they continue to STATICALLY ROUTE my ARIN ALLOCATED block to me. They advertise it from their AS. Their AS advertises known bad space to me (which I've complained about). Their AS, In my humble opinion, is completely unreliable and non-trustworthy. My ARIN block is advertised by them, and I HATE it. They will not respond to me when I ask them to allow me to advertise my own space to them. Of course, having them 'listen' for my space, it would also allow me to advertise to other 'providers' which would allow for redundancy Note...I have a /21. It's not like I'm advertising a /24, nor am I trying to do something that isn't in the best interest of my community. Steve What's the block? -M -- Martin Hannigan mar...@theicelandguy.com p: +16178216079 Power, Network, and Costs Consulting for Iceland Datacenters and Occupants
Re: Upstream BGP community support
On Sun, Nov 1, 2009 at 6:09 PM, Steve Bertrand st...@ibctech.ca wrote: ... I am AS14270. BGP with me... I tried, but I couldn't find you in http://peeringdb.org/ its been two years... you've got to have an engineer who can set up a session by now, no? Steve You might consider just taking matters into your own hands, and getting a connection to an exchange point, adding an entry into peeringdb, and start doing BGP with other folks; announce your /21 directly to people, and it's likely your upstream will suddenly wake up and smell the coffee when they realize you've actually become truly multihomed in spite of them. Nothing shows clue factor quite as much as, well, practical demonstrations--and turning up sessions with other networks at an exchange point is a really good way to let folks see the level at which you're ready to play. Best of luck! Matt
Re: Upstream BGP community support
On Nov 1, 2009, at 5:11 AM, Karl Auer wrote: On Sun, 2009-11-01 at 17:06 +0900, Randy Bush wrote: The answer is fairly simple. Does your business benefit by having the ability to modify routing strategy as you see fit? hint: we live in a commons Yes. I was about to ask Tony what if *their* business benefits by NOT giving you the ability to modify routing strategy as you see fit? What's the answer then? To answer your question, obviously each network should do whatever is in their best interest. But isn't it in a transit provider's best interest to make their customers happy? :) However, I'm pretty sure that's not what Randy meant. Randy frequently (and correctly) points out that the Internet is a shared resource. What you do can affect others. BGP sucks, but it's the only thing we have. So try not to break it. OTOH: The Internet is not a science project. I'm not even going to say any more, since no one should be confused about that today. Transit providers are almost always for-profit companies. These two basic facts create an interesting dynamic. Everyone wants to do what is best for themselves to make more money, but what one network does affects other networks. Finding a happy medium is hard, m-KAY. I personally believe transit providers should support communities. I don't think the added complexity is too dangers, and I think it will help add to the profit of providers. Others may disagree. But as someone (either Richard or Paul, sometimes I have trouble telling them apart) pointed out, it's been happening for a long time. Past performance is no guarantee of future profit, but it does give one at least a little confidence that supporting community tags will not collapse the Internet tomorrow. End of day, I'll just fall back on what I always say: Your Network, Your Decision. But try to remember that Your Network is connected to everyone else's network. -- TTFN, patrick
Re: Upstream BGP community support
jim deleskie wrote: Agree'd :) On Sat, Oct 31, 2009 at 9:34 PM, Randy Bush ra...@psg.com wrote: Here is the problem as I see it. Sure some % fo the people using BGP are bright nuff to use some upstreams communities, but sadly many are not. So this ends up breaking one or more networks, who in turn twist more dials causing other changes.. rinse, wash and repeat. But like Randy said who am I to stop anyone from playing... just means those of us with clue will be able to continue to earn a pay check for a very long time still :) i would rather earn it by designing things, not by cleaning up messes made by kiddies needing to show off. For those who try their best, given your comment, what in the fsck is one to do? What practices should be followed? Is this about not pushing knobs, or is this about people with big dicks? What really should we do? I mean those with 2691's still in practice. What do we do? We watch for guidance from here. It seems as though people are making a mochary of communities. How many steps am I really behind? Steve
Re: Upstream BGP community support
On Sat, Oct 31, 2009 at 09:37:03PM +0100, Andy B. wrote: While most decent upstream providers support this kind of traffic engineering, one of them refuses to send and accept BGP communities. I tried to contact my upstream several times through different channels to get some background as to why they would not be able to provide us this service, but all we get is tickets that get closed without an answer. Management itself does not seem to bother either. Is this normal or is it too much to ask for BGP communities from an upstream who has points of presence in the US, Europe and Asia? Yes and no. There are a handful of old stodgy networks who are of the belief that this kind of information is proprietary, and therefore should not be sent to customers or other networks on the Internet. My opinion is that those networks are idiots, and therefore money should not be sent to them. Even if (for whatever reason) you don't need a particular set of features in BGP communities, I personally think that they are an excellent indicator of the networks' general technical competence and ability to work with them on a wide variety of other issues. In this day and age a robust and functional set of communities should really be a requirement for any network provider. shamelessplug There was also a NANOG presentation on a pretty reasonable design and implementation of BGP communities for a service provider: http://www.nanog.org/meetings/nanog40/presentations/BGPcommunities.pdf /shamelessplug -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: Upstream BGP community support
On Sat, Oct 31, 2009 at 09:37:03PM +0100, Andy B. wrote: Hi, Quick question: Would you buy transit from someone who does not support BGP communities? No. -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE
Re: Upstream BGP community support
On Sat, Oct 31, 2009 at 7:00 PM, Andy B. globic...@gmail.com wrote: In this day and age a robust and functional set of communities should really be a requirement for any network provider. We're almost 2010. Hurricane Electric, please do something about it! maybe bake them a cake? -chris
Re: Upstream BGP community support
On Sun, Nov 01, 2009 at 12:00:20AM +0100, Andy B. wrote: I would not say that my upstream is an old stodgy network and certainly will I not consider them as idiots, because they seem to know what they are doing. I'd rather say they are pretty ignorant when it comes to some advanced customer requirements. By they, I am referring myself to Hurricane Electric. But you are right: money should not be sent to them while they lack any kind of BGP community support. Wow, really? I would never have guessed in a million years that HE would have a problem supporting communities. Typically lack of community support falls into one of two categories. 1) Old stodgy tier 1's who have communities but don't want to share them with the world, because of silly NDA concerns or the like. This covers a wide variety of positions, from we won't export them to anyone to you have to sign some paperwork and/or yell a lot to get the secret decoder ring. 2) Those who lacks communities completely. IMHO both are idiots, but category #2 is a special breed which you should avoid like the plague. A common problem for service providers who lack communities is the inability to control their advertisements properly. Consider what happens when they have a multihomed customer who typically announces a prefix through them, but who decided to stop for some reason. They then end up hearing that prefix via some other route, such as a peer or transit provider, but without a community tag to know that it wasn't learned from a customer they will blindly readvertise it, providing unintentional (and typically unwanted) transit. -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: Upstream BGP community support
On Sat, Oct 31, 2009 at 06:27:38PM -0500, Richard A Steenbergen wrote: 1) Old stodgy tier 1's who have communities but don't want to share them with the world, because of silly NDA concerns or the like. This covers a I'm curious, since when did respecting bounds of contracts and agreements one has signed become stodgy? -dorian
Re: Upstream BGP community support
Andy B. wrote: I tried to contact my upstream several times through different channels to get some background as to why they would not be able to provide us this service, but all we get is tickets that get closed without an answer. Management itself does not seem to bother either. Completely separate from your question about BGP community support policies, the quoted text above is a stopper for me. Any company that wants my money shouldn't close tickets without an answer - about anything, ever. This is a huge customer support red-flag issue for me. As always, YMMV. jc
Re: Upstream BGP community support
On Sat, Oct 31, 2009 at 06:35:31PM -0500, Dorian Kim wrote: On Sat, Oct 31, 2009 at 06:27:38PM -0500, Richard A Steenbergen wrote: 1) Old stodgy tier 1's who have communities but don't want to share them with the world, because of silly NDA concerns or the like. This covers a I'm curious, since when did respecting bounds of contracts and agreements one has signed become stodgy? There is no excuse for not being able to tell people where you learned a route from (continent, region, city, country, etc). I'm personally of the opinion that this is a good thing to share with the entire Internet, as it lets people make intelligent TE decisions for your routes even if they don't have a direct relationship with your network. You should also be able to at a minimum allow no-export or prepend to specific ASNs, and not being able to provide these to customers is absolutely grounds for should never ever buy from status. The we aren't allowed to say we're a peer argument seems easily defeatable, realistically if you're a stodgy tier 1 all you need is this is a customer tag and you can figure out the rest with not a customer logic without explicitly violating any NDAs. The alter export attributes within a specific region argument is a somewhat legitimate one due to requirements for consistent announcements, but I prefer to enable it by default and deal with unhappy peers on a case by case basis. -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: Upstream BGP community support
while i can understand folk's wanting to signal upstream using communities, and i know it's all the rage. one issue needs to be raised. bgp is a brilliant information hiding protocol. policy is horribly opaque. complexity abounds. and it has unfun consequences, e.g. see tim on wedgies etc. and this just adds to the complexity and opacity. so i ain't sayin' don't do it. after all, who would deny you the ability to show off your bgp macho? just try to minimize its use to only when you *really* need it. randy
Re: Upstream BGP community support
Here is the problem as I see it. Sure some % fo the people using BGP are bright nuff to use some upstreams communities, but sadly many are not. So this ends up breaking one or more networks, who in turn twist more dials causing other changes.. rinse, wash and repeat. But like Randy said who am I to stop anyone from playing... just means those of us with clue will be able to continue to earn a pay check for a very long time still :) -jim On Sat, Oct 31, 2009 at 9:25 PM, Randy Bush ra...@psg.com wrote: while i can understand folk's wanting to signal upstream using communities, and i know it's all the rage. one issue needs to be raised. bgp is a brilliant information hiding protocol. policy is horribly opaque. complexity abounds. and it has unfun consequences, e.g. see tim on wedgies etc. and this just adds to the complexity and opacity. so i ain't sayin' don't do it. after all, who would deny you the ability to show off your bgp macho? just try to minimize its use to only when you *really* need it. randy
Re: Upstream BGP community support
On Sat, Oct 31, 2009 at 06:49:03PM -0500, Richard A Steenbergen wrote: I'm curious, since when did respecting bounds of contracts and agreements one has signed become stodgy? There is no excuse for not being able to tell people where you learned a route from (continent, region, city, country, etc). I'm personally of the opinion that this is a good thing to share with the entire Internet, as it lets people make intelligent TE decisions for your routes even if they don't have a direct relationship with your network. You should also be able to at a minimum allow no-export or prepend to specific ASNs, and not being able to provide these to customers is absolutely grounds for should never ever buy from status. The we aren't allowed to say we're a peer argument seems easily defeatable, realistically if you're a stodgy tier 1 all you need is this is a customer tag and you can figure out the rest with not a customer logic without explicitly violating any NDAs. The alter export attributes within a specific region argument is a somewhat legitimate one due to requirements for consistent announcements, but I prefer to enable it by default and deal with unhappy peers on a case by case basis. This is a strawman argument. I never said that any of the above was a bad thing, nor that transit providers shouldn't support them. They should. Only point I was addressing was your characterisation that networks who do support various communities but do not publish those supported communities were stodgy becuase they were doing so due to silly NDA concerns or the like. Fact is, regardless of whether you or I think it makes any sense or not is that some peering agreements preclude disclosure of the locations of peering, and in some extreme cases even the disclosure of the existance of said peering. So if you were a party to such an agreement, you can not disclose things you are bound from doing without breeching the agreement. Apologies to the list for the derail, -dorian
Re: Upstream BGP community support
Here is the problem as I see it. Sure some % fo the people using BGP are bright nuff to use some upstreams communities, but sadly many are not. So this ends up breaking one or more networks, who in turn twist more dials causing other changes.. rinse, wash and repeat. But like Randy said who am I to stop anyone from playing... just means those of us with clue will be able to continue to earn a pay check for a very long time still :) i would rather earn it by designing things, not by cleaning up messes made by kiddies needing to show off. randy
Re: Upstream BGP community support
Agree'd :) On Sat, Oct 31, 2009 at 9:34 PM, Randy Bush ra...@psg.com wrote: Here is the problem as I see it. Sure some % fo the people using BGP are bright nuff to use some upstreams communities, but sadly many are not. So this ends up breaking one or more networks, who in turn twist more dials causing other changes.. rinse, wash and repeat. But like Randy said who am I to stop anyone from playing... just means those of us with clue will be able to continue to earn a pay check for a very long time still :) i would rather earn it by designing things, not by cleaning up messes made by kiddies needing to show off. randy
Re: Upstream BGP community support
On Sat, Oct 31, 2009 at 07:33:52PM -0500, Dorian Kim wrote: This is a strawman argument. I never said that any of the above was a bad thing, nor that transit providers shouldn't support them. They should. Only point I was addressing was your characterisation that networks who do support various communities but do not publish those supported communities were stodgy becuase they were doing so due to silly NDA concerns or the like. Fact is, regardless of whether you or I think it makes any sense or not is that some peering agreements preclude disclosure of the locations of peering, and in some extreme cases even the disclosure of the existance of said peering. So if you were a party to such an agreement, you can not disclose things you are bound from doing without breeching the agreement. Ok I think we're commingling issues. As I said in my first message, I apply the stodgy label to folks who won't export any communities at all because they're considered proprietary. In my second message I was trying to expand on their considerations (i.e. NDA concerns), which didn't come across well. Clearly there are a large variety of communities you can support which don't come with any such concerns. Obviously any time NDAs are involved you have to give them some serious consideration, but the question becomes at what point does an excessive concern start degrading the quality of service you provider to your customers for no reason. My opinion is that an NDA preventing you from disclosing who you peer with and in what locations means you shouldn't put up a website with the address of every interconnection address and capacity, not that you can't say this route goes to the Chicago region. At a certain point there is only so much information you can obscure. I'm going to be able to figure out who your customers are when I see you readvertising them to the Internet. I'm going to be able to figure out where you peer because I can read the DNS in your traceroute and then walk around the major colo facilities until I see your router with the label on front, does this mean you can't use reverse DNS or label your routers? At some point all you're doing by obscuring most of this information is making it harder for me the customer, peer, or remote party who just happens to be exchanging information with someone on your network, resulting in poorer quality service for your customers. And I'll conclude my argument with this: whois -h whois.radb.net | grep remarks: If Level 3 can tag routes with pop codes, cities, and peer/customer origin tags, then you (for some value of you by which I mean anyone who might ever get the stodgy label :P) can too. -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: Upstream BGP community support
On Sat, Oct 31, 2009 at 08:03:12PM -0500, Richard A Steenbergen wrote: And I'll conclude my argument with this: whois -h whois.radb.net | grep remarks: Err insert AS3356 in there, sorry failure in proofreading. I'll leave it there, but clearly this is being done by many other large networks without the world ending. And if you're a stodgy network reading this, maybe this explains where all your customers are going. :) -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: Upstream BGP community support
Being the architect/head-nerd-in-charge of a fairly new network. Not reading ras's HOWTOs and others is suicide There's no excuse... It really makes running your network easier.. If my customer needs to prepend X to Y transit/peer/customer or not announce to them at 3am, that means they don't have to call me... My customers like it, and so do I. RTFM and we'll all be happier... On 10/31/09, Richard A Steenbergen r...@e-gerbil.net wrote: On Sat, Oct 31, 2009 at 09:37:03PM +0100, Andy B. wrote: While most decent upstream providers support this kind of traffic engineering, one of them refuses to send and accept BGP communities. I tried to contact my upstream several times through different channels to get some background as to why they would not be able to provide us this service, but all we get is tickets that get closed without an answer. Management itself does not seem to bother either. Is this normal or is it too much to ask for BGP communities from an upstream who has points of presence in the US, Europe and Asia? Yes and no. There are a handful of old stodgy networks who are of the belief that this kind of information is proprietary, and therefore should not be sent to customers or other networks on the Internet. My opinion is that those networks are idiots, and therefore money should not be sent to them. Even if (for whatever reason) you don't need a particular set of features in BGP communities, I personally think that they are an excellent indicator of the networks' general technical competence and ability to work with them on a wide variety of other issues. In this day and age a robust and functional set of communities should really be a requirement for any network provider. shamelessplug There was also a NANOG presentation on a pretty reasonable design and implementation of BGP communities for a service provider: http://www.nanog.org/meetings/nanog40/presentations/BGPcommunities.pdf /shamelessplug -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) -- Sent from my mobile device
Re: Upstream BGP community support
On Sun, Nov 1, 2009 at 2:13 AM, Tim Jackson jackson@gmail.com wrote: Being the architect/head-nerd-in-charge of a fairly new network. Not reading ras's HOWTOs and others is suicide There's no excuse... It really makes running your network easier.. If my customer needs to prepend X to Y transit/peer/customer or not announce to them at 3am, that means they don't have to call me... That's exactly what I expect from a decent upstream. So far all our upstreams (Level3, Cogent, Tata), with the exception of HE, provide this service. I don't even care about receiving their communities which describe where the prefix has been injected, since I can handle outbound traffic more or less myself. It's a nice-to-have feature though. It's the inbound that I cannot control without a little help from my upstreams, hence our desperate need to send BGP communities. Andy
Re: Upstream BGP community support
The answer is fairly simple. Does your business benefit by having the ability to modify routing strategy as you see fit? Yes or no? IMO, the answer is yes. If your business partners aren't on the same page or align correctly with your requirements, seek new ones. tv - Original Message - From: Andy B. globic...@gmail.com To: nanog@nanog.org Sent: Saturday, October 31, 2009 3:37 PM Subject: Upstream BGP community support Hi, Quick question: Would you buy transit from someone who does not support BGP communities? Here is the story: My company is pushing several GBit/s through various upstream providers. We have reached the point where we rely on BGP communitiy support, especially communities that can be sent to the upstream to change the way he announces our prefixes to his peers/transits. While most decent upstream providers support this kind of traffic engineering, one of them refuses to send and accept BGP communities. I tried to contact my upstream several times through different channels to get some background as to why they would not be able to provide us this service, but all we get is tickets that get closed without an answer. Management itself does not seem to bother either. Is this normal or is it too much to ask for BGP communities from an upstream who has points of presence in the US, Europe and Asia? Andy
Re: Upstream BGP community support
On Sat, Oct 31, 2009 at 8:25 PM, Randy Bush ra...@psg.com wrote: while i can understand folk's wanting to signal upstream using communities, and i know it's all the rage. one issue needs to be raised. BGP communities are all the rage? I don't think this is new concept or fad. Signaling behaviors as well as informing users of types of routes have been around for awhile. For example, RFC1998 (Aug 1996) outlines some of these behaviors with modifying local preference. Even Sprint was advertising the ability to not advertise or prepend to individual peers back in 2002 (http://web.archive.org/web/20020607092619/www.sprintlink.net/policy/bgp.html). so i ain't sayin' don't do it. after all, who would deny you the ability to show off your bgp macho? How is providing better capabilities for your customers macho? People have been using these knobs 10 years ago and it worked then (just as well as it works now). Drive Slow (as there are trick-or-treaters out tonight)
