Re: Cogent input

[Stephen Kratzer <kratzers () pa net>]

Should have said "And, they have no plans to deploy IPv6 in the immediate 
future."

On Thursday 11 June 2009 10:33:25 Stephen Kratzer wrote:
> We've only recently started using Cogent transit, but it's been stable
> since its introduction 6 months ago. Turn-up was a bit rocky since we never
> received engineering details, and engineering was atypical in that two eBGP
> sessions were established, one just to advertise loopbacks, and another for
> the actual feed. The biggest issue we have with them is that they don't
> allow deaggregation. If you've been allocated a prefix of length yy,
> they'll accept only x.x.x.x/yy, not x.x.x.x/yy le 24. Yes, sometimes
> deaggregation is necessary or desirable even if only temporarily.
>
> And, they have no plans to support IPv6.
>
> "Cogent's official stance on IPv6 is that we will deploy IPv6 when it
> becomes a commercial necessity. We have tested IPv6 and we have our plan
> for rolling it out, but there are no commercial drivers to spend money
> to upgrade a network to IPv6 for no real return on investment."
>
> Stephen Kratzer
> Network Engineer
> CTI Networks, Inc.
>
> On Thursday 11 June 2009 09:46:45 Justin Shore wrote:
> > I'm in search of some information about Cogent, it's past, present and
> > future.  I've heard bits and pieces about Cogent's past over the years
> > but by no means have I actively been keeping up.
> >
> > I'm aware of some (regular?) depeering issues.  The NANOG archives have
> > given me some additional insight into that (recurring?) problem.  The
> > reasoning behind the depeering events is a bit fuzzy though.  I would be
> > interested in people's opinion on whether or not they should be consider
> > for upstream service based on this particular issue.  Are there any
> > reasonable mitigation measures available to Cogent downstreams if
> > (when?) Cogent were to be depeered again?  My understanding is that at
> > least on previous depeering occasion, the depeering partner simply
> > null-routed all prefixes being received via Cogent, creating a blackhole
> > essentially.  I also recall reading that this meant that prefixes being
> > advertised and received by the depeering partner from other peers would
> > still end up in the blackhole.  The only solution I would see to this
> > problem would be to shut down the BGP session with Cogent and rely on a
> > 2nd upstream.  Are there any other possible steps for mitigation in a
> > depeering event?
> >
> > I also know that their bandwidth is extremely cheap.  This of course
> > creates an issue for technical folks when trying to justify other
> > upstream options that cost significantly more but also don't have a
> > damaging history of getting depeered.
> >
> > Does Cogent still have an issue with depeering?  Are there any
> > reasonable mitigation measures or should a downstream customer do any
> > thing in particular to ready themselves for a depeering event?  Does
> > their low cost outweigh the risks?  What are the specific risks?
> >
> > Thanks
> >   Justin