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