Re: Recommended L2 switches for a new IXP
On Tue, Jan 13, 2015 at 4:45 PM, Stephen R. Carter stephen.car...@gltgc.org wrote: We love our 5100s here. Out of interest: Are you running 13.2 or 14.1? What features are you using? Our own experiences with a bunch of 48 96 port machines running 14.1 is painful to say the least. Richard
Direct sales contacts to local loop providers in NYC
Dear all, I have received a lot of off-list mail as a result of my last email, so I figured I would try the same approach local loops. We seem to be unable to get past the silk screen of residential, private lines with most carriers of local loops within NYC. Specifically, we are looking for one 10M line in Manhattan as of right now, but we already have new deals in our pipeline and wouldn't make the jump across the pond if we didn't see steady long-term growth in the future. If anyone has contact with the right sales people (or the right sales people lurk on this list), please feel free to contact me. Thanks, Richard
Carrier-neutral data center in NYC with good connectivity to long-haul and local loop
Dear all, we want to establish a presence in NYC and will need to collect a few local loops (10M-100M) from around NYC. From there, we will connect back to Germany. So, in summary, we will need: * 2-5 rack units to allow for initial deployment and growth * good connectivity to local loops * good connectivity to long-haul back over the Atlantic and within the Continental US While I already compiled a preliminary list of possible choices, I would like input on what DCs would be well-suited for this. As an aside, who are the most painless and efficient Local Loop carriers within NYC and the US? ATT and Verizon come to mind, but I don't know the local market at all. Thanks, Richard
Re: [v6ops] Conclusions? - Introducing draft-denog-v6ops-addresspartnaming
On Mon, Nov 29, 2010 at 21:34, Doug Barton do...@dougbarton.us wrote: If you're looking for serious feedback: We are. 3. I've never had a problem calling it field, I think that 5952 is a perfectly good normative ref for that, and I don't understand what the fuss is about. :) I seem to remember one of the authors of the initial RFCs telling us that they went with field with the understanding that it's so generic that someone could/would think of something else down the road. I didn't have time to really search for that mail, though. The fact that GMail is refusing to display quite a few mails atm (or serve them via SMTP) does not help, either. Most of my draft-related emails are amongst that... To give a short summary of the current status: Hextet received the most votes by far, followed by quibble. Everything else didn't get nearly as much support. Quad has been suggested a lot of times, but its meaning within the C/C++ world and very frequent use within the Kame stack sadly makes this a no-go. Quibble already has a meaning in English and a negative one, at that. Hextet is incorrect if you are being pedantic, but it's reasonably unique so that you don't have to call it IPv6 hextet to avoid confusion. Given all of the above, my personal opinion is that hextet will come out as the winner. Richard PS: Thanks to Joel. I was contemplating how to refocus the whole thing and he did our job for us; and nicely.
Re: Introducing draft-denog-v6ops-addresspartnaming
On Sat, Nov 20, 2010 at 23:15, Owen DeLong o...@delong.com wrote: You seem to be indirectly answering the parent posting in much of what you say. That is fine, I just wanted to point it out. It's a commonly accepted, well-defined convention to save humans effort while not sacrificing readability. There are weirder things in technology. I don't think it's all that weird and it's a major savings in writing out IPv6 addresses and being able to read them (except in lists of varying sized addresses (please, when dumping routing tables and such, just keep the optional zeroes or give us a flag to choose). In practice, the :: usually ends up being placed between the network number and the host number for things with static addresses and rarely appears in EUI-64 based addresses, so, I don't see this as a problem. FWIW, I do not see it as weird or as a problem, either. There are weirder things does not mean the thing I am referring to is weird itself :) I don't see a problem with people not assigning customers /56s so long as they go in the correct direction and give /48s and not /60s or /64s. Many ISPs will end up handing their customers /64, /62 or other less-than-ideal prefixes. As soon as a customer needs to subnet their /64, the real fun starts. There is nothing we can do about it, other than trying to educated people and hope for the best. I honestly think I never explained (as in, after I understood the matter, myself) netmasks other than as a bit vector. Unless you mean write 255.255.255.0 in there cause that's what right for you. Then you are young and never had to deal with systems that didn't know about bit-vector syntax. I have had to explain the translation between bit-vector syntax (/n) and bit-field syntax (255.255.255.240) to many people. It's easy when n is a multiple of 8. After that, it can be quite hard for some mathematically challenged individuals unfamiliar with binary and BCD to wrap their heads around. I wish ;) Either the person can grasp that a dotted netmask can be transformed into a bit vector or I tell them use 255.255.255.0 everywhere, it will work for everything you will ever need. 80/20 and all that. Removing bitmath from operations where possible is a good thing that reduces outages caused by human factors. It's just good human factors engineering. We can't do so in IPv4, there aren't enough bits to do it. We seek to do so in IPv6 with ARIN draft policy 2010-8 and proposal 121. If by bitmath you mean ending netmasks not on full bytes only, I could not agree more. This will reduce a lot of useless overhead. I really wish the RIRs would get unique a name space for their respective drafts. If even my person object needs a -RIPE suffix, I don't see why drafts etc don't. Should we all sing kumbayah now? Only if you bring a tambourine. Basically, as I recall the earlier discussions of this and the IETF arriving at the decision to use colon (:), it boiled down to the simple fact that colon (:) is the worst choice except for all the others. Agreed. Richard
Re: Introducing draft-denog-v6ops-addresspartnaming
On Sun, Nov 21, 2010 at 16:54, William Herrin b...@herrin.us wrote: Because in my version fd::/8 actually is the same as fd00::/8, which, as you rightly point out, is exactly what a normal human being would naturally expect. Which is against every expectation of anyone who ever learned Arabic numbers in a left-to-right system. As Owen pointed out, filling with zeros on the right-hand side would be, to put it lightly, a disaster. Maybe I should have worded that more strongly in my last reply. Imea nrea lly, what ifwe wrot eEng lish thew aywe writ eIPv 6add ress es? Looks pretty stupid without a floating separator, doesn't it? Reductio ad absurdum. We've gone too far down the wrong path to change it now; colons are going to separate every second byte in the v6 address. But from a human factors perspective, floating colons would have been better. No. See my, and Owen's, emails. From a computer parser perspective, a character other than a colon would have been better because colons are already claimed for many for other syntax elements that include an IP address, like the address/port separator in a URL. It's the least bad amongst a highly limited choice of even worse chars. There is a reason why the colon is used so often. Making the jump in logic, it would help mitigate the errant design if the two-byte groupings separated by the colons were intentionally and formally not named. That fits a training scenario which reinforces the idea that the colons are there for convenience but that there is nothing special about those two byte groupings. Personally, I have no interest whatsoever in limiting my efficiency and increasing the chance that I or others make mistakes because people who don't understand the matter at hand might misinterpret something. The question leads me to recall a fancy version of traceroute I once used. In addition to looking up the PTR record for each hop, it also looked up the org and AS number currently associated. If users found it valuable to have the router present variable colon placement, it's a doable albeit complex computing task. If you ever looked at the state of a lot of data in the RIR's whois databases, you know that's literally impossible. And a _lot_ of effort for little to no gain. And what if a LIR changes their numbering scheme, at some point? Attach parsing instructions to inetnum? Richard
Re: Introducing draft-denog-v6ops-addresspartnaming
On Sun, Nov 21, 2010 at 23:15, Owen DeLong o...@delong.com wrote: In fact, it would look pretty weird to most people if we started writing 951-21-42-33 (or I bet they wouldn't expect that was a zip code in any case). Similarly, if we start placing the separators in arbitrary places in phone numbers, people get confused. The complete uniformity of telephone numbers seems to be a North American phenomena, but as a German who is used to wildly different phone numbers, I would still prefer a common scheme for all of them, yes. I still disagree. While I noted the one pathology with the current system, that same pathology is present with floating colons and there are others which I also pointed out (difficulty in reproducing the correct placement of the floating colons in automated output, for example. Even worse, allowing floating colons will mean different groups will adapt different defaults. Not a desirable goal. The syntax for handling this was already present in IPv4 and is easily adapted to the problem in IPv6. Simply wrap the IPv6 address in square brackets (e.g. [2001:db8:feed::cafe]:80 is the ipv6 address 2001:db8:feed::cafe on port 80). Which is admittedly ugly, but I can't think of anything better, either. We did forego ::192.168.1.1. However, we still have :::192.168.1.1 and for good reason. This is a useful construct for allowing humans to see in log files that an IPv6-aware application on a dual-stack machine accepted an IPv4 connection on an IPv6 socket. Agreed. Ugly, but useful needed. Richard
Re: Introducing draft-denog-v6ops-addresspartnaming
Please don't group several emails into one. It breaks threads. And while I could not find anything about this in the NANOG FAQ, it's common netiquette not to do so. On Sun, Nov 21, 2010 at 23:50, William Herrin b...@herrin.us wrote: On Sun, Nov 21, 2010 at 11:40 AM, Joel Jaeggli joe...@bogus.com wrote: Looks like an ass-u-me. If you think the use if IPv4 addresses in URLs is infrequent, it's mostly u. Get out in the field some time. Ad hominem usually does not do much to maintain or improve the quality of a discussion. That server op is the kind of guy we're asking to understand that there's nothing special about the two bytes between the colons in the IPv6 address. He's gonna be trouble. As you described yourself, he is gonna be trouble anyway. People end up working around him anyway, so why bother to cater to his needs? Especially as the fixed colons are here to stay and a good thing, also. On Sun, Nov 21, 2010 at 1:42 PM, valdis.kletni...@vt.edu wrote: Whatever you want to do. That's the point of optional/movable separators. Principle of least surprise. On Sun, Nov 21, 2010 at 5:15 PM, Owen DeLong o...@delong.com wrote: That would be a more compelling argument if it accurately described phone number notation. It doesn't. +44 121 410 5228, for example, is the phone number for parking services at Heathrow airport, exactly as described on http://www.heathrowairport.com/'s contact us page. No dashes at all, and not 10 digits. The UK is not part of the USA nor of Canada. IPv6 is one of very few addressing schemes in which the separators intentionally have no greater meaning within the protocol or its use. As has been pointed out several times before, helping humans reduce errors is a highly desirable goal. _And_ the discussion is moot anyway. I think I am at a point where I will simply ignore any new occurrences of this theme. Richard
Re: Introducing draft-denog-v6ops-addresspartnaming
For the sake of completeness, the relevant part of what I answered privately can be found below. On Mon, Nov 22, 2010 at 13:22, Jeff Aitken jait...@aitken.com wrote: [ Meant to send this to the list and not directly to Richard. ] On Fri, Nov 19, 2010 at 03:07:40AM +0100, Richard Hartmann wrote: If any of you have any additional suggestions, you are more than welcome to share them. I will add quad to -03 anyway. If you get a few +1 on hexquad, I am against adding that, as well. Richard
Re: Introducing draft-denog-v6ops-addresspartnaming
On Mon, Nov 22, 2010 at 15:07, William Herrin b...@herrin.us wrote: Trimming zeros on both the left and the right, as the correctly written IPv6 notation 1::/16 would have us do, is confusing. It's like writing one million and one tenth as 1,,.1 instead of 1,000,000.1. No, there are simply two mechanisms at work: I start with 0001:::::::/16 then, I remove leading zeros as they are not needed 1:::::::/16 which I can further reduce by the same mechanism to 1:0:0:0:0:0:0/16 Finally, the accepted convention for IPv6 addresses is that I can drop a continuous block of zeros which means I end up with 1::/16 Makes perfect sense to me. Six of one, half a dozen of the other. Flooding a list with half a dozen replies on the same thread at the same time is poor netiquette for its impact on unthreaded mail agents and if your mailer started a new thread for this message in spite of the identical subject and in-reply-to header then it's broken. I disagree, but if you want to continue this part of the discussion, we should do so off-list. I do apologize that I wrote this in-line and did not poke you off-list in the first place. Insolence alone does not rise to argumentum ad hominem. The predicate assumption is wrong. Here's several paragraphs about what's actually observed in the field, certainly isn't. If you want to call me out on a logical fallacy, at least call me out on one I've actually committed. I called out a social, not a logical, fallacy. As per the rest, see above. Richard
Re: Introducing draft-denog-v6ops-addresspartnaming
On Mon, Nov 22, 2010 at 16:23, Owen DeLong o...@delong.com wrote: then, the other ISPs will eventually find themselves at a competitive disadvantage as their customers start to ask Why can't I have a /48 like my friend Bob got from provider Z? I kinda implied that, but yes, I should have written it out. Thanks :) So... Don't worry, I ended up picking up the educational task where you left off. Even though this is getting kinda off topic: In my private life, I either explain what a bit vector is or I tell them to use a /24. In my professional life, I either deal with people who can grasp the bit vector thing or they bought the complete care package anyway, meaning that we tell them where to click on the CMS to make the colourful overload they call a website go bling. In the latter case, I don't have to explain anything because a) that part is handled by someone else b) they have no interest whatsoever in learning what an IP address is, let alone a netmask. (OK, maybe not the exact same set of users, but, honest, you're not the only one who took this approach and it did lead to interesting breakages by users so educated in a number of places I have worked.) The question is: Would those users have acted any differently if someone went to the trouble of explaining in depth what they would have forgotten within days? Well, in IPv6, I think ending them on nibbles is fine. Hmm, true. That's fine, too. Richard
Re: Introducing draft-denog-v6ops-addresspartnaming
On Mon, Nov 22, 2010 at 18:33, Daniel Hagerty h...@linnaean.org wrote: Ambiguating usages like Take the least signifigant quad of that ipv6 address to mean either 16 bits or 64 bits, when it currently is unamibigously 64 bits won't make the lives of C/C++ programmers writing IPv6 code any easier. Agreed. Thanks a lot for pointing this out. Comments like this are incredibly valuable to me. I think I will still add quad to -03 as it has been requested a lot of times, but more to point out and document that there is a significant problem with it than anything else. Thanks again, Richard
Re: Introducing draft-denog-v6ops-addresspartnaming
On Mon, Nov 22, 2010 at 14:05, Richard Hartmann richih.mailingl...@gmail.com wrote: I will add quad to -03 anyway. If you get a few +1 on hexquad, I am against adding that, as well. Erm. Belated, but I am _not_ against adding etc pp. Richard
Re: Introducing draft-denog-v6ops-addresspartnaming
On Fri, Nov 19, 2010 at 23:52, William Herrin b...@herrin.us wrote: I thought about that. Have a one colon rule that IPv6 addresses in hexidecimal format have to include at least one colon somewhere. The regex which picks that token out versus the other possibilities is easy enough to write and so is the human rule: Oh, it's got hexidecimal digits and a colon in it. IPv6 address. Even if this were feasible at this point, and it's not, this would still make it hard for humans to detect an IPv6 address at a glance, makes it impossible to quickly pick out any sections that are more relevant at the moment and would hog the colon for all eternity, blocking it for other uses. Also, this would make adding a port even more cumbersome. fd00:68::1 and fd:0068::1 mean different things now. The former means fd00:0068::1 while the latter means 00fd:0068::1. I would instead have them mean the same thing: fd00:6800::1. The single-colon separator gets syntax but no semantics I am not sure if this would actually be an advantage. and the :: separator means all middle nibbles are zero instead of all middle two-byte components are zero. Putting the burden of parsing that on humans (and computers). Same as modern compression algorithms are optimized to doing more work while encoding and less work during decoding, it does not really make sense to make it harder to understand an address while reading it for the dubious gain of saving up to six colons. I mean, when you think about it, the consequence that :: means all middle two-byte components are zero is kinda weird. It's a commonly accepted, well-defined convention to save humans effort while not sacrificing readability. There are weirder things in technology. Anything you call out will be interpreted as special. The more you call it out, the greater the expectation that the distinction is important. That's human nature. Pattern recognition is a central part of our intelligence, so yes, it's human nature. This is not necessarily a bad thing. While I agree that some of the delimitations are social, rather than technical, it's still useful to have them. If this results in some people not assigning their customers a /56 cause it looks funny, so be it. You've explained netmasks before to folks whose brains couldn't get past the dots in the address. We all have. I honestly think I never explained (as in, after I understood the matter, myself) netmasks other than as a bit vector. Unless you mean write 255.255.255.0 in there cause that's what right for you. And referring to IP address notation as dotted quads just reinforces classful addressing concepts so that folks assigning themselves 10/8 subnets damn near always split on /16 and /24 boundaries. And why shouldn't they? Unless they are a large ISP or similar, they will have enough space for pretty much everything they ever need to do. It's as good as anything and it allows people to be somewhat familiar with this stuff. Not everyone is an expert and that is fine. Personally, I have no motivation whatsoever to _truly_ understand _everything_ that's involved in today's wireless systems. Still, it's nice that I can use them reliably without needing this level of involvement. And even more efficiently when we don't have to repeatedly explain that the mental model implied by the notation style is, in fact, not how the technology actually works. If the person can grasp what a bit vector is, they will understand. If they don't, they will not understand it anyway and I won't waste time trying to explain it in depth. At least as of right now, you are giving those people some middle ground which allows them to have a good working knowledge to use IPv6 reliably without needing this level of involvement. No sweat. When I shoot my mouth off, I expect to be challenged on the remarks. Part of the fun lies in discovering whether the thesis is defensible. For at least a few rounds, I am usually good for that, too. Personally, I think I answered the implicit question above, but it made me re-asses and re-think my personal professional opinion on quite a few things and that's a Good Thing, from time to time. By the by, as long as I'm criticizing IPv6 notation, let me express just how poor a choice of separator character the colon is. The colon separates the IPv4 address from a directory or port description only slightly less often than the slash. Writing the parsers to handle an IPv6 address as a drop in is a pain in the tail. Should have used a dash, underscore or plus. Those are far more rarely used in tokenization. A dash is the character people use when there is not a standard. Look at what they had to do for UUIDs to make them recognizable (which worked out really well, especially the version encoding. I really like their solution). Though they had the advantage that substring length _really_ doesn't matter other than as a way to correctly distinguish UUIDs from anything else.
Re: Introducing draft-denog-v6ops-addresspartnaming
On Fri, Nov 19, 2010 at 07:00, bmann...@vacation.karoshi.com wrote: problem is, its not alwas ggoig to be two bytes... It's always two bytes, but people may choose to omit them. That is a social, not a (purely) technical, syntax, though. Richard
Re: Introducing draft-denog-v6ops-addresspartnaming
On Fri, Nov 19, 2010 at 08:42, Owen DeLong o...@delong.com wrote: Since the poll is a straight yes/no option with no preference, I will express my preference here. I considered using the Condorcet method [1] (modified for NotA), but as past experience has shown that people get easily confused by it, I decided to create a plain poll, instead. While I find the term quibble fun and amusing, I think hextet is a far more useful term because it does not have the overloaded human semantics that come with quibble. To be completely honest, while I did know the term, I had forgotten about it. This is part of the reason why I am seeking a wider audience. I'll add this consideration to the draft. I agree that this might be (not has to be) a deal breaker. I'm sorry to quibble with the majority here, but, in this case, I think we have enough problems with ambiguous terminology in networking and this opportunity to avoid creating one more should not be missed. Agreed. OTOH, Hextet is not technically correct while appearing to be so. Thanks a lot, Richard [1] http://en.wikipedia.org/wiki/Condorcet_method
Re: Introducing draft-denog-v6ops-addresspartnaming
On Fri, Nov 19, 2010 at 10:57, George Bonser gbon...@seven.com wrote: That's exactly what I was going to say but didn't want to quibble. We tend to call them quads at work. What do you call that indeterminate space between two colons :: where it might be four or more zeros in there? That's a bunch of nibbles, maybe a gulp? I don't call it anything. The fourth $decided_upon is zero/empty suffices :) Though if that gap does not have a name yet, I suppose it can't hurt to try and think of a canonical name, either. Richard
Re: Introducing draft-denog-v6ops-addresspartnaming
On Fri, Nov 19, 2010 at 14:14, Scott Morris s...@emanon.com wrote: If 8 bits is a byte, then 16 bits should be a mouthful. When does it become a meal and, more importantly, do you want to supper (sic) size? RIchard
Re: Introducing draft-denog-v6ops-addresspartnaming
On Fri, Nov 19, 2010 at 17:58, Owen DeLong o...@delong.com wrote: It is always two bytes. A byte is not always an octet. Some machines do have byte sizes other than 8 bits Vice versa. It's always two octects, but on some systems it may not be two bytes. , although few of them are likely to have IPv6 stacks, so, this may be an academic distinction at this point. Agreed. We can revisit this once we all own a few portable quantum computers, though :) Richard
Re: Introducing draft-denog-v6ops-addresspartnaming
On Fri, Nov 19, 2010 at 21:45, William Herrin b...@herrin.us wrote: I have an anti-naming proposal: Allow users to place the colons -anywhere- or even leave them out altogether without changing the semantics of the IPv6 address. A decade or two of established syntax disagree. IPv6 addresses, UUIDs and similar have a unique syntax for a reason. Otherwise, we, nor computers, wouldn't be able to quickly distinguish an IP from a hash. The colons are there for readability purposes only. They have no special significance and should not be elevated to significance by naming the parts of the address they delineate. Treat them specially and some fools will attach importance to arranging tasks on two-byte boundaries. Even if they were for readability only, they would still be for humans. Same as the specific, canonical name we are trying to agree on. If people want to interpret more into the colons than there is to see, they will do so regardless of a name. The rest of us will work faster, more efficiently and not explain the same old thing a gazillion times. Richard
Re: Introducing draft-denog-v6ops-addresspartnaming
On Fri, Nov 19, 2010 at 22:17, William Herrin b...@herrin.us wrote: Bit, nibble and /64 then. /64 is treated specially by functions in the protocol (like SLAAC) thus it's a protocol boundary rather than a social one (/12 IANA allocations, /32 ISP allocations, /48 end-user assignments). I would argue that /0 and /128 are somewhat special, too. Unless you particularly feel the need to assign /64's to router loopbacks, you'll see plenty of routes longer than /64 in your table too. That's a personal preference, really. Unless you mess up, or are an end user permanently stuck with a /64 (in which case your ISP messed up), there isn't really much need to assign anything longer, though. That being said, for whatever reason, several of my upstreams use /126 for their sessions. In any case, other than some people might see the colons as magic markers I don't really see an argument in favour of avoiding a common name. And that does not seem to hold much water. This is not meant to be an attack, I simply wonder if I am missing something. Richard
Introducing draft-denog-v6ops-addresspartnaming
Hi all, as most of you are aware, there is no definite, canonical name for the two bytes of IPv6 addresses between colons. This forces people to use a description like I just did instead of a single, specific term. Being highly pedantic Germans, this annoyed quite a few people within the DENOG community. This, in turn, lead to an I-D[1]. If any of you have any additional suggestions, you are more than welcome to share them. Additionally, I want to invite everyone to participate in an informal poll which we created[2]. We're fully aware that it's trivial to cheat on this poll; that's life. As of right now, Quibble leads with Hextet being a close second. All other options got significantly less votes. Thanks, Richard [1] http://tools.ietf.org/html/draft-denog-v6ops-addresspartnaming [2] http://doodle.com/5q9gfvk4qe6zmzc6
