- NANOG - lists.nanog.org

New block of AS Numbers to APNIC (37888-38911)
by Doug Barton 10 Jun '05

10 Jun '05

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greetings, This is to inform you that the IANA has allocated the following block of AS Numbers to APNIC: 37888-38911 For a full list of IANA AS Number allocations please see <http://www.iana.org/assignments/as-numbers> - -- Doug Barton General Manager, The Internet Assigned Numbers Authority -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (MingW32) iD8DBQFCqNmowtDPyTesBYwRAq87AJ9vZylxVXcni50h2sKEebZLDpa1jQCcDU4a Uiryl1vEehaC/xj6rby0te0= =Q3MX -----END PGP SIGNATURE-----

1 0

Re: Outage queries and notices (was Re: GBLX congestion in Dallas area )
by Jay R. Ashworth 09 Jun '05

09 Jun '05

On Wed, Jun 08, 2005 at 07:11:21PM -0400, David Andersen wrote: > On Jun 8, 2005, at 4:46 PM, Jay R. Ashworth wrote: > > On Wed, Jun 08, 2005 at 06:30:50PM +0000, Fergie (Paul Ferguson) wrote: > >> What's the matter with simply using the mailing list? > >> Don't reinvent the wheel. > > > > For precisely that reason, I, personally, am on your side. > > It's not the *best* solution, but it's probably the least worst. > > As a comment from the research side - I know several people who've > ended up combing the NANOG mailing list archives for outage reports of > various sorts (myself included). Perhaps a great middle step on this > if people were to agree on a quasi-maybe-slightly-standard format for > reporting outages to the mailing list, so that the statistics gathering > types can mine through and get at the data. > > I'm not suggesting that all mail to nanog be XML-encoded goop, but some > loose text convention might help move things along nicely. Over time, > I suspect that a general consensus style would emerge. Probably RFC-822 style headers between ==BEGIN OUTAGE== and ==END OUTAGE== or something akin to that. It remains easy to parse, especially by the most likely subect, perl. A subject-line tag is probably not out of the question, either. But, of course, we're figuring out the best way to implement something that we haven't completely decided is the best idea. :-) Cheers, -- jra -- Jay R. Ashworth jra(a)baylink.com Designer +-Internetworking------+----------+ RFC 2100 Ashworth & Associates | Best Practices Wiki | | '87 e24 St Petersburg FL USA http://bestpractices.wikicities.com +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me

1 0

Re: Active BGP Probing and large AS-sets
by Lorenzo Colitti 09 Jun '05

09 Jun '05

Hannigan, Martin wrote: > Yes, but last time you said you were going to use > _other peoples_ ASN's to test with and allow these > announcements beyond your borders. > > Is this still the case? The probing AS (call it Z) announces one of its prefixes to the Internet with an AS-path that is not just Z but Z {a,b,c...}, where a,b,c,... are the numbers of other ASes in the Internet. For the technique to be useful, the numbers in the set must belong to ASes that actually receive Z's announcements. These ASes will not use or propagate the route, effectively "disappearing" from the Internet as far as the prefix is concerned. This causes alternate and backup paths, not normally visible, to become active for that prefix. By looking at RIS and RV and the looking glasses of other ASes, Z can then see who propagates the prefix, where its announcements go, if other ASes have particular preferences for particular paths to it, and so on. Apart from the different AS-path, the prefix is announced in the same way as all the other prefixes belonging to Z. So yes, the ASes inserted in the AS-set are operated by others, and yes, the announcements are sent out to the Internet at large. Regards, Lorenzo -- lorenzo(a)ripe.net colitti(a)dia.uniroma3.it www.ripe.net www.dia.uniroma3.it/~compunet RIPE NCC Roma Tre Computer Networks research group

4 4

Active BGP Probing and large AS-sets
by Lorenzo Colitti 09 Jun '05

09 Jun '05

Hi, our announcement on nanog a few months ago of experiments involving BGP updates containing large AS-sets [1] caused a few flames. Now we have an in-depth document with results on the subject and would like to explain what we intended to do. We have presented our techniques at RIPE 50, and there is a Web page on the project, with links to the full report and the slides, up at: http://www.dia.uniroma3.it/~compunet/bgp-probing/ What follows is a brief summary of what we do, why we believe it is safe, and why it shouldn't cause problems to current operational practices. For more details, see the presentation and the report. We will be happy to answer any further questions you might have. Regards, Lorenzo Colitti --- Active BGP Probing ================== What we do ---------- Existing topology discovery techniques are good at discovering topology but bad at discovering policy. However, to predict the effect of network faults, perform effective traffic engineering, develop peering strategies, and evaluate the quality of upstreams, it would be useful for ISPs to to know how their announcements can be propagated and how the policies of other ASes in the Internet affect their prefixes. No operational tools exist to do this. The principle is the following: an AS using our probing techniques can announce one of its prefixes with AS-paths including the numbers of other ASes. Due to loop detection, these "prohibited" ASes will not use or propagate the announcement. To avoid influencing AS-path length, the prohibited ASes are placed in an AS-set at the end of the path. Thus, to stop its announcement from being propagated by ASes 1, 2, and 3, an AS (say AS12654) might announce one of its prefixes with an AS-path of 12654 {1,2,3}. This allows AS 12654 to discover who propagates its announcements, find backup paths, and deduce the policies of other ASes with respect to its prefixes. To collect data it is possible to the RIS or ORV route collectors. However, since our methods operate in steady state, the results are visible from any looking glass on the Internet. Why it is safe -------------- We are confident that such announcements are safe, provided that the length of the AS-set announced is limited. We say this based on: 1. Equipment tests. Juniper routers seem to have no problems with long AS-paths, while Cisco routers reset the BGP session when the AS-path more than 512 bytes long (about 254 ASes). Cisco is aware of this issue and is in the process of fixing it; in any case, our techniques limit the length of the AS-sets announced to a suitable number to account for propagation (obviously, much smaller than 254). 2. IPv6 tests. We started testing our techniques on the IPv6 backbone in November. No problems were reported. The first report (of only two) we got of someone even noticing the unusually long paths arrived at the end of February. 3. Observation. Longer AS-sets (123 [2] and 124 [3] elements) and longer AS-paths have been observed in the wild with no ill effects that we know of -- at least, we know of no operators who reported problems. Why it doesn't impact routers ----------------------------- Route flap dampening limits our probing to the order of one update per hour. This is negligible compared to the over 15,000 updates/hour a typical Tier-1 router might receive. As regards impact on memory, the amount of RAM to store a 100-element AS-set for one prefix is of the order of hundreds of bytes, which is irrelevant for core routers which are already using tens of megabytes of memory for BGP. Why it doesn't hamper debugging ------------------------------- Prepending other AS numbers is to a certain extent already done today. Our techniques are similar, but foreign ASes are only in the AS-set at the end of the path, so it's immediately obvious which path the announcement has taken. Due to the size of the AS-set, we doubt that anyone seeing such an announcement would believe it was due to one of the ASes in the set, but would probably look at the first AS before the set. Furthermore, the prefix immediately identifies the source of the announcements. Finally, the routes can also be tagged with communities to help identify them. [1] http://www.merit.edu/mail.archives/nanog/2005-03/msg00029.html [2] http://www.ripe.net/projects/ris/Talks/0101_RIPE38_AA/sld003.html [3] http://www.ripe.net/maillists/ncc-archives/ris-users/2002/msg00044.html -- RIPE NCC Roma Tre Computer Networks research group www.ripe.net www.dia.uniroma3.it/~compunet lorenzo(a)ripe.net colitti(a)dia.uniroma3.it

2 2

RE: GBLX congestion in Dallas area
by Joel Perez 09 Jun '05

09 Jun '05

I totally agree with you Richard. But, in this case all im getting is the run-around from GBLX when calling them about it. I managed to open up a trouble ticket with them but their Techs weren't telling me anything other than they will look into it and call me back. Even though I am a customer, im not getting any answers so I tried the list as a last ditch effort to get some info. -------------------------------------------- Joel Perez | Network Engineer 305.914.3412 | Ntera -------------------------------------------- -----Original Message----- From: Richard A Steenbergen [mailto:ras@e-gerbil.net] Sent: Tuesday, June 07, 2005 12:28 PM To: Joel Perez Cc: nanog(a)merit.edu Subject: Re: GBLX congestion in Dallas area On Tue, Jun 07, 2005 at 12:09:26PM -0400, Joel Perez wrote: > > Is anybody seeing any congestion in the Dallas area for Global Crossing? > > I'm seeing packet loss to some of my equipment up there. There is a large fiber cut in the area (somewhere between Dallas and Houston), affecting a lot of capacity coming out of Dallas on several carriers (including GX and Qwest at the very least). Two of our OC48s on this path have been down since around 14:57 UTC. That said, this isn't the proper place to whine about congestion. Normally I would say that is what customer support numbers are for, but since there is nothing they can do to splice it any faster, I'm going to recommend a healthy dose of suck it up and deal. :) -- Richard A Steenbergen <ras(a)e-gerbil.net> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

12 14

Fwd: ICANN Board Designates VeriSign ...
by Eric Brunner-Williams in Portland Maine 09 Jun '05

09 Jun '05

ICANN's announcement is at: http://www.icann.org/announcements/announcement-08jun05.htm See also: http://icann.org/tlds/dotnet-reassignment/net-rfp-process-summary-08jun05.p… And so much for that. Eric

1 0

Re: Micorsoft's Sender ID Authentication......?
by Anne P. Mitchell, Esq. 09 Jun '05

09 Jun '05

> Wasn't there a lot of turmoil within the IETF last year > on sender authentication because Microsoft was trying to > push it's own sender ID authetication mechasnisms as a > draft standard? In part the problem was 'legal' (versus technical)...the folks involved in the working list from MS...technical people, offered ongoing reassurance that the as-yet-unpublished patent apps were benign, that it would always be available free, etc. etc... but once the patent apps were published, they were far over-reaching, included SPF aspects, etc.. (I have _zero_ doubt that the legal/corporate folks upstairs at MS were responsible for that, and that the good folks from MS on the working list were as surprised as were the rest of us). Anne Anne P. Mitchell, Esq. President/CEO Institute for Spam and Internet Public Policy IADB Email Sender Accreditation Database: http://www.isipp.com/iadb.php Professor of Law, Lincoln Law School of SJ Advisor, Kinar Secure Email Advisor, Relemail Email Privacy Certification Advisor, Virus Bulletin Asilomar Microcomputer Workshop Planning Committee

2 1

RE: Outage queries and notices (was Re: GBLX congestion in Dallas area)
by Henry Linneweh 09 Jun '05

09 Jun '05

I did notice A low number on the index at http://www.internettrafficreport.com/namerica.htm -Henry --- Joel Perez <jperez(a)numind.net> wrote: > > > [ SNIP ] > > >I think that these things are operational and > belong here. Its' > >the level that ras is talking about and the > content. Saying > >MCI has a massive fiber cut impacting 230 Congress > IX vs. > >GBLX is not doing what I demand are very different > types of > >outage posts. > > My original post to the list contained nothing about > any services I > expect with provider xxx. I asked if anybody else > saw packet loss or > congestion. > > My follow-up posts contained the reason as to why I > was posting this to > the list instead of to my provider, I then took it > off-list with 2 other > posters and managed to get more info out of them > then out of GBLX. I try > not to bash anybody because I know that doesn't > really resolve anything > most of the time. > > > >I'd like to see the higher level stuff we used to > do and have some > >sort of information along with it vs. "i see a > packet drop in XYZ". > >A prefix or something. That usually makes people go > look. > > I agree, it totally slipped my mind to provide that > info. I just typed > up a quick post and sent it out. > > Im my humble opinion I think this is Nanog content > and that is why I > posted it. Most posters opinion of what is and what > isn't appropriate > content varies. I love my delete key, if I don't > think it's appropriate > I delete it. No harm done to me. > > To each his own I guess. > > Thanks to those that responded. > >

1 0

Reminder: Open nominations for Program Committee members
by Steve Feldman 08 Jun '05

08 Jun '05

Just a reminder that nominations for the three open NANOG Program Committee positions are due by Friday! ----- Forwarded message from Steve Feldman <feldman(a)twincreeks.net> ----- From: Steve Feldman <feldman(a)twincreeks.net> To: nanog-announce(a)nanog.org Date: Sat, 28 May 2005 18:24:06 -0700 Subject: Open nominations for Program Committee members There are currently three vacant positions on the NANOG Program Committee. According to the draft charter[1]: "... the three Program Committee seats vacant as of May 2005 will be filled through appointment by the current committee after an open nomination process." Accordingly, the committee is soliciting nominations for these open positions, from now through Friday, June 10, 2005. ** Procedure ** To nominate yourself or someone else, please send mail to nominate(a)nanogpc.org with the following information, no later than Friday, June 10: - Your name - Nominee's name (if not you) - Nominee's email address - Nominee's phone number - Reasons why you believe the nominee is qualified to serve on the Program Committee. A committee member will contact each of the nominees to verify interest and possibly request additional information. Once all nominations have been received, the committee will begin selecting the three new members from among the nominees. The results will be announced to the nanog-announce list. ** Eligibility ** The draft charter states: "To be eligible to be appointed as a member of the Program Committee, an individual must have attended one NANOG meeting within the prior calendar year (12 months). " ** Duties ** Again quoting the draft charter: "The Program Committee is responsible for motivating/soliciting people to submit interesting talks, selecting the submissions which seem most appropriate (with some attention to presentation skills), and following up with speakers after acceptances to ensure that presentations are completed in time, with ample warning of potential problems with the presentation." "Each member of the Program Committee must review all presentations submitted for each meeting. The Chair may excuse a member from one meeting's review cycle due to extenuating circumstances, but if a member misses two meetings in a row, he or she may be removed from the committee." ** Length of term ** These appointments are temporary (as are those for the rest of the current committee), lasting only until the October 2005 meeting. The draft charter does require that the Steering Committee in forming their first appointed Program Committee, carry forward at least half the current members as of that time. If you have any further questions, please post to the nanog list, contact me directly, or entire committee at nanogpc(a)nanog.org. Finally, on behalf of the Program Committee, I would like to thank our three outgoing members, Barry Raveendran Greene, kc claffy, and Curtis Villamizar, for their years of dedicated service to NANOG and the Internet operations community. Steve Feldman PC Chair [1] The draft charter is available at http://www.nanog.org/charter05.html ----- End forwarded message -----

1 0

Supercomm: Securing service provider networks is a matter of national security
by Fergie (Paul Ferguson) 08 Jun '05

08 Jun '05

Head's up... - ferg [snip] "Top executives of major telecom equipment makers say beefing up security and reliability on service provider networks is necessary to protect customers and is a matter of national security." [snip] http://www.networkworld.com/edge/news/2005/060805-supercomm-security.html -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(a)netzero.net or fergdawg(a)sbcglobal.net ferg's tech blog: http://fergdawg.blogspot.com/

3 2