RE: Can a Customer take their IP's with them? (Court says yes!)
Why would the other side(new provider) violate ARIN policy and route the space? The court order doesn't apply to ARIN, or the new provider. I'd say it would be a violation of the agreement, but I'm not a lawyer. Just a thought. -M -- Martin Hannigan (c) 617-388-2663 VeriSign, Inc. (w) 703-948-7018 Network Engineer IV Operations & Infrastructure hannigan@verisign.com
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Brad Passwaters Sent: Tuesday, June 29, 2004 12:02 PM To: Matthew Crocker Cc: nanog@nanog.org Subject: Re: Can a Customer take their IP's with them? (Court says yes!)
On Tue, 29 Jun 2004 11:45:40 -0400, Matthew Crocker <matthew@crocker.com> wrote:
The TRO is irrelevant, The courts made the wrong decision,
did anyone
actually think they would have a clue?
Here is the solution:
Perhaps before proposing a solution we should make sure that all the facts are in evidence. I might suggest since at least some of the legal documents are available to you at the url below you take time to read them.
http://www.e-gerbil.net/ras/nac-case/
Its not clear at all that what the courts are proposing is that the customer be allowed to keep the addresses forever, just that they have adequate time for an orderly move. Its also not clear that NAC won't receive comensatation for use of their resources. I think those people who have done service provider moves realize that without the help of their old service provider their life could well be hellish. If the requirements for the lack of IP portability are indeed purely technical and not some effort to hold onto customers then service providers have a duty to make almost any reasonable effort to make the transition as painless as possible
--
Brad Passwaters ------------------------------------------ brad.passwaters@gmail.com
On Tue, 29 Jun 2004 12:27:43 -0400, Hannigan, Martin <hannigan@verisign.com> wrote:
Why would the other side(new provider) violate ARIN policy and route the space?
They would not be legaly obligated to do so by the current TRO. However note this is supposedly a temporay use of IP space. Some normal provider transtition might do end up with the same situation of routing the space. It could also be that the new provider is only used to route their new addresses while NAC in accordence with TRO continues to deliver service under the same conditons as the old agreement for the old address space.
The court order doesn't apply to ARIN, or the new provider. I'd say it would be a violation of the agreement, but I'm not a lawyer. Just a thought.
Did you mean it would not be a violation of the TRO? or where you saying the court counlt require others to break the currnet ARIN agreement/contact? In either case I would tend to agree but also am not a lawyer... In fact one might conclude that indeed the only way to currently prevent the customer from making a smooth transtion would be to stir up a bunch of ISP's and have *them* blackhole the customer purely on their own. Hmm what does "natural and probable consequence" mean again.... Brad
The TRO reads to me along the lines that the customer wants protections from increased charges and fees (anything above normal rates) while they are able to move their equipment away from the co-located facilities. They do not wish to incur expenses from NAC for access to the facilities. I see nothing that would prevent NAC from charging their regular fees and expenses as long as the customer is using the IP space. I do see NAC as being restrained from re-assigning the IP space to another customer prior to the hearing on the merits of the case, and before the customer has had the opportunity to orderly move their equipment to new facilities. TROs usually have a short and finite life, lasting only until a hearing on the merits. If NAC is pursuing increased expenses, fees and other charges (above their contract rates) then perhaps the customer has a case. If that is not the case, then perhaps the court is slightly out of line. The old legal trick of moving a case from Federal Court to a state court, is a common legal tactic where friendly judges and judge shopping can take place ( Think the SCO action against IBM over the Unix/Linux debacle) It also appears there is much more to the story, from both sides, and picking one catch-all paragraph from the TRO does not really tell the story, but tends to spread FUD. Not an attorney........................
The old legal trick of moving a case from Federal Court to a state court, is a common legal tactic where friendly judges and judge shopping can take place ( Think the SCO action against IBM over the Unix/Linux debacle)
It's not a trick - the requirements for removal jurisdiction within the Federal court system are rather strict. And even so, in a non-Fedreal question issue (which this clearly appears to be), Erie requires the use and application of state substantive law to decide the case. Judge shopping sounds interesting, but it's about 99.999% myth.
It also appears there is much more to the story, from both sides, and picking one catch-all paragraph from the TRO does not really tell the story, but tends to spread FUD.
Indeed. Reading the intial filings (which I've yet to have time to find) and the memorandum of order would be necessary before any meaningful discussion should even be considered.
Not an attorney........................
Me either....till mid-2006 or so. -ed ----------------- ed@the7thbeer.com
On Tue, 29 Jun 2004 12:27:43 -0400 "Hannigan, Martin" <hannigan@verisign.com> wrote:
Why would the other side(new provider) violate ARIN policy and route the space? The court order doesn't apply to ARIN, or the new provider. I'd say it would be a violation of the agreement, but I'm not a lawyer. Just a thought.
i suspect this will turn out to be a non-issue, even of the new provider routes the blocks and nac.net strictly obeys the requirements of the TRO. the blocks broken out of the aggregates are probably (i haven't looked) likely to be dropped by filters at many large providers, which will seriously limit their utility. so i think both nac.net and the "new provider" should do the obvious TRO compliant things while nac.net hashes it out in court. the customer will likely discover somewhere down the line that they've shot themselves in the foot, as they won't be able to afford to sue _everyone_ who is dropping their announcements as part of normal filter policy going back many years. i don't think anyone should be changing policies in response to this. let it play out in court. for most ISPs, "change nothing" seems like the smart response. richard -- Richard Welty rwelty@averillpark.net Averill Park Networking 518-573-7592 Java, PHP, PostgreSQL, Unix, Linux, IP Network Engineering, Security
On Tue, 29 Jun 2004, Richard Welty wrote:
i suspect this will turn out to be a non-issue, even of the new provider routes the blocks and nac.net strictly obeys the requirements of the TRO. the blocks broken out of the aggregates are probably (i haven't looked) likely to be dropped by filters at many large providers, which will seriously limit their utility.
We're not talking about a /24 or longer prefix here. Based on the amount of ARIN space Pegasus has and claims they've made, I'd guess they must have somewhere in the neighborhood of a /16 worth of NAC space, probably in several blocks of /24 and shorter. So, how do your filters tell the difference between these broken out NAC routes through a new provider and "multihomed customer routes with the primary provider's connection down"? ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
On Tue, 29 Jun 2004 13:32:30 -0400 (EDT) Jon Lewis <jlewis@lewis.org> wrote:
So, how do your filters tell the difference between these broken out NAC routes through a new provider and "multihomed customer routes with the primary provider's connection down"?
i've played this game from the multi-homed customer side before. you get your second provider to route the smaller space, and you expect the small announcements to be dropped by some ISPs and depend on the aggregate from your first provider to cover your bases there. it only works as long as the first provider continues to provide transit. richard -- Richard Welty rwelty@averillpark.net Averill Park Networking 518-573-7592 Java, PHP, PostgreSQL, Unix, Linux, IP Network Engineering, Security
On Jun 29, 2004, at 1:44 PM, Richard Welty wrote:
On Tue, 29 Jun 2004 13:32:30 -0400 (EDT) Jon Lewis <jlewis@lewis.org> wrote:
So, how do your filters tell the difference between these broken out NAC routes through a new provider and "multihomed customer routes with the primary provider's connection down"?
i've played this game from the multi-homed customer side before. you get your second provider to route the smaller space, and you expect the small announcements to be dropped by some ISPs and depend on the aggregate from your first provider to cover your bases there.
it only works as long as the first provider continues to provide transit.
It works as long as the first provider: 1) Continues to announce the aggregate, which NAC obviously will, and 2) Accepts deaggregates of his own space from peers, which the TRO requires NAC to do. (Not specifically, but if NAC filters this block, the judge almost certainly will find them in contempt.) If it is Pegasus and they have a /16, the point is moot. If it is some guy with a /24 out of non-swamp space, NAC will be providing transit for them. For instance, traffic from, say, Verio will be routed to the aggregate NAC announces, and NAC will have to pass it off to the new transit provider since Verio will not see the /24. This obviously has a cost to NAC, and it could be a high cost if this traffic goes over NAC transit in any real volume. IANAL, but seems like a Very Good Reason to not make the "T"RO permanent. -- TTFN, patrick
On Tue, Jun 29, 2004 at 01:14:05PM -0400, Richard Welty wrote:
On Tue, 29 Jun 2004 12:27:43 -0400 "Hannigan, Martin" <hannigan@verisign.com> wrote:
Why would the other side(new provider) violate ARIN policy and route the space? The court order doesn't apply to ARIN, or the new provider. I'd say it would be a violation of the agreement, but I'm not a lawyer. Just a thought.
i suspect this will turn out to be a non-issue, even of the new provider routes the blocks and nac.net strictly obeys the requirements of the TRO. the blocks broken out of the aggregates are probably (i haven't looked) likely to be dropped by filters at many large providers, which will seriously limit their utility.
I haven't really read the court decision, but there might be ways to work around this, if both providers want. Assign an IP-address to the customer out of the new providers space, dig a tunnel to the old provider, route the customers net through the tunnel.
From the outside it will look like the customer is still connected to the old ISP, but the physical connection goes to the new one.
Did the court actually rule, that the new provider has to announce the network via BGP to its peers or did the court rule, that the customer must be reached via his old IPs for a limited amount of time? The second option can be fullfilled without announcing PA-Space in other networks or something like this. At least if the providers REALLY want to. Yes it is not really nice, but it is just a workaround. Somebody has to think about the costs for the additional traffic (especially for the old provider), but well ... You do not get service for free. Nils
participants (8)
-
Brad Passwaters -
Doug White -
ed＠the7thbeer.com -
Hannigan, Martin -
Jon Lewis -
Nils Ketelsen -
Patrick W Gilmore -
Richard Welty