[71811] in North American Network Operators' Group
Re: Can a customer take IP's with them?
daemon@ATHENA.MIT.EDU (Richard Welty)
Wed Jun 23 22:13:42 2004
Date: Wed, 23 Jun 2004 22:10:30 -0400 (EDT)
From: Richard Welty <rwelty@averillpark.net>
To: nanog@merit.edu
In-Reply-To: <MDEHLPKNGKAHNMBLJOLKIEGCMNAA.davids@webmaster.com>
Errors-To: owner-nanog-outgoing@merit.edu
On Wed, 23 Jun 2004 18:40:06 -0700 David Schwartz <davids@webmaster.com> wrote:
> > a TRO against nacs.net has no effect on the behavior of providers
> > such as verio who won't honor the advertisement of the subnet
> > in BGP. the customer would have to, one-by-one i think, go after
> > everybody with the relatively common policy of ignoring such
> > advertisements (isn't sprint one of these? that'd be a pretty big
> > hunk of internet to be disconnected from. sprint having no
> > contractual relationship with the idiot, er, customer in question,
> > it'd be hard for the customer to get anywhere there.)
> >
> > in other words, by itself the requested TRO incompletely solves
> > the problem, making it fairly pointless.
> We don't know enough about the specifics to know if this argument works or
> not. There are two obvious cases where it doesn't:
> 1) The block in question is large enough (or located in legacy space) such
> that most/all providers will listen to it anyway.
maybe. many filtering policies against legacy space are pretty severe
(e.g., filter at /16 for legacy B space.) you'd have to have a block of /20
or larger for modern allocations.
> 2) The customer's new provider meets with their old provider directly and
> the new block is inside a larger block the original provider will continue
> to advertise. (This is a very common case if both providers are large.)
> It's worth pointing out, however, that if case 2 applies and case 1
> doesn't, then the ISP will still be providing a level of actual packet
> carrying service to the customer.
bzzzzt. if the ISPs have sensible policy implementations at the border,
nobody will be be providing free transit because of accidents of
adjacency.
richard
--
Richard Welty rwelty@averillpark.net
Averill Park Networking 518-573-7592
Java, PHP, PostgreSQL, Unix, Linux, IP Network Engineering, Security
