- NANOG - lists.nanog.org

RE: Scalability issues in the Internet routing system - #2
by Susan Hares 18 Oct '05

18 Oct '05

Andre: #2 FIBs doesn't have to be impacted by Moore's law. In certain times of routing technology people "cooked" routing tables in order to solve #2. The key there is to run through the proposed FIB table Generated by a routing table and cook it for FIB insertion. You can often summarize (from the viewpoint of a particular router) all the routes into a manageable set of FIB entries. The issue is how much fluctuation. 10% (actually 8-14% but 10% is average) of the Internet (see route-views, etc). FIB hardware can allow you to split the prefix load and the next-hops. So, you load prefixes that fluctuate and only break the prefix-next-hop when they fluctuate. .. bottom line.. I don't think we will be limited by Moore's law for #2.. If we utilize existing technology existing in Hw and software methodology, we can change the game on #2. Sue Hares PS - My answers tend to be brief - glad to expand in private or public. Your choice. -----Original Message----- From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Andre Oppermann Sent: Tuesday, October 18, 2005 11:31 AM To: nanog(a)nanog.org Subject: Scalability issues in the Internet routing system I guess it's time to have a look at the actual scalability issues we face in the Internet routing system. Maybe the area of action becomes a bit more clear with such an assessment. In the current Internet routing system we face two distinctive scalability issues: 1. The number of prefixes*paths in the routing table and interdomain routing system (BGP) This problem scales with the number of prefixes and available paths to a particlar router/network in addition to constant churn in the reachablility state. The required capacity for a routers control plane is: capacity = prefix * path * churnfactor / second I think it is safe, even with projected AS and IP uptake, to assume Moore's law can cope with this. 2. The number of longest match prefixes in the forwarding table This problem scales with the number of prefixes and the number of packets per second the router has to process under full or expected load. The required capacity for a routers forwarding plane is: capacity = prefixes * packets / second This one is much harder to cope with as the number of prefixes and the link speeds are rising. Thus the problem is multiplicative to quadratic. Here I think Moore's law doesn't cope with the increase in projected growth in longest prefix match prefixes and link speed. Doing longest prefix matches in hardware is relatively complex. Even more so for the additional bits in IPv6. Doing perfect matches in hardware is much easier though... -- Andre

2 1

RE: Verizon outage in Southern California?
by Hannigan, Martin 18 Oct '05

18 Oct '05

> > > > We lost connectivity to a number of customers in the Los Angeles and > Long beach area and the local AM radio news stations are talking about > some major telephone issues regarding Verizon. > > Anyone have more information? It seems to have started around 02:30 > local time this morning. There was a post here earlier regarding a major outage. Did you lose POTS or circuit level connectivity to customers or both? (I see circuits live in LA) -M<

2 1

Verizon outage in Southern California?
by Jay Hennigan 18 Oct '05

18 Oct '05

We lost connectivity to a number of customers in the Los Angeles and Long beach area and the local AM radio news stations are talking about some major telephone issues regarding Verizon. Anyone have more information? It seems to have started around 02:30 local time this morning. -- Jay Hennigan - CCIE #7880 - Network Administration - jay(a)west.net WestNet: Connecting you to the planet. 805 884-6323 WB6RDV NetLojix Communications, Inc. - http://www.netlojix.com/

2 1

Puerto Rico Internet Exchange Update..
by Mehmet Akcin 18 Oct '05

18 Oct '05

Hi everyone, I wanted to keep you guys updated about what's going on with Puerto Rico Internet Exchange Project, we are gearing up the project and soon we will start inviting peers to participate once our infrastructure is done. We are getting donated equipments from PCH (thanks Bill) and Dell Inc. for the IX operations, and we have arranged the space for the IX , put some racks that are empty and waiting to be filled!... I would like to say thank you for those who has replied us previously with their great comments and recommendations. If you are interested in helping us, please don't hesitate to contact with me anytime!. We will be also participating in NANOG and ARIN meetings in Los Angeles next week, so we hope to see you all at there. Mehmet Akcin Puerto Rico Internet Exchange

1 0

RE: IPv6 news
by Hannigan, Martin 18 Oct '05

18 Oct '05

> > > Nope, it's not. Can you name a phone prefix routing protocol? > > Ehm, SS7 ;). One of the functions provided for in the SS7 network is called Global Title Translation (GTT). The SCCP, in this case call it the switch, has the ability to perform minimal routing using GTT. GTT frees the STP, let's call that the "edge router" from being burdended with lcoations for all possible end nodes. You could say it's like ASN information. It enables the ss7 to pass on small messages that the STP's understand and are able to route on to the next destination in the path until it reaches the final STP and returns an answer in the same fashion. It's a combination of dynamic and static information used to find destinations. [ Long discussion on GTT fundamentals avoided - I recommend "SS7 Signalling - 2nd Edition" for more information on GTT et. al. ] A good example of the integration of SS7 into *IP* routing is to be found in the convergence of SS7 stacks into dial gear which enables the IP network to signal the SS7 network and perform optimized call aggregation. What I mean by this is that instead of dedicating a box of 672 ports to one customer, many customers can share one box and bypass the SCCP (TDM switching component) and talk directly to the PSTN. The aggregation model is much finer in this respect and the utilization of hardware is more cost effective. Kinda old stuff actually circa 1998. So. Yes. Sort of. SS7 is a routing protocol for all intents and purposes. NotSoOb: Verisign runs one of the largest facilities based SS7 networks in the world. -M<

1 0

Verizon telco outage in LongBeach, CA
by Matthew Black 18 Oct '05

18 Oct '05

Verizon California is reporting a loss of local telephone service in Long Beach, California. Calls into and out of the area are not possible. They are advising citizens to use their wireless carriers for 911 service. As 911 calls are connected to the CA Highway Patrol here, that could delay emergency response times quite significantly. matthew black california state university, long beach

1 0

RE: IPv6 news
by Hannigan, Martin 18 Oct '05

18 Oct '05

> > No. Within a region. Normally area codes are a region. Sometimes > entire country codes are a region in this sense. Depends on the size > of the region/country though. In some cases there is even more than > one area code for the same region. LATA's are geographic areas and NPX(prefix) are switching areas within the LATA(Local Access and Transport Area). The geo regions(LATA) are set up to differentiate local and long distance inside the US. There's a three level hiearchy within each LATA, and there are three levels in the United States as defined by the regulators, post divestiture. I'd have to say your definition may be accurate outside the US, but not inside. [ SNIP ] > The telco peering points is just a technicality. It's there just for > optimization. Most regulators have set up an "easy interconnection" > policy to prevent your favorite incumbant from offering 'peering' only > on lands end. They're more than a technicality. They are required by the regulator. There are commodity markets related to IXC minutes exchange as well. This helps to keep LD cheap (as it can be) and reliable as if one carrier is unable to carry minutes, others can. The basic telco archictecture in the USA is EO, TO, and AT. In the case of LD, it's EO, TO, to a POP, and IXC. EO, TO and AT are all interconnected some symetrically, some asymetrically, with the exception of the IXC which is all symetric. Personally, this is a very interesting thread to me, but I think this is starting to go way off topic for NANOG. -M<

1 0

The exhaustion of IPv4 address space
by Vicky Rode 17 Oct '05

17 Oct '05

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 well, if the existing discussion is not enough, cisco has an interesting article out...see /. for more information. http://www.cisco.com/en/US/about/ac123/ac147/archived_issues/ipj_8-3/ipv4.h… wearing my flame suite :-) regards, /virendra -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDU9cKpbZvCIJx1bcRAoNWAKC5UUyUqfPcAEKJ8GX5Iky2y1qbxwCeMdUM TkjJ1xoc4NK+y8Bv3YnZCjU= =kVtG -----END PGP SIGNATURE-----

1 0

Re: IPv6 daydreams
by Peter Dambier 17 Oct '05

17 Oct '05

Mohacsi Janos wrote: > > > > > On Mon, 17 Oct 2005, Peter Dambier wrote: > >> >> From an end-user: >> >> I dont know what I should need an /64 for but it's barf, barf anyhow. >> >> My routing table is telling me I have got a /124 only: >> >> The tunnel (network) *::0 >> The end of the tunnel *::1 >> Me *::2 >> The tunnel broadcast *::3 > > > What? Broadcast? Well, it is singlecast :) ping *::3 and 1 answers. ping *::1 ok 1 answers. ping *::2 nobody answers - that is my configuration problem. ping *::0 nobody answers > >> >> Right now I have the impression we are only enusers. >> Right now I have the impression we are all connected to the same >> university PC running BSD something. >> >> Ok, today I have some NATted stuff that would be fond of its own >> ip. Kicking my NAT-box out I could grow my hair again. No more >> worring who needs what port and why. >> >> Beware! >> >> Who is printing all those bank listings on my new printer. It >> was a wholesale networkprinter. Just plug it into the power >> and print. Must have been stolen from the bank of china because >> it is all chines companies. >> >> And why is that van with the ice cream waiting in front of my >> neighour? It is me who ordered the icream. They have thrown >> out their freecer. I dont know why. It was working perfectly. >> I had no problems connecting it to my wlan and ordering. They >> did not even care about my bank account beeing empty. They told >> me I had enough credit to by their company. >> >> Sorry I have to stop now. Some policemen want to talk with me >> about a major fraud done with my IPv6 tunnel. >> >> See you later :) > > > > Janos Mohacsi > Network Engineer, Research Associate > NIIF/HUNGARNET, HUNGARY > Key 00F9AF98: 8645 1312 D249 471B DBAE 21A2 9F52 0D1F 00F9 AF98 > >> >> >> Jeroen Massar wrote: >> >>> On Mon, 2005-10-17 at 02:52 +0000, Christopher L. Morrow wrote: >>> >>>> On Sat, 15 Oct 2005, Tony Li wrote: >>>> >>>>> Hopefully, that will reach a point where the operators show up and >>>>> participate at IETF, rather than the IETF coming to NANOG. >>>>> >>>> >>>> agreed. >>> >>> >>> >>> Full ack. Ops should really realize that they can have a lot of >>> influence in the processes and what is actually being standardized. >>> Which really helps the ops a lot as they then have an extra foot in >>> the door at the Vendors, as the IETF is also known as the IVTF as some >>> people like to call it :) >>> >>> On Mon, 2005-10-17 at 09:15 +0530, Suresh Ramasubramanian wrote: >>> >>>> On 17/10/05, David Barak <thegameiam(a)yahoo.com> wrote: >>>> >>>>> I'd change the allocation approach: rather than give >>>>> every customer a /64, which represents an IPv4 >>>>> universe full of IPv4 universes, I'd think that any >>>>> customer can make do with a single IPv4-size universe, >>>>> and make the default end-customer allocation a /96. >>>> >>>> >>>> I personally am in favor of reducing minimum allocations like this - >>>> and as was discussed quite extensively in the "botnet of toasters and >>>> microwave ovens when you ipv6 enable the lot" thread a few weeks back, >>>> it usually ends up that there's just one host in a /48 or /64 so that >>>> the sparsely populated v6 address space means bots cant go scanning IP >>>> space for vulnerable hosts like they do in v4 >>> >>> >>> >>> There is a current document out for trying to get this stepped back to >>> a /56 for _enduser_ sites. Corporate / Organisational / Business sites >>> should then still get a /48. >>> >>> HD ratio docs: >>> http://www.ripe.net/ripe/policies/proposals/2005-1.html >>> http://www.ripe.net/ripe/policies/proposals/2005-08.html >>> >>> Endsite definition: >>> http://www.ripe.net/ripe/policies/proposals/2005-4.html >>> >>> As a note, out of my IPv6 /48, at home, I only use one /64 as I bridged >>> the wireless and wired networks. This was easier than having Samba do >>> remote announces to the other /64 and also allows me to re-attach my >>> laptop and plug it into the wired without it changing the IP, very cheap >>> 'mobility' :) A /56 for 'home usage', thus having 2^8 = 256 /64's or >>> subnets would IMHO (force me to drink beer when this ever turns out to >>> be wrong :) be enough for most home usages. I really don't see people >>> installing 200+ routed networks in a home. Most people don't even have >>> more than 4 rooms and one /64 already contains 2^64 addresses, unless we >>> go for the IP-per-carpet-fiber approach, just give the carpet in your >>> house a single /64 and you still have 255 subnets to go... >>> >>> >>>> It also means that when Vint Cerf's research about extending the >>>> internet into outer space comes through (or when we finally start >>>> exchanging email, http or whatever traffic with aliens), there's >>>> sooner or later going to be an intergalactic assembly of some sort >>>> where delegations from Betelgeuse and Magrathea will complain about >>>> how those @^$^$#^$^ earthlings hogged all the v6 space thinking >>>> there's more than enough v6 IP space to allot a /48 to every single >>>> molecule on earth, so now they're not getting enough IP space to >>>> network a group of computers that'll plot the answer to life, the >>>> universe and everything. >>> >>> >>> >>> They don't need to, this computer is already there, it is Earth..... >>> there just ain't no plotter installed and we will be destroyed for that >>> superhighway and then re-built as Earth 2, but we won't notice that :) >>> >>> >>>> Well, I know that sounds silly, but people were handing out class A, B >>>> and C space for years thinking nobody at all would run out of v4 >>>> space, there's lots of it so why not just parcel it out with open >>>> hands. >>> >>> >>> >>> The Huitema-Durand / Host-Density (HD) ratio RFC3194 it explains quite a >>> number of these issues and covers most of them. >>> >>> Next to that note that 2000::/3 is only 1/8th of the total IPv6 address >>> space. If we peep up, we can do that 8 times before the address space is >>> full and I am quite sure if 2000::/3 runs out that people will start >>> having some really loud discussions. Indeed 2000::/3 would then be >>> similar to 'class A' space... >>> >>> >>>> Back to operations - there was this interesting proposal - well, two >>>> proposals as it turned out - at apnic 20 - >>>> http://www.apnic.net/meetings/20/report.html >>> >>> >>> >>> Similar to the one done above in the RIPE region :) >>> >>> Greets, >>> Jeroen >>> >> >> >> -- >> Peter and Karin Dambier >> Public-Root >> Graeffstrasse 14 >> D-64646 Heppenheim >> +49-6252-671788 (Telekom) >> +49-179-108-3978 (O2 Genion) >> +49-6252-750308 (VoIP: sipgate.de) >> mail: peter(a)peter-dambier.de >> mail: peter(a)echnaton.serveftp.com >> http://iason.site.voila.fr >> http://www.kokoom.com/iason >> >> > -- Peter and Karin Dambier Public-Root Graeffstrasse 14 D-64646 Heppenheim +49-6252-671788 (Telekom) +49-179-108-3978 (O2 Genion) +49-6252-750308 (VoIP: sipgate.de) mail: peter(a)peter-dambier.de mail: peter(a)echnaton.serveftp.com http://iason.site.voila.fr http://www.kokoom.com/iason

1 0

IPv6 news
by Steven M. Bellovin 17 Oct '05

17 Oct '05

Global Crossing says it has deployed native IPv6. Also, TeliaSonera has picked Lucent to help it prepare for IPv6 service. http://www.techweb.com/wire/172300284 --Steven M. Bellovin, http://www.cs.columbia.edu/~smb

36 72