On Sat, Oct 31, 2009 at 11:09 PM, Richard A Steenbergen <ras@e-gerbil.net> wrote:

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.

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.

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.

We're almost 2010. Hurricane Electric, please do something about it! Andy

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

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

jim deleskie wrote:

Agree'd :)

On Sat, Oct 31, 2009 at 9:34 PM, Randy Bush <randy@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

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 <ras@e-gerbil.net> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

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

Randy Bush expunged (randy@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

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

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

Jack Bates expunged (jbates@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

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:xxxxx 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 <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 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 <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 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 <ras@e-gerbil.net> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

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?

On Sat, Oct 31, 2009 at 8:25 PM, Randy Bush <randy@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)

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 <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 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 <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 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 <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 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?

On Mon, Nov 2, 2009 at 6:36 AM, Randy Bush <randy@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

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 (kauer@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

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, mmmmm-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

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 <ras@e-gerbil.net> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

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". :)

fwiw, - I have a spotless BGP record v6-wise. - even though I am a small provider, I have ops from large providers who will vouch for me - we have s/rtbh everywhere - we ensure that my network does not spam (and if it does, I collapse things quickly) - even though I'm small, I'll entertain legitimate complaints from known ops immediately, and fix them - I have an *extremely* tight iBGP practice happening. Although I'm not a CCIE, I know what I'm doing. To be honest, I think that I could help my upstream. Meh. Here's to no redundancy. Come on guys, without names, feel the clue bat, and finally get back to me. Steve

Steve Bertrand 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.

Perhaps it's time to find a new isp, something called adsl4u.ca doesn't sounds like a wholesale transit provider.

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

On Sun, Nov 1, 2009 at 9:43 PM, Steve Bertrand <steve@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 martin@theicelandguy.com p: +16178216079 Power, Network, and Costs Consulting for Iceland Datacenters and Occupants