Re: Abuse response [Was: RE: Yahoo Mail Update]

[Joe Abley]

On 16 Apr 2008, at 13:33 , Simon Waters wrote:

Ask anyone in the business "if I want a free email account who do I  
use.." and

you'll get the almost universal answer Gmail.


I think amongst those not in the business there are regional trends,  
however. Around this neck of the woods (for some reason) the answer  
amongst your average, common-or-garden man in the street is "yahoo!".


I don't know why this is. But that's my observation.

There are also the large number of people using Y! mail who don't  
realise they're using Y! mail, because the telco or cableco they use  
for access have outsourced mail operations to Y!, and there are still  
(apparently) many people who assume that access providers and mail  
providers should match. In those cases choice of mail provider may  
have far more to do with "price of tv channel selections" or  
"availability of long-distance voice plans" than anything to do with e- 
mail.


So, with respect to your other comments, correlation between technical/ 
operational competence and customer choice seems weak, from my  
perspective. If there's competition, it may not driven by service  
quality, and the conclusion that well-staffed abuse desks promote  
subscriber growth is, I think, faulty.



Joe

Re: Abuse response [Was: RE: Yahoo Mail Update]

[Joe Abley]

On 15 Apr 2008, at 11:22 , William Herrin wrote:


There's a novel idea. Require incoming senior staff at an email
company to work a month at the abuse desk before they can assume the
duties for which they were hired.


At a long-previous employer we once toyed with the idea of having  
everybody in the (fairly small) operations and architecture/ 
development groups spend at least a day on the helpdesk every month.


The downside to such a plan from the customer's perspective is that  
I'm pretty sure most of us would have been really bad helpdesk people.  
There's a lot of skill in dealing with end-users that is rarely  
reflected in the org chart or pay scale.



Joe

Re: Problems sending mail to yahoo?

[Joe Abley]

On 10 Apr 2008, at 23:58 , Rob Szarka wrote:


At 02:23 PM 4/10/2008, you wrote:
Maybe we all should do the same to them until they quit spewing out  
all the
Nigerian scams and the like that I've been seeing from their  
servers lately!




If there were an coordinated boycott, I would participate. Yahoo is  
*by far* the worst single abuser of our server among the  
"legitimate" email providers.


Having done my own share of small-scale banging-of-heads-against-yahoo  
recently, the thing that surprised me was how many people with non- 
yahoo addresses had their mail handled by yahoo. It turns out that if  
Y! doesn't want to receive mail from me, suddenly I can't send mail to  
anybody in my extended family, or to most people I know in the town  
where I live. These involve domains like ROGERS.COM and  
BTINTERNET.COM, and not just the obvious Y! domains.


In my more paranoid moments I have wondered how big a market share Y!  
now has in personal e-mail, given the number of large cable/telcos who  
have outsourced mail handling to them for their residential products.  
Once you pass a certain threshold, the fact that Y! subscribers are  
the only people who can reliably deliver mail to other Y! subscribers  
provides a competitive advantage and a sales hook to make the resi  
mail empire even larger. At that point it makes no sense for Y! to  
expend effort to accept *more* mail from subscribers of other services.


To return to the topic at hand, you may already have outsourced the  
coordination of your boycott to Yahoo!, too! They're already not  
accepting your mail. There's no need to stop sending it! :-)



Joe

Re: rack power question

[Joe Abley]

On 25 Mar 2008, at 09:11 , Dorn Hetzel wrote:

It would sure be nice if along with choosing to order servers with  
DC or AC power inputs one could choose air or water cooling.


Or perhaps some non-conductive working fluid instead of water.  That  
might not carry quite as much heat as water, but it would surely  
carry more than air and if chosen correctly would have more benign  
results when the inevitable leaks and spills occur.


The conductivity of (ion-carrying) water seems like a sensible thing  
to worry about. The other thing is its boiling point.


I presume that the fact that nobody ever brings that up means it's a  
non-issue, but it'd be good to understand why.


Seems to me that any large-scale system designed to distribute water  
for cooling has the potential for hot spots to appear, and that any  
hot spot that approaches 100C is going to cause some interesting  
problems.


Wouldn't some light mineral oil be a better option than water?


Joe

Re: Transition Planning for IPv6 as mandated by the US Govt

[Joe Abley]

On 17-Mar-2008, at 06:07, <[EMAIL PROTECTED]>  
<[EMAIL PROTECTED]> wrote:



If you're providing content or network services on v6 and you
don't have both a Teredo and 6to4 relay, you should - there
are more v6 users on those two than there are on native
v6[1]. Talk to me and I'll give you a pre-built FreeBSD image
that does it, boot off compact flash or hard drives. Soekris
(~$350USD, incl. power supply and CF card), or regular
server/whatever PC.


Pardon me for interfering with your lucrative business here,
but anyone contemplating running a Teredo relay and 6to4 relay
should first understand the capacity issues before buying a
little embedded box to stick in their network.


Do you imagine that Soekris are giving Nathan kick-backs for  
mentioning the price of their boxes on NANOG? :-)


I'm sure for many small networks a Soekris box would do fine. For the  
record, FreeBSD also runs on more capable hardware.



Joe

Re: load balancing and fault tolerance without load balancer

[Joe Abley]

On 14-Mar-2008, at 12:42, Joe Shen wrote:


  Is there any way to solve problem above?


The approach described in  would probably work, so long as the routers choosing between the  
ECMP routes are able to make route selections per flow, and not just  
per packet (e.g. "ip cef" on a cisco).


Tony Kapela did a lightning talk a few meetings ago about another  
cisco-specific approach which used some kind of SLA-measuring cisco  
feature to do the same thing without needing to run a routing protocol  
on a server. I can't seem to find a link to the details, but if  
someone else knows where it is it'd be good to know.



Joe

Re: IPv6 on SOHO routers?

[Joe Abley]

On 12-Mar-2008, at 16:06, Frank Bulk - iNAME wrote:


Slightly off-topic, but tangentially related that I'll dare to ask.

I'm attending an "Emerging Communications" course where the instructor
stated that there are SOHO routers that natively support IPv6,  
pointing to

Asia specifically.

Do Linksys, D-Link, Netgear, etc. have such software for the Asian  
markets?


I seem to think I've seen SOHO routers (or "gateways" I suppose,  
assuming that these boxes are rarely simply routers) on display at  
beer'n'gear-type venues at APRICOT meetings, going back several years.  
The glossy pamphlets have long since been discarded, so I can't tell  
you names of vendors.


More mainstream for this market, Apple's airport extreme "SOHO router"  
does IPv6.


  http://www.apple.com/airportextreme/specs.html

I have not had the time to figure out what "does IPv6" means, exactly  
(DHCPv6? IPv6 DNS resolver?) but I seem to think it will provide route  
advertisements and route out either using 6to4 or a manually- 
configured tunnel.



Joe

Re: Qwest desires mesh to reduce unused standby capacity

[Joe Abley]

On 28-Feb-2008, at 09:26, Adrian Chadd wrote:

Then you probably haven't been on the ass end of a continental fibre  
link

drop. That actually mattered.


If both sides of your SONET ring drop, then surely you're as dead in  
the water as you would be if each side of the ring was being used as a  
separate, unprotected circuit.


(But quite possibly I'm missing your point.)


Joe

Re: Qwest desires mesh to reduce unused standby capacity

[Joe Abley]

On 28-Feb-2008, at 01:56, Paul Wall wrote:

UU/MFS tried running IP on the 'protect' path of their SONET rings  
10 years ago. It didn't work then.


Well, it works so long as whoever was trying to troubleshoot the  
circuits at 3am on US Thanksgiving understands that having the system  
"switch to protect" is quite bad, in the sense that it causes both  
sides to go down at once (I seem to remember there was a protect paths  
built for each side of the original ring using a loopback).


Other than the unfamiliarity with the concept demonstrated by phone  
companies, I didn't notice any great fundamental problem with the  
idea. The extra 10G of capacity across the Atlantic was arguably more  
useful in the grand scheme of things than the being able to recover  
from a single-point failure at SONET speeds. It's probably fair to say  
there's more real-time traffic on the network today than there was  
then, however.


I have never worked for UU/MFS, lest anybody draw that conclusion.


Joe

Re: IETF Journal Announcement (fwd)

[Joe Abley]

On 27-Feb-2008, at 15:09, Mark Smith wrote:


Don't worry if the ISOC website times out, their firewall isn't TCP
ECN compatible.


Isn't it the case in the real world that the Internet isn't TCP ECN  
compatible?


I thought people had relegated that to the "nice idea but, in  
practice, waste of time" bucket years ago.



Joe

Re: Aggregation for IPv4-compatible IPv6 address space

[Joe Abley]

On 4-Feb-2008, at 00:19, Scott Morris wrote:


You mean do you have to express it in hex?


There are two related things here: (a) the ability to represent a 32- 
bit word in an IPv6 address in the form of a dotted-quad, and (b) the  
legitimacy of an IPv6 address of the form ::A.B.C.D, where A.B.C.D is  
an IPv4 address.


(a) is a question about the presentation of IPv6 addresses. (b) is a  
question about the construction of IPv6 addresses to be used in packet  
headers.


I believe (a) is still allowed. However, (b) is not allowed. Since (b)  
is not allowed, (a) is arguably not very useful.



Joe

Re: Cost per prefix [was: request for help w/ ATT and terminology]

[Joe Abley]

On 20-Jan-2008, at 15:34, William Herrin wrote:


Perhaps your definition of "entry level DFZ router" differs from mine.
I selected a Cisco 7600 w/ sup720-3bxl or rsp720-3xcl as my baseline
for an entry level DFZ router.


A new cisco 2851 can be found for under $10k and can take a gig of  
RAM. If your goal is to have fine-grained routing data, and not to  
carry gigs of traffic, that particular router is perfectly adequate.


If you're prepared to consider second-hand equipment (which seems  
fair, since it's not as though the real Internet has no eBay VXRs in  
it) you could get better performance, or lower cost, depending on  
which way you wanted to turn the dial.


Sometimes it's important to appreciate that the network edge is bigger  
than the network core. Just because this kind of equipment wouldn't  
come close to cutting it in a carrier network doesn't mean that they  
aren't perfectly appropriate for a large proportion of deployed  
routers which take a full table.



Joe

Re: v6 gluelessness

[Joe Abley]

On 18-Jan-2008, at 18:56, Randy Bush wrote:


The .com/.net registry has supported  RRs for over five years
(since May, 2002).  The issue you may be encountering is that not
every .com/.net registrar supports them.


way cool.

do you happen to know if opensrs registrars have a path to do so?


Typing "IPv6" into the search box at  returns:


Q: Is IPV6 supported?
A: No. IPV6 is currently not supported.

It's not entirely clear what that means (glue? transport?), but it  
doesn't sound tremendously promising.



Joe

Re: v6 gluelessness

[Joe Abley]

On 18-Jan-2008, at 05:39, Randy Bush wrote:


similarly for the root, as rip.psg.com serves some tlds.

The request has to come from a TLD manager (anyone which uses
rip.psg.com)


i can go down the hall to the mirror and ask myself to ask me to do  
it. :)


:-)


but, of course, you would get a more authoritative reply from IANA.


i am hoping that.


It's the same process that is used to update a delegation in the root  
zone. For ccTLDs I believe there's some kind of web portal to allow  
such changes to be requested, but my experience is that the old text  
form also still works just fine.


I've done this a number of times over the past few years and have not  
had any problems.


I don't know what the process is for getting IPv6 addresses associated  
with host records in the VGRS COM/NET registry, but it seems like good  
information to share here if you find a definitive answer.



Joe

Re: Network Operator Groups Outside the US

[Joe Abley]

On 16-Jan-2008, at 07:09, Rod Beck wrote:

6. I am not aware of any Dutch per se ISP conferences although that  
market is certainly quite vibrant. I am also disappointed to see the  
Canadians and Irish have next to nothing despite Ireland being the  
European base of operations for Google, Microsoft, Amazon, and  
Yahoo. And Canada has over 30 million people. Where is the National  
Pride?




We have played host to a couple of NANOG meetings, you know :-)

And the TorIX community in Toronto has occasional meetings with  
technical content, and has had at least one meeting with no technical  
content but a lot of alcohol and poker.



Joe

Re: Looking for geo-directional DNS service

[Joe Abley]

On 15-Jan-2008, at 12:50, Patrick W. Gilmore wrote:


Anycast gives you BGP distance, not topological distance.


Yeah, it's topology modulated by economics :-)


Joe

Re: BGP Filtering

[Joe Abley]

On 15-Jan-2008, at 11:40, Ben Butler wrote:

Defaults wont work because a routing decision has to be made, my  
transit

originating a default or me pointing a default at them does not
guarantee the reachability of all prefixes..


Taking a table that won't fit in RAM similarly won't guarantee  
reachability of anything :-)


Filter on assignment boundaries and supplement with a default. That  
ought to mean that you have a reasonable shot at surviving de-peering/ 
partitioning events, and the defaults will pick up the slack in the  
event that you don't.


For extra credit, supplement with a bunch of null routes for bogons so  
packets with bogon destination addresses don't leave your network, and  
maybe make exceptions for "golden prefixes".


I am struggling to see a defensible position for why just shy of 50%  
of

all routes appears to be mostly comprised of de-aggregated routes when
aggregation is one of the aims RIRs make the LIRs strive to  
achieve.  If

we cant clean the mess up because there is no incentive than cant I
simply ignore the duplicates.


You can search the archives I'm sure for more detailed discussion of  
this. However, you can't necessarily always attribute the presence of  
covered prefixes to incompetence.



Joe

Re:

[Joe Abley]

On 8-Dec-2007, at 00:18, sana sohail wrote:


I am looking for a typical percentage of external(inter-domain) routes
versus typical percentage of internal (intra-domain) routes in a core
router with couple of hundred thousand entries in the routing table.
Can anyone please help me in this?


I think first you have to decide what a typical AS looks like. The  
question, as it stands, is too general for any answer to be  
(in)defensible.



Joe

Re: General question on rfc1918

[Joe Abley]

On 13-Nov-2007, at 10:35, Robert Bonomi wrote:


On 13-Nov-2007, at 10:08, Drew Weaver wrote:


  Hi there, I just had a real quick question. I hope this is
found to be on topic.

Is it to be expected to see rfc1918 src'd packets coming from
transit carriers?


You should not send packets with RFC1918 source or destination
addresses to the Internet. Everybody should follow this advice. If
everybody did follow that advice, you wouldn't see the packets you  
are

seeing.


Really?  What do you do if a 'network internal' device -- a legitimate
use of RFC1918 addresses -- discovers 'host/network unreachable' for  
an

external-origin packet transitinng that device?   


You drop the packet at your border before it is sent out to the  
Internet.


This is why numbering interfaces in the data path of non-internal  
traffic is a bad idea.


Packets which are strictly error/status reporting -- e.g. IMP  
'unreachable',
'ttl exceeded', 'redirect', etc. -- should *NOT* be filtered at  
network

boundaries  _solely_ because of an RFC1918 source address.


I respectfully disagree.


Joe

Re: General question on rfc1918

[Joe Abley]

On 13-Nov-2007, at 10:08, Drew Weaver wrote:

   Hi there, I just had a real quick question. I hope this is  
found to be on topic.


Is it to be expected to see rfc1918 src'd packets coming from  
transit carriers?


You should not send packets with RFC1918 source or destination  
addresses to the Internet. Everybody should follow this advice. If  
everybody did follow that advice, you wouldn't see the packets you are  
seeing.


The cynical answer, however, based on observation of real-life  
networks, is "yes" because people are naturally messy creatures.


We have filters in place on our edge (obviously) but should we be  
seeing traffic from 192.168.0.0 and 10.0.0.0 et cetera hitting our  
transit interfaces?


I guess I'm not sure why large carrier networks wouldn't simply  
filter this in their core?


I can think of lots of things that large carrier networks (as well as  
smaller, non-carrier networks!) do that seem on the face of it to defy  
explanation, of which this is just one example :-)



Joe

Re: wanted: offshore hosting

[Joe Abley]

On 9-Oct-2007, at 1553, [EMAIL PROTECTED] wrote:


So, I'd like to rent a box somewhere outside of the US, for geographic
redundancy and other reasons.


[...]


I'd prefer if they spoke English, but weren't in the UK or US.  I
could deal with it if they only spoke Spanish.


Lots of options in Canada :-) Or is that not far away enough for you?


Joe

Re: Why do some ISP's have bandwidth quotas?

[Joe Abley]

On 4-Oct-2007, at 1416, Joe Greco wrote:

It'd be interesting to know what the average utilization of an  
unlimited

US broadband customer was, compared to the average utilization of an
unlimited AU broadband customer.  It would be interesting, then, to  
look

at where the quotas lie on the curve in both the US and AU.


I think the implication here is that there's a smoothing effect that  
comes with large customer bases.


For example, I remember back to when DSL was first rolled out in New  
Zealand. It was priced well beyond the means of any normal  
residential user, and as a result DSL customers tended to be just the  
people who would consume a lot of external bandwidth.


At around the same time, my wife's mother in Ontario, Canada got  
hooked up with a cablemodem on the grounds that unlimited cable  
internet service cost less than a second phone line (she was fed up  
with missing phone calls when she was checking her mail).


She used/uses her computer mainly for e-mail, although she  
occasionally uses a browser. (These days I'm sure legions of  
miscreants are using her computer too, but back then we were pre- 
botnet).


If you have mainly customers like my mother-in-law, with just a few  
heavy users, the cost per user is nice and predictable, and you don't  
need to worry too much about usage caps.


If you have mainly heavy users, the cost per user has the potential  
to be enormous.


It seems like the pertinent question here is: what is stopping DSL  
(or cable) providers in Australia and New Zealand from selling N x  
meg DSL service at low enough prices to avoid the need for a data  
cap? Is it the cost of crossing an ocean which makes the risk of  
unlimited service too great to implement, or something else?



Joe

Re: IPv6 Information Wiki

[Joe Abley]

On 25-Sep-2007, at 1128, <[EMAIL PROTECTED]>  
<[EMAIL PROTECTED]> wrote:


ARIN has set up a wiki at http://www.getipv6.info to publish  
information
that will help ISPs, large and small in implementing IPv6 and  
migrating

to an IPv6 Internet.


It might be worth syncing up with the people who are working on  
, in the interests of concentrating effort.



Joe

Re: Good Stuff [was] Re: shameful-cabling gallery of infamy - does anybody know where it went?

[Joe Abley]

On 11-Sep-2007, at 1514, Justin M. Streiner wrote:

Some of the local old-school Bell Atlantic/Verizon techs also did  
very clean work, but most of them took the early retirement  
packages that were offered 4-5 years ago.


This (the general subject of how to keep real-world cabinets tidy and  
do cabling in a sane way) seems like an excellent topic for a NANOG  
tutorial. I'd come, for sure :-)


When I worked on the ISP side of a phone company in New Zealand in  
the early nineties the telco facilities techs did some beautiful  
work, particularly on some very large copper distribution frames (for  
strange regulatory reasons there was one very large class 5 switch at  
this telco to service local access customers all over Auckland, with  
result that almost the whole first floor of 49 Symonds Street was  
built out as an enormous CO).


I once asked one of the telco guys to come and impart some cable  
management clue to us, but didn't get very far. The bemused response  
when we were both standing in front of the ISP racks was "but this is  
IT gear. IT gear is always messy."



Joe

Re: Congestion control train-wreck workshop at Stanford: Call for Demos

[Joe Abley]

On 3-Sep-2007, at 1328, [EMAIL PROTECTED] wrote:

Spurred on by a widespread belief that TCP is showing its age and  
needs replacing


I don't mean to hijack this thread unnecessarily, but this seems like  
an interesting disconnect between ops people and research people  
(either that or I'm just showing my ignorance, which will be nothing  
new).


Is there a groundswell of *operators* who think TCP should be  
replaced, and believe it can be replaced?


Or is the motivation for replacing TCP mainly felt by those who spend  
a lot of time trying to get maximum performance out of single flows  
over high bandwidth-delay product paths?



Joe

Re: Network Inventory Tool

[Joe Abley]

On 13-Aug-2007, at 23:31, Wguisa71 wrote:


Does anyone known some tool for network documentation with:

- inventory (cards, serial numbers, manufactor...)
- documentation (configurations, software version control, etc)
- topology building (L2, L3.. connections, layer control, ...)

All-in-one solution and It don't need to be free. I'm just looking
for some thing to control the equipments we have like routers
from some sort of suppliers, etc...


If you don't succeed in finding an all-in-one, vendor-neutral  
solution which does precisely what you want straight out of the box  
(and don't feel bad if so, since many have failed before you) there  
are some clues for rolling your own here:


  http://www.nanog.org/mtg-0210/ppt/stephen.pdf


Joe

Re: The Choice: IPv4 Exhaustion or Transition to IPv6

[Joe Abley]

On 28-Jun-2007, at 13:16, Randy Bush wrote:


Interoperability is achieved by having public facing
servers reachable via IPv4 and IPv6.


that may be what it looks like from the view of an address allocator.

but if you actually have to deliver data from servers you need a path
where data from/in both protocols is supported on every link of the
chain that goes all the way to every bit of back end data in your
system.  and if one link in that chain is missing, .


I think this is one reason why the transition is hard: supporting  
dual stacks in clients when the demonstrated quality of the v6  
network is noticably worse than the v4 network is a difficult  
business case to sell.


When you depends on users being able to talk to you reliably, having  
them use a low-quality transport when a high-quality transport is  
also available has a direct impact on the bottom line, without even  
considering the capex/opex costs of supporting IPv6. The difference  
in performance/reliability might be relatively small to a single  
user, but to a company who is trying to service millions of clients  
every minute (and is earning revenue from each visit) the aggregate  
effect is surely much more significant.


Providing access to (e.g.) web services over both IPv4 and IPv6 using  
(e.g.) a single URL hence reduces revenue when serving the non-zero  
(but small) set of dual-stack clients, and does not increase revenue  
from the set of IPv6-only clients in any practical sense since that  
set is (to all intents and purposes) empty.


Providing separate URLs for services over IPv6 requires user  
education, which is arguably even more expensive.


The way to avoid this scenario is presumably to improve the quality  
of the IPv6 network such that the risk of revenue loss from IPv6  
support falls below an acceptable threshold. Which would be much  
easier to do if people were using it, and opening trouble tickets  
when things need to be fixed :-)



Joe

Re: Network Level Content Blocking (UK)

[Joe Abley]

On 7-Jun-2007, at 10:47, Jon Lewis wrote:



On Thu, 7 Jun 2007, James Blessing wrote:


Sorry for the cross posting to a number of lists but this is an
important topic for many of you (especially if you get multiple  
copies).


As many people are aware there is an 'expectation' that 'consumer'
broadband providers introduce network level content blocking for
specified content on the IWF list before the end of 07.


There are no British colonies in North America...are there?


[On the mainland, not since Belize's independence in 1981. There are  
British Overseas Territories in the Caribbean (Anguilla, Bermuda,  
British Virgin Islands, Cayman Islands, Montserrat and the Turks and  
Caicos Islands) which are in North America according to at least some  
definitions of the phrase.


However, to answer the question you were really asking, there are  
surely North American companies on this list who do business in the  
UK, and certainly no reason to think that North American politicians,  
given an example to follow, would never do so in this continent. So  
it's not obvious to me that this is off-topic here, speaking as one  
single subscriber.]


Anyway, how does BT's cleanfeed work? How are British 3G operators  
doing equivalent blocking? I'd be interested in learning about the  
implementation.



Joe

Re: Security gain from NAT: Top 5

[Joe Abley]

On 7-Jun-2007, at 02:48, Brandon Butterworth wrote:




  #1 NAT advantage: it protects consumers from vendor
  lock-in.

Speaking of FUD...  NAT does nothing here that is not also  
accomplished

through the use of PI addressing.


True, diy PI (mmm, PI) is a major reason people use it for v4 and why
they'll want something similar for v6. No internal renumbering,
ever. I can see why they choose it, even with the disadvantages

PI for everyone?


LISP! :-)

Re: NANOG 40 agenda posted

[Joe Abley]

On 4-Jun-2007, at 02:03, Colm MacCarthaigh wrote:


On Mon, Jun 04, 2007 at 02:53:52AM +, Paul Vixie wrote:

ipv6 load balancers exist, one's current load balancer is/may  
probably

not be up to the task.


my favourite load balancer is OSPF ECMP, since there are no extra  
boxes,

just the routers and switches and hosts i'd have to have anyway.

quagga ospf6d works great, and currently lacks only a health check  
API.


If you're load-balancing N nodes, and 1 node dies, the distribution  
hash

is re-calced and TCP sessions to all N are terminated simultaneously.


Yep. This is a disadvantage that was mentioned in both www.nanog.org/mtg-0505/abley.cluster.html> and . I seem to think there's general text  
about this in RFC 4786, too. From the ISC tech note:


   CEF's route selection algorithm is stateless and deterministic for a
   stable set of ECMP routes. In general, however, a change in the
   number or ordering of those routes may cause the route selected  
for a

   particular (source, destination) hash to change. This fragility
   should be considered when gauging whether this load distribution
   approach is appropriate to particular protocols.

I have used dedicated load-balancing appliances for this kind of  
application. They have the disadvantages that (a) they are not cheap,  
and (b) sometimes the non-cheapness encourages people to use them in  
a fashion which exposes a single point of failure. They have many  
advantages, too, including (often) a sufficiently-capable state  
engine that the issue you mention does not arise.


As with all things, the trick is to weigh the risk of disaster  
against the probability of benefit and do whatever makes sense within  
your own particular constraints.



Joe

Re: BGP announce/withdrawal history.

[Joe Abley]

On 24-May-2007, at 03:42, Forrest W. Christian wrote:

Earlier today I had an issue where a circuit to one of my two BGP  
connected upstreams went away for an hour or so.
During this period, I expected BGP to act as expected and migrate  
the traffic to the second circuit with a second provider.  This did  
not occur.


When this has happened to me before, I have been suspicious about  
whether the upstream to whom the circuit broke was routing my nets  
down the dead circuit with static routes that for whatever reason  
(layer-2 obfuscation, etc) didn't go away when the link went down.


This hasn't always been the answer, but sometimes it has; in several  
cases poking about within RIS (or interactively through a route-views  
router while the circuit was down) revealed that upstream in question  
was originating routes on my behalf while the circuit was down.



Joe

Re: OT: NANOG 40 accomodations

[Joe Abley]

On 24-May-2007, at 09:43, Brighten Godfrey wrote:

I'm a Ph.D. student from UC Berkeley who will be attending the  
upcoming NANOG in Bellevue.  If anyone is interested in splitting a  
hotel room to reduce costs, please drop me an email.  (I have a  
room booked already but could cancel.)


I made a wiki page for NANOG 40 here:

  http://nanog.cluepon.net/index.php/NANOG40

and made a bare link on that page to a "NANOG40 Roommates Wanted"  
topic. Perhaps this is a reasonable way to co-ordinate the sharing of  
rooms, for those who are otherwise struggling to find accommodation.


Note that NANOG has a room occupancy target at each hotel that it is  
financially annoying not to meet, though, so those who have funding  
available to book their own rooms directly within the NANOG room  
blocks will be doing the meeting budget a favour if they do so.



Joe

Re: ISP CALEA compliance

[Joe Abley]

On 23-May-2007, at 14:56, Joe Abley wrote:


On 11-May-2007, at 13:55, Chris L. Morrow wrote:


On Fri, 11 May 2007, Jared Mauch wrote:


If there is interest, perhaps I can make a call to DoJ and
see if someone can present on CALEA at nanog in a few weeks?   
(incase

the PC can accomodate them).


that seems like a great idea, atleast a lightning talk would be nice.


From the sounds of things, a tutorial would be better.


Oh! That was a really old message I just replied to. Mail got  
kidnapped in a rogue barracuda, it seems, and someone just paid the  
ransom. Sorry about the noise :-)



Joe

Re: ISP CALEA compliance

[Joe Abley]

On 11-May-2007, at 13:55, Chris L. Morrow wrote:


On Fri, 11 May 2007, Jared Mauch wrote:



If there is interest, perhaps I can make a call to DoJ and
see if someone can present on CALEA at nanog in a few weeks?  (incase
the PC can accomodate them).


that seems like a great idea, atleast a lightning talk would be nice.


From the sounds of things, a tutorial would be better.


Joe

Re: Interesting new dns failures

[Joe Abley]

On 21-May-2007, at 10:26, Chris L. Morrow wrote:

I wonder how the .de or .uk folks see things? Is the same true  
elsewhere?


I think the phenomenon of "that doesn't look right because it doesn't  
end in .com" is peculiar to the US.


Elsewhere, you don't need a particularly large TLD zone to get  
mindshare -- NZ, CA and NP are three random examples of ccTLDs which  
are well-recognised locally and which are far smaller than UK or DE;  
there are many more.



Joe

Re: Juniper M10i sufficient for BGP, or go with M20?

[Joe Abley]

On 13-May-2007, at 15:33, Neal Rauhauser wrote:

 I don't know much about Juniper but I'm about to learn with a new  
job. If I'm going to take full routes from a couple of upstreams  
and have a couple of peers will the M10i (768M max) be enough or is  
the M20 (2048M max) a better choice.


I think the quick answer based on just that requirement is "an M10i  
will do fine". I am not aware that Juniper sell a router which will  
struggle with a default configuration to handle a few views of the  
full table, but perhaps my rhetorical spectacles are unreasonably  
rosy right now.


Layout here is such that I'd expect to use a single quad gigabit  
port ethernet blade in each of a pair of M10i/M20 to achieve  
redundancy.


 Is there a pricing resource for this stuff online some where? I do  
*not* want to hear from any sales people over this comment ...


Try checking the j-nsp archives at . Good luck with not hearing from sales people.



Joe

Re: [cacti-announce] Cacti 0.8.6j Released (fwd)

[Joe Abley]

On 9-May-2007, at 05:25, <[EMAIL PROTECTED]>  
<[EMAIL PROTECTED]> wrote:



but I'm still unclear on
what an MIB actually _is_,


A MIB is the database schema for an object-oriented hierarchical
database.


I believe that (some?) purists would assert that there is but one  
MIB, and that all other MIB-like entities shipped by vendors and  
others are properly called MIB Extensions. This is pedantry, however.


Once upon a time when I was called about to care about this stuff I  
digested the book "Understanding SNMP MIBs" by David Perkins and Evan  
McGinnis, Prentice Hall, ISBN 0-13-437708-7. Anybody looking for a  
dead-tree treatment of SNMP from the design perspective could do a  
lot worse.



Joe

Re: BGP certificate insanity was: (DHS insanity - offtopic)

[Joe Abley]

On 24-Apr-2007, at 11:51, <[EMAIL PROTECTED]> wrote:


How can anybody be sure that the random peering tech they are
talking
to really works for the organisation listed in the whois record? By
visual inspection of the e-mail address?


Do people really talk to random peering techs? I thought that peering
contacts were all set up via face-to-face meetings.


Your view of the world is far from universal.


In any case, if it
is email authentication that you are after, putting certificates in  
your

router will not help you.


I never suggested putting certificates in a router.


Also, normal business practices can be very useful to establish the
identity of people.


For sure, but I don't need to care about the identity of people if I  
have am given a signed ROA which checks out back to a trust anchor I  
am prepared to trust.


No crypto on routers involved.


Joe

Re: BGP certificate insanity was: (DHS insanity - offtopic)

[Joe Abley]

On 24-Apr-2007, at 10:15, <[EMAIL PROTECTED]> wrote:


You might try taking a look at the various presentations at
NANOG/RIPE/ARIN/
APNIC/APRICOT about the whole idea.  Central point: the
entity that gives
you a suballocation of its own address space signs something
that says you
now hold it.


If the whois directories actually operated under some set of  
guidelines

defining their purpose and scope which was enforced by the directory
publishers, then there would be no need for this certificate nonsense.


How can anybody be sure that the random peering tech they are talking  
to really works for the organisation listed in the whois record? By  
visual inspection of the e-mail address? A faxed LOA on company  
letterhead?


Given a polished toolset, I'd take a signed ROA over any of those.


Joe

Re: DHCPv6, was: Re: IPv6 Finally gets off the ground

[Joe Abley]

On 15-Apr-2007, at 06:38, Iljitsch van Beijnum wrote:

With IPv6, there's of course still manual configuration, but PPP is  
out because it can't negotiate IPv6 addresses.


I've heard you say this a few times now, but I am also told by  
various people in various places that they have succeeded in getting  
IPv6 addresses assigned using PPPoE. Colour me confused.


Does RFC 2472 have some practical limitations in the real world that  
I haven't noticed? Or is the problem a simple matter of implementation?



Joe

Re: On-going Internet Emergency and Domain Names

[Joe Abley]

On 1-Apr-2007, at 22:30, Gadi Evron wrote:

But building a wall to protect your port from attacks by pirates  
will not
make the pirates go away, and unfortunately, we can't convince  
everybody

to build walls and our security is nwoadays dependent on others'.


If you consider the possibility that you can never make the pirates  
go away, building walls sounds like sensible advice.



Joe

Re: TCP and WAN issue

[Joe Abley]

On 27-Mar-2007, at 16:35, Joe Abley wrote:

You might take a look through RFC 2488/BCP 28, if you haven't  
already. The circuit propagation delays in that scenarios painted  
by that document are far higher than yours, but the principles are  
the same.


"... in *the* scenarios..." I am having trouble with words, today.

Re: TCP and WAN issue

[Joe Abley]

On 27-Mar-2007, at 16:26, Philip Lavine wrote:

I have an east coast and west coast data center connected with a  
DS3. I am running into issues with streaming data via TCP and was  
wondering besides hardware acceleration, is there any options at  
increasing throughput and maximizing the bandwidth? How can I  
overcome the TCP stack limitations inherent in Windows (registry  
tweaks seem to not functions too well)?


You might take a look through RFC 2488/BCP 28, if you haven't  
already. The circuit propagation delays in that scenarios painted by  
that document are far higher than yours, but the principles are the  
same.



Joe

Re: SaidCom disconnected by Level 3 (former Telcove property)

[Joe Abley]

On 16-Mar-2007, at 19:56, Wil Schultz wrote:


Almost ALL?


Surely all those except those who are competing with you for the same  
customers should multi-home. :-)



Joe

Re: [funsec] Not so fast, broadband providers tell big users (fwd)

[Joe Abley]

On 13-Mar-2007, at 18:36, [EMAIL PROTECTED] wrote:

Keeping this in perspective, the CIA Factbook says that Niue had a  
population
of 2,166 in July 2006, an area of 100 square miles (1.5 times the  
size of Wash DC),

and a highest elevation of a whole whopping 250 feet.


They used to have a bunch of trees that caused unwelcome attenuation  
the 2.4GHz band, but cyclone Heta took care of that little problem.



Meanwhile, Montgomery County, Virginia has some 85K or so people, 393
square miles, and more ridgelines and hollows than you can shake a  
stick at

(elevations from 1,300 to 3,700 feet inclusive).

Probably 70K of those people are crowded into about 40 square miles  
in 2 main
plateaus - those are easy to cover.  The other 15K people scattered  
across

350 square miles of ridgelines and hollows are a lot harder to cover.

I posit that those 350 square miles are more remote, measured from  
"the point
the big fat cable lands at" (whatever landing station Niue has, and  
the 2 or 3
main telco CO's here), than any point on the island of Niue.  At  
least measured

by criteria that matter to the guy engineering the towers.


This conversation has suddenly become very weird. I suggest you go  
and spend a year on Niue before you decide to make claims that  
anywhere in the US is as remote (and, for the record, there are no  
cables which land in Niue, fat or otherwise).


If there's a practical difference between Niue and Montgomery County  
with respect to network access, perhaps it's that Niue is home to  
someone who decided to build a network rather than just complain  
about it not being there (hi, Rich!). Do the 70k people that are  
"easy to cover" in Montgomery County have free wifi? If it's so easy,  
why not?



Joe

Re: [funsec] Not so fast, broadband providers tell big users (fwd)

[Joe Abley]

On 13-Mar-2007, at 14:15, Todd Vierling wrote:


Depends on how rural the area is.  Some parts of the US have
problematic terrain and *very* sparse population; there, the cost
would far outweigh the subscriber uptake.  Should someone want
bandwidth in such an area, powerline or satellite are probably better
choices.


If powerlines are an option, you're not really rural :-)

However, just because you're remote doesn't mean that there aren't  
options in the last mile, so long as you're prepared to do something  
rather than just complain about others not doing it. The island of  
Niue in the South Pacific has had free, nation-wide wifi available  
for all since 2003, for example, and you don't get much more remote  
than Niue.



Joe

Re: [funsec] Not so fast, broadband providers tell big users (fwd)

[Joe Abley]

On 13-Mar-2007, at 12:34, Mills, Charles wrote:


Probably sooner in this case.  Verizon is already rolling out fiber to
the home (FIOS) in the Pittsburgh area.  Massive truck rolls...lots of
glass being strung.


Subsidising a loss-leading access project with revenue from copper- 
based services sounds indeed like a plausible option for those few  
companies who own the copper.



Joe

Re: [funsec] Not so fast, broadband providers tell big users (fwd)

[Joe Abley]

On 13-Mar-2007, at 11:27, Roland Dobbins wrote:


On Mar 13, 2007, at 8:17 AM, Chris L. Morrow wrote:


what business drivers are there to put more bits on the wire to
the end user?


BitTorrent.


So long as most torrent clients are used to share content illicitly,  
that doesn't sound like much of a business driver for the DSL/CATV  
ISP. And so long as the average user doesn't have an alternative  
provider which gives better torrent sharing capabilities, there  
doesn't seem to be much of a risk of churn because of being torrent- 
unfriendly.


Building high-capacity access to the home is sooner or later going to  
involve fibre, which is going to necessitate truck roll and digging.  
There's a high cost associated with that, which means there's a  
significant competitive disadvantage to anybody doing it in order to  
compete with DSL/CATV folks whose last mile costs are sunk and were  
paid for long ago. Residential customers are notoriously price- 
sensitive and low-yield.


Pressure seems like it could come from either or both of two  
directions: there could be some new market shift which entices  
customers to pay substantially more for increased performance, and to  
do so in great numbers, to make it cost-effective for a green-fields  
entrant to deploy a new network, or the cost of digging up the  
streets could become much lower.


Given that there's only so much TV one household can realistically  
download and watch per day, and since that amount of TV demonstrably  
fits within DSL- and cable-sized pipes already, I don't see the  
average neighbourhood throwing money around in order to get fibre to  
the home. On the contrary, here at least I see people switching  
providers in order to take advantage of bundles of phone/TV/cell  
which will save them $10 per month.


Perhaps city planners have a role to play here. In cities where the  
streets are routinely dug up every spring as soon as the last snow  
disappears, for example, municipalities could choose to invest in  
equal-access conduit to reduce the cost for anybody who wants to blow  
fibre down them in the future. Such approaches are somewhat common in  
the business core, but perhaps not so much in residential areas.



Joe

Re: wifi for 600, alex

[Joe Abley]

On 15-Feb-2007, at 10:39, Carl Karsten wrote:

That is a really nice list.  Is there a wiki somewhere I could post  
this to?


http://nanog.cluepon.net/ !

Re: DNS: Definitely Not Safe?

[Joe Abley]

On 14-Feb-2007, at 13:38, Chris L. Morrow wrote:


On Wed, 14 Feb 2007, MARLON BORBA wrote:


my intention, when suggested that reading, was to get your attention
about that recent attack which targeted DNS top-level servers and to


i thought it was actually covered on-list... during the event, no?


I don't think it was especially covered on this list (you are no  
doubt thinking of other lists). There was a lightning talk about it  
in Toronto, for which slides can be found in the usual place.



Joe

Re: Solaris telnet vuln solutions digest and network risks

[Joe Abley]

On 14-Feb-2007, at 09:59, MARLON BORBA wrote:

I agree with Gadi. Everything which affects Internet stability  
(e.g. DNS
denial-of-service attacks) deserves attention of network operators.  
IMHO

it's time to think about a new NANOG AUP.


The NANOG charter says that the people responsible for updating the  
AUP are those on the Steering Committee. If you have proposed  
revisions to the AUP, please send them to [EMAIL PROTECTED] for  
consideration. If you want to engage in public debate about the AUP,  
please do it on the [EMAIL PROTECTED] mailing list, or ask for  
time on the floor at the next community meeting, or both.


Second-guessing the MLC's interpretation of the AUP on this list is  
not productive, and is (in my opinion, although it's not my job to  
decide) off-topic. Anybody who feels that the MLC has acted  
inappropriately for some reason is very welcome to send their  
concerns to the SC at [EMAIL PROTECTED] However, raising those  
concerns on this list is also (in my opinion) off-topic.


Apologies for extending this thread by one more message; I do so in  
the hope that some of the energy on display here can be more  
appropriately directed. Reply-To set to [EMAIL PROTECTED]



Joe

Re: death of the net predicted by deloitte -- film at 11

[Joe Abley]

On 12-Feb-2007, at 12:03, Brandon Butterworth wrote:


I think you're presupposing that the concept of "channels" is
something that will persist.


For some time.

There's quite an industry with an interest in maintaining that. It
probably won't vanish until the current generations die.


It could be argued that channels are already simply a transport  
mechanism for on-demand content, at least to the growing population  
of users who choose to pay extra for PVR/TiVO functionality at home.  
And, interestingly, the people pushing the PVR functionality at users  
here are the satellite and cable providers; there's no third-party,  
packaged solution for the non-technical user.


You might imagine that these PVR-pushing cablecos are expecting the  
death of channel-oriented content, and are preparing for it by  
seizing control of the set-top box. Having a general-purpose computer  
installed in half of Canadian living rooms, pre-cabled with AV and  
CATV, with an IP address and a 80GB hard disk, presenting an on- 
demand-like interface that consumers are familiar with seems useful  
if you're anticipating a head-to-head competition with the likes of  
Apple.


[Perhaps my viewpoint is skewed because channel-delivered TV content  
in Canada is horrible; it's almost as bad as American TV. I seem to  
think that broadcast TV in the UK more tolerable, although I haven't  
really seen it since I left the UK in the mid 90s so perhaps I'm just  
deluded.]



Channel based and discrete delivery of content (radio vs records,
tv/cinema vs vhs/dvd) have coexisted for some time.

If one loses ground it's not a problem unless you take sides.


Cursory consideration of your examples above provide clues as to  
which way the scale is tipping; radio has for a long time been a way  
to promote record sales, and the video stores here are now half-full  
with boxed sets of TV series on DVD.


It looks to me like people increasingly want their content on-demand,  
and that there's a growing industry supplying that demand. While I  
don't doubt you when you describe an industry whose bottom line will  
benefit from the persistence of channel-based content delivery, I  
don't think those companies are the only ones in the game.



Joe

Re: death of the net predicted by deloitte -- film at 11

[Joe Abley]

On 12-Feb-2007, at 09:23, Brandon Butterworth wrote:


Sure it degrades to effective unicast if too few people watch the same
channel in the same area (so just use unicast for those channels),  
that
doesn't mean it's no use for the popular channels that have  
millions of

viewers.


I think you're presupposing that the concept of "channels" is  
something that will persist.



Joe

Re: Hackers hit key Internet traffic computers

[Joe Abley]

On 7-Feb-2007, at 15:24, virendra rode // wrote:


Looking at these attacks, F in particular, if my memory serves me
correct, there are 35 f-root anycast nodes deployed. Maybe this helped
in some respect.


Dave Knight's lightning talk in Toronto seemed to indicate that F's  
anycast platform did a good job at sinking the bulk of the attack  
traffic in Seoul and Beijing, and that the spill-over from the region  
was mopped up easily by the very large nodes in California. Most  
other locations that have a local F-root server saw very little impact.


Isolation of attack traffic seems like a big help to me.


Then again, I like to see what kind of analysis comes out from the
collected data.



Joe

Re: TorIX Tours on Tuesday February 6

[Joe Abley]

On 1-Feb-2007, at 12:31, Joe Abley wrote:

For those attending NANOG 39 in Toronto next week who don't already  
see enough generic data centre space in their normal work week,  
there will be a TorIX tour on Tuesday February 6, some time after  
the last BOF/Tutorial finishes.


[...]

If you're interested, sign up here:

  http://nanog.cluepon.net/index.php/NANOG39TorIXTour


We have an slightly astounding 40 people signed up to visit 151 Front  
Street tomorrow evening. Building security have agreed to sign people  
in ahead of time according to the list at the above URL, which will  
save some time. PLEASE REMEMBER TO BRING PHOTO ID - you won't be let  
in without it.


Due to the large number of people, we'll be going through the  
building in two shifts. If people could start milling about in the  
hotel lobby at 6pm instead of 6:30, that'd be very handy; as soon as  
we have 20 people assembled, we'll dispatch them off through the PATH.


[There's a few hundred metres at the end of the walk down to Front  
Street that can't happen underground through the PATH, so bring a  
coat or you're going to feel a bit frosty.]


Two suites which contain TorIX switches will be open, one by the nice  
people at Switch and Data, and another by the very excellent Matt  
Potvin of Standard Connections (who also smoothed the sign-in process  
with 151 Front security). Many thanks to both.



Joe

Re: broken DNS proxying at public wireless hotspots

[Joe Abley]

On 4-Feb-2007, at 00:58, Trent Lloyd wrote:

The flaw here is that DNS operates over 53(UDP), last time I  
checked SSH

doesn't do UDP port forwarding?


In the interests of dispelling a common myth, DNS operates over both  
53/udp and 53/tcp. However, given that a substantial portion of most  
clients' queries will likely use UDP transport, your fundamental  
point stands.



Joe

Re: broken DNS proxying at public wireless hotspots

[Joe Abley]

On 3-Feb-2007, at 06:20, Fergie wrote:


Use OpenDNS?


OpenDNS provides service on other than 53/tcp and 53/udp?

If so, how do you configure your client operating system of choice to  
use the novel, un-proxied ports instead of using port 53?



Joe

TorIX Tours on Tuesday February 6

[Joe Abley]

[Apologies for the following non-operational content; if you are not  
coming to Toronto next week, hit delete now]


For those attending NANOG 39 in Toronto next week who don't already  
see enough generic data centre space in their normal work week, there  
will be a TorIX tour on Tuesday February 6, some time after the last  
BOF/Tutorial finishes.


There's a limit to the number of people we can practically haul  
through building security without causing trouble, so first-come,  
first-served. If for some bizarre reason there is an unexpectedly  
large number of people who think touring 151 Front is the right way  
to spend a Tuesday evening, we might try and do two trips, find  
people to open more than one suite, etc.


If you're interested, sign up here:

  http://nanog.cluepon.net/index.php/NANOG39TorIXTour


Joe

Re: WTH does Paul do now?

[Joe Abley]

On 1-Feb-2007, at 06:50, Stefan Schmidt wrote:


Well...
reject-all.vix.com. 3600IN  NS  ns.lah1.vix.com.
reject-all.vix.com. 3600IN  NS  ns.sql1.vix.com.

dig any 2.0.0.127.reject-all.vix.com @ns.sql1.vix.com gives
status: REFUSED
and as ns.lah1.vix.com does alike all authorative nameservers for this
zone are some kind of hmm 'unreachable' thus resulting in a  
SERVFAIL from

your recursive nameserver.
It seems like your MTA is not very gracious to SERVFAILs from DNSRBLs.


... or alternatively, that this is a private DNSRBL which has access  
restrictions.



Joe

How to Host a NANOG Meeting

[Joe Abley]

We have a BOF slot in Toronto to discuss the general topic meeting  
hosting, from the perspective of learning from past mistakes and  
making the organisation of future events easier, and with the  
additional goal of demystifying the process to those who might like  
to host a meeting, but don't know what's involved.


If you have ever thought vaguely about hosting a NANOG meeting in  
your city but either assumed it would be too expensive or simply  
didn't know where to take your vague thoughts next, you might like to  
drop by and join the conversation. Feel very free to drop me a note  
off-list if you want to find out more.


We'll be in Sheraton Hall B/C from 4pm - 5:30pm on Tuesday 6 Feb.  
This means we clash with the Second Coming of the Peering BOF, so  
apologies in advance to wbn and co. for the several hundred people  
that will no doubt abandon his session in order to attend this one. :-)

Re: Google wants to be your Internet

[Joe Abley]

On 29-Jan-2007, at 20:12, Brandon Galbraith wrote:


On 1/29/07, Henning Brauer <[EMAIL PROTECTED]> wrote:

* Joseph S D Yao <[EMAIL PROTECTED]> [2007-01-30 01:59]:
>
> IPv6 firewalls?  Where?  Good ones?

OpenBSD's pf has support for v6 for years now.

Do a fair amount of appliance firewalls support it?


To be fair, I think the question was about good firewalls, not  
appliances.



Joe

Re: Birmingham UK colocation

[Joe Abley]

On 29-Jan-2007, at 16:16, Joe Abley wrote:


I've never heard of anybody acquiring peering in Birminghag.


For the record that was a typo, not some kind of weird dig at  
Birmingham :-)



Joe

Re: Birmingham UK colocation

[Joe Abley]

On 29-Jan-2007, at 15:56, Andrew Gristina wrote:


I have two racks in London UK.  The colocation is
currently in London.  The contract is up soon and most
of the feet on the ground in the UK of the company is
in the greater Birmingham area. So I'm interested in
colocating about two racks of servers to Birmingham.
I would need a cage if the space were shared.


If peering and choice of transit is your primary concern, then you  
might well find the best approach lies in staying in London and  
finding a reliable contractor who is local and who can do things for  
you there when needed.


I've never heard of anybody acquiring peering in Birminghag.

You can peer in Manchester at the MaNAP, although I'm not sure how  
well that theory stacks up in practice these days. In any case from  
Brum it's not much further to London than it is to Manchester,  
ignoring the traffic issues.



Joe

Dell PowerConnect 3324

[Joe Abley]

I'm looking at a somewhat convoluted switched gigE path between an  
M7i and an ERX, both of which I am expecting to be able to fill a  
gigabit ethernet interface, but in practice the throughput is maxing  
out at around half a gig of internet-sized packets in each direction.


(This is nothing to do with Afilias; it's a friend's network.)

The bottleneck in the path (based on choosing the switch with the  
lowest model number, on the principle that bigger model numbers means  
mroe fastar1!1) is probably a Dell PowerConnect 3324 with one SX SFP,  
one LX SFP and all the 100M ports pretty much idle. There are no  
increasing error counters on transmit or receive on any of the  
devices in the path.


Is it reasonable to expect a Dell 3324 to be able to switch more than  
~500M of internet-sized packets?

Re: Google wants to be your Internet

[Joe Abley]

On 24-Jan-2007, at 10:01, Jamie Bowden wrote:


Some days it kills
me that v6
is still not really viable, I keep asking providers where they're at
with it.  Their most common complaint is that the operating systems
don't support it yet.  They mention primarily Windows since
that is what
is most implemented, not in the colo world but what the users
have.


Windows XP SP2 has IPv6.  It isn't enabled by default, but it's not
difficult to do.

Apparently Vista does do IPv6 by default out of the box, but I don't
have a Vista system to play with yet to confirm this.


I might argue that, legacy systems and hardware aside, the main  
reason that v6 might be considered non-viable these days is the lack  
of customers willing to pay for it.


I don't think the viability of v6 has been blocking on operating  
systems or router hardware for quite some time, now. It's still a  
problem for many operational support systems, but arguably that would  
change rapidly if there was some prospect of revenue.



Joe

Re: Network end users to pull down 2 gigabytes a day, continuously?

[Joe Abley]

On 21-Jan-2007, at 14:07, Stephen Sprunk wrote:

Every torrent indexing site I'm aware of has RSS feeds for newly- 
added torrents, categorized many different ways.  Any ISP that  
wanted to set up such a service could do so _today_ with _existing_  
tools.  All that's missing is the budget and a go-ahead from the  
lawyers.


Yes, I know.

If anybody has tried this, I'd be interested to hear whether on- 
net clients actually take advantage of the local monster seed, or  
whether they persist in pulling data from elsewhere.


[...] Do I have hard data?  No. [...]


So, has anybody actually tried this?

Speculating about how clients might behave is easy, but real  
experience is more interesting.



Joe

Re: Network end users to pull down 2 gigabytes a day, continuously?

[Joe Abley]

On 21-Jan-2007, at 07:14, Alexander Harrowell wrote:

Regarding your first point, it's really surprising that existing  
P2P applications don't include topology awareness. After all, the  
underlying TCP already has mechanisms to perceive the relative  
nearness of a network entity - counting hops or round-trip latency.  
Imagine a BT-like client that searches for available torrents, and  
records the round-trip time to each host it contacts. These it  
places in a lookup table and picks the fastest responders to  
initiate the data transfer. Those are likely to be the closest, if  
not in distance then topologically, and the ones with the most  
bandwidth. Further, imagine that it caches the search -  so when  
you next seek a file, it checks for it first on the hosts nearest  
to it in its "routing table", stepping down progressively if it's  
not there. It's a form of local-pref.


Remember though that the dynamics of the system need to assume that  
individual clients will be selfish, and even though it might be in  
the interests of the network as a whole to choose local peers, if you  
can get faster *throughput* (not round-trip response) from a remote  
peer, it's a necessary assumption that the peer will do so.


Protocols need to be designed such that a client is rewarded in  
faster downloads for uploading in a fashion that best benefits the  
swarm.



The third step is for content producers to directly add their torrents
to the ISP peers before releasing the torrent directly to the public.
This gets "official" content pre-positioned for efficient  
distribution,

making it perform better (from a user's perspective) than pirated
content.


If there was a big fast server in every ISP with a monstrous pile of  
disk which retrieved torrents automatically from a selection of  
popular RSS feeds, which kept seeding torrents for as long as there  
was interest and/or disk, and which had some rate shaping installed  
on the host such that traffic that wasn't on-net (e.g. to/from  
customers) or free (e.g. to/from peers) was rate-crippled, how far  
would that go to emulating this behaviour with existing live  
torrents? Speaking from a technical perspective only, and ignoring  
the legal minefield.


If anybody has tried this, I'd be interested to hear whether on-net  
clients actually take advantage of the local monster seed, or whether  
they persist in pulling data from elsewhere.



Joe

Re: HTML email, was Re: Phishing and BGP Blackholing

[Joe Abley]

On 17-Jan-2007, at 21:05, Joseph Jackson wrote:

Proper education for whom, the people setting up the site probably  
know

this already.  It's the bosses and marketing that don't care about DNS
structure.  Damn it they want mazdausa.com and not usa.mazda.com and
they will have it their way!

At least that's how it is most places I've seen.


Back in the day, pre-CIRA, .CA was managed according to rules which  
included the restriction that a single company was only allowed one  
domain name. So, to choose a company at random, General Motors Canada  
was welcome to GMC.CA but they couldn't also register PONTIAC.CA or  
GM.CA or GENERALMOTORS.CA.


I think that policy was good for the DNS, but it was apparently  
widely hated by everybody else, despite the fact that .CA names at  
that time were free. .CA is no longer managed according to such rules.



Joe

Re: How big a network is routed these days?

[Joe Abley]

On 17-Jan-2007, at 18:36, Owen DeLong wrote:

Actually, generally, the expectation under 4.4 is that the  
addresses will not be advertised at all for the most part, since,  
generally, there's no need to advertise the route to the exchange  
point, itself, into the global routing table.  4.4 is intended to  
support internet exchanges, ala MAEs, etc.


... and operators of critical DNS infrastructure, as the text I  
quoted indicated. Not much point in numbering a TLD server out of a  
block that isn't going to be advertised.


In terms of 4.3.2.1 and 4.3.2.2, I believe ARIN has worked very  
hard to express no expectation or
intent about how assignments relate to route advertisements and  
routing policy.


Indeed, as I believe I mentioned.


Joe

Re: How big a network is routed these days?

[Joe Abley]

On 17-Jan-2007, at 12:43, Marshall Eubanks wrote:


On Jan 17, 2007, at 12:19 PM, David Freedman wrote:


I'm interested as to why RIRs dont set the minimum PI allocatable
to /24 in order to fit with the current trend.


In the 2002-3 micro-assignment policy, the RIR's assign a minimum  
of a /22.


The RIRs all have different policies, and anybody interested in  
finding out the rules for any individual RIR are best advised to  
consult the policy documents published by the RIR in question  
directly. The original question in this thread (that of reachability  
of addresses covered by long-prefix announcements) is profoundly on- 
topic here, however, and explicitly disclaimed by all the RIRs last  
time I checked.


For the ARIN region, the Number Resource Policy Manual currently  
published at  mentions the following minima:



4.3.2.1 Single Connection

The minimum block of IP address space assigned by ARIN to end- 
users is a /20. [...]


4.3.2.2 Multihomed Connection

For end-users who demonstrate an intent to announce the requested  
space in a multihomed fashion, the minimum block of IP address  
space assigned is a /22. [...]


4.4 Micro-allocation

ARIN will make micro-allocations to critical infrastructure  
providers of the Internet, including public exchange points, core  
DNS service providers (e.g. ICANN-sanctioned root, gTLD and ccTLD  
operators) as well as the RIRs and IANA. These allocations will  
be no longer than a /24 using IPv4 or a /48 using IPv6. [...]



As far as I know, all of the PI /24's are thus "legacy" in nature.


As the above snippet from the policy manual suggests (and as my  
experience confirms) there are recent assignments made to end users  
by ARIN under the micro-allocation policy which were made with the  
expectation that individual /24s would be advertised globally.  
Clearly these are not the most usual case, as the description of  
those who qualify for such assignments above indicates, but it would  
be a mistake to assume that *all* /24 assignments are legacy.


From my experience, /24's and longer assigned by RIRs likely to be  
routed, as well as ones from the old class C space, and people have  
mostly had problems with /24 PA space in the old Class A and B space.


I'm not aware of widespread filtering of /24s based on assignment  
boundaries in recent years. Can anybody confirm whether this is still  
a real problem?


The real problem today, I thought, was that of allocations or  
assignments being made from fresh /8s that still feature in peoples'  
bogon filters.



Joe

Re: Ams-ix issues?

[Joe Abley]

On 16-Jan-2007, at 16:52, Christian Koch wrote:

Anyone aware of any issues as of right now? Seems I may have lost  
connectivity at amsix




The [EMAIL PROTECTED] list is probably a better place to find signs  
of widespread problems (and since I've heard no noise on that list  
today, I would say the chance of there being widespread problems  
right now is low).



Joe

Re: Network end users to pull down 2 gigabytes a day, continuously?

[Joe Abley]

On 15-Jan-2007, at 08:48, Michal Krsek wrote:

This system works perfectly in our linear-line distribution  
(channels). As user you can choose time you want to see the show,  
but not the show itself. Capacity on PVR device is finite and if  
you don't want to waste the space with any broadcasted content you  
have to program the device. I have ten channels in my cable TV and  
sometimes I'm confused what to record. Beeing in the US and paid  
for ~100 channels will make me mad to crawl channel schedules :-)


So the technology is nice, but not a "What you want is what you  
get". So you cannot address the long tail using this technology.


These are all UI details.

The (Scientific Atlanta, I think) PVRs that Rogers Cable gives  
subscribers here in Ontario let you specify the *names* of shows that  
you like, rather than selecting specific channels and times; I seem  
to think you can also tell it to automatically ditch old recorded  
material when disk space becomes low.


One thing that may not be obvious to people who haven't had this  
misfortune of consuming it at first hand is that North American TV,  
awash with channels as it is, contains a lot of duplicated content.  
The same episode of the same show might be broadcast tens of times  
per week; the same advertisement might be broadcast tens of times per  
hour.


How much more programming would the existing networks support if they  
were able to reduce those retransmissions, relying on the ubiquity of  
set-top boxes with PVR functionality?



Joe

Re: Network end users to pull down 2 gigabytes a day, continuously?

[Joe Abley]

On 9-Jan-2007, at 13:04, Gian Constantine wrote:

You are correct. Today, IP multicast is limited to a few small  
closed networks. If we ever migrate to IPv6, this would instantly  
change. One of my previous assertions was the possibility of  
streaming video as the major motivator of IPv6 migration. Without  
it, video streaming to a large market, outside of multicasting in a  
closed network, is not scalable, and therefore, not feasible.  
Unicast streaming is a short-term bandwidth-hogging solution  
without a future at high take rates.


So you are of the opinion that inter-domain multicast doesn't exist  
today for technical reasons, and those technical reasons are fixed in  
IPv6?



Joe

Re: Network end users to pull down 2 gigabytes a day, continuously?

[Joe Abley]

On 9-Jan-2007, at 11:29, Gian Constantine wrote:

Those numbers are reasonably accurate for some networks at certain  
times. There is often a back and forth between BitTorrent and NNTP  
traffic. Many ISPs regulate BitTorrent traffic for this very  
reason. Massive increases in this type of traffic would not be  
looked upon favorably.


The act of regulating p2p traffic is a bit like playing whack-a-mole.  
At what point does it cost more to play that game than it costs to  
build out to carry the traffic?


If you considered my previous posts, you would know I agree  
streaming is scary on a large scale, but unicast streaming is what  
I reference. Multicast streaming is the real solution. Ultimately,  
a global multicast network is the only way to deliver these  
services to a large market.


The trouble with IP multicast is that it doesn't exist, in a wide- 
scale, deployed, inter-provider sense.



Joe

Re: Network end users to pull down 2 gigabytes a day, continuously?

[Joe Abley]

On 8-Jan-2007, at 22:26, Gian Constantine wrote:

My contention is simple. The content providers will not allow P2P  
video as a legal commercial service anytime in the near future.  
Furthermore, most ISPs are going to side with the content providers  
on this one. Therefore, discussing it at this point in time is  
purely academic, or more so, diversionary.


There are some ISPs in North America who tell me that something like  
80% of their traffic *today* is BitTorrent. I don't know how accurate  
their numbers are, or whether those ISPs form a representative  
sample, but it certainly seems possible that the traffic exists  
regardless of the legality of the distribution.


If the traffic is real, and growing, the question is neither academic  
nor diversionary.


However, if we close our eyes and accept for a minute that P2P video  
isn't happening, and all growth in video over the Internet will be in  
real-time streaming, then I think the future looks a lot more scary.  
When TSN.CA streamed the World Junior Hockey Championship final via  
Akamai last Friday, there were several ISPs in Toronto who saw their  
transit traffic *double* during the game.



Joe

Re: Network end users to pull down 2 gigabytes a day, continuously?

[Joe Abley]

On 8-Jan-2007, at 02:34, Sean Donelan wrote:


On Sun, 7 Jan 2007, Joe Abley wrote:
Setting aside the issue of what particular ISPs today have to pay,  
the real cost of sending data, best-effort over an existing  
network which has spare capacity and which is already supported  
and managed is surely zero.


As long as the additional traffic doesn't exceed the existing  
capacity.


Indeed.

So perhaps we should expect to see distribution price models whose  
success depends on that spare (off-peak, whatever) capacity being  
available being replaced by others which don't.


If that's the case, and assuming the cost benefits of using slack  
capacity continue to be exploited, the bandwidth metrics mentioned in  
the original post might be those which assume a periodic utilisation  
profile, rather than those which just assume that spare bandwidth  
will be used.


(It's still accounting based on peak; the difference might be that in  
the second model there really isn't that much of a peak any more, and  
the effect of that is a bonus window during which existing capacity  
models will sustain the flood.)



If you limit yourself to the Internet, you exclude a lot of content
being shifted around and consumed in the world.  The World Cup or  
Superbowl are still much bigger events than Internet-only events.  
Broadcast
television shows with even bottom ratings are still more popular  
than most Internet content.  The Internet is good for  
narrowcasting, but its

still working on mass audience events.


Ah, but I wasn't comparing internet distribution with cable/satellite/ 
UHF/whatever -- I was comparing content which is streamed with  
content which isn't.


The cost differences between those are fairly well understood, I  
think. Reliable, high-quality streaming media is expensive (ask  
someone like Akamai for a quote), whereas asynchronous delivery of  
content (e.g. through BitTorrent trackers) can result in enormous  
distribution of data with a centralised investment in hardware and  
network which is demonstrably sustainable by voluntary donations.


"Asynchronous receivers" are more expensive and usually more  
complicated

than "synchronous receivers."


Well, there's no main-stream, blessed product which does the kind of  
asynchronous acquisition of content on anything like the scale of  
digital cable terminals; however, that's not to say that one couldn't  
be produced for the same cost. I'd guess that most of those digital  
cable boxes are running linux anyway, which makes it a software problem.


If we're considering a fight between an intelligent network (one  
which can support good-quality, isochronous streaming video at high  
data rates from the producer to the consumer) and a stupid one (which  
concentrates on best-effort distribution of data, asynchronously,  
with a smarter edge) then absent external constraints regarding  
copyright, digital rights, etc, I presume we'd expect the stupid  
network model to win. Eventually.



  Not everyone owns a computer or spends a
several hundred dollars for a DVR.  If you already own a computer,  
you might consider it "free."


Since I was comparing two methods of distributing material over the  
Internet, the availability of a computer is more or less a given. I'm  
not aware of a noticeable population of broadband users who don't own  
a computer, for example (apart from those who are broadband users  
without noticing, e.g. through a digital cable terminal which talks  
IP to the network).



Joe

Re: Network end users to pull down 2 gigabytes a day, continuously?

[Joe Abley]

On 7-Jan-2007, at 15:17, Brandon Butterworth wrote:


The only time that costs increase is when I download
data from outside of BT's network because the increased
traffic reaquires larger circuits or more circuits, etc.


Incorrect, DSLAM backhaul costs regardless of where the traffic
comes from. ISPs pay for that, it costs more than transit


Setting aside the issue of what particular ISPs today have to pay,  
the real cost of sending data, best-effort over an existing network  
which has spare capacity and which is already supported and managed  
is surely zero.


If I acquire content while I'm sleeping, during a low dip in my ISP's  
usage profile, the chances good that are nobody incurs more costs  
that month than if I had decided not to acquire it. (For example, you  
might imagine an RSS feed with BitTorrent enclosures, which requires  
no human presence to trigger the downloads.)


If I acquire content the same time as many other people, since what  
I'm watching is some coordinated, streaming event, then it seems far  
more likely that the popularity of the content will lead to network  
congestion, or push up a peak on an interface somewhere which will  
lead to a requirement for a circuit upgrade, or affect a 95%ile  
transit cost, or something.


If asynchronous delivery of content is as free as I think it is, and  
synchronous delivery of content is as expensive as I suspect it might  
be, it follows that there ought to be more of the former than the  
latter going on.


If it turned out that there was several orders of magnitude more  
content being shifted around the Internet in a "download when you are  
able; watch later" fashion than there is content being streamed to  
viewers in real-time I would be thoroughly unsurprised.



Joe

Re: Collocation Access

[Joe Abley]

On 27-Dec-2006, at 18:22, Mark Newton wrote:


On Thu, Dec 28, 2006 at 12:13:07AM +0100, Leo Vegoda wrote:


My driving license doesn't have a photograph on it, so using it as an
identity document is pointless.


There's no way for a minimum-wage security grunt to verify the
particulars of my passport, so using it as an identity document
is pointless.


Which makes it hard for me to understand why they bother, and why  
they go to such great lengths to enforce arbitrary rules about what  
is acceptable and what isn't.


I gave my Ontario drivers licence to Equinix security in LA, once,  
and they refused to accept it as proof of ID since it wasn't  
government issued. I said it was; they disagreed. I tried to explain  
that there was more than one government in the world, but I got blank  
looks, and had to head out back past building security and up to the  
roof in the adjacent parking garage to get my passport.


For some reason it seemed a good idea to get all my various passports  
while I was there (I have three), and when I made it back inside I  
handed them all over together. I realised about two seconds after  
handing them over that I was probably doing a stupid thing. A whole  
group of them appeared, and huddled around my passports with their  
backs to me. They seemed on the verge of calling the FBI.


They gave the passports back, eventually, and I didn't go to jail. So  
it could have been worse. :-)



Joe

Re: Best networks with international presence..

[Joe Abley]

On 18-Dec-2006, at 12:04, Joel Jaeggli wrote:


Drew Weaver wrote:

I am looking for opinions of what US carriers have the best
connectivity with the international players such as teleglobe, etc.
Mainly, we are trying to determine if there is any way for us to get
less latency from teleglobe's customers to our network (we  
currently see
something like 1100 ms in teleglobe's london POP in traceroutes  
from our

customers to our network).


You sure the cpu on the teleglobe router in the path isn't just  
pegged?
If the rtt for the whole path is 400ms but one hop in the middles  
shows
1100ms you're probably measuring the performance of the scheduler  
in the
OS the router is running not rtt to and from that router, packets  
going
through it rather than to it likely take a different path through  
the box.


Of course if the customer's rtt is 1100+ ms then sure there's probably
serious congestion on one of those links.


Or the return path from that router is asymmetric, and involves a few  
congested hops into space and back. Teleglobe has customers in many  
parts of the world where such things are not so unusual.



Joe

Re: DNS - connection limit (without any extra hardware)

[Joe Abley]

On 8-Dec-2006, at 11:52, Geo. wrote:



Actually, reading your reply (which is the same as my own, pretty  
much), I
figure the guy asked a question and he has a real problem.  
Assuming he

doesn't want to clean them up is not nice of us.


Infected machines (bots) will cause a lot more than just DNS  
issues. Issues
like this have a way of getting worse all by themselves if not  
addressed.


Anyway, to play nice.. how about using a router to dampen traffic  
much like

icmp dampening? Would it be possible to do DNS dampening?


I think the trouble comes when you want to limit the request rate  
*per client source address*, rather than limiting the request rate  
across the board. That implies the retention of state, and since DNS  
transactions are brief (and since the client population is often  
large) that can add up to a lot of state to keep at an aggregation  
point like a router.


There some appliances which are designed to hold large amounts of  
state (e.g. f5's big-ip) but you're talking non-trivial dollars for  
that. Beware enterprise-scale stateful firewall devices which might  
seem like sensible solutions to this problem. They are often not  
suitable for use in front of busy DNS servers (even a few hundred new  
flows per second is a lot for some vendors, despite the apparent  
marketing headroom based on the number of kbps you need to handle).


You may find that you can install ipfw (or similar) rules on your  
nameservers themselves to do this kind of thing. Take careful note of  
what happens when the client population becomes large, though -- the  
garbage collection ought to be smooth and painless, or you'll just  
wind up swapping one worm proliferation failure mode for another.


Host-based per-client rate limits scale better if there are many  
hosts providing service, e.g. behind a load balancer or using  
something like .


As to the wider question, cleaning up the infected hosts is an  
excellent goal, but it'd certainly be nice if your DNS servers  
continued to function while you were doing so. Having every non- 
infected customer phone up screaming at once can be an unwelcome  
distraction when you already have more man hours of work to do per  
day than you have (staff * 24).



Joe

Re: anycasting behind different ASNs?

[Joe Abley]

On 6-Dec-2006, at 13:05, [EMAIL PROTECTED] wrote:


this is done today for the AS112 servers.


Actually, I think the origin AS of the AS112 prefix 192.175.48.0/24  
is intended to be consistent, and the view from route-views.oregon- 
ix.net doesn't contradict that theory, in practice.


This isn't a rabid endorsement of using consistent origin ASes;  
merely an observation, since you mentioned it.



Joe


route-views.oregon-ix.net>show ip bgp 192.175.48.0
BGP routing table entry for 192.175.48.0/24, version 92957
Paths: (44 available, best #40, table Default-IP-Routing-Table)
  Not advertised to any peer
  3277 112, (aggregated by 112 194.85.103.253)
194.85.4.55 from 194.85.4.55 (194.85.4.16)
  Origin IGP, localpref 100, valid, external
  Community: 3277:65400 3277:65401
  701 10913 10515 112
157.130.10.233 (inaccessible) from 157.130.10.233 (137.39.3.60)
  Origin incomplete, localpref 100, valid, external
  286 1257 8674 112
134.222.85.45 from 134.222.85.45 (134.222.85.45)
  Origin IGP, localpref 100, valid, external
  Community: 286:85 286:800 286:3031 286:4001
  6395 6453 3557 112
216.140.2.59 from 216.140.2.59 (216.140.2.59)
  Origin IGP, metric 20, localpref 100, valid, external
  Community: 6395:200
  16150 112
217.75.96.60 from 217.75.96.60 (217.75.96.60)
  Origin IGP, metric 0, localpref 100, valid, external
  Community: 16150:90 16150:63392 16150:64520 16150:65308  
16150:65320 16150:65330

  6079 174 27552 112
207.172.6.162 from 207.172.6.162 (207.172.6.162)
  Origin IGP, metric 6, localpref 100, valid, external
  7018 10515 112
12.0.1.63 from 12.0.1.63 (12.0.1.63)
  Origin incomplete, localpref 100, valid, external
  Community: 7018:2000
  2905 701 10913 10515 112
196.7.106.245 from 196.7.106.245 (196.7.106.245)
  Origin incomplete, metric 0, localpref 100, valid, external
  5511 3557 112
193.251.245.6 from 193.251.245.6 (193.251.245.6)
  Origin IGP, localpref 100, valid, external
  6395 174 27552 112
216.140.8.59 from 216.140.8.59 (216.140.8.59)
  Origin IGP, metric 20, localpref 100, valid, external
  Community: 6395:200
  12956 10429 22548 112
213.140.32.146 from 213.140.32.146 (213.140.32.146)
  Origin IGP, localpref 100, valid, external
  Community: 10429:110 10429:151 12956:1330 12956:2010  
12956:2960 12956:3043 12956:3076 12956:3117 12956:3120 12956:3126  
12956:3128 12956:3238 12956:3298 12956:3305 12956:3488 12956:3556  
12956:3570 12956:3620 12956:3666 12956:3723 12956:3880 12956:3886  
12956:4723 12956:4726 12956:4729 12956:4743 12956:7225 12956:15820  
12956:15822

  852 6461 3557 112
154.11.98.225 from 154.11.98.225 (154.11.98.225)
  Origin IGP, metric 0, localpref 100, valid, external
  Community: 852:180
  852 6461 3557 112
154.11.11.113 from 154.11.11.113 (154.11.11.113)
  Origin IGP, metric 0, localpref 100, valid, external
  Community: 852:180
  6939 112
216.218.252.145 from 216.218.252.145 (216.218.255.241)
  Origin IGP, localpref 100, valid, external
  2914 3557 112
129.250.0.85 from 129.250.0.85 (129.250.0.85)
  Origin IGP, metric 92, localpref 100, valid, external
  Community: 2914:410 2914:2000 2914:3000
  5650 2914 3557 112
74.40.7.36 from 74.40.7.36 (74.40.0.11)
  Origin IGP, metric 0, localpref 100, valid, external
  5650 174 3557 112
74.40.7.35 from 74.40.7.35 (207.173.112.63)
  Origin IGP, metric 0, localpref 100, valid, external
  6539 19318 112
216.18.63.137 from 216.18.63.137 (216.18.63.137)
  Origin IGP, localpref 100, valid, external
  2914 3557 112
129.250.0.11 from 129.250.0.11 (129.250.0.88)
  Origin IGP, metric 6, localpref 100, valid, external
  Community: 2914:410 2914:2000 2914:3000
  11608 3557 112
207.246.129.13 from 207.246.129.13 (207.246.129.15)
  Origin IGP, localpref 100, valid, external
  Community: 11608:444 11608:801 11608:1008 11608:6601
  1668 6461 3557 112
66.185.128.48 from 66.185.128.48 (66.185.128.48)
  Origin IGP, metric 504, localpref 100, valid, external
  4513 19318 112
209.10.12.125 (inaccessible) from 209.10.12.125 (209.10.12.125)
  Origin IGP, metric 8203, localpref 100, valid, external
  4513 19318 112
209.10.12.28 (inaccessible) from 209.10.12.28 (209.10.12.31)
  Origin IGP, metric 0, localpref 100, valid, external
  6079 174 27552 112
207.172.6.20 from 207.172.6.20 (207.172.6.20)
  Origin IGP, metric 0, localpref 100, valid, external
  4513 3557 112
209.10.12.156 (inaccessible) from 209.10.12.156 (209.10.12.156)
  Origin IGP, metric 0, localpref 100, valid, external
  3356 12956 10429 22548 112
4.68.1.166 from 4.68.1.166 (4.68.1.166)
  Origin IGP, metric 0, localpref 100, valid, external
  Community: 3356:3 3356:22 3356:100 3356:123 3356:575 3356:2008  
10429:110 10429:151 12956:1330 12956:2010 12956:2960 12956:3043  
12956:3076 12956:3117 12956:3120 12956:3126 

Re: anycasting behind different ASNs?

[Joe Abley]

On 6-Dec-2006, at 13:03, James Jun wrote:

Check 192.88.99.0/24.  It is an anycasted prefix for 6to4  
tunneling.  No AS
number was assigned for 6to4, thus it has inconsistent AS origin,  
and works

without any problems.


Well, without any problems that a consistent origin AS would fix,  
anyway.



Joe

Re: Reasons for attendance drop off

[Joe Abley]

On 5-Dec-2006, at 05:39, [EMAIL PROTECTED] wrote:


since you can't register w/o specifying a shirt size,
this is not an unreasonable assumption.


[For context, this is a thread that is happening on the nanog-futures  
mailing list. To subscribe, echo "subscribe nanog-futures" | mail  
[EMAIL PROTECTED] I'm not entirely sure how the thread escaped  
onto this list, but it might be nice if it could be herded back.]

Re: The IESG Approved the Expansion of the AS Number Registry

[Joe Abley]

On 30-Nov-2006, at 12:59, John Payne wrote:


On Nov 29, 2006, at 2:36 PM, Marshall Eubanks wrote:


Seems relevant.


Any word from vendors on supporting images?   I found some old  
presentations that said Juniper (ERX) and Redback had announced  
supporting images and Cisco had an unannounced version, but thats all.


http://www.potaroo.net/drafts/draft-huston-idr-as4bytes-survey-00.txt  
has some relevant info, although that draft is a year or so old now.



Joe

Increase in NANOG Meeting Attendance Fees

[Joe Abley]

[sent to nanog-futures@, bcc'ing nanog-announce@, apologies for  
duplicates]


During the past several community meetings, Merit have presented  
accounts for NANOG which show that revenue from membership fees and  
sponsorship are not sufficient to cover costs, despite substantial  
measures taken by Merit over the past several meetings to reduce the  
overhead involved in NANOG activities.


Recent efforts to plan ahead and arrange meeting venues up to 18  
months in the future have provided additional financial pressure,  
since hotels require substantial deposits. Extending the length of  
the meeting from Sunday-Tuesday to Sunday-Wednesday has also  
contributed to increased costs, as have the improvements in network  
infrastructure which have been evident at recent meetings. Revenue  
has not increased to offset these additional costs.


Merit and the SC are together working on changes to the sponsorship  
structure at NANOG meetings in order to increase the value to  
sponsors from participating with the goal of increasing meeting  
revenue. Changes will take some time to implement, however, and are  
by their nature somewhat speculative since the benefits of the  
changes will not be really apparent until they have been implemented.


At past community meetings, people have clearly expressed that modest  
increases in meeting fees would not present significant barriers to  
meeting attendance, so long as the other costs of attending (hotel  
block rates, travel, etc) were maintained at current levels. NANOG  
meeting fees are low when compared to other, similar events. The  
current meeting fee of $350 has been in place since NANOG 28 in June  
2003.


Both Merit and the SC are committed to finding a sustainable funding  
model which will ensure that NANOG continues to be a viable community  
resource for many years to come, and is predictably and reliably self- 
sustaining for the benefit of all participants.


In their meeting on Wednesday 2006-11-22 the Steering Committee  
approved an increase of NANOG meeting attendance fees from $350 to  
$450. This will be implemented for NANOG 39 in Toronto.


Further discussion of funding models and related topics is  
encouraged, and should take place on the nanog-futures mailing list.  
Please see <http://www.nanog.org/email.html> for subscription  
instructions.



Joe Abley
for the SC

Re: passports for NANOG-39, Toronto

[Joe Abley]

On 26-Oct-2006, at 09:26, [EMAIL PROTECTED] wrote:


You could do the same fly-drive via Detroit but there is
a lot more driving.


Indeed. Rough estimates, excluding time taken to cross the border and  
assuming good weather:


  BUF to Toronto: 2 hours
  DTW to Toronto: 5 hours
  CLE to Toronto: 6 hours
  LGA to Toronto: 9 hours
  BOS to Toronto: 9 hours
  ORD to Toronto: 10 hours
  IAD to Toronto: 10 hours


Joe

Re: Need help explaining in-addr.arpa to Limelight

[Joe Abley]

On 23-Oct-2006, at 21:13, Edward Lewis wrote:

If an admin were granted the authority for a /25 worth of space,  
then you can't just delegate that part of the in-addr.arpa domain.   
That's the RFC Joe Abley cited.


Ah, so you smell an apex CNAME. They might be using DNAME, though :-)


Joe

Re: Need help explaining in-addr.arpa to Limelight

[Joe Abley]

Tuc!

On 23-Oct-2006, at 18:03, Tuc at T-B-O-H.NET wrote:


Is there someone out there that might be able
to help me explain this to the techs there. That you
can't "subdomain" an in-addr.arpa like you do a domain
name?


RFC 2317. A zone's a zone's a zone, and zones can contain CNAMEs.


Joe

New NANOG Programme Committee

[Joe Abley]

In its last scheduled conference call, the NANOG SC selected a new  
Programme Committee.


With twenty well-qualified new candidates, and only eight open  
positions, it was a difficult decision to make. The SC, with input  
from the current PC, strongly felt it necessary to form a balanced  
PC, with a diversity of backgrounds, knowledge, and experience, and  
is representative of the entire NANOG constituency.


The SC would like to thank outgoing PC members Hank Kilmer, Dave  
O'Leary and Kevin Epperson for their valuable contributions to the  
PC. In addition, the SC is grateful to the 12 candidates who  
volunteered their time but who weren't selected this time round. We  
hope you will all consider volunteering again next time.


The NANOG Programme Committee for 2006/2007 is as follows:

Existing members:

  Nick Feamster
  Dan Golding
  Joel Jaeggli
  Ren Provo
  Josh Snowhorn
  Pete Templin
  Todd Underwood
  Vish Yelsangikar

New (or returning) members:

  Steve Feldman
  Igor Gashinsky
  Kobi Hsu
  Mike Hughes
  Keith Mitchell
  Ted Seely
  Richard Steenbergen
  Bill Woodcock


Joe Abley
(for the SC)

Re: Collocation Access

[Joe Abley]

On 23-Oct-2006, at 11:54, Craig Holland wrote:

I just ran into something for the first time, and apparently it  
isn’t that uncommon.  AT&T was asked to install a circuit into a  
collocation facility where, like any I’ve been into, required them  
to show a government ID.


In a similar vein, it'd be nice if colo facilities who require  
government-issued ID could be taught that there is actually more than  
one government in the world, and that if they mean "US-federal-or- 
state-government-issued" they should say so.


(They let me in eventually with a passport. But if they're going to  
trust a foreign-issued passport as photo id, it's not really that  
obvious to me why they wouldn't trust a foreign-issued driving  
licence. It's not like they can really tell whether either of them  
are forged.)



Joe

New NANOG Mailing List Admin Team

[Joe Abley]

Last night the NANOG SC made some changes to the composition of the  
mailing list admin team, in response to the revisions to the NANOG  
charter which were approved by the community in St Louis.


After extensive discussion the SC selected an admin team which  
provided some continuity whilst also welcoming a new volunteer. The  
SC assigned terms to each member of the team in order to make the re- 
selection process described in the new charter straightforward to  
follow next year. These terms were assigned semi-arbitrarily (in one  
instance we tossed a coin to decide).


Chris Malayter and Steve Wilcox have not been appointed to the new  
team. The SC would like to thank both of them for their dedication to  
the mailing list, and their key roles in helping NANOG evolve into a  
community-driven organisation.


There were many excellent new volunteers who offered to serve on the  
panel, and from that pool of candidates the SC selected Aleksandr  
Pilosov. The SC would like to thank Aleksandr for offering to  
contribute his time to NANOG in this way.


The SC also thanks those volunteers who were not selected for  
stepping forward and offering to help. We hope you will feel able to  
volunteer again in the future.


The new mailing list admin team is as follows:

  Sue Joiner (appointed by Merit)
  Rob Seastrom (appointed by SC, 1-year term)
  Brett Watson (appointed by SC, 1-year term)
  David Barak (appointed by SC, 2-year term)
  Aleksandr Pilosov (appointed by SC, 2-year term)


Joe Abley
(for the SC)

selection of new NANOG programme committee

[Joe Abley]

The SC plans to select a new Programme Committee during their meeting  
on Thursday 19 October. The complete list of PC candidates is here:


  http://www.nanog.org/pccandidates06.html

If you have any opinions or comments you would like to share with the  
SC about any of the PC candidates please feel free to send them to  
[EMAIL PROTECTED]


[Comments received will be archived in a private mailing list archive  
accessible to the SC, will be used only as an aid to the PC selection  
process, and will not be forwarded outside the SC.]

Call for Volunteers for Mailing List Administration Panel

[Joe Abley]

The NANOG charter, as amended by the community as part of the voting  
process in St Louis, requires the reappointment of members of the  
Mailing List Administration Panel at the autumn meeting.  
Correspondingly, there are now openings on the panel.


According to the charter:

"... The NANOG list will be administered and minimally
moderated by a panel selected by the Steering Committee."

Accordingly, the Steering Committee is soliciting nominations for the  
Mailing List Admininistration Panel, from now through 1700 UTC,  
Thursday 19 October 2006.


** Procedure **

To volunteer yourself or nominate someone else, please send mail to  
[EMAIL PROTECTED] with the following information, no later than 1700  
UTC, Thursday 19 October 2006.


  - Your name
  - Nominee's name (if not you)
  - Nominee's email address
  - Nominee's phone number
  - Nominee's employer
  - Reasons why you believe the nominee is qualified to serve
on the Mail List Panel.

We will contact each of the nominees to verify interest and possibly  
request additional information.


Once all nominations have been received, the Steering Committee, in  
cooperation with the Mailing List Admin Panel, will select the Panel.  
The result will be announced on the nanog-announce mailing list.


** Eligibility **

A nominee may not be a member of the NANOG Program Committee or of  
the NANOG Steering Committee. Anybody else actively reading the  
[EMAIL PROTECTED] mailing list is eligible.


** Duties **

Basic duties include reading the mailing list and assisting with  
keeping things on-topic. The team also deals with abuse issues as  
they arise.


** Length of term **

The current NANOG charter specifies term lengths of two years.

If you have any questions, please post to [EMAIL PROTECTED], or  
email [EMAIL PROTECTED] and [EMAIL PROTECTED]


Finally, on behalf of the Mailing List Panel and the Steering  
Committee, we would like to thank everyone for their help in making  
NANOG a useful environment for operators.



Joe Abley, SC chair
Chris Malayter, MLC chair

The Postel Network Operator's Scholarship

[Joe Abley]

The Internet Society (ISOC) a 501c(3) corporation (http://
www.isoc.org/isoc/general/trustees/incorp.shtml), has agreed to
accept a restricted donation from an anonymous source to be known as
the "Postel Network Operator's Scholarship."

The Scholarship will be awarded annually to a recipient selected by a
"Selection Committee" consisting of a representative of the then
serving Board of ARIN (The American Registry of Internet Numbers -
http://www.arin.net) and a representative of the then serving
Steering Committee of NANOG (The North American Network Operator's
Group - http://www.nanog.org).

The award is intended to enable a deserving network operator who
would not otherwise be able to attend the Joint Meeting to do so, and
whose attendance at the Joint Meeting will continue to build on the
legacy of Jon's lifetime contribution to the Internet.

The Selection Committee will develop an open and public application
process, and will "whimsically" select the annual recipient
exclusively in response to the question: "What Would Jon Do?" if he
were asked to select a recipient. There are no criteria or
restrictions or other requirements, including but not limited to
nationality, location, age, or gender.

The scholarship will cover the costs of travel from the recipient's
home city to the Joint Meeting.  It will also cover the costs of
Hotel accommodation at the Conference Hotel.  It will include a daily
stipend for food, beverages, and incidentals.  It is expected that
the attendence fee for the meetings will be waived by ARIN and NANOG.

The membership of the Selection Committee shall not be changed except
in the event that the membership of either the Board (in the case of
ARIN) or the Steering Committee (in the case of NANOG) ceases to be
based on the popular vote of the community each serve; in which case
the member whose process changes will be replaced by a similar body
that is based on the popular vote of the community that was served by
the ineligible member, and which will be appointed at the sole
discretion of the Board of Trustees of the Internet Society, and
under the same terms as the initial Selection Committee.

At its option, the Internet Society may increase or decrease the
number of recipients each year based on the current state of the
Scholarship Fund, and the variable costs of travel and accommodation.

Re: that 4byte ASN you were considering...

[Joe Abley]

On 10-Oct-2006, at 12:01, David W. Hankins wrote:


But it's just /weird/ to ask the IETF to have this kind of
role...one it has never had to my memory, and seeks constantly
not to fulfill.


It's not so weird when you realise that the notation adopted has an  
impact on other IETF work (RPSL is the obvious example that springs  
to mind).



Joe

Re: [Fwd: Important ICANN Notice Regarding Your Domain Name(s)]

[Joe Abley]

On 4-Oct-2006, at 19:04, Steve Sobol wrote:


ICANN *does* have a requirement for accurate information in WHOIS and
while I don't know how strongly the requirement is enforced, they  
*can*

pull your domain registration if you don't have accurate information.


While I'm not familiar with the precise enforcement mechanisms or  
policy, I do know of one ISP who had the delegation for their (.com)  
domain name unexpectedly pulled by the registry in response to a  
complaint about inaccurate whois information directed at ICANN.


It was painful for the ISP, especially since it happened during the  
time that Verisign's sitefinder was live, which caused e-mail to ISP  
customers to be hard bounced from Verisign and people looking for  
their web page to be presented with a "this domain is not registered"  
page instead of a browser error.


It's well worth avoiding, even without the additional sitefinder  
complications :-)



Joe

Re: International phone numbers (was Re: AOL Non-Lameness)

[Joe Abley]

On 3-Oct-2006, at 08:53, Joe Abley wrote:

E.123 also tells us how to write our e-mail addresses and URLs on  
business cards, except that it calls URLs "web addresses". At  
least, this is what I can glean from the many E.123 summaries I  
could find, since the actual document isn't available for free  
download. We're certainly lucky to have the ITU.


I was asked to pass on the following.

On 3-Oct-2006, at 16:37, <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>  
wrote:



I'm not a subscriber to nanog so please pass this on...

From 1 January 2007, all ITU-T Recommendations will
be freely available in pdf. Currently this is supposed to
run as a "trial" until the third quarter of 2007 when an
evaluation will be done on its success.

rs

Re: International phone numbers (was Re: AOL Non-Lameness)

[Joe Abley]

On 3-Oct-2006, at 00:37, Rick Kunkel wrote:


Boy, this is certainly OT.


Yeah. Apologies for contributing to the noise, but since someone  
mentioned it earlier...



I had a suspicion it might be standard somewhere.


The ITU recommendation is E.123 (02/01), ITU article number E20897 in  
English. That document recommends that a hyphen, space or period be  
used to provide visual separation between groups of numbers;  
parentheses are to be used for sections of the number which are  
sometimes not dialled, but not in the full international notation  
which includes an E.164 country-code.


E.123 also tells us how to write our e-mail addresses and URLs on  
business cards, except that it calls URLs "web addresses". At least,  
this is what I can glean from the many E.123 summaries I could find,  
since the actual document isn't available for free download. We're  
certainly lucky to have the ITU.



Joe

Re: Zimbabwe satellite service shutdown for non-payment

[Joe Abley]

On 2006-09-19, at 03:59, Brandon Galbraith wrote:


Does any fiber run into Zimbabwe? Or is everything via satellite?


Having fibre to your neighbiour is the exception in Africa, not the  
rule.


There has to be a remaining uplink (albeit low-capacity) if  
nameservers within the country are still accessible.


There's more than one satellite operator with footprints that cover  
Zimbabwe.



Joe

Re: Watch your replies (was Kremen....)

[Joe Abley]

Le 2006-09-13 à 15:59, Andrew Kirch a écrit :

I might just to watch the hilarity.  Is there any real interest in  
this?

MediaWiki with restricted editing for people on the NANOG list.


At the risk of repeating myself, . This is  
a NANOG wiki with somewhat restricted editing (you have to register  
an account) running on MediaWiki.



Joe