Tier 1 just means they don't pay for ip transit themselves, only Peering. Doesn't mean that it's good transit. Best provider i've ever used is hurricane electric, actually a tier 2 provider, but bigger/better than many tier 1s. On 22 January 2018 at 19:07, Martin List-Petersen <martin@airwire.ie> wrote:

On 22/01/18 20:05, Mike Hammett wrote:

...

I much prefer using WDM transport as opposed to Ethernet\VPLS transport due to it being significantly harder (I try not to say impossible) to oversubscribe. That said, it isn't always available at a decent rate at a given location.

Cogent has a reputation (right or wrong) for running things a little hot.

Have any of you used Cogent Ethernet\VPLS services? What are you experiences? Offlist is fine if you don't want it public.

Never use them without a backup alternative. I've seen more outages, that one would want to ever see from a provider, that would like to be categorised as Tier1.

Especially, when some of these are longer than expected, because there were no cold-spares in the country and the cold-spare needed missed the flight.

/M -- Airwire Ltd. - Ag Nascadh Pobail an Iarthair http://www.airwire.ie Phone: 091-395 000 Registered Office: Moy, Kinvara, Co. Galway, 091-395 000 - Registered in Ireland No. 508961

If only they had decent BGP community support. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Martin List-Petersen" <martin@airwire.ie> To: "Michael Crapse" <michael@wi-fiber.io> Cc: "Mike Hammett" <nanog@ics-il.net>, "NANOG list" <nanog@nanog.org> Sent: Monday, January 22, 2018 8:24:46 PM Subject: Re: Anyone using Cogent Ethernet On 23/01/18 02:12, Michael Crapse wrote:

Tier 1 just means they don't pay for ip transit themselves, only Peering. Doesn't mean that it's good transit. Best provider i've ever used is hurricane electric, actually a tier 2 provider, but bigger/better than many tier 1s.

I'd still categorise Hurricane a lot better than Cogent. Both quality and customer service wise. /M

On 22 January 2018 at 19:07, Martin List-Petersen <martin@airwire.ie> wrote:

...

On 22/01/18 20:05, Mike Hammett wrote:

...

I much prefer using WDM transport as opposed to Ethernet\VPLS transport due to it being significantly harder (I try not to say impossible) to oversubscribe. That said, it isn't always available at a decent rate at a given location.

Cogent has a reputation (right or wrong) for running things a little hot.

Have any of you used Cogent Ethernet\VPLS services? What are you experiences? Offlist is fine if you don't want it public.

Never use them without a backup alternative. I've seen more outages, that one would want to ever see from a provider, that would like to be categorised as Tier1.

Especially, when some of these are longer than expected, because there were no cold-spares in the country and the cold-spare needed missed the flight.

/M -- Airwire Ltd. - Ag Nascadh Pobail an Iarthair http://www.airwire.ie Phone: 091-395 000 Registered Office: Moy, Kinvara, Co. Galway, 091-395 000 - Registered in Ireland No. 508961

-- Airwire Ltd. - Ag Nascadh Pobail an Iarthair http://www.airwire.ie Phone: 091-395 000 Registered Office: Moy, Kinvara, Co. Galway, 091-395 000 - Registered in Ireland No. 508961

These? :-) https://www.nanog.org/meetings/nanog40/presentations/BGPcommunities.pdf ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "James Breeden" <James@arenalgroup.co> To: "Mike Hammett" <nanog@ics-il.net> Cc: "NANOG list" <nanog@nanog.org> Sent: Tuesday, January 23, 2018 12:38:36 PM Subject: BGP Community Support WAS: Re: Cogent vs. HE ;-) WAS: Anyone using Cogent Ethernet While we're on the topic of BGP community support, I'd be interested in the greater group's favorites, pros, and cons of what you want to see in a BGP community support table/system from a provider. Taking notes for a customer.. James W. Breeden Managing Partner logo_transparent_background Arenal Group: Arenal Consulting Group | Acilis Telecom | Pines Media PO Box 1063 | Smithville, TX 78957 Email: james@arenalgroup.co | office 512.360.0000 | cell 512.304.0745 | www.arenalgroup.co From: NANOG <nanog-bounces@nanog.org> on behalf of Mike Hammett <nanog@ics-il.net> Sent: Tuesday, January 23, 2018 8:12 AM Cc: NANOG list Subject: Cogent vs. HE ;-) WAS: Anyone using Cogent Ethernet If only they had decent BGP community support. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Martin List-Petersen" <martin@airwire.ie> To: "Michael Crapse" <michael@wi-fiber.io> Cc: "Mike Hammett" <nanog@ics-il.net>, "NANOG list" <nanog@nanog.org> Sent: Monday, January 22, 2018 8:24:46 PM Subject: Re: Anyone using Cogent Ethernet On 23/01/18 02:12, Michael Crapse wrote:

Tier 1 just means they don't pay for ip transit themselves, only Peering. Doesn't mean that it's good transit. Best provider i've ever used is hurricane electric, actually a tier 2 provider, but bigger/better than many tier 1s.

I'd still categorise Hurricane a lot better than Cogent. Both quality and customer service wise. /M

On 22 January 2018 at 19:07, Martin List-Petersen <martin@airwire.ie> wrote:

...

On 22/01/18 20:05, Mike Hammett wrote:

...

I much prefer using WDM transport as opposed to Ethernet\VPLS transport due to it being significantly harder (I try not to say impossible) to oversubscribe. That said, it isn't always available at a decent rate at a given location.

Cogent has a reputation (right or wrong) for running things a little hot.

Have any of you used Cogent Ethernet\VPLS services? What are you experiences? Offlist is fine if you don't want it public.

Never use them without a backup alternative. I've seen more outages, that one would want to ever see from a provider, that would like to be categorised as Tier1.

Especially, when some of these are longer than expected, because there were no cold-spares in the country and the cold-spare needed missed the flight.

/M -- Airwire Ltd. - Ag Nascadh Pobail an Iarthair http://www.airwire.ie Phone: 091-395 000 Registered Office: Moy, Kinvara, Co. Galway, 091-395 000 - Registered in Ireland No. 508961

-- Airwire Ltd. - Ag Nascadh Pobail an Iarthair http://www.airwire.ie Phone: 091-395 000 Registered Office: Moy, Kinvara, Co. Galway, 091-395 000 - Registered in Ireland No. 508961

I've seen the onestep list but the presentation is helpful. I guess my question was moreso to the people side of communities vs the technicalities of communities - what ones do people find themselves using most often and what do they wish was available from providers that really isn't otherwise out there? James W. Breeden Managing Partner [logo_transparent_background] Arenal Group: Arenal Consulting Group | Acilis Telecom | Pines Media PO Box 1063 | Smithville, TX 78957 Email: james@arenalgroup.co<mailto:james@arenalgroup.co> | office 512.360.0000 | cell 512.304.0745 | www.arenalgroup.co<http://www.arenalgroup.co/> ________________________________ From: christopher.morrow@gmail.com <christopher.morrow@gmail.com> on behalf of Christopher Morrow <morrowc.lists@gmail.com> Sent: Tuesday, January 23, 2018 1:07:29 PM To: Mike Hammett Cc: James Breeden; NANOG list Subject: Re: BGP Community Support WAS: Re: Cogent vs. HE ;-) WAS: Anyone using Cogent Ethernet On Tue, Jan 23, 2018 at 1:40 PM, Mike Hammett <nanog@ics-il.net<mailto:nanog@ics-il.net>> wrote: These? :-) https://www.nanog.org/meetings/nanog40/presentations/BGPcommunities.pdf you could also probably get some good examples cribbed from the collection: https://onestep.net/communities/

On 01/23/18 19:17 +0000, James Breeden wrote:

I've seen the onestep list but the presentation is helpful. I guess my question was moreso to the people side of communities vs the technicalities of communities - what ones do people find themselves using most often and what do they wish was available from providers that really isn't otherwise out there?

The most useful to me: Blackhole this prefix Only advertise this prefix to your customers Prepend my/your ASN to this prefix X number of times Do not readvertise this prefix to any content caches you host and I'd like to see more transits offer BFD. -- Dan White

    Hi,     We have a case when someone decided to create an AS-SET of the same name as ours.     It kinda messed up with our peering (hopefully he got it worst).     Management feedback was mostly "who do we sue?" and we know it isn't that simple.     So,         Any feedback on best practices and "other avenue" about IRR naming?     PS: I have to understand that we're not in the 90's anymore and younglings just don't give a damn :( ----- Alain Hebert ahebert@pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443

On Wed, Jan 24, 2018 at 02:23:48PM +0000, Nick Hilliard wrote:

Alain Hebert wrote:

...

Any feedback on best practices and "other avenue" about IRR naming?

Known problem - you're asking for trouble unless you filter IRRDB queries by source:

There isn't a global namespace for as-set names, unless you use source: as a database key element.

In addition to the above, one could use "hierarchical" AS-SET names, in some databases (from the top of my head: APNIC, AfriNIC, RIPE) only the owner of the ASN can create AS-SETs under that ASN's namespace. But more importantly: using the ASN in the AS-SET name chances of collision are reduced. Example: I defined "AS15562:AS-SNIJDERS" in the RIPE database, instead of "AS-SNIJDERS". Same for "AS2914:AS-GLOBAL" in NTTCOM. --- thread hijack --- Coincidentally, I'm working to define something like "AS-SETs in RPKI". There are a number of downsides to "AS-SETs in IRR": collisions between databases can exist, it is hard to figure out what AS-SET to use for what ASN (we rely on service order forms, peeringdb or guessing for that), and the way the recursion was done can too easily result in gigantic sets. I'd be interested to know what others think about improving feature parity between IRR and RPKI, and while doing that make the bad aspects of AS-SETs go away and keep the good parts. Thoughts? Kind regards, Job ps. raised the question here too https://mail.lacnic.net/pipermail/lacnog/2018-January/005845.html

On Sat, Jan 27, 2018 at 04:30:56PM -0500, Jared Mauch wrote:

On Wed, Jan 24, 2018 at 02:48:58PM +0000, Job Snijders wrote:

...

--- thread hijack ---

Coincidentally, I'm working to define something like "AS-SETs in RPKI". There are a number of downsides to "AS-SETs in IRR": collisions between databases can exist, it is hard to figure out what AS-SET to use for what ASN (we rely on service order forms, peeringdb or guessing for that), and the way the recursion was done can too easily result in gigantic sets.

Obviously you have to prune once you hit a loop, but this is how you can traverse a edge-node graph to find the leaves given a starting point.

...

I'd be interested to know what others think about improving feature parity between IRR and RPKI, and while doing that make the bad aspects of AS-SETs go away and keep the good parts. Thoughts?

I've found that saying RR, IRR and RPKI overloads one technology with another. One needs a standards based method to access a database about routing information. We can federate databases together or come up with methods to do this. RPKI is another database you can validate against but it also has limits.

Yes, I'm moving away from "let us all use this one thing", and rather explore how to integrate all the available data sources (IRR, WHOIS, RPKI, our internal DB, and $the_next_thing) and create more choice for customers. Addressing the various threats that one can model may be resolved through local policy ("data type X from source A overrides data type Y from source B", or merge, or prune actions, etc).

If I were a backbone, I would be asking myself: How can customers effectively communicate with me their intent? RPKI and IRR have weknesses and the networks with automation and tooling here are light years ahead of those that have nothing. [ snip ]

Yeah, a real problem for ISPs is that it isn't clear wat AS-SET to use for what neighbor. - The discovery mechanism that RPSL was to provide is broken beyond repair: import/export lines are unparsable. - I know of route server config generators that query PeeringDB to fetch the "IRR Record" as a starting point to generate filters, but that is sometimes problematic because (a) we may be using the wrong IRR DB in case of duplicate AS-SET names and (b) there is a lack of granularity (you may not want to announce the same as-set to all route-servers). - NTT simply asks customers/peers what as-set to use during the turn-up process, but that as-set name may be deprecated by the peer over time, and the mechanism to inform us is a bit archaic "email us". What I think could be done with RPKI: A mechanism that addresses the autodiscovery, and allows a degree of granularity by allowing you to specify on a per-ASN basis what should be used as the starting point to create a filter will make things better. Toolchains (COTS, closed, and open source) would increase their chances of finding the right starting point if they first try to query the RPKI for information, and if that fails, fall back to either a database record from a service order form or a query to PeeringDB. With "right" I mean the most up to date and most likely intended one. An 'AS-SET in RPKI' statement could also be published in IRR format (by RIRs publishing it under a new "source:" name) to provide some backwards compatibility. This helps address challenges in geographical regions where the whole concept of "IRR" never took off, but RPKI is popular (LATAM comes to mind).

There's no universal way to communicate these relationships yet we have web based platforms where I can tell you what many list members ate for dinner last night. There is a lack of will to take action here and a lack of common toolchains that can be integrated to perform the tasks.

Any platform under end-to-end control of a single entity will be able to innovate and deliver at a much faster pace than something that'll need to facilitate coordination across administrative domains :-)

A few interesting AS_Paths:

2497 701 5511 59378 7473 2914 132602 38203 137038 3356 6453 21502 1299 6848 44216 701 6453 21502 1299 6848 44216

I'll make some phone calls Monday. Kind regards, Job

On Sun, Jan 28, 2018 at 04:02:44AM +0100, Baldur Norddahl wrote:

The hierarchical as-set strategy has the problem that many fails to parse it correctly. We use it at NL-IX with the result that their portal believe we have no peers.

That sounds like a simple bug in that specific portal. If you want, please share details with me off list. I don't believe this to be a common issue. Kind regards, Job

Knowing the relationship between my provider and whomever they are learning the route from is handy. It allows me to do things such as filter on those communities for passing prefixes down into less capable hardware. I may elect to pass customer or customer and peering routes from a given provider down into routers throughout my network with limited FIB capability. They can decide which way to send traffic that should be immediately apparent where the best path is, while leaving the provider edge routers to decide for prefixes beyond that. Say a CCR or a switch with some layer 3 capabilities. Then obviously things like blackhole and (local_pref, prepend, no export, etc. per AS). The above I'd say is rather important. The next step would be location-aware stuff in the presentation that would be nice to have. If your provider is having an issue with an upstream or peer in a given city\region, being able to avoid that would be nice. Of course that assumes you figure out their problem and the work-around before they're able to fix it themselves. Well, assuming it's a short-term issue, anyway. If it's a constant issue, your provider isn't likely to fix it faster than you because they're not fixing it at all. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "James Breeden" <James@arenalgroup.co> To: "NANOG list" <nanog@nanog.org> Sent: Tuesday, January 23, 2018 1:17:45 PM Subject: Re: BGP Community Support WAS: Re: Cogent vs. HE ;-) WAS: Anyone using Cogent Ethernet I've seen the onestep list but the presentation is helpful. I guess my question was moreso to the people side of communities vs the technicalities of communities - what ones do people find themselves using most often and what do they wish was available from providers that really isn't otherwise out there? James W. Breeden Managing Partner [logo_transparent_background] Arenal Group: Arenal Consulting Group | Acilis Telecom | Pines Media PO Box 1063 | Smithville, TX 78957 Email: james@arenalgroup.co<mailto:james@arenalgroup.co> | office 512.360.0000 | cell 512.304.0745 | www.arenalgroup.co<http://www.arenalgroup.co/> ________________________________ From: christopher.morrow@gmail.com <christopher.morrow@gmail.com> on behalf of Christopher Morrow <morrowc.lists@gmail.com> Sent: Tuesday, January 23, 2018 1:07:29 PM To: Mike Hammett Cc: James Breeden; NANOG list Subject: Re: BGP Community Support WAS: Re: Cogent vs. HE ;-) WAS: Anyone using Cogent Ethernet On Tue, Jan 23, 2018 at 1:40 PM, Mike Hammett <nanog@ics-il.net<mailto:nanog@ics-il.net>> wrote: These? :-) https://www.nanog.org/meetings/nanog40/presentations/BGPcommunities.pdf you could also probably get some good examples cribbed from the collection: https://onestep.net/communities/