On Mon, 5 Sep 2011, Jima wrote:
I'm with Frank on this one: ICMP yes, HTTP/HTTPS no, via native IPv6
(multiple locations). No, wait -- it shows as open from a couple tunnels
(both HE & SixXS). So it's not consistent. Lovely.
$ telnet -6 www.savvis.com 80
Trying 2001:460:100:1000::37...
tel
I'm with Frank on this one: ICMP yes, HTTP/HTTPS no, via native IPv6
(multiple locations). No, wait -- it shows as open from a couple
tunnels (both HE & SixXS). So it's not consistent. Lovely.
Closed from:
2607:ff50::/32 (native)
2607:fcd0::/32 (native)
Open from:
2001:1938::/32 (SixXS t
- Original Message -
> From: "Joel jaeggli"
> having customers that want to use your service is rarely a bad thing.
Ask a chief engineer at a national wireless carrier who told his administrative
bosses that selling "unlimited" wireless data was a Pretty Neat Idea if he
thinks that's a g
Strange, not for me.
nagios:/etc/nagios3# ping6 www.savvis.com
PING www.savvis.com(2001:460:100:1000::37) 56 data bytes
64 bytes from 2001:460:100:1000::37: icmp_seq=1 ttl=239 time=55.5 ms
64 bytes from 2001:460:100:1000::37: icmp_seq=2 ttl=239 time=55.4 ms
64 bytes from 2001:460:100:1000::37: icm
In message <007f01cc6c37$0f4ac060$2de04120$@iname.com>, "Frank Bulk" writes:
> A Chrome plugin alerted me to the fact that savvis.com has an for
> www.savvis.com. Unfortunately access to that host over IPv6 is down, too.
>
> Frank
The fault must be local to you. Works fine from here.
Mar
A Chrome plugin alerted me to the fact that savvis.com has an for
www.savvis.com. Unfortunately access to that host over IPv6 is down, too.
Frank
-Original Message-
From: Frank Bulk [mailto:frnk...@iname.com]
Sent: Thursday, September 01, 2011 5:03 PM
To: nanog@nanog.org
Subject: R
>
>> 3. I think the discussion on the list so far misses what I see as the
>> central question about the economic assumptions in that paper. The paper
>> assumes that all destinations are equally valuable, which we know is not the
>> case. This implicitly (and perhaps mistakenly?) shifts the
On 9/3/11 04:20 , Skeeve Stevens wrote:
> Hey all,
>
> I've been thinking about the impact that iCloud (by Apple) will have
> on the Internet.
>
> My guess is that 99% of consumer internet access is Asymmetrical
> (DSL, Cable, wireless, etc) and iCloud when launched will 'upload'
> obscene amount
Nick Feamster wrote:
> 2. I question what fraction of routing decisions come down to a blind
> tiebreak---nearly all of them are likely to be driven by some other
> consideration (reliability, cost, etc.). Our paper details a richer economic
> model by which ASes actually select paths, for exam
On Sep 5, 2011, at 8:36 AM, Joe Maimon wrote:
>
>
> Owen DeLong wrote:
>>
>> On Sep 5, 2011, at 7:24 AM, Jennifer Rexford wrote:
>>
>>>
One could argue that rejecting routes which you previously had no way to
know you should reject will inherently alter the routing system and
Hivelocity has a facility in Tampa. I have a virtual private server
there with someone colo'd there and it's great. Email me off list and
I'll give you the IP address for tracerouting or whatever you need to
do.
-C
On Sep 5, 2011, at 11:51 PM, Nick Feamster wrote:
> If the most "valuable" destinations
'Most valuable', 'least expensive', 'least congested', 'most reliable', 'most
responsive', 'least contractually onerous', 'most generous ratio', 'most
lucrative', et. al. - all these criteria and more come
Three thoughts on the thread so far.
1. I think Randy raises an interesting point about the complexity of contracts.
We had a paper in SIGCOMM this year on the increasing use of more complicated
interconnection contracts (and, in particular, tiered pricing). See Section 2
of our paper [1]:
ht
Owen DeLong wrote:
On Sep 5, 2011, at 7:24 AM, Jennifer Rexford wrote:
One could argue that rejecting routes which you previously had no way to
know you should reject will inherently alter the routing system and that this
is probably a good thing.
Good point. Also, "tie breaking" in fa
On Sep 5, 2011, at 7:24 AM, Jennifer Rexford wrote:
>
>>
>> One could argue that rejecting routes which you previously had no way to
>> know you should reject will inherently alter the routing system and that this
>> is probably a good thing.
>
> Good point. Also, "tie breaking" in favor of s
On Sep 4, 2011, at 9:18 PM, Patrick W. Gilmore wrote:
> I would like the large networks of the world to state whether they prefer
> their customer routes over peer routes, and how. For instance, does $NETWORK
> prefer customers only when the AS path is the same, or all the time no matter
> wh
On Sep 5, 2011, at 11:55 AM, Dobbins, Roland wrote:
> The idea of origin validation is a simple one. The idea of path validation
> isn't to determine the 'correctness' or 'desirability' of a
> particular AS-path, but rather to determine the *validity* (or at least the
> *feasability*) of a give
>
> One could argue that rejecting routes which you previously had no way to
> know you should reject will inherently alter the routing system and that this
> is probably a good thing.
Good point. Also, "tie breaking" in favor of signed-and-verified routes over
not-signed-and-verified routes d
On Sep 5, 2011, at 5:47 AM, Leo Bicknell wrote:
> In a message written on Sun, Sep 04, 2011 at 04:16:45PM -0400, Sharon
> Goldberg wrote:
>> An ISP might deploy S*BGP in order to increase the volume of traffic
>> that it transits for its customers.
>
> I think this phrase summarizes the problem
In a message written on Sun, Sep 04, 2011 at 04:16:45PM -0400, Sharon Goldberg
wrote:
> An ISP might deploy S*BGP in order to increase the volume of traffic
> that it transits for its customers.
I think this phrase summarizes the problem with this argument nicely.
If, as an ISP, deploying a "sec
Hi Jen,
> Thanks for the suggestion! Yes, I would encourage interested people to
> contact me. We won't be able to put everyone on the working group (in the
> interest of having a small enough group to make progress), but we are very
> interested in having people who can offer their expertise,
> One crucial way in which S*BGP differs from other features is that
> ASes which deploy S*BGP *must* use their ability to validate paths to
> inform route selection
not really. you may wish to read the bgpsec docs, in particular
draft-ietf-sidr-bgpsec-ops
randy
22 matches
Mail list logo
