- NZNOG - lists.nznog.org

newzealand.com UDRP attempt coming up!
by Andy Gardner 23 Sep '02

23 Sep '02

http://arbiter.wipo.int/domains/cases/2002/d0600-0799.html Check out case D2002-0754 newzealand.com We're not told who is attempting to get the name. They keep all the case details secret until the decision is made, and then you only get to see what the "arbitor" decides you NEED to see. Perhaps a journalist here might like to contact the current name holder and ask him? It would be interesting to find out exactly who thinks they have enough rights over the term "New Zealand" to be allowed to wrestle it out of someone elses hands via the UDRP. Once they've got newzealand.com I guess nz.com will be their next target. -- Andrew P. Gardner barcelona.com stolen, stmoritz.com stays. What's uniform about the UDRP? We could ask ICANN to send WIPO a clue, but do they have any to spare? Get active: http://www.tldlobby.com - To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

2 2

NZNOG conference 2003
by Chris Hellberg 17 Sep '02

17 Sep '02

Roger, I've lost the origional email about the conference, but what I'd like to see next year is someone involved from the early days of the NZ interweb. Somone who flicked the switch on the 4K8 link to NZ, or who ran the origional NZ DNS or similar would be interesting - grey hair types preferred ;) Cheers, Chris - To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

11 17

Mail blip today?
by Simon Lyall 16 Sep '02

16 Sep '02

Did anybody else see a big jump in mail volume (as in bits/second) between 4pm and 5pm today? I think it was a combination of mailouts by travel.co.nz's (90-something kilobytes) and finewineonline.co.nz (1.6 Meg of "I accidentally included our logo" ) but it might be something else I missed that was affecting only us. -- Simon Lyall. | Newsmaster | Work: simon.lyall(a)ihug.co.nz Senior Network/System Admin | Postmaster | Home: simon(a)darkmere.gen.nz ihug, Auckland, NZ | Asst Doorman | Web: http://www.darkmere.gen.nz - To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

1 0

RE: NZNOG conference 2003
by Frank March 16 Sep '02

16 Sep '02

> -----Original Message----- > From: Don Stokes [SMTP:don(a)daedalus.co.nz] > Sent: Tuesday, 17 September 2002 16:41 > To: nznog(a)list.waikato.ac.nz > Subject: Re: NZNOG conference 2003 > > Some of the ex-DSIR people might be fun to have along -- these folks > were doing serious vendor-independent networking back when nobody much > else knew what it was, and developed the Ace/Network Dynamics/Securicor > 3net/Allied Telesyn routers which many ISPs used for many years. > The key guy at Allied Telesyn is the General Manager, Geoff Peck. He was deeply involved in all of the above which evolved out of the DSIR National Computer Network developments in the late 70s. Frank March Specialist Advisor, IT Policy Group Ministry of Economic Development, PO Box 1473, Wellington, NZ Ph: (+64 4) 474 2908; Fax: (+64 4) 471 2658 Any opinions expressed in this message are not necessarily those of the Ministry of Economic Development. This message and any files transmitted with it are confidential and solely for the use of the intended recipient. If you are not the intended recipient or the person responsible for delivery to the intended recipient, be advised that you have received this message in error and that any use is strictly prohibited. Please contact the sender and delete the message and any attachment from your computer. - To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

1 0

Peering at APE
by Craig Whitmore 15 Sep '02

15 Sep '02

Can people peering with Orcon Internet (AS17746 192.203.154.66) at APE, please peer with 192.203.154.67 as well with the same prefix-list as the 1st. Also if you wish to MSDP and/or MBGP peer please let me know. Please let me know when/if you have set this up. Thanks Craig Whitmore Orcon Internet http://www.orcon.net.nz - To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

1 0

RE: BGP Private ASes
by Andy Linton 12 Sep '02

12 Sep '02

I'm pleased to see this thread generate lots of discussion and I've thought some more about my position on this. I think the community should look at a number of things: 1) I think from postings from Philip Smith, Joe Abley, myself (and others) it's clear there is a mechanism for applying for globally unique ASNs and it is possible to get them assigned where need can be demonstrated. There may be an additional cost associated with this. Clearly such an ASN can be used anywhere on the net including Citylink or the APE. This should be the preferred option for anyone who wants to peer in whatever form with more than one other entity. Private ASNs should be reserved for use between two entities. This may well cover Simon's WIX route reflectors. Perhaps ISPs, telcos, and other organisations like Citylink should create mechanisms (if they don't already have them) to enable their customers to obtain ASN numbers from APNIC where those customers need an ASN. (My cynical mind makes me suspect that there may be some resistance to this as it may be perceived that customers are using this to avoid charging, connect to another provider etc. Please prove me wrong! Public declarations on this list might help.) 2) Additionally there is a mechanisms also identified in previous postings for obtaining IPv4 address space for multihoming. Explore those mechanisms if you *need* address space. 3) It would be good if we could work together to make the WIX model work efficiently. Some larger providers might wish that there were only larger providers peering at the WIX. That clearly isn't the case so it would be good to see them sit down with Simon Blake and work out how to get efficient and redundant peering working. 4) Ditto the APE. 5) If people want address the related but separate problem of using RPSL and the routing registry mechanism to express their public policy (and automatic generation of filter lists etc) then start trying to understand policy in terms of the provisions of RFC2622 and RFC2650. I'm happy to work on this with people when I get back to NZ in November. Others have said the same but I'll let them put their hands up. If you intend to do this please strongly consider using the APNIC service coming shortly. I posted yesterday that the service was hosted in Brisbane and mirrored at RIPE. They are also investigating the deployment of redundant services using anycast on four separate continents. How redundant do you need the service to be? andy - To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

1 0

Updated BGP monitoring
by Rob Thomas 12 Sep '02

12 Sep '02

Hi, NZNOG listfolk. [ Apologies to those of you who have received this note in other fora. ] I have updated my BGP monitoring to include ASN analysis. This includes the count of unique ASNs, the count of ASNs that originate at least one prefix, the average path length, the maximum path length, and the bogus ASNs. You will find it all here: http://www.cymru.com/BGP/index.html The bogus ASN page, complete with a colorful graph, can be found here: http://www.cymru.com/BGP/asnbogusrep.html Comments and feedback are always welcome! My thanks to those who donate peering and gear to my monitoring efforts. :) Thanks, Rob. -- Rob Thomas http://www.cymru.com ASSERT(coffee != empty); - To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

1 0

Re: BGP Private ASes
by Ewen McNeill 12 Sep '02

12 Sep '02

Andy Linton sent me this response, which he tells me he intended for nznog as well. Below is Andy's response, and then my reply to Andy's response. Both are at least as relevant to the list as discussing Klez all day :-) Andy's response: On Wed, 11 Sep 2002, Ewen McNeill wrote: > In message <NABBJDOPDKGCDCNBNEDOCEPKFAAA.ascott(a)cisco.com>, "Arron Scott" writes: > >I get endless number of customers who want to peer with more than one ISP at > >a time, usually with the intention of resiliency at both the institutional > >and upstream provider levels. [... Want Class C, public AS, advertised > >prefix... ] > >Now ... what I was thinking is ... can we do this without the rare (and > >increasingly difficult to obtain) Public AS numbers. There are proposals to increase the size of the AS numbers from 16 to 32 bits but that soesn't solve the immediate difficulties in getting an AS number. > > I'm also in touch with clients that would like to do this -- they don't > especially care about the Class C, or Public AS, etc, but they would like > some resiliency for any disconnections from their provider or routing > issues for their provider, often because they have clients that have > that as a tick-box feature. I've heard some very interesting discussions about flap damping at the RIPE meeting this week. See http://psg.com/~randy/020910.zmao-flap.pdf. The important thing to note is that the thing that is damped is prefixes so dual homing may not give you all you hope for if flap damping is in use. > >Could we have a publically agreed on pool of Private AS numbers that > >enterprises can use to peer with service providers. The pool would > >administered by a "impartial" group (maybe WIX/APE). The AS number > >would then be stripped by both higher-order ISPs and and the IP > >address potentially unsuppressed by the ISP who owns the IP address aggregate. > > If I'm not mistaken about what you mean, this is what WIX (the route > reflectors) are trying to do. Dean Pemberton and I have been talking with Simon about trying to get WIX and APE whois servers running so that people could start registering routes and AS policy for RPSL use in NZ. Using these to allocate locally scoped private ASes for use on the WIX and APE would be a doddle. > The WIX approach seems to work, but: > - it appears some providers do not peer with the WIX route reflectors, > or do so only to advertise their routes, not to allow in extra routes > > - most providers filter "long" prefixes (and most enterprises without > public ASes tend to have only long prefixes). Certainly it's my > impression that pretty much all providers filter anything longer than > /24, and some appear to even filter /24, /23, /22, etc, meaning the > prefixes advertised by enterprises are likely to be filtered. It seems difficult to believe that the relatively small additional number of prefixes being announced by the enterprises on the WIX is significant. The total number of prefixes is around the 250 mark and many of those come from the "providers" anyway. Filtering out the few dozen prefixes that are /25 or greater would seem to have little impact on table size and the kosher ones could easily handled in a prefix-list. > So from an enterprise point of view WIX (the route reflectors) are useful > for picking up direct routes to providers POPs, but this tends to lead to > asymetric routes to/from the providers (and hence no real resiliency). So it would be nice to get the providers to use them. Some of them resist but surely this is an issue that could be driven by their respective customers. E.g. "As my provider I need you to provide a resilient efficient local mesh at WIX and APE. Perhaps I should consider moving to a provider who...." > > And it's useful for enterprise to enterprise peering (indeed one of my > clients connected to the WIX route reflectors soley for the enterprise > to enterprise peering; at the request of the other enterprise). > > The WIX route reflectors (according to the route table on a router > peering with them) appears to have about 50 systems peering with it > at present. > > But without providers willing to (a) peer with the route reflectors, and > (b) accept long prefixes (at least locally), it's probably not going to > be of general use for resiliency. > > To be of much general use providers would have to be willing to at least > accept /24 prefixes locally, even if they're part of a larger supernet > advertised by another provider. Longer prefixes would be desirable, > because otherwise anyone wanting resilency with CIDR space would need > to beg for a class-C sized CIDR chunk. See above --------------------------------------------------------------------------- And my response to Andy: In message <Pine.LNX.4.44.0209111930390.1763-100000(a)wark.lionra.net.nz>, Andy Linton writes: >On Wed, 11 Sep 2002, Ewen McNeill wrote: >> I'm also in touch with clients that would like to do this [advertise >> their blocks to multiple providers for resiliency] > >I've heard some very interesting discussions about flap damping at the >RIPE meeting this week. [...] The important thing to note is that the >thing that is damped is prefixes so dual homing may not give you all >you hope for if flap damping is in use. For both the clients I have in mind most of their benefits would be gained in about the first 5 hops or so (ie, within New Zealand), as that is the main market they're serving. So how important flap damping was to that would largely depend on how soon it was applied. >Dean Pemberton and I have been talking with Simon about trying to get WIX >and APE whois servers running so that people could start registering >routes and AS policy for RPSL use in NZ. Using these to allocate locally >scoped private ASes for use on the WIX and APE would be a doddle. This would definitely be a good thing. RPSL (from your talk at the Uniforum conference) looks like a Good Thing (tm), and a whole lot more sensible than the alternatives (yet more prefix listson nznog!). Scoped private ASes would also solve the immediate problem -- probably for Aaron too (hence my suggestion you mention this on nznog, and/or directly to Aaron). >It seems difficult to believe that the relatively small additional number >of prefixes being announced by the enterprises on the WIX is significant. WIX is worth about 300 prefixes or so on an average day, and "generally" includes the POPs of most NZ providers. For an organisation hosting a lot of content, there's definitely a win for them in sending traffic "directly" to the POPs (and bypassing the ticket counter at their ISP :-) ). If those routes were symmetric, then there'd also be a resiliency win. >The total number of prefixes is around the 250 mark and many of those come >from the "providers" anyway. Filtering out the few dozen prefixes that are >/25 or greater would seem to have little impact on table size and the >kosher ones could easily handled in a prefix-list. Last I spoke to Simon about it, he was starting to put filters in on the expected prefixes from each peer with the WIX route reflectors -- which would make it possible to have a pretty "exact" set of expected prefixes. There are 27 prefixes in WIX (right now) longer than /24. Some of them are as long as /30s, and there's a bunch of /29s. One of the clients I have in mind has a /27 CIDR block. They're starting to run out of public address space (despite using RFC1918 everywhere it can be used, and lots of NAT), and will probably try asking for more space. But even that more space is likely to be only another /28, another /27, or maybe if they're very lucky one /26. My point here is that while there might not be very many prefixes longer than /25 in WIX now, that's sort of a self-fulfilling prohpehcy, because prefixes longer than /24 (or /23, /22, /21, etc -- I haven't managed to find out what's considered "best practice" by NZ providers) are being filtered out already by lots of people. So "what's the point?". If the answer is "everyone use RPSL, and persuade people to accept all properly described RPSL lists" then I'm all for it. If the answer is "only providers get to do peering", then that's tantamount to "only people with public ASes get to do peering". And may well lead to a bunch of people chasing public ASes (and provider independant space for that matter) when they don't otherwise need them. Ewen - To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

8 13

Re: BGP Private ASes
by Andy Linton 11 Sep '02

11 Sep '02

On Thu, 12 Sep 2002, Ewen McNeill wrote: > In message <Pine.LNX.4.44.0209120130270.2162-100000(a)wark.lionra.net.nz>, Andy Li > nton writes: > >I meant to post to all concerned. Do you want to forward my mail and your > >response to get this rolling again? > > Done. Joe Abley seems to be suggesting that public ASes can be obtained > (at least by providers for their customers) for the purposes that Aaron > is talking about, perhaps along with provider independent space with a > long prefix. But something tells me that won't scale to everyone on > Citylink getting provider independent space and their own AS... I agree with Joe that it is possible to get a public AS and some address space for mulithoming but we'd be talking about a 50% increase in NZ's AS number assignment. (APNIC have currently allocated 89 AS numbers to NZ + some earlier allocations from the US registries and we'd need 42+ private AS replacements for Citylink alone). The policy for AS numbers is effectively described at http://www.apnic.net/docs/drafts/apnic-draft-asn-v002.txt The problem I see with say Citylink customers applying under this schema is that assigning them an AS number does nothing to reduce the size of global address tables and the number will not be used to describe diverse routes in the global routing fabric. So private AS numbers seem like the 'right thing'. Where people really do want to multihome for global connectivity there is a mechanism - see the above and for multihoming IPv4 address space see http://www.apnic.net/info/faq/multihoming_faq.html But people should note - there is a cost in dollars and renumbering effort. - To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

1 0

Re: BGP Private ASes
by Ewen McNeill 11 Sep '02

11 Sep '02

In message <NABBJDOPDKGCDCNBNEDOCEPKFAAA.ascott(a)cisco.com>, "Arron Scott" writes: >I get endless number of customers who want to peer with more than one ISP at >a time, usually with the intention of resiliency at both the institutional >and upstream provider levels. [... Want Class C, public AS, advertised >prefix... ] >Now ... what I was thinking is ... can we do this without the rare (and >increasingly difficult to obtain) Public AS numbers. I'm also in touch with clients that would like to do this -- they don't especially care about the Class C, or Public AS, etc, but they would like some resiliency for any disconnections from their provider or routing issues for their provider, often because they have clients that have that as a tick-box feature. >Could we have a publically agreed on pool of Private AS numbers that >enterprises can use to peer with service providers. The pool would >administered by a "impartial" group (maybe WIX/APE). The AS number >would then be stripped by both higher-order ISPs and and the IP >address potentially unsuppressed by the ISP who owns the IP address aggregate. If I'm not mistaken about what you mean, this is what WIX (the route reflectors) are trying to do. Enterprises on Citylink with an appropriate connection, but without public ASes are assigned a private AS, advertise their routes to the WIX route reflectors with that private AS, and the WIX route reflectors then advertises those to all other peers. APE may also have a similar setup, but my impression is that APE is mostly bilaterial peering, and it's mostly treated as a peering point, rather than a multilateral route exchange. The WIX approach seems to work, but: - it appears some providers do not peer with the WIX route reflectors, or do so only to advertise their routes, not to allow in extra routes - most providers filter "long" prefixes (and most enterprises without public ASes tend to have only long prefixes). Certainly it's my impression that pretty much all providers filter anything longer than /24, and some appear to even filter /24, /23, /22, etc, meaning the prefixes advertised by enterprises are likely to be filtered. So from an enterprise point of view WIX (the route reflectors) are useful for picking up direct routes to providers POPs, but this tends to lead to asymetric routes to/from the providers (and hence no real resiliency). And it's useful for enterprise to enterprise peering (indeed one of my clients connected to the WIX route reflectors soley for the enterprise to enterprise peering; at the request of the other enterprise). The WIX route reflectors (according to the route table on a router peering with them) appears to have about 50 systems peering with it at present. But without providers willing to (a) peer with the route reflectors, and (b) accept long prefixes (at least locally), it's probably not going to be of general use for resiliency. To be of much general use providers would have to be willing to at least accept /24 prefixes locally, even if they're part of a larger supernet advertised by another provider. Longer prefixes would be desirable, because otherwise anyone wanting resilency with CIDR space would need to beg for a class-C sized CIDR chunk. Simon Blake (Citylink) could probably speak more about what WIX's route reflectors do, and how well it's worked (or not worked) in practice. Ewen - To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

2 1