Re: Really odd pings going out

[Tony Rall]

On Tuesday, 2005-10-18 at 21:18 MST, Aaron Glenn <[EMAIL PROTECTED]> 
wrote:
> I've found this tool to be very handy in finding out just what process
> is doing what.
> 
> http://www.sysinternals.com/Utilities/TcpView.html

But Tcpview doesn't show anything for icmp - which is what was happening 
in this case.  However, if the "guilty" process is also using tcp, Tcpview 
will likely identify it.

On the other hand, a firewall that limits outbound traffic to only 
"permitted" programs would probably nail the program involved (Zonealarm 
is one example of such a firewall).

> btw, I don't think nanog is the most appropriate list for these types
> of questions, fyi.

Probably so.  The newsgroup news:comp.security.misc might be a better 
place.

Tony Rall

Re: Really odd pings going out

[Aaron Glenn]

On 10/18/05, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
> --- some process is trying to call home...  part of a botnet perhaps.

I've found this tool to be very handy in finding out just what process
is doing what.

http://www.sysinternals.com/Utilities/TcpView.html

btw, I don't think nanog is the most appropriate list for these types
of questions, fyi.

Re: Verizon outage in Southern California?

[David Lesher]

Speaking on Deep Background, the Press Secretary whispered:
> 
> 
> I'm not completely familiar with the telco jargon.
> Does Tandem mean the same as a local central office, where
> POTS lines terminate at the switch? Long Beach has a population
> of 470,000. The C/Os I know of are:


A "Central Office" switch talks to subscribers aka end-users. 
On its backside, it talks to other CO's and tandems. Time
was, that was also VF copper pairs, but it's long since all 
DS1 and up.

A tandem is a switch that talks not to subs, but only to CO's. In
days of old, when a {dialup} call went to the other side of town,
chances are it went you-yourCO-downtown tandem-joesCO-joe. {copper
all the way...}.

A tandem was always housed in large CO building, but might have
been ATT's vice the operationg company, etc...

But ESS's and ""classless switching"" and massive expansion of the
plant really muddled the picture. An ESS could be both a CO switch
[for multiple prefixes and even multiple NPA's..] AND act like a
tandem.. And oh, the actual "line cards" can be remoted 100 miles
away in a horz. phonebooth box alongside the road in Smallville
with DS1's/OC coming back. 

My guess is a DACS, a cross-connect point that is an software-driven
patch panel, lost its marbles. [engineering term of art.]
A DACS could have dozen->MANY dozen DS1/DS3/OC-n going hither
and yon. Some will be leased circuits. Others will be the CO trunks
going from one switch to another. It may/may not have muxes internal,
so that what arrives on a DS1 leaves in a OC96..

I note it went down at 2:20 AM. That SCREAMS software
upgrade/cutover. What's to bet GEE, no...VZEEE, was doing just
that and there was a major ohshit.

Sean noted a long while back that somehow, DACS crashes always
seem to take hours to recover. Maybe the backups are on Kansas
City standard tapes, I donno.. but this sounds like that..

-- 
A host is a host from coast to [EMAIL PROTECTED]
& no one will talk to a host that's close[v].(301) 56-LINUX
Unless the host (that isn't close).pob 1433
is busy, hung or dead20915-1433

Re: Really odd pings going out

[bmanning]

the four IPs... 

in the mcsp.com domain
   swip.net domain
the machine dsmmr.shoalhaven.net.au.
in the  iij.ad.jp domain

--- some process is trying to call home...  part of a botnet perhaps.

--bill



On Tue, Oct 18, 2005 at 05:02:23PM -0700, Nicole wrote:
> 
> 
> 
>  Hello All.
>   I have seen people writing in now and again with things like this and I 
> never
> thought I would be one of them. But here goes.
> 
>  After doing a netgear firewall upgrade which suplpied some extra information,
> I started noticing these odd pings to all over the place from a computer I 
> have.
> I don't notce any attempted return traffic from the same Ip's. So I am
> at a loss as to what this could be or why. Any thoughts would be appreciated.
>  
> 
> - Destination:204.152.43.107,[Type:8],WAN [Forward] - [Outbound Default rule
> match]
> Mon, 2005-10-17 01:10:27 - ICMP packet - Source:192.168.1.3,[Echo Request],LAN
> - Destination:130.244.175.141,[Type:8],WAN [Forward] - [Outbound Default rule
> match]
> Mon, 2005-10-17 01:10:27 - ICMP packet - Source:192.168.1.3,[Echo Request],LAN
> - Destination:202.139.21.27,[Type:8],WAN [Forward] - [Outbound Default rule
> match]
> Mon, 2005-10-17 01:10:27 - ICMP packet - Source:192.168.1.3,[Echo Request],LAN
> - Destination:202.232.175.9,[Type:8],WAN [Forward] - [Outbound Default rule
> match]
> Mon, 2005-10-17 01:10:27 - ICMP packet - Source:192.168.1.3,[Echo Request],LAN
> - Destination:204.152.43.107,[Type:8],WAN [Forward] - [Outbound Default rule
> match]
> Mon, 2005-10-17 01:10:27 - ICMP packet - Source:192.168.1.3,[Echo Request],LAN
> - Destination:130.244.175.141,[Type:8],WAN [Forward] - [Outbound Default rule
> match]
> Mon, 2005-10-17 01:10:27 - ICMP packet - Source:192.168.1.3,[Echo Request],LAN
> - Destination:202.139.21.27,[Type:8],WAN [Forward] - [Outbound Default rule
> match]
> Mon, 2005-10-17 01:10:27 - ICMP packet - Source:192.168.1.3,[Echo Request],LAN
> - Destination:202.232.175.9,[Type:8],WAN [Forward] - [Outbound Default rule
> match]
> Mon, 2005-10-17 01:10:27 - ICMP packet - Source:192.168.1.3,[Echo Request],LAN
> - Destination:204.152.43.107,[Type:8],WAN [Forward] - [Outbound Default rule
> match]
> Mon, 2005-10-17 01:10:27 - ICMP packet - Source:192.168.1.3,[Echo Request],LAN
> - Destination:130.244.175.141,[Type:8],WAN [Forward] - [Outbound Default rule
> match]
> Mon, 2005-10-17 01:10:27 - ICMP packet - Source:192.168.1.3,[Echo Request],LAN
> - Destination:202.139.21.27,[Type:8],WAN [Forward] - [Outbound Default rule
> match]
> Mon, 2005-10-17 01:10:27 - ICMP packet - Source:192.168.1.3,[Echo Request],LAN
> - Destination:202.232.175.9,[Type:8],WAN [Forward] - [Outbound Default rule
> match]
> Mon, 2005-10-17 01:10:27 - ICMP packet - Source:192.168.1.3,[Echo Request],LAN
> - Destination:204.152.43.107,[Type:8],WAN [Forward] - [Outbound Default rule
> match]
> Mon, 2005-10-17 01:10:27 - ICMP packet - Source:192.168.1.3,[Echo Request],LAN
> - Destination:130.244.175.141,[Type:8],WAN [Forward] - [Outbound Default rule
> match]
> Mon, 2005-10-17 01:10:27 - ICMP packet - Source:192.168.1.3,[Echo Request],LAN
> - Destination:202.139.21.27,[Type:8],WAN [Forward] - [Outbound Default rule
> match]
> Mon, 2005-10-17 01:10:27 - ICMP packet - Source:192.168.1.3,[Echo Request],LAN
> - Destination:202.232.175.9,[Type:8],WAN [Forward] - [Outbound Default rule
> match]
> Mon, 2005-10-17 01:10:28 - ICMP packet - Source:192.168.1.3,[Echo Request],LAN
> - Destination:151.164.243.2,[Type:8],WAN [Forward] - [Outbound Default rule
> match]
> Mon, 2005-10-17 01:10:29 - ICMP packet - Source:192.168.1.3,[Echo Request],LAN
> - Destination:151.164.243.2,[Type:8],WAN [Forward] - [Outbound Default rule
> match]
> Mon, 2005-10-17 01:10:30 - ICMP packet - Source:192.168.1.3,[Echo Request],LAN
> - Destination:151.164.243.2,[Type:8],WAN [Forward] - [Outbound Default rule
> match]
> Mon, 2005-10-17 16:11:02 - ICMP packet - Source:192.168.1.3,[Echo Request],LAN
> - Destination:204.152.167.33,[Type:8],WAN [Forward] - [Outbound Default rule
> match]
> Mon, 2005-10-17 16:11:02 - ICMP packet - Source:192.168.1.3,[Echo Request],LAN
> - Destination:130.244.203.3,[Type:8],WAN [Forward] - [Outbound Default rule
> match]
> Mon, 2005-10-17 16:11:02 - ICMP packet - Source:192.168.1.3,[Echo Request],LAN
> - Destination:202.139.215.213,[Type:8],WAN [Forward] - [Outbound Default rule
> match]
> Mon, 2005-10-17 16:11:02 - ICMP packet - Source:192.168.1.3,[Echo Request],LAN
> - Destination:202.232.11.117,[Type:8],WAN [Forward] - [Outbound Default rule
> match]
> Mon, 2005-10-17 16:11:02 - ICMP packet - Source:192.168.1.3,[Echo Request],LAN
> - Destination:204.152.167.33,[Type:8],WAN [Forward] - [Outbound Default rule
> match]
> Mon, 2005-10-17 16:11:02 - ICMP packet - Source:192.168.1.3,[Echo Request],LAN
> - Destination:130.244.203.3,[Type:8],WAN [Forward] - [Outbound Default rule
> match]
> Mon, 2005-10-17 16:11:02 - ICMP packet - Source:192.168.1.3,[Echo Re

RE: Really odd pings going out

[Peter Kranz]

Doesn't look very odd to me, it's a very specific, rotating sequence..

204.152.43.107
130.244.175.141
202.139.21.27
202.232.175.9
Then back to .107,.141,.27,.9 ad nauseum..

Something on your laptop is trying to a. call home, b. find the best way
home, c. who knows..

Kill processes until it goes away and then go.. aha!

Peter Kranz
[EMAIL PROTECTED]

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Nicole
Sent: Tuesday, October 18, 2005 5:02 PM
To: [EMAIL PROTECTED]
Subject: Really odd pings going out




 Hello All.
  I have seen people writing in now and again with things like this and I
never
thought I would be one of them. But here goes.

 After doing a netgear firewall upgrade which suplpied some extra
information,
I started noticing these odd pings to all over the place from a computer I
have.
I don't notce any attempted return traffic from the same Ip's. So I am
at a loss as to what this could be or why. Any thoughts would be
appreciated.
 

- Destination:204.152.43.107,[Type:8],WAN [Forward] - [Outbound Default rule
match]
Mon, 2005-10-17 01:10:27 - ICMP packet - Source:192.168.1.3,[Echo
Request],LAN
- Destination:130.244.175.141,[Type:8],WAN [Forward] - [Outbound Default
rule
match]
Mon, 2005-10-17 01:10:27 - ICMP packet - Source:192.168.1.3,[Echo
Request],LAN
- Destination:202.139.21.27,[Type:8],WAN [Forward] - [Outbound Default rule
match]
Mon, 2005-10-17 01:10:27 - ICMP packet - Source:192.168.1.3,[Echo
Request],LAN
- Destination:202.232.175.9,[Type:8],WAN [Forward] - [Outbound Default rule
match]
Mon, 2005-10-17 01:10:27 - ICMP packet - Source:192.168.1.3,[Echo
Request],LAN
- Destination:204.152.43.107,[Type:8],WAN [Forward] - [Outbound Default rule
match]
Mon, 2005-10-17 01:10:27 - ICMP packet - Source:192.168.1.3,[Echo
Request],LAN
- Destination:130.244.175.141,[Type:8],WAN [Forward] - [Outbound Default
rule
match]
Mon, 2005-10-17 01:10:27 - ICMP packet - Source:192.168.1.3,[Echo
Request],LAN
- Destination:202.139.21.27,[Type:8],WAN [Forward] - [Outbound Default rule
match]
Mon, 2005-10-17 01:10:27 - ICMP packet - Source:192.168.1.3,[Echo
Request],LAN
- Destination:202.232.175.9,[Type:8],WAN [Forward] - [Outbound Default rule
match]
Mon, 2005-10-17 01:10:27 - ICMP packet - Source:192.168.1.3,[Echo
Request],LAN
- Destination:204.152.43.107,[Type:8],WAN [Forward] - [Outbound Default rule
match]
Mon, 2005-10-17 01:10:27 - ICMP packet - Source:192.168.1.3,[Echo
Request],LAN
- Destination:130.244.175.141,[Type:8],WAN [Forward] - [Outbound Default
rule
match]
Mon, 2005-10-17 01:10:27 - ICMP packet - Source:192.168.1.3,[Echo
Request],LAN
- Destination:202.139.21.27,[Type:8],WAN [Forward] - [Outbound Default rule
match]
Mon, 2005-10-17 01:10:27 - ICMP packet - Source:192.168.1.3,[Echo
Request],LAN
- Destination:202.232.175.9,[Type:8],WAN [Forward] - [Outbound Default rule
match]
Mon, 2005-10-17 01:10:27 - ICMP packet - Source:192.168.1.3,[Echo
Request],LAN
- Destination:204.152.43.107,[Type:8],WAN [Forward] - [Outbound Default rule
match]
Mon, 2005-10-17 01:10:27 - ICMP packet - Source:192.168.1.3,[Echo
Request],LAN
- Destination:130.244.175.141,[Type:8],WAN [Forward] - [Outbound Default
rule
match]
Mon, 2005-10-17 01:10:27 - ICMP packet - Source:192.168.1.3,[Echo
Request],LAN
- Destination:202.139.21.27,[Type:8],WAN [Forward] - [Outbound Default rule
match]
Mon, 2005-10-17 01:10:27 - ICMP packet - Source:192.168.1.3,[Echo
Request],LAN
- Destination:202.232.175.9,[Type:8],WAN [Forward] - [Outbound Default rule
match]
Mon, 2005-10-17 01:10:28 - ICMP packet - Source:192.168.1.3,[Echo
Request],LAN
- Destination:151.164.243.2,[Type:8],WAN [Forward] - [Outbound Default rule
match]
Mon, 2005-10-17 01:10:29 - ICMP packet - Source:192.168.1.3,[Echo
Request],LAN
- Destination:151.164.243.2,[Type:8],WAN [Forward] - [Outbound Default rule
match]
Mon, 2005-10-17 01:10:30 - ICMP packet - Source:192.168.1.3,[Echo
Request],LAN
- Destination:151.164.243.2,[Type:8],WAN [Forward] - [Outbound Default rule
match]
Mon, 2005-10-17 16:11:02 - ICMP packet - Source:192.168.1.3,[Echo
Request],LAN
- Destination:204.152.167.33,[Type:8],WAN [Forward] - [Outbound Default rule
match]
Mon, 2005-10-17 16:11:02 - ICMP packet - Source:192.168.1.3,[Echo
Request],LAN
- Destination:130.244.203.3,[Type:8],WAN [Forward] - [Outbound Default rule
match]
Mon, 2005-10-17 16:11:02 - ICMP packet - Source:192.168.1.3,[Echo
Request],LAN
- Destination:202.139.215.213,[Type:8],WAN [Forward] - [Outbound Default
rule
match]
Mon, 2005-10-17 16:11:02 - ICMP packet - Source:192.168.1.3,[Echo
Request],LAN
- Destination:202.232.11.117,[Type:8],WAN [Forward] - [Outbound Default rule
match]
Mon, 2005-10-17 16:11:02 - ICMP packet - Source:192.168.1.3,[Echo
Request],LAN
- Destination:204.152.167.33,[Type:8],WAN [Forward] - [Outbound Default rule
match]
Mon, 2005-10-17 16:11:02 - ICMP packet - Source:192.168.1.3,[Echo
Request],LAN
- Destination:130.244.203.3,[Type:8],WAN [Forward] - [Outbound Default rule
match]
Mon,

Really odd pings going out

[Nicole]

 Hello All.
  I have seen people writing in now and again with things like this and I never
thought I would be one of them. But here goes.

 After doing a netgear firewall upgrade which suplpied some extra information,
I started noticing these odd pings to all over the place from a computer I have.
I don't notce any attempted return traffic from the same Ip's. So I am
at a loss as to what this could be or why. Any thoughts would be appreciated.
 

- Destination:204.152.43.107,[Type:8],WAN [Forward] - [Outbound Default rule
match]
Mon, 2005-10-17 01:10:27 - ICMP packet - Source:192.168.1.3,[Echo Request],LAN
- Destination:130.244.175.141,[Type:8],WAN [Forward] - [Outbound Default rule
match]
Mon, 2005-10-17 01:10:27 - ICMP packet - Source:192.168.1.3,[Echo Request],LAN
- Destination:202.139.21.27,[Type:8],WAN [Forward] - [Outbound Default rule
match]
Mon, 2005-10-17 01:10:27 - ICMP packet - Source:192.168.1.3,[Echo Request],LAN
- Destination:202.232.175.9,[Type:8],WAN [Forward] - [Outbound Default rule
match]
Mon, 2005-10-17 01:10:27 - ICMP packet - Source:192.168.1.3,[Echo Request],LAN
- Destination:204.152.43.107,[Type:8],WAN [Forward] - [Outbound Default rule
match]
Mon, 2005-10-17 01:10:27 - ICMP packet - Source:192.168.1.3,[Echo Request],LAN
- Destination:130.244.175.141,[Type:8],WAN [Forward] - [Outbound Default rule
match]
Mon, 2005-10-17 01:10:27 - ICMP packet - Source:192.168.1.3,[Echo Request],LAN
- Destination:202.139.21.27,[Type:8],WAN [Forward] - [Outbound Default rule
match]
Mon, 2005-10-17 01:10:27 - ICMP packet - Source:192.168.1.3,[Echo Request],LAN
- Destination:202.232.175.9,[Type:8],WAN [Forward] - [Outbound Default rule
match]
Mon, 2005-10-17 01:10:27 - ICMP packet - Source:192.168.1.3,[Echo Request],LAN
- Destination:204.152.43.107,[Type:8],WAN [Forward] - [Outbound Default rule
match]
Mon, 2005-10-17 01:10:27 - ICMP packet - Source:192.168.1.3,[Echo Request],LAN
- Destination:130.244.175.141,[Type:8],WAN [Forward] - [Outbound Default rule
match]
Mon, 2005-10-17 01:10:27 - ICMP packet - Source:192.168.1.3,[Echo Request],LAN
- Destination:202.139.21.27,[Type:8],WAN [Forward] - [Outbound Default rule
match]
Mon, 2005-10-17 01:10:27 - ICMP packet - Source:192.168.1.3,[Echo Request],LAN
- Destination:202.232.175.9,[Type:8],WAN [Forward] - [Outbound Default rule
match]
Mon, 2005-10-17 01:10:27 - ICMP packet - Source:192.168.1.3,[Echo Request],LAN
- Destination:204.152.43.107,[Type:8],WAN [Forward] - [Outbound Default rule
match]
Mon, 2005-10-17 01:10:27 - ICMP packet - Source:192.168.1.3,[Echo Request],LAN
- Destination:130.244.175.141,[Type:8],WAN [Forward] - [Outbound Default rule
match]
Mon, 2005-10-17 01:10:27 - ICMP packet - Source:192.168.1.3,[Echo Request],LAN
- Destination:202.139.21.27,[Type:8],WAN [Forward] - [Outbound Default rule
match]
Mon, 2005-10-17 01:10:27 - ICMP packet - Source:192.168.1.3,[Echo Request],LAN
- Destination:202.232.175.9,[Type:8],WAN [Forward] - [Outbound Default rule
match]
Mon, 2005-10-17 01:10:28 - ICMP packet - Source:192.168.1.3,[Echo Request],LAN
- Destination:151.164.243.2,[Type:8],WAN [Forward] - [Outbound Default rule
match]
Mon, 2005-10-17 01:10:29 - ICMP packet - Source:192.168.1.3,[Echo Request],LAN
- Destination:151.164.243.2,[Type:8],WAN [Forward] - [Outbound Default rule
match]
Mon, 2005-10-17 01:10:30 - ICMP packet - Source:192.168.1.3,[Echo Request],LAN
- Destination:151.164.243.2,[Type:8],WAN [Forward] - [Outbound Default rule
match]
Mon, 2005-10-17 16:11:02 - ICMP packet - Source:192.168.1.3,[Echo Request],LAN
- Destination:204.152.167.33,[Type:8],WAN [Forward] - [Outbound Default rule
match]
Mon, 2005-10-17 16:11:02 - ICMP packet - Source:192.168.1.3,[Echo Request],LAN
- Destination:130.244.203.3,[Type:8],WAN [Forward] - [Outbound Default rule
match]
Mon, 2005-10-17 16:11:02 - ICMP packet - Source:192.168.1.3,[Echo Request],LAN
- Destination:202.139.215.213,[Type:8],WAN [Forward] - [Outbound Default rule
match]
Mon, 2005-10-17 16:11:02 - ICMP packet - Source:192.168.1.3,[Echo Request],LAN
- Destination:202.232.11.117,[Type:8],WAN [Forward] - [Outbound Default rule
match]
Mon, 2005-10-17 16:11:02 - ICMP packet - Source:192.168.1.3,[Echo Request],LAN
- Destination:204.152.167.33,[Type:8],WAN [Forward] - [Outbound Default rule
match]
Mon, 2005-10-17 16:11:02 - ICMP packet - Source:192.168.1.3,[Echo Request],LAN
- Destination:130.244.203.3,[Type:8],WAN [Forward] - [Outbound Default rule
match]
Mon, 2005-10-17 16:11:02 - ICMP packet - Source:192.168.1.3,[Echo Request],LAN
- Destination:202.139.215.213,[Type:8],WAN [Forward] - [Outbound Default rule
match]
Mon, 2005-10-17 16:11:02 - ICMP packet - Source:192.168.1.3,[Echo Request],LAN
- Destination:202.232.11.117,[Type:8],WAN [Forward] - [Outbound Default rule
match]
Mon, 2005-10-17 16:11:02 - ICMP packet - Source:192.168.1.3,[Echo Request],LAN
- Destination:204.152.167.33,[Type:8],WAN [Forward] - [Outbound Default rule
match]
Mon, 2005-10-17 16:11:02 - ICMP packet - Source:192.168.1.3,[Echo 

Re: FW: Verizon outage in Southern California?

[Vicky Rode]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Apparently there was a software glitch in the switch(s) which disrupted
 route calls.


regards,
/virendra

Hannigan, Martin wrote:
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On 
Behalf Of Matthew Black
Sent: Tuesday, October 18, 2005 3:13 PM
>>>
> 
>  
> 
>>I'm not completely familiar with the telco jargon.
>>Does Tandem mean the same as a local central office, where
>>POTS lines terminate at the switch? Long Beach has a population
>>of 470,000. The C/Os I know of are:
> 
> 
> A tandem office is a CO primarily used as an aggregated switch point
> between local CO's. Think interconnection of local CO's or long haul
> tandems.
> 
>  
> 
>>Alamitos at 7th Street and Termino, ZIP 90814
>>
>>Clark near Clark Ave and Pacific Coast Highway, ZIP 90804
>>
>>LongBeach at 6th Street and Elm Ave, ZIP 90802
>>
>>Lakewood at Clark Ave and Connant St, ZIP 90808
>>
>>LNBHCAXG at 3440 California Ave, ZIP 90807 (for my home)
> 
> 
> That's the building CLLI, the switch is LNBCHAXGDS0.
> 
> This one is a 5ESS and serves 12 exchanges.
> 
> 562-290 562-424 562-426 562-427 562-490 
> 562-492 562-595 562-933 562-981 562-988 
> 562-989 562-997 
> 
> I see 7 5ESS and 1 Nortel SLC DMS 10, possibly a remote to
> a campus or something, in Long Beach.
> 
> 507 E LEW is holding the most switching gear is likely
> a tandem. Um, I think this is the tandem code, PNTCMIMN50T,
> and it's servicing about 20 areas.
> 
> 
> 
>>I have no idea whether cell service was truly affected. The
>>announcements we sent to our campus suggested people use their
>>cell phones for 911 service which would be serviced by the
>>CA Highway Patrol (Erik Estrada, etc.) or a campus telephone
>>which is serviced by our local campus police (sworn state police).
>>I was completely unaware of the outage until someone else
>>mentioned it in my office.
> 
> 
> If you know of an NPA-NXX of a cell phone that was impacted,
> send it privately and I'll tell you what CO it terminates in.
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDVYhLpbZvCIJx1bcRApL+AKDRikufgOgg032THSg/Ai4S/iKSVwCg0O8c
HrvDIjtCgTVh5l+NFM8RG6I=
=vFGk
-END PGP SIGNATURE-

Re: And Now for Something Completely Different (was Re: IPv6 news)

[David Conrad]

Tony,

On Oct 18, 2005, at 1:56 PM, Tony Li wrote:

Not necessarily.  If you transition at the edge, what happens  
within the site matters only to the site and what matters to the  
core only matters to the core.  No stacks, either core or edge,  
need to be rewritten.


Transitioning at the edge implies to me that the hosts need to know  
about different semantics for the IPv6 header.  That, in turn,  
implies that there is different code for the hosts.
Alternately, if there is no new code anywhere, it's clear that you  
must necessarily have the same semantics and must not have made a  
change.




No.  The only code change that must occur is at the core/edge  
transition device _at both ends_.  Let me try explaining this by  
example:


Assume you have:
- ISP A providing service to site X.
- ISP B providing service to site Y.
- ISP A has locator prefix A000::0
- ISP B has locator prefix B000::0
- Site X has identifier prefix 1000::0
- Site Y has identifier prefix 2000::0
- Host 1000::1 wants to send a packet to host 2000::2

Then:

1. Packet leaves host 1000::1 destined for 2000:2 and ends up at the  
site edge router for ISP A.
2. The site edge router for ISP A sees destination 2000:2 and looks  
up the locator in some globally distributed database using the  
identifier prefix 2000::0, getting back locator prefix B000::0.
3. The site edge router for ISP A rewrites the destination address  
with the locator prefix, i.e., B000::2.
4. The site edge router for ISP A forwards the packet to the next  
(core) hop for destination B000::2.
5. The site edge router for ISP B receives the packet destined for  
B000::2
6. The site edge router for ISP B rewrites the destination prefix  
with the identifier prefix, i.e., 2000::2
7. The site edge router for ISP B forwards the packet to the  
destination.


You want multi-homing?  Site Y has two ISPs, each having their own  
locator prefix, e.g., ISP B (B000::0) and ISP C (C000::0).  The  
lookup at step 2 returns two locators and the site edge router for  
ISP A can choose which path to take (perhaps with advice from the  
administrator of Site Y encoded in the response from the lookup,  
e.g., a preference or priority value).  Transparent renumbering is  
obvious.  Mobility might be possible with a little work and the old  
site edge router forwarding to the new site edge router for the  
duration of the cached response from the lookup.


No code changes within the site or within the core would be necessary.

Of course, the tricky bit is in looking up the locator in the  
globally distributed database and caching the response (which  
presumably would be necessary because the lookup will take a long  
time, relatively speaking).  When a new 'conversation' between two  
hosts start, the initial packet will obviously have increased  
latency, but subsequent packets could rely on cached information.


Again, I realize this is a hack, but I suspect it is a hack that  
impacts fewer points than something like shim6.



Again, source address selection is going to require something  
different than what we have today.  The host might have to interact  
with some centralized policy server, execute a selection algorithm,  
or consult an oracle.  Whatever that might be, there is new code  
involved.




Well, yes, if source address selection is important.  My point was  
that there didn't have to be new code in the IP stack.



As with any political process, the stated requirements are a  
function of perspective.  The stated requirements may or may not  
have anything to do with reality, realizability, practicality, or  
architectural elegance.




Hmm.  Are the aliens who took the _real_ IETF and replaced it with  
what's there now going to give it back? :-)



It could have been done the right way in the protocol, but it  
wasn't.  Yes, the result is that the subsequent 'work around'  
solution is much more complicated than it could have been.




I grant additional complexity is necessary.  However, additional  
complexity in every system seems like a bad idea to me.



Again, between multihoming and mobility, the ubiquity and necessity  
of Internet access, and the reliability of the last mile, this is  
not going to remain a rare or even minority issue.




I very much agree.

Rgds,
-drc

RE: Verizon outage in Southern California?

[Hannigan, Martin]

> - Original Message - 
> From: "Hannigan, Martin" <[EMAIL PROTECTED]>
> To: "Matthew Black" <[EMAIL PROTECTED]>; "NANOG" <[EMAIL PROTECTED]>
> Sent: Tuesday, October 18, 2005 4:35 PM
> Subject: FW: Verizon outage in Southern California?
> 
> >507 E LEW is holding the most switching gear is likely
> >a tandem. Um, I think this is the tandem code, PNTCMIMN50T,
> >and it's servicing about 20 areas.
> 
> Uhh, think you might have the wrong CLLI code. PNTCMIMN50T is
> in Pontiac, Michigan and yes, it is a tandem.

Yep, Majdi caught it and mailed me earlier. There's a data 
anomaly between 507 LEW and 507 Mill. I'm looking into it now, 
but I doubt I'll repost it to NANOG. I think we've 
defined this outage as much as posslible and most 
"get it".

There's a lot of telco knowledge in SoCal. Kudos!


-M<

Re: Verizon outage in Southern California?

[John Palmer (NANOG Acct)]

- Original Message - 
From: "Hannigan, Martin" <[EMAIL PROTECTED]>
To: "Matthew Black" <[EMAIL PROTECTED]>; "NANOG" <[EMAIL PROTECTED]>
Sent: Tuesday, October 18, 2005 4:35 PM
Subject: FW: Verizon outage in Southern California?

>507 E LEW is holding the most switching gear is likely
>a tandem. Um, I think this is the tandem code, PNTCMIMN50T,
>and it's servicing about 20 areas.

Uhh, think you might have the wrong CLLI code. PNTCMIMN50T is
in Pontiac, Michigan and yes, it is a tandem.

RE: Scalability issues in the Internet routing system

[Susan Hares]

(cookinjg = cooking) -- ;-)..

Sue

(but you knew that.)

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Susan Hares
Sent: Tuesday, October 18, 2005 5:49 PM
To: Tony Li; Andre Oppermann
Cc: [EMAIL PROTECTED]
Subject: RE: Scalability issues in the Internet routing system


Andre:

Hence my earlier point on #2 - the prefixes in the routing hit one part
of 
Moore's law.  The FIB hits another.

Using the compression ("cooking") per router can provide one level of
abstraction [reduction of prefix space] at router.  So cooking down your

Large number of routes to a "minimum" set of routes can provide some
leverage against the prefix growth.

Tony point still stands.  The "cookinjg" way to deal with prefix growth
by
using a compression algorithm for FIB insertion.  Moore's law hits the 
security filters, the route filters, and lots more - that may or may-not
be
able to be "cooked".

Sue Hares


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Tony Li
Sent: Tuesday, October 18, 2005 4:46 PM
To: Andre Oppermann
Cc: [EMAIL PROTECTED]
Subject: Re: Scalability issues in the Internet routing system




Andre,

>  capacity = prefix * path * churnfactor / second
>
>  capacity = prefixes * packets / second

> I think it is safe, even with projected AS and IP uptake, to assume
> Moore's law can cope with this.
>
> 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.


You'll note that the number of prefixes is key to both of your  
equations.  If the number of prefixes exceeds Moore's law, then it  
will be very difficult to get either of your equations to remain  
under Moore's law on the left hand side.

That's the whole point of the discussion.

Tony

RE: Scalability issues in the Internet routing system

[Susan Hares]

Andre:

Hence my earlier point on #2 - the prefixes in the routing hit one part
of 
Moore's law.  The FIB hits another.

Using the compression ("cooking") per router can provide one level of
abstraction [reduction of prefix space] at router.  So cooking down your

Large number of routes to a "minimum" set of routes can provide some
leverage against the prefix growth.

Tony point still stands.  The "cookinjg" way to deal with prefix growth
by
using a compression algorithm for FIB insertion.  Moore's law hits the 
security filters, the route filters, and lots more - that may or may-not
be
able to be "cooked".

Sue Hares


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Tony Li
Sent: Tuesday, October 18, 2005 4:46 PM
To: Andre Oppermann
Cc: [EMAIL PROTECTED]
Subject: Re: Scalability issues in the Internet routing system




Andre,

>  capacity = prefix * path * churnfactor / second
>
>  capacity = prefixes * packets / second

> I think it is safe, even with projected AS and IP uptake, to assume
> Moore's law can cope with this.
>
> 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.


You'll note that the number of prefixes is key to both of your  
equations.  If the number of prefixes exceeds Moore's law, then it  
will be very difficult to get either of your equations to remain  
under Moore's law on the left hand side.

That's the whole point of the discussion.

Tony

Re: And Now for Something Completely Different

[Robert E . Seastrom]

>> Moore will likely have to continue to produce the solution.
>
> What happens if he can't?  Silicon technology *is* topping out.  What
> happens to v6 if every single household and business on the planet
> decides to multihome?

I often wonder what would happen if IETF and NANOG were to
collectively swear off reductio ad absurdum scenarios.

For extra credit, the reader is invited to compare and contrast the
relative probabilities of "pervasive end-site multihoming" and "IETF
and NANOG learning what a 'false dichotomy' is".

Traditional multihoming techniques work today and buy us a decade or
more _until the v6 routing table is the same size as today's v4
table_.  That's a decade to make Pad's seminal work (cited by Vixie
earlier; it's nice to have it back in print!) required reading for
IETF participation and smack some sense into the acolytes of Rube
Goldberg whose influence on shim6 is all too apparent.

---Rob

FW: Verizon outage in Southern California?

[Hannigan, Martin]

> > 
> >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On 
> >> Behalf Of Matthew Black
> >> Sent: Tuesday, October 18, 2005 3:13 PM
> > 

 
> I'm not completely familiar with the telco jargon.
> Does Tandem mean the same as a local central office, where
> POTS lines terminate at the switch? Long Beach has a population
> of 470,000. The C/Os I know of are:

A tandem office is a CO primarily used as an aggregated switch point
between local CO's. Think interconnection of local CO's or long haul
tandems.

 
> Alamitos at 7th Street and Termino, ZIP 90814
> 
> Clark near Clark Ave and Pacific Coast Highway, ZIP 90804
> 
> LongBeach at 6th Street and Elm Ave, ZIP 90802
> 
> Lakewood at Clark Ave and Connant St, ZIP 90808
> 
> LNBHCAXG at 3440 California Ave, ZIP 90807 (for my home)

That's the building CLLI, the switch is LNBCHAXGDS0.

This one is a 5ESS and serves 12 exchanges.

562-290 562-424 562-426 562-427 562-490 
562-492 562-595 562-933 562-981 562-988 
562-989 562-997 

I see 7 5ESS and 1 Nortel SLC DMS 10, possibly a remote to
a campus or something, in Long Beach.

507 E LEW is holding the most switching gear is likely
a tandem. Um, I think this is the tandem code, PNTCMIMN50T,
and it's servicing about 20 areas.


> I have no idea whether cell service was truly affected. The
> announcements we sent to our campus suggested people use their
> cell phones for 911 service which would be serviced by the
> CA Highway Patrol (Erik Estrada, etc.) or a campus telephone
> which is serviced by our local campus police (sworn state police).
> I was completely unaware of the outage until someone else
> mentioned it in my office.

If you know of an NPA-NXX of a cell phone that was impacted,
send it privately and I'll tell you what CO it terminates in.

Re: Verizon outage in Southern California?

[Aaron Glenn]

On 10/18/05, Hannigan, Martin <[EMAIL PROTECTED]> wrote:
> My guess is water on a DACS bay or complete power loss in the
> CO (rarer than water on a DACS).
>

Having grown up two blocks from said CO; I can attest the power setup
is very, very well built out. Not to say even the biggest, well
engineered power plants can't fail spectacularly; but this  isn't a
tiny CO by any standard.

regards,
aaron.glenn

Re: Verizon outage in Southern California?

[Matthew Black]

On Tue, 18 Oct 2005 15:38:06 -0500
 "Olsen, Jason" <[EMAIL PROTECTED]> wrote:


From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On 
Behalf Of Matthew Black

Sent: Tuesday, October 18, 2005 3:13 PM


Telephone service is beginning to be restored in the Long 
Beach area but is still sporadic.


Our ATM WAN link through Sprint came back up around 1345 Central time,
and the two DS1s for the school's Internet service were revived about
fifteen minutes ago (1507 CDT).  They've been rock-solid so something
must be going right out there.

When I called Sprint about any information they might have for the
outage the tech said that the area was down due to a Verizon DACS
failure.  That must have been a spectacular failure, because I'm reading
that it wiped out most everything (
http://www2.presstelegram.com/news/ci_3128087  indicates four tandems
hit?! ) in the area.  The articles are primarily focusing on the impact
to E911 services, followed with the hit to POTS lines.  I have yet to
see any mention of impact to data in any of 'em.  Here's what intrigues
me about this outage: if it wiped out E911, most of the POTS and also
impacted data services (as Jay Hannigan and I can attest), how did the
cell towers that are also served by the network live through it?

Jason "Feren" Olsen  Senior Network Engineer DeVry, Inc



Thanks for the link to the story update. Our OC3C (155 Mbps link)
goes through a place called WestEd (not WestCom) in Seal Beach
which is the headquarters for CENIC, the CA higher education network.
We never saw any data outage for CSULB.

I'm not completely familiar with the telco jargon.
Does Tandem mean the same as a local central office, where
POTS lines terminate at the switch? Long Beach has a population
of 470,000. The C/Os I know of are:

Alamitos at 7th Street and Termino, ZIP 90814

Clark near Clark Ave and Pacific Coast Highway, ZIP 90804

LongBeach at 6th Street and Elm Ave, ZIP 90802

Lakewood at Clark Ave and Connant St, ZIP 90808

LNBHCAXG at 3440 California Ave, ZIP 90807 (for my home)


I have no idea whether cell service was truly affected. The
announcements we sent to our campus suggested people use their
cell phones for 911 service which would be serviced by the
CA Highway Patrol (Erik Estrada, etc.) or a campus telephone
which is serviced by our local campus police (sworn state police).
I was completely unaware of the outage until someone else
mentioned it in my office.

matthew black
california state university, long beach

Re: And Now for Something Completely Different (was Re: IPv6 news)

[Tony Li]

Daniel,

But wasn't that the rationale for originally putting the kitchen  
sink into IPv6, rather than fixing the address length issue?



The stated rationale was to fix the address length issue.



I think we missed a lot of opportunities.



Amen.


We're 10 years on, and talking about whether there will need to be  
more than one massive pain of migration, because the kitchen sink  
didn't take into account multihoming.



More generally because we were unwilling to make changes to the  
routing architecture.



Now we're talking about a solution that appear to be an even worse  
Rube Goldberg than token ring source-route bridging.



No one has proposed anything that is as bad as the exponential  
traffic explosion caused by explorers.




Moore will likely have to continue to produce the solution.



What happens if he can't?  Silicon technology *is* topping out.  What  
happens to v6 if every single household and business on the planet  
decides to multihome?


Tony

Re: And Now for Something Completely Different (was Re: IPv6 news)

[Tony Li]

David,


A real locator/identifier separation requires a rewrite.


Not necessarily.  If you transition at the edge, what happens  
within the site matters only to the site and what matters to the  
core only matters to the core.  No stacks, either core or edge,  
need to be rewritten.



Transitioning at the edge implies to me that the hosts need to know  
about different semantics for the IPv6 header.  That, in turn,  
implies that there is different code for the hosts.


Alternately, if there is no new code anywhere, it's clear that you  
must necessarily have the same semantics and must not have made a  
change.



Any system that provided site-wide source address control was  
going to require a rewrite.


Not necessarily (depending on what you mean by the ambiguous term  
"address").  A lot depends on the actual requirements for source  
locator or identifier control.



Again, source address selection is going to require something  
different than what we have today.  The host might have to interact  
with some centralized policy server, execute a selection algorithm,  
or consult an oracle.  Whatever that might be, there is new code  
involved.


David, I should point out that if only a small number of folks  
care about multihoming, then only a small number of folks need to  
change their stacks.


I thought all clients would have to be modified if they wanted to  
take full advantage of a shim6 enabled multi-homed server?



The keyword there is "full".  Unmodified clients can still interact  
with a multi-homed server in a legacy manner.



And even in your solution, there would need to be some changes to  
the end host if you want to support exit point selection, or carry  
alternate locators in the transport.


One of the problems that I have seen in the IETF is calling desires  
"requirements".  How important is exit point selection?  Are there  
ways of implementing exit point selection without changing the IP  
stack?  How critical is it that alternate locators be carried in  
the transport?  Does the lack of that functionality make the  
protocol unusable?


What _are_ the actual requirements (not the "Goals")?  From my  
perspective, the really, really critical flaw in both IPv4 and IPv6  
is the lack of _transparent_ renumberability.  Multi-homing is also  
a flaw, but less critical and I believe it can be addressed with  
the right solution to renumberability.  A "few" folks worry about  
multi-homing.  Everybody worries about end site renumbering.



As with any political process, the stated requirements are a function  
of perspective.  The stated requirements may or may not have anything  
to do with reality, realizability, practicality, or architectural  
elegance.



It's just a mess.  I think that we all can agree that a real  
locator/identifier split is the correct architectural direction,  
but that's simply not politically tractable.


Right.  And since it couldn't be done the right way in the  
protocol, we make the protocol much more complicated and force a  
reset to address functionality that relatively few folks need.



It could have been done the right way in the protocol, but it  
wasn't.  Yes, the result is that the subsequent 'work around'  
solution is much more complicated than it could have been.


Again, between multihoming and mobility, the ubiquity and necessity  
of Internet access, and the reliability of the last mile, this is not  
going to remain a rare or even minority issue.


Regards,
Tony

RE: Verizon outage in Southern California?

[Hannigan, Martin]

> 
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On 
> > Behalf Of Matthew Black
> > Sent: Tuesday, October 18, 2005 3:13 PM
> 
> > Telephone service is beginning to be restored in the Long 
> > Beach area but is still sporadic.
> 
> Our ATM WAN link through Sprint came back up around 1345 Central time,
> and the two DS1s for the school's Internet service were revived about
> fifteen minutes ago (1507 CDT).  They've been rock-solid so something
> must be going right out there.
> 
> When I called Sprint about any information they might have for the
> outage the tech said that the area was down due to a Verizon DACS
> failure.  That must have been a spectacular failure, because 
> I'm reading
> that it wiped out most everything (
> http://www2.presstelegram.com/news/ci_3128087  indicates four tandems
> hit?! ) in the area.  The articles are primarily focusing on 
> the impact
> to E911 services, followed with the hit to POTS lines.  I have yet to
> see any mention of impact to data in any of 'em.  Here's what 
> intrigues
> me about this outage: if it wiped out E911, most of the POTS and also
> impacted data services (as Jay Hannigan and I can attest), how did the
> cell towers that are also served by the network live through it?


The dependancy between all of those would be a DACS so that
seems to make sense. I'm guessing the impacted circuits were
DS3 or below, with Verizon providing resale of the Z ends.

I'm not sure of the relation to E911 though. Could be, but
it sounds odd since E911 has redundancies to tandems IIRC.

My guess is water on a DACS bay or complete power loss in the
CO (rarer than water on a DACS).

-M<

Re: Scalability issues in the Internet routing system

[Richard A Steenbergen]

On Tue, Oct 18, 2005 at 01:41:53PM -0400, vijay gill wrote:
> 
> Moore's law for CPUs is kaput. Really, Moore's Law is more of an 
> observation, than a law. We need to stop fixating on Moore's law for the 
> love of god.  It doesn't exist in a vacuum, Components don't get on the 
> curve for free.  Each generation requires enormously more capital to 
> engineer the improved Si process, innovation, process, which only get 
> paid for by increasing demand.   If the demand slows down then the 
> investment won't be recovered and the cycle will stop, possibly before 
> the physics limits, depending on the amount of demand, amount of 
> investment required for the next turn etc.

Moore's "observation" would also seem to apply only to the highest end of 
components that are actually "available", not to what a particular vendor 
ships in a particular product. Of course we have the technology available 
to handle 1 million BGP routes or more if we really needed to. Processing 
BGP is fairly easy and linear, modern CPUs are cheap and almost absurdly 
powerful in comparison to the task at hand (they're made to run Windows 
code remember :P).  But if there is no reason to make a product, it 
doesn't get made.

Comparing consumer-grade PCs which are produced in the millions or 
billions with one small part of a high-end router which is produced in the 
thousands, and which is essentially an embedded product, is a non-starter.
The product that is sold does what it needs to do and no more. There is no 
reason to design a scalable route processor which can be easily upgraded. 
There is no need to ship the latest state of the art Dual Xeon 3.6GHz with 
support for 64GB of DRAM that will last you for your BGP needs for the 
next 10 years, or even to throw in 128MB of SSRAM for a few thousand bucks 
more.

Everyone needs to sell their latest and greatest new product on a regular 
basis to stay in business, it is no different for router vendors. They 
sell you a $20,000 route processor that you could pick up from their 
vendor directly at Qty 1 for $1000, and the markup goes into the what you 
are really paying for (R&D, software dev, testing, support, sales, and the 
bottom line). A few years later when you need something a little faster, 
you can buy a new router. Besides, you probably needed to come back for 
the next-gen platform and interfaces anyways. Most customers are barely 
qualified to add RAM to their million dollar router, and I doubt the 
vendors see any need to change this.

> Also, no network I know is on the upgrade path at a velocity that they 
> are swapping out components in a 18 month window. Ideally, for an 
> economically viable network, you want to be on an upgrade cycle that 
> lags Moore's observation. Getting routers off your books is not an 18 
> month cycle, it is closer to 48 months or even in some cases 60 months.

Want to venture a guess as to how many networks are still operating 
routers with parts at the end of that 60 month cycle (purchased in 2000), 
which were in turn based off of 1997 technology back when they were 
manufactured in 1998-1999?

-- 
Richard A Steenbergen <[EMAIL PROTECTED]>   http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

Re: And Now for Something Completely Different (was Re: IPv6 news)

[Stephen Sprunk]

Thus spake <[EMAIL PROTECTED]>

E.g prevously
announced address-blocks that has disappeared from the global
routing-table for more than X months should go back to the RIR-pool
(X<=6).


In RFC 2050 section 3 a)
  the organization has no intention of connecting to
  the Internet-either now or in the future-but it still
  requires a globally unique IP address.  The organization
  should consider using reserved addresses from RFC1918.
  If it is determined this is not possible, they can be
  issued unique (if not Internet routable) IP addresses.

Seems to me that the Internet routing table contents
past and present are irrelevant. Note also that the
so-called Internet routing table contents vary depending
on where you look at it.


Obviously if the RIRs contacted the folks responsible for a given block and 
were provided justification for its continued allocation, then it should not 
be reclaimed.  On the other hand, folks sitting on several class Bs and not 
using them could have their blocks reclaimed trivially; ditto for companies 
that no longer exist.  The last is certainly doable without much risk of 
controversy.


However, one of the articles referred to recently in this thread (I forget 
which) showed that even if we reclaimed all of the address space that is 
currently unannounced (in use or not), we'd buy ourselves a trivially short 
extension of the IPv4 address space exhaustion date.  Considering the cost 
of performing the task, doing so seems rather pointless; our time would be 
better spent getting IPv6 deployed and either reengineering the routing 
system or switching to geo addresses.


S

Stephen Sprunk"Stupid people surround themselves with smart
CCIE #3723   people.  Smart people surround themselves with
K5SSS smart people who disagree with them."  --Aaron Sorkin 

Re: Scalability issues in the Internet routing system

[Tony Li]

Andre,


 capacity = prefix * path * churnfactor / second

 capacity = prefixes * packets / second



I think it is safe, even with projected AS and IP uptake, to assume
Moore's law can cope with this.

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.



You'll note that the number of prefixes is key to both of your  
equations.  If the number of prefixes exceeds Moore's law, then it  
will be very difficult to get either of your equations to remain  
under Moore's law on the left hand side.


That's the whole point of the discussion.

Tony

Re: And Now for Something Completely Different (was Re: IPv6 news)

[Gary E. Miller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Yo Fred!

On Tue, 18 Oct 2005, Fred Baker wrote:

> But yes, communities of a rational size and density could get an address
> block, the relevant ISPs could all advertise it into the backbone, and the
> ISPs could determine among themselves how to deliver traffic to the homes,

That assumes they can agree on how to get traffic to/from the world and
the local IX.  One of our local ISPs goes the cheap way and uses an
overloaded (and therefore cost effective) link to a cheap tier 2.  Another
pays a premium price to have a lightly loaded link for it's customers.

They will never agree on their business model, not should they have to.  By
forcing local ISPs to use the same routing prefix you force them to share
the same routing strategy to the outside world.  For semi-isolated
communities this is a big issue.

RGDS
GARY
- ---
Gary E. Miller Rellim 20340 Empire Blvd, Suite E-3, Bend, OR 97701
[EMAIL PROTECTED]  Tel:+1(541)382-8588 Fax: +1(541)382-8676

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDVV4g8KZibdeR3qURAuhjAKCuvsd/ZmXebyyTNkfdQ3tBbQvdmACg1OnL
RE0lRoxSElVzNaZFpdYcObA=
=b5O1
-END PGP SIGNATURE-

RE: Verizon outage in Southern California?

[Olsen, Jason]

> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On 
> Behalf Of Matthew Black
> Sent: Tuesday, October 18, 2005 3:13 PM

> Telephone service is beginning to be restored in the Long 
> Beach area but is still sporadic.

Our ATM WAN link through Sprint came back up around 1345 Central time,
and the two DS1s for the school's Internet service were revived about
fifteen minutes ago (1507 CDT).  They've been rock-solid so something
must be going right out there.

When I called Sprint about any information they might have for the
outage the tech said that the area was down due to a Verizon DACS
failure.  That must have been a spectacular failure, because I'm reading
that it wiped out most everything (
http://www2.presstelegram.com/news/ci_3128087  indicates four tandems
hit?! ) in the area.  The articles are primarily focusing on the impact
to E911 services, followed with the hit to POTS lines.  I have yet to
see any mention of impact to data in any of 'em.  Here's what intrigues
me about this outage: if it wiped out E911, most of the POTS and also
impacted data services (as Jay Hannigan and I can attest), how did the
cell towers that are also served by the network live through it?

Jason "Feren" Olsen  Senior Network Engineer DeVry, Inc
Em: [EMAIL PROTECTED] Ph: 630-645-1607One Tower Lane
INOC-DBA: 19258*526  Fx: 630-389-2929Oakbrook Terrace,
IL 60181

Re: Verizon outage in Southern California?

[Matthew Black]

Around 2:20 or 2:30 a.m., I was awoken by my clock radio with
three or more sets of soft buzzing noises--as though a radio
station went silent. I checked my cordless phone and had
dialtone, then went back to sleep. Is there any correlation?



I guess my posting wasn't clear. The radio portion of my
clock radio was completely off. The clock was working and the
alarm was set for 5:50 a.m. to turn on the radio.

My cordless phone sits adjacent to the clock radio. The cordless
phone near my bed is an extension sitting in its charging base
but it is not the base telephone station which is located in
another room and plugged into a POTS line.

During the night, my radio is normally silent. Maybe the noises
that I heard around 2:30 a.m. came from the cordless phone
instead of the clock radio. I just thought it was a conicidence
that I hear strange noises around the same time my local phone
company experiences a major outage.

matthew black
california state university, long beach

Re: And Now for Something Completely Different (was Re: IPv6 news)

[Fred Baker]

the principal issue I see with your proposal is that it is DUAL  
homing vs MULTI homing. To make it viable, I think you have to say  
something like "two or more ISPs must participate in a multilateral  
peering arrangement that shares the address pool among them". The  
location of the actual peering is immaterial - doing one for Santa  
Barbara County in California might actually mean peering at One  
Wilshire Way in LA, for example. However, the peering arrangement  
would have to be open to the ISPs that serve the community;  
otherwise, it would be exposed to anti-trust litigation (if Cox and  
Verizon, the Cable Modem and DSL providers in Santa Barbara, did  
this, but it was not open to smaller ISPs in the community, the  
latter might complain that it had the effect of locking out  
competition).


But yes, communities of a rational size and density could get an  
address block, the relevant ISPs could all advertise it into the  
backbone, and the ISPs could determine among themselves how to  
deliver traffic to the homes, which I should expect would mean that  
they would deliver directly if they could and otherwise hand off to  
another ISP, and that handoff would require an appropriate routing  
exchange. Can you say "lots of long prefixes within a limited  
domain"? They would want to configure the home's address block on its  
interior interface and route to it through their own networks. Note  
that NAT breaks this... this requires end to end connectivity. I  
should expect that they would not literally expect the homes to run  
BGP (heaven forfend); I could imagine the "last mile" being the last  
bastion of RIP - the home sends a IP update upstream for its interior  
address, and the ISP sends a default route plus routes to its own  
data centers down.


The biggest issue here might be the effect on cost models in routing.  
Today, hot potato routing makes a some relationships relatively cheap  
while other relationships are more expensive; this reverses those.  
Today, if a datagram is handed to me that will be delivered in your  
network, I hand it to you at my earliest opportunity and you deliver  
it. In this model, I can't tell who will deliver it until I get  
relatively close to the community. Hence, I will carry the packet to  
that exchange point, and only then hand it to you. Funny. I described  
this in an internet draft nearly a decade ago, and got dumped on  
because of this issue - something about living in an ivory tower and  
playing with people's livelihoods, as I recall. I'll see if I can  
resurrect that, if you like.


On Oct 18, 2005, at 10:40 AM, Church, Chuck wrote:







Nanog,

I've been thinking a bunch about this IPv6 multihoming issue.
It seems that the method of hierarchical summarization will keep the
global tables small for all single-homed end user blocks.  But the
multihomed ones will be the problem.  The possible solution I've been
thinking about is 'adjacency blocks', for lack of a better term.  In
theory, the first customer to home to two different ISPs causes a new
large address block to be advertised upstream by these two ISPs.
Further customers homing to these two ISPs get an allocation out of  
this
same block.  The two ISPs will only announce the large block.  Of  
course

there are issues involving failure and scalability...
Failure would involve an ISP losing contact with end customer,
but still announcing the aggregate upstream.  This can be solved by
requiring that two ISPs must have a direct peering agreement, before
they can accept dual-homed customers.  Or a possible method (maybe  
using
communities?) where ISP B will announce the customer's actual block  
(the

small one) to it's upstreams, if notified by ISP A that it's not
reachable by them.  When ISP A resumes contact with end customer,  
ISP B

retracts the smaller prefix.
Scalability is an obvious issue, as the possible number of these
'adjacency blocks' would be N * (N-1), where N is the number of  
ISPs in
the world.  Obviously pretty large.  But I feel the number of ISPs  
that

people would actually dual home to (due to reputation, regional
existence, etc) is a few orders of magnitude smaller.  ~100,000  
prefixes

(each can be an ASN, I suppose) should cover all needs, doing some
simple math.
The downside is that end customers are going to lose the ability
to prefer traffic from one ISP versus another for inbound traffic.   
That
alone might be a show-stopper, not sure how important it is.  Since  
IPv6

is a whole new ballgame, maybe it's ok to change the rules...
Looking for any thoughts about it.  I'm sure there's things I
haven't considered, but the people I've bounced it off of haven't seen
any obvious problems.  Flame-retardant clothes on, just in case  
though.



Chuck







Every multi-homer will be needing their own ASN, so that's what






clutters






up your routing tables. It's economy there. Btw, a lot of ASNs






advertise





one netw

Re: Verizon outage in Southern California?

[Steve Sobol]

Matthew Black wrote:


While weather in Southern California may affect your electricity,


...It does, and it's more of an electric utility problem than a weather 
problem. :P



it has only a minor effect in the Long Beach area. Monday evening's
storm was fairly mild with winds under 10 MPH and less than a half
an inch of rain overnight. Not what I would consider a heavy storm.


Yeah, I figured the heavy winds might have more to do with any possible 
outages than the rain did. Obviously, though, not a big issue in Long Beach...



Rains do cause telco data problems. When I had dial-up, my maximum
rate dropeed from about 45K to 37Kbps during and for a day or two
following rain.


*nod* but that's 56K dialup, which is a crapshoot anyhow. I'd be more 
interested in finding out if there were any weather-related issues with 
services that are normally more stable than dialup.


--
Steve Sobol, Professional Geek   888-480-4638   PGP: 0xE3AE35ED
Company website: http://JustThe.net/
Personal blog, resume, portfolio: http://SteveSobol.com/
E: [EMAIL PROTECTED] Snail: 22674 Motnocab Road, Apple Valley, CA 92307

Re: Verizon outage in Southern California?

[Matthew Black]

On Tue, 18 Oct 2005 12:59:37 -0700
 Steve Sobol <[EMAIL PROTECTED]> wrote:


Olsen, Jason wrote:

Anyone have more information?  It seems to have started around 02:30 local 
time this morning.


We lost connectivity (WAN/Internet/POTS) to our Long Beach site at
around 2:27 AM PDT today.  Several news agencies are reporting it on the
web (hooray news.google.com), citing "mechanical glitches" or bad
weather.


Bad weather could definitely be a factor.

Southern Cali electric utilities are notoriously unreliable during bad 
weather, especially up in my neck of the woods. It's been raining pretty 
steadily here for the past two days; I drove 150 miles from Apple Valley to 
northeast San Diego this morning and it was even raining down here in SD -- 
may still be raining now, I just haven't looked outside. I even heard a 
radio report that a funnel cloud touched down in the foothills outside Los 
Angeles; I forget exactly where. (That doesn't happen very often around 
here.)



While weather in Southern California may affect your electricity,
it has only a minor effect in the Long Beach area. Monday evening's
storm was fairly mild with winds under 10 MPH and less than a half
an inch of rain overnight. Not what I would consider a heavy storm.

Rains do cause telco data problems. When I had dial-up, my maximum
rate dropeed from about 45K to 37Kbps during and for a day or two
following rain.

Telephone service is beginning to be restored in the Long Beach
area but is still sporadic.

Around 2:20 or 2:30 a.m., I was awoken by my clock radio with
three or more sets of soft buzzing noises--as though a radio
station went silent. I checked my cordless phone and had
dialtone, then went back to sleep. Is there any correlation?

matthew black
e-mail postmaster
california state university, long beach

Re: Verizon outage in Southern California?

[Steve Sobol]

Olsen, Jason wrote:

Anyone have more information?  It seems to have started 
around 02:30 local time this morning.


We lost connectivity (WAN/Internet/POTS) to our Long Beach site at
around 2:27 AM PDT today.  Several news agencies are reporting it on the
web (hooray news.google.com), citing "mechanical glitches" or bad
weather.


Bad weather could definitely be a factor.

Southern Cali electric utilities are notoriously unreliable during bad 
weather, especially up in my neck of the woods. It's been raining pretty 
steadily here for the past two days; I drove 150 miles from Apple Valley to 
northeast San Diego this morning and it was even raining down here in SD -- 
may still be raining now, I just haven't looked outside. I even heard a 
radio report that a funnel cloud touched down in the foothills outside Los 
Angeles; I forget exactly where. (That doesn't happen very often around here.)


--
Steve Sobol, Professional Geek   888-480-4638   PGP: 0xE3AE35ED
Company website: http://JustThe.net/
Personal blog, resume, portfolio: http://SteveSobol.com/
E: [EMAIL PROTECTED] Snail: 22674 Motnocab Road, Apple Valley, CA 92307

Re: Scalability issues in the Internet routing system

[vijay gill]

Andre Oppermann wrote:

vijay gill wrote:


Moore's law for CPUs is kaput. Really, Moore's Law is more of an 
observation, than a law. We need to stop fixating on Moore's law for 
the love of god.  It doesn't exist in a vacuum, Components don't get 
on the curve for free.  Each generation requires enormously more 
capital to engineer the improved Si process, innovation, process, 
which only get paid for by increasing demand.   If the demand slows 
down then the investment won't be recovered and the cycle will stop, 
possibly before the physics limits, depending on the amount of demand, 
amount of investment required for the next turn etc.


Predicting the future was a tricky business ten years ago and still is
today.  What makes you think the wheel stops turning today?  Customer
access speed will no increase?  No more improvements in DSL, Cable and
Wireless technologies?  Come on, you're kidding.  Right?


Missing the point. We can deal with increased speeds by going wider, the 
network topology data/control plane isn't going wider, THAT is where the 
moore's observation was targeted at.




Also, no network I know is on the upgrade path at a velocity that they 
are swapping out components in a 18 month window. Ideally, for an 
economically viable network, you want to be on an upgrade cycle that 
lags Moore's observation. Getting routers off your books is not an 18 
month cycle, it is closer to 48 months or even in some cases 60 months.


When you are buying a router today do you specify it to cope with 200k
routes or more?  Planning ahead is essential.



And we're paying for it. But again, assuming that the prefix/memory 
bandwidth churn can be accommodated by the next generation of cpus. I am 
not going to throw out my router in 18 months. Its still on the books.



Then we have the issue of an memory bandwidth to keep the ever 
changing prefixes updated and synced.


Compared to link speed this is nothing.  And nowhere near to memory 
bandwidth.


Each update to and fro from memory takes cycles, and as the routing 
tables become bigger, the frequency of access to the memory for keeping 
the system in sync impose a larger burden. This is orthogonal to link speed.


/vijay

Re: Scalability issues in the Internet routing system

[Andre Oppermann]

Daniel Senie wrote:

[many interesting hw design approaches that you can buy already deleted]

I should point out that none of this really is about scalability of the 
routing system of the Internet, it's all about hardware and software 
design to allow the present system to scale. Looking at completely 
different and more scalable routing would require finding a better way 
to do things than the present BGP approach.


I disagree.  By your description there is no problem scaling the current
model to much bigger numbers of prefixes and paths.  Then why not simply
do it???  Apparently there ain't a problem then?

For routing you have to ways: The BGP (DFZ) way or the aggregation (by
whatever arbitrary level/layer divider de jour) way.  If you have third,
different (not just a modification or merge of partial aspects of the
former two) you may be eglible for a Nobel prize in mathematics in a
few decades.  They run behind a bit, you know...

--
Andre

Re: Scalability issues in the Internet routing system

[Daniel Senie]

At 11:30 AM 10/18/2005, Andre Oppermann wrote:


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.


Moore will keep up reasonably with both the CPU needed to keep BGP 
perking, and with memory requirements for the RIB, as well as other 
non-data-path functions of routers.





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...


Several items regarding FIB lookup:

1) The design of the FIB need not be the same as the RIB. There is 
plenty of room for creativity in router design in this space. 
Specifically, the FIB could be dramatically reduced in size via 
aggregation. The number of egress points (real or virtual) and/or 
policies within a router is likely FAR smaller than the total number 
of routes. It's unclear if any significant effort has been put into this.


2) Nothing says the design of the FIB lookup hardware has to be 
longest match. Other designs are quite possible. Again, some 
creativity in design could go a long way. The end result must match 
that which would be provided by longest-match lookup, but that 
doesn't mean the ASIC/FPGA or general purpose CPUs on the line card 
actually have to implement the mechanism in that fashion.


3) Don't discount novel uses of commodity components. There are fast 
CPU chips available today that may be appropriate to embed on line 
cards with a bit of firmware, and may be a lot more cost effective 
and sufficiently fast compared to custom ASICs of a few years ago. 
The definition of what's hardware and what's software on line cards 
need not be entirely defined by whether the design is executed 
entirely by a hardware engineer or a software engineer.


Finally, don't discount the value and performance of software-based 
routers. MPLS was first "sold" as a way to deal with core routers not 
handling Gigabit links. The idea was to get the edge routers to take 
over. Present CPU technology, especially with good embedded systems 
software design, is quite capable of performing the functions needed 
for edge routers in many circumstances. It may well make sense to 
consider a mix of router types based on port count and speed at edges 
and/or chassis routers with line cards that are using general purpose 
CPUs for forwarding engines instead of ASICs for lower-volume sites. 
If we actually wind up with the core of most backbones running MPLS 
after all, well, we've got the technology so use it. Inter-AS routers 
for backbones, will likely need to continue to be large, power-hungry 
boxes so that policy can be separately applied on the borders.


I should point out that none of this really is about scalability of 
the routing system of the Internet, it's all about hardware and 
software design to allow the present system to scale. Looking at 
completely different and more scalable routing would require finding 
a better way to do things than the present BGP approach.

Re: Scalability issues in the Internet routing system

[Andre Oppermann]

vijay gill wrote:

Andre Oppermann wrote:

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.


Moore's law for CPUs is kaput. Really, Moore's Law is more of an 
observation, than a law. We need to stop fixating on Moore's law for the 
love of god.  It doesn't exist in a vacuum, Components don't get on the 
curve for free.  Each generation requires enormously more capital to 
engineer the improved Si process, innovation, process, which only get 
paid for by increasing demand.   If the demand slows down then the 
investment won't be recovered and the cycle will stop, possibly before 
the physics limits, depending on the amount of demand, amount of 
investment required for the next turn etc.


Predicting the future was a tricky business ten years ago and still is
today.  What makes you think the wheel stops turning today?  Customer
access speed will no increase?  No more improvements in DSL, Cable and
Wireless technologies?  Come on, you're kidding.  Right?

Also, no network I know is on the upgrade path at a velocity that they 
are swapping out components in a 18 month window. Ideally, for an 
economically viable network, you want to be on an upgrade cycle that 
lags Moore's observation. Getting routers off your books is not an 18 
month cycle, it is closer to 48 months or even in some cases 60 months.


When you are buying a router today do you specify it to cope with 200k
routes or more?  Planning ahead is essential.

Then we have the issue of an memory bandwidth to keep the ever changing 
prefixes updated and synced.


Compared to link speed this is nothing.  And nowhere near to memory bandwidth.

--
Andre

Re: Scalability issues in the Internet routing system

[vijay gill]

Andre Oppermann wrote:


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.


Moore's law for CPUs is kaput. Really, Moore's Law is more of an 
observation, than a law. We need to stop fixating on Moore's law for the 
love of god.  It doesn't exist in a vacuum, Components don't get on the 
curve for free.  Each generation requires enormously more capital to 
engineer the improved Si process, innovation, process, which only get 
paid for by increasing demand.   If the demand slows down then the 
investment won't be recovered and the cycle will stop, possibly before 
the physics limits, depending on the amount of demand, amount of 
investment required for the next turn etc.


Also, no network I know is on the upgrade path at a velocity that they 
are swapping out components in a 18 month window. Ideally, for an 
economically viable network, you want to be on an upgrade cycle that 
lags Moore's observation. Getting routers off your books is not an 18 
month cycle, it is closer to 48 months or even in some cases 60 months.


Then we have the issue of an memory bandwidth to keep the ever changing 
prefixes updated and synced.



/vijay

RE: And Now for Something Completely Different (was Re: IPv6 news)

[Church, Chuck]

Nanog,

I've been thinking a bunch about this IPv6 multihoming issue.
It seems that the method of hierarchical summarization will keep the
global tables small for all single-homed end user blocks.  But the
multihomed ones will be the problem.  The possible solution I've been
thinking about is 'adjacency blocks', for lack of a better term.  In
theory, the first customer to home to two different ISPs causes a new
large address block to be advertised upstream by these two ISPs.
Further customers homing to these two ISPs get an allocation out of this
same block.  The two ISPs will only announce the large block.  Of course
there are issues involving failure and scalability...
Failure would involve an ISP losing contact with end customer,
but still announcing the aggregate upstream.  This can be solved by
requiring that two ISPs must have a direct peering agreement, before
they can accept dual-homed customers.  Or a possible method (maybe using
communities?) where ISP B will announce the customer's actual block (the
small one) to it's upstreams, if notified by ISP A that it's not
reachable by them.  When ISP A resumes contact with end customer, ISP B
retracts the smaller prefix.
Scalability is an obvious issue, as the possible number of these
'adjacency blocks' would be N * (N-1), where N is the number of ISPs in
the world.  Obviously pretty large.  But I feel the number of ISPs that
people would actually dual home to (due to reputation, regional
existence, etc) is a few orders of magnitude smaller.  ~100,000 prefixes
(each can be an ASN, I suppose) should cover all needs, doing some
simple math.
The downside is that end customers are going to lose the ability
to prefer traffic from one ISP versus another for inbound traffic.  That
alone might be a show-stopper, not sure how important it is.  Since IPv6
is a whole new ballgame, maybe it's ok to change the rules...
Looking for any thoughts about it.  I'm sure there's things I
haven't considered, but the people I've bounced it off of haven't seen
any obvious problems.  Flame-retardant clothes on, just in case though.


Chuck

>Every multi-homer will be needing their own ASN, so that's what
clutters
>up your routing tables. It's economy there. Btw, a lot of ASNs
advertise
>one network only. People surely think multihoming is important to them
>(and I cannot blame them for that).

>Hierarchical routing is one possible solution, with a lot of drawbacks
>and problems. Forget about geographic hierarchies; there's always
people
>who do not peer. Visibility radius limitation is another (I cannot
believe
>the idea is new, I only don't know what it's called).

Re: Scalability issues in the Internet routing system

[Patrick W. Gilmore]

On Oct 18, 2005, at 12:46 PM, Andre Oppermann wrote:


I'm not talking about BGP here but the actual forwarding on the line
card or wherever it happens for any particular architecture.  The ASIC
thingie.  It has to do longest-match lookups for every packet that  
comes

in to figure out the egres interface.


Depends on the way the FIB is engineered.

--
TTFN,
patrick

LACNIC to start allocating from 189/8 and 190/8

[Ricardo Patara]

This an announcement that LACNIC will start to make allocations from
address space 189.0.0.0/8 and 190.0.0.0/8 on next November 2005.

These blocks were allocated to LACNIC by IANA on last June 2005.

This announcement has the objective to remind you that adjusts to any
filters in place might be needed.

For additional information about blocks under LACNIC administration
and responsibility, please refer to:
http://lacnic.net/en/registro/index.html

Tests have been conducted in order to verify possibles routing
problems and or filters.
The following blocks are being announced:

189.0.0.0/20
189.128.0.0/21
190.0.0.0/20
190.128.0.0/21

Regards

Ricardo Patara
RS Manager
--
L A C N I C
Latin American and Caribbean Internet Addresses Registry

Re: Scalability issues in the Internet routing system - #2

[Andre Oppermann]

Susan Hares wrote:

PS - My answers tend to be brief - glad to expand in private or public.
 Your choice.


Please expand here on the list.  That's very on-topic for NANOG actually.

--
Andre

RE: Scalability issues in the Internet routing system - #2

[Susan Hares]

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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Andre Oppermann
Sent: Tuesday, October 18, 2005 11:31 AM
To: [EMAIL PROTECTED]
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

Re: Scalability issues in the Internet routing system

[Andre Oppermann]

Patrick W. Gilmore wrote:

On Oct 18, 2005, at 11:30 AM, Andre Oppermann wrote:

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...


You are mistaken in one of your assumptions.  The FIB is generated  
asynchronously to packets being forwarded, and usually not even by  the 
same processor (at least for routers "in the core").  Therefore  things 
like pps / link speed are orthogonal to longest match.   (Unless you are 
claiming the number of new prefixes is related to  link speed.  But I 
don't think anyone considers a link which has  nothing but BGP updates 
on it a realistic or useful metric.


I'm not talking about BGP here but the actual forwarding on the line
card or wherever it happens for any particular architecture.  The ASIC
thingie.  It has to do longest-match lookups for every packet that comes
in to figure out the egres interface.

--
Andre

Re: And Now for Something Completely Different (was Re: IPv6 news)

[Elmar K. Bins]

[EMAIL PROTECTED] (David Conrad) wrote:

> I'm suggesting not mucking with the packet format anymore.  It might  
> be ugly, but it can be made to work until somebody comes up with  
> IPv7.  Instead, since the locator/identifier split wasn't done in the  
> protocol, do the split in _operation_.

It has been done a long time ago, IMHO.

I wonder whether I am the only one seeing this, but we already have
a (albeit routing-) locator (ASN) and an identifier (IP address),
that are pretty much distinct and where the routing locator is not
used inside the "local" network, but only outside. There's your
edge/core boundary.

Every multi-homer will be needing their own ASN, so that's what clutters
up your routing tables. It's economy there. Btw, a lot of ASNs advertise
one network only. People surely think multihoming is important to them
(and I cannot blame them for that).

Hierarchical routing is one possible solution, with a lot of drawbacks
and problems. Forget about geographic hierarchies; there's always people
who do not peer. Visibility radius limitation is another (I cannot believe
the idea is new, I only don't know what it's called).

Cheers,
Elmi.

--

"Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren."
  (PLemken, <[EMAIL PROTECTED]>)

--[ ELMI-RIPE ]---

Re: IPv6 news

[John Dupuy]

At 07:36 AM 10/18/2005, Andre Oppermann wrote:
[... items deleted ...]

To summarize the differences between PSTN and Internet routing:


 o  PSTN ports numbers only within regions/area codes
 o  PSTN routes the return path along the forward path (symetric)
 o  PSTN calls have pre-determined characteristics and performance (64kbit)
 o  PSTN has static routing with periodic sync from porting database
 o  PSTN pays the routing table lookup only once when doing call setup
 o  PSTN call forwarding and peering is not free or zero settlement

--
Andre


Largely true; influenced by history and the difference between 
circuit-switched networks and packet-switched networks. LNP is more like 
DNS than multihoming. Sort of. Imagine TCP using domain names rather than 
IP addresses.


I should note however, that in the U.S., Number Portability (LNP) rarely 
uses call forwarding anymore. Except in legacy rural areas, the LNP dip 
occurs before reaching the host office and is thus shunted to the correct 
carrier earlier up in the stream. At minimum it is done by the N+1 switch. 
However, it is common for the IXCs (LD Carriers) and CLECs do it even 
earlier to avoid paying the local ILEC database lookup fees. In that 
scenario, it routes perfectly to the correct carrier.


BTW, telephone networks are generally do not multihome and are very 
fragile. Node (Switch) failure brings down large sections of the network. 
They instead concentrate on 99.99%+ uptime for the switches themselves. In 
other words, they concentrate on internal component redudancy and 
same-destination route redundancy rather than handling an outage of the 
entire switch. The SS7 network has removed some of this fragility, but not 
all. Not by a long shot.


Describing this in a picture:

Internet way: "route around problems"

  A - B - C
   \ /
\-D-/

The Telco way: "try to make problems never happen"

  A--B--C
  A--B--C

Where the AA in the Telco model is essentially the same equipment in the 
same room with redundant components.


Anyway, ... TCP using DNS rather than IP?... Interesting thought.

John 

RE: Verizon outage in Southern California?

[Jay Hennigan]

On Tue, 18 Oct 2005, Hannigan, Martin wrote:

> There was a post here earlier regarding a major outage. Did you lose
> POTS or circuit level connectivity to customers or both?

Frame-relay, SDSL, ADSL.  Straight DS-1 connections are OK.  Not sure
about POTS.

--
Jay Hennigan - CCIE #7880 - Network Administration - [EMAIL PROTECTED]
WestNet:  Connecting you to the planet.  805 884-6323  WB6RDV
NetLojix Communications, Inc.  -  http://www.netlojix.com/

Re: And Now for Something Completely Different (was Re: IPv6 news)

[David Conrad]

Tony,

On Oct 16, 2005, at 1:15 AM, Tony Li wrote:

A real locator/identifier separation requires a rewrite.


Not necessarily.  If you transition at the edge, what happens within  
the site matters only to the site and what matters to the core only  
matters to the core.  No stacks, either core or edge, need to be  
rewritten.


Any system that provided site-wide source address control was going  
to require a rewrite.


Not necessarily (depending on what you mean by the ambiguous term  
"address").  A lot depends on the actual requirements for source  
locator or identifier control.


David, I should point out that if only a small number of folks care  
about multihoming, then only a small number of folks need to change  
their stacks.


I thought all clients would have to be modified if they wanted to  
take full advantage of a shim6 enabled multi-homed server?


And even in your solution, there would need to be some changes to  
the end host if you want to support exit point selection, or carry  
alternate locators in the transport.


One of the problems that I have seen in the IETF is calling desires  
"requirements".  How important is exit point selection?  Are there  
ways of implementing exit point selection without changing the IP  
stack?  How critical is it that alternate locators be carried in the  
transport?  Does the lack of that functionality make the protocol  
unusable?


What _are_ the actual requirements (not the "Goals")?  From my  
perspective, the really, really critical flaw in both IPv4 and IPv6  
is the lack of _transparent_ renumberability.  Multi-homing is also a  
flaw, but less critical and I believe it can be addressed with the  
right solution to renumberability.  A "few" folks worry about multi- 
homing.  Everybody worries about end site renumbering.


It's just a mess.  I think that we all can agree that a real  
locator/identifier split is the correct architectural direction,  
but that's simply not politically tractable.


Right.  And since it couldn't be done the right way in the protocol,  
we make the protocol much more complicated and force a reset to  
address functionality that relatively few folks need.


I'm suggesting not mucking with the packet format anymore.  It might  
be ugly, but it can be made to work until somebody comes up with  
IPv7.  Instead, since the locator/identifier split wasn't done in the  
protocol, do the split in _operation_.  Make the edge/core boundary  
real.  Both edge and core could be addressed without hierarchy, but  
the mapping between the edge and core would change such that the edge  
would never be seen in the DFZ.  Within the core, nothing new or  
different need be done (well, except for deploying IPv6 and running  
the core/edge translators).  Within the edge, nothing new need be  
done either.  Yes, it is a hack.  But I suspect it would address the  
real requirements (or, at least my pet requirement :-)).


Rgds,
-drc

RE: Verizon outage in Southern California?

[Olsen, Jason]

> 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.

We lost connectivity (WAN/Internet/POTS) to our Long Beach site at
around 2:27 AM PDT today.  Several news agencies are reporting it on the
web (hooray news.google.com), citing "mechanical glitches" or bad
weather.  I've also heard rumors of a power outage, though I find those
highly suspect.  Choose your villan, I guess. 

http://www.mercurynews.com/mld/mercurynews/news/local/states/california/
northern_california/12933014.htm
http://www.nbc4.tv/news/5115425/detail.html
http://abclocal.go.com/kabc/story?section=local&id=3546999


Jason "Feren" Olsen  Senior Network Engineer DeVry, Inc
Em: [EMAIL PROTECTED] Ph: 630-645-1607One Tower Lane
INOC-DBA: 19258*526  Fx: 630-389-2929Oakbrook Terrace,
IL 60181

Re: Verizon outage in Southern California?

[Matthew Black]

On Tue, 18 Oct 2005 08:48:50 -0700 (PDT)
 Jay Hennigan <[EMAIL PROTECTED]> wrote:


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.



Yup, the news is true. We have lost outside telephone service
at CSU Long Beach to all but Verizon customers connected to
our local central office. Newspapers are reporting that the
outage began Tuesday around 2:30 a.m. local time and is affecting
a wide area including Long Beach, Huntington Beach, Laguna Beach,
Artesia, Downey, Bellflower and Westminster (not a complete list).

Search for details.



matthew black
california state university, long beach

RE: Verizon outage in Southern California?

[Hannigan, Martin]

> 
> 
> 
> 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<

Re: Scalability issues in the Internet routing system

[Patrick W. Gilmore]

On Oct 18, 2005, at 11:30 AM, Andre Oppermann wrote:


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.


Especially since this does not have to be done in real time.  BGP  
updates can take many seconds to process without end users thinking  
anything is amiss.




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...


You are mistaken in one of your assumptions.  The FIB is generated  
asynchronously to packets being forwarded, and usually not even by  
the same processor (at least for routers "in the core").  Therefore  
things like pps / link speed are orthogonal to longest match.   
(Unless you are claiming the number of new prefixes is related to  
link speed.  But I don't think anyone considers a link which has  
nothing but BGP updates on it a realistic or useful metric.


--
TTFN,
patrick

Verizon outage in Southern California?

[Jay Hennigan]

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 - [EMAIL PROTECTED]
WestNet:  Connecting you to the planet.  805 884-6323  WB6RDV
NetLojix Communications, Inc.  -  http://www.netlojix.com/

Re: IPv6 news

[Andre Oppermann]

Paul Jakma wrote:

On Tue, 18 Oct 2005, Andre Oppermann wrote:
SS7 over IP is quite popular these days.  However call routing != SS7 
message routing.


By call-routing you mean the actual circuit switching of each call? I 
don't mean that, I mean the number routing, which SS7 /does/ do - you 
referred to it as being more analogous to DNS iirc in operation.

>

Nope, it's not.  Can you name a phone prefix routing protocol?


Ehm, SS7 ;).

You might call it DNS-like because it's request based, but it still 
provides routing information.


SS7 is not a routing protocol.  SS7 is a transport stack like what
we refer commonly to as TCP/IP.  There are a number of protocols that
run atop the basic SS7 transport network.  Some protocols are datagram
oriented and some are session oriented.  For call handling ISUP or
derivates are used.  The main difference to the IP world is the limited
scope in the PSTN.  A PSTN switch consults its (static) number routing
table for the trunk to forward the call on.  Then it contacts the switch
at the other end of the tunk and hands over further forwarding to it.
If that doesn't work out the circuit gets shut down backward switch to
switch.  For special numbers like 800 and 900 there is another protocol
called IN (Intelligent Network) which is nothing else than DNS.  Each
special number has a 'real' number in its shadow.  The originating
switch requests the real number through IN and then the normal call
forward happens.  IN may deliver different numbers based on the location
of the orginating switch or daytime or any other criteria you may think
of.  A little bit like Akamai if you wish.

However there is nothing akin BGP or OSPF in the SS7 suite of protocols.
All the forwarding/trunk tables are computed offline for each switch and
then stored on the switches by some bulk data transfer.  Variantions are
emerging with extended IN platforms where you have one more central
databases of forwarding information but that is just a large geographically
distributed switch then.

--
Andre

Puerto Rico Internet Exchange Update..

[Mehmet Akcin]

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 

Re: IPv6 news

[David Conrad]

Michael,

On Oct 17, 2005, at 6:17 AM, [EMAIL PROTECTED] wrote:
Is VJ compression considered a violation of the "end-to-end"  
principle?

VJ compression happens in the middle of the network, between
two routers/gateways. End-to-end refers to the hosts, i.e.
the computers which "host" the end users' applications.


It was a rhetorical question.  My point was that what happens between  
the ends is irrelevant if what gets sent from one end is what is  
received by the other end.  Yes, it is obvious, however I have seen  
people freak out when you suggest touching the address fields,  
regardless of the fact that you say it'll be put back before it hits  
the destination end host.



Theoretically, in a network, a router/gateway could
have some intelligence/state so that it does not simply
forward packets based on destination addresses in the routing
table. Instead it does some kind of query/lookup to identify
the real destination location.


Yes.

All of this is simply hackery to get around a fundamental flaw in the  
Internet Protocol (either v4 or v6) - the lack of locator/identifier  
separation.  My concerns with shim6 aren't that the protocol is  
broken, but rather it is so complex that I fear (a) it will take a  
very long time to implement, (b) it will take much, much longer to  
implement correctly, (c) it will never get fully deployed.  Since I  
see multi-homing/renumbering/mobility (all facets of the same thing)  
as the underlying problem with IPv4, I'm hoping that by addressing  
that problem, IPv6 could actually justify its existence in a business  
sense.  Since non-shim6 enabled stacks are already being deployed, I  
suspect an edge box approach will be the most pragmatic way of  
actually getting something people can use.  Unfortunately, delays in  
deploying some sort of multi-homing/renumbering/mobility solution  
will, I suspect, entrench (single sided) NAT even more than it is  
entrenched today, even on IPv6 sites.  So it goes.


Rgds,
-drc

Scalability issues in the Internet routing system

[Andre Oppermann]

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

RE: IPv6 news

[Hannigan, Martin]

> 
> > 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<

Re: IPv6 news

[Paul Jakma]

On Tue, 18 Oct 2005, Andre Oppermann wrote:


Yea, but only by chance, not by design. ;-)


Nope, by design. Routing would generally be better. The entire area 
would effectively be multihomed to the set of area-ISPs.


There'd be some downsides too, eg where a provider attracting traffic 
for the prefix has some failure internally and for some reason 
doesn't withdraw the area-aggregate to ASes wholly external to the 
area.


regards,
--
Paul Jakma  [EMAIL PROTECTED]   [EMAIL PROTECTED]   Key ID: 64A2FF6A
Fortune:
To give of yourself, you must first know yourself.

Re: IPv6 news

[Andre Oppermann]

Paul Jakma wrote:

On Tue, 18 Oct 2005, Andre Oppermann wrote:

you care whether it is Sprint, Level(3) or Cogent?  Apparently you 
don't.  With your proposed you don't have much/any influence on the 
way your packets take.


They might take much better routes actually than is possible today.


Yea, but only by chance, not by design. ;-)

--
Andre

Re: IPv6 daydreams

[David Conrad]

On Oct 17, 2005, at 10:39 PM, Paul Jakma wrote:
Wrong issue.  What I'm unhappy about is not the size of the  
address - you'll notice that I didn't say "make the whole address  
space smaller."  What I'm unhappy about is the exceedingly sparse  
allocation policies
You can allocate to 100% density on the network identifier if you  
want, right down to /64.


I believe the complaint isn't about what _can be_ done, rather what  
_is being_ done.


The host identifier simply is indivisible, and just happens to be  
64bit.


I've always wondered why they made a single "address" field if the  
IPv6 architects really wanted a hard separation between the host  
identifier and the network identifer.  Making the "address" a  
contiguous set of bits seems to imply that the components of the  
"address" can be variable length.


Rgds,
-drc

Verizon telco outage in LongBeach, CA

[Matthew Black]

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

Re: IPv6 news

[Paul Jakma]

On Tue, 18 Oct 2005, Andre Oppermann wrote:

don't.  With your proposed you don't have much/any influence on the 
way your packets take.


Oh, NB: It's not my proposal at all. I'm merely exploring it. ;)

Further, most of the thinking on this was done by the likes of 
Marcelo Bagnulo, Iljitsch van Beijnum and others. The fact that both 
of them are working on SHIM6 now probably is telling.


regards,
--
Paul Jakma  [EMAIL PROTECTED]   [EMAIL PROTECTED]   Key ID: 64A2FF6A
Fortune:
Yeah.  Maybe I do have the right ... What's that stuff?

-- Homer Simpson
   Deep Space Homer

Re: IPv6 news

[Paul Jakma]

On Tue, 18 Oct 2005, Andre Oppermann wrote:

you care whether it is Sprint, Level(3) or Cogent?  Apparently you 
don't.  With your proposed you don't have much/any influence on the 
way your packets take.


They might take much better routes actually than is possible today.

regards,
--
Paul Jakma  [EMAIL PROTECTED]   [EMAIL PROTECTED]   Key ID: 64A2FF6A
Fortune:
The early worm gets the bird.

Re: IPv6 news

[Paul Jakma]

On Tue, 18 Oct 2005, Andre Oppermann wrote:

Yes, but it's a very cumbersum process.  You have to track this 
stuff for all regions and countries.  They all vary how they do it. 
For example your ComReg publishes a couple of tables now and then 
with new/changed information.  (Look for ComReg 04/35, 03/143R, 
etc.)


Presumably, for IP, we'd use databases and processes more typical to 
normal IP ops, eg RIR databases and such, to record which ISPs can 
service which geo-prefixes. The subscriber_prefix->provider 
information itself can just be dynamically routed locally.


SS7 over IP is quite popular these days.  However call routing != 
SS7 message routing.


By call-routing you mean the actual circuit switching of each call? I 
don't mean that, I mean the number routing, which SS7 /does/ do - you 
referred to it as being more analogous to DNS iirc in operation.


IP routing is not symmetric whereas circuit switching is.  In a 
case of individual IP address portability the return traffic always 
goes back to the ISP who has that particular prefix.  No matter who 
'opened' the connection.  If I port my static dial-up IP to my new 
super FTTH ISP then suddenly up to 100Mbit of return traffic have 
to pass from Dial-Up ISP to FTTH ISP.  I'd say this screws the 
Dial-Up ISP pretty royally.  And you too because he most likely 
doesn't have that much capacity.


Ah, multi-homed. We havn't considered this case yet, but in the 
above, you're a customer of both these ISPs. I'd say the dial-up ISP 
would ask you sharpish to relist your "home" ISP as the FTTH ISP 
while charging you for that 100Mb/s of traffic (as the contract would 
provide for).


The same thing can happen today with multihomed PI customers - what 
would happen today?



Nope, it's not.  Can you name a phone prefix routing protocol?


Ehm, SS7 ;).

You might call it DNS-like because it's request based, but it still 
provides routing information.


However there is no dynamic call routing as we know it from BGP or 
OSPF.  At least not directly.  Some switch vendors have developed 
call optimization software which runs in some sort of central 
intelligence center in the network and tries to optimize the trunk 
usage and priorities based on statistical and historical data.


I meant only the routing information, not the switching (which is 
clearly completely different in packet switched IP).



The stumbling block is that all IP packets return to the prefix
holder (the old ISP) and the end-user bandwidth is not fixed.


See above, what happens today? Multihomed sites can already try screw 
upstreams in this way, so no difference.


$RIR making allocations that way is not sufficient.  It would need 
regulatory backing to enforce IP address portability.


Probably.

Every established carrier is not very interested in porting IP 
addresses to competitors.


Why not, if you can money off it. Two-edged sword too, if you must 
easily port addresses to competitors you can get their customers more 
easily too.


Whether this is the right solution depends on whether ISPs would 
prefer such a mechanism to end-host based solutions. I can't answer 
that question.


regards,
--
Paul Jakma  [EMAIL PROTECTED]   [EMAIL PROTECTED]   Key ID: 64A2FF6A
Fortune:
If you stand on your head, you will get footprints in your hair.

Re: IPv6 news

[Andre Oppermann]

Paul Jakma wrote:


On Tue, 18 Oct 2005, Andre Oppermann wrote:
Traffic flows will just happen there. Forget capacity planning. You'd 
have a hard time finding ISP's interested in that.


Maybe.

Look at it the other way though, it's a business opportunity - you can 
make money by attracting as much area-destined external traffic as 
possible and handing it off to correct intra-area ISP for that 
subscriber. The more the better, it's a potential revenue source. It's 
in your interest to be able to carry all the external traffic into the 
area that you can get.


Do you care from which upstream you get your connectivity from?  Do
you care whether it is Sprint, Level(3) or Cogent?  Apparently you
don't.  With your proposed you don't have much/any influence on the
way your packets take.

--
Andre

Re: IPv6 news

[Andre Oppermann]

[EMAIL PROTECTED] wrote:
Right, cause phone number portability is up and running for several 


sets 

of prefixes in various regions across the world[1], so there's 
definitely nothing we can learn from them. ;)


Well, we can learn from them that circuit switched networks are 
different

than packet switched networks.  Beyond that not much.


I disagree. There are many parallels and in many ways the 
telephony operators are struggling with the same kinds of

problems that we are. NANPA has forecast that the North
American number plan will be exhausted within 20 years.
Just like the IPv4 address space.

Their plan is to extend the number plan by two digits
using 4-digit area codes and 4 digit central office
codes. Rather like IPv6's extended address length.
The new digits will be introduced at the same time
so that everyone will dial an extra digit at the end
of their existing area code, and another extra digit
at the beginning of their central office code. Today
you would dial (703)227-0660 to reach ARIN's help
desk. After the change you would dial (7030)0227-0660.
Full details here:
http://www.atis.org/inc/docs/finaldocs/020107029.doc

NANPA's website points to more information.
http://www.nanpa.com/index.html

There is also a North American Numbering Council 
that meets regularly and has several working groups.

http://www.nanc-chair.org/docs/documents.html

It is foolish to regard people outside the IP
networking industry as inferior. Good ideas can
come from anywhere and we can often understand our
own area of interest much better by comparing and 
contrasting with other similar areas of interest.


There is a major difference between phone numbers and IP addresses
which makes direct comparisons harder.  Phone numbers are more like
Domain names (+email addresses behind them) than IP addresses.  People
use phone numbers the same way they use domain names.  They remember
them and use them to access other people, or companies.  I haven't
seen many billboards with IP addresses on them lately. Nobody cares
about the actual IP address.  Only the computer does at the time of
the DNS lookup.

So an IP address is only used as underlying transport vehicle of
data.  For the enduser it doesn't have any direct significance.

A phone number has significance to the end user and has a hybrid
function as underlying routing element to varying degrees too.

The entire problemset with IP address portability comes from two
issues: Ease of ISP changes and redundant connectivity.  The former
could theoretically be solved with with better procedures and methods
for host address assignment.  However it still requires some labor
intensive transition period and the IP addresses are much tangled with
other things like DNS and so on.  The second issue is IP architecture
specific.  The PSTN, due to its symmetric nature, doesn't have the
redundancy problem to the same extent as the Internet.  For the
IP prefix however you have to participate in the global routing
system to survive link losses.  Without any shim6 or SCTP stuff
that is.

Again, phone numbers and their portability can and should not be
compared with the IP address portability issues.  They're very
different animals.

--
Andre

Re: IPv6 news

[Paul Jakma]

On Tue, 18 Oct 2005, Andre Oppermann wrote:


Again, this fails with the asymmetric nature of IP routing.


The assymetric nature is plus-point. It means the traffic out of the 
area goes out via the "correct" provider (ie the one whose customer 
it is).


On top it fails on bandwidth issues.  What if super-cheap pron 
hoster X is in that area doing streaming full-res HDTV to it's 
suckers?


It goes via the ISP(s) which "super cheap hoster X" pays for transit.

I bet some participants in your service area face some serious link 
saturation issues.  None of the participants have any control or 
estimates over the traffic that is and will be passing through 
them.


Yep.

Traffic flows will just happen there. Forget capacity planning. 
You'd have a hard time finding ISP's interested in that.


Maybe.

Look at it the other way though, it's a business opportunity - you 
can make money by attracting as much area-destined external traffic 
as possible and handing it off to correct intra-area ISP for that 
subscriber. The more the better, it's a potential revenue source. 
It's in your interest to be able to carry all the external traffic 
into the area that you can get.


regards,
--
Paul Jakma  [EMAIL PROTECTED]   [EMAIL PROTECTED]   Key ID: 64A2FF6A
Fortune:
Profanity is the one language all programmers know best.

Re: And Now for Something Completely Different (was Re: IPv6 news)

[Michael . Dillon]

> this because padlipsky's mantra about maps and territories came into my 
head

S.I. Hayakawa - Language and Thought in Action
   "The symbol is not the thing the thing symbolized;
The map is not the territory: The word is not 
the thing."

Nevertheless, Padlipsky is a good thing to read. Here
is the book review from the Cisco IP Journal with a 
taste of the book.
http://www.cisco.com/en/US/about/ac123/ac147/ac174/ac179/about_cisco_ipj_archive_article09186a00800e55d2.html

--Michael Dillon

RE: IPv6 news

[Hannigan, Martin]

> 
> 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<

Re: IPv6 news

[Michael . Dillon]

> 1. Does the US have number portability anywhere? If so, that would be 
> a /huge/ region, and very interesting to examine to see how they 
> manage it.

In the USA this is called LNP (Local Number Portability).

This article has a couple of pages of history and then
a technical overview of how LNP works.
http://scholar.lib.vt.edu/ejournals/JOTS/Winter-Spring-2001/pdf/obermier.pdf

This document explains the architecture of LNP in
today's phone network:
http://www.verisign.com/stellent/groups/public/documents/white_paper/001950.pdf

However, LNP is not as simple as most laypeople think.
It has other applications than simply consumer 
convenience. For instance, disaster recovery
http://www.neustar.com/pressroom/datasheets/DisasterRecPress.pdf

Read this description of number pooling
http://www.verisign.com/stellent/groups/public/documents/white_paper/001949.pdf
and reflect on how similar this seems to injecting
longer prefixes into BGP (hole punching) to support
moving a customer from another network.

LNP and routing are the same problem. The details of
the solutions differ because the technology environment
and constraints differ. But you will never understand
IP routing unless you understand how non-IP networks
solve these same problems. That's why some people use
RIP to teach routing even though it is considered bad
practice to run RIP on any network in this day and age.
People need to learn routing theory separately
from "How to configure BGP on your brand-X boxes".

--Michael Dillon

Re: IPv6 news

[Andre Oppermann]

Paul Jakma wrote:

On Tue, 18 Oct 2005, Paul Jakma wrote:

If you want to focus on the differences between IP and POTS/GSM, sure, 
they're completely different. However, the point is to examine the 
abstract model for how telcos manage to achieve number portability 
without global-scope exchange of subscriber information and see what, 
if any, techniques could apply to IP.


Eg, given some arbitrary area:

- RIR assigns a prefix to that area

- For that area, for the set of ISPs providing service in that
  area (the area-ISP set) which are all peered with each other (eg at 
some IX in or near the area

  concerned), each ISP:
- announces the area prefix as far and wide as they can
  (doing so will be an advantage for settlement with the
   other area-ISP set ISPs)
- exchanges very very specific routes of:

area-site -> AS

  with the other area-ISP set ISPs (if they peer locally,
  they can keep these very specific routes local too)

- keep track of how much traffic to the area-prefix is handed
  off to other area-ISP set ISPs (and to which, obviously),
  and how much is received.

- periodically, for every other area-ISP, reconcile traffic
  handed off / received and either send your or wait for
  their invoice as appropriate.

Fraught with some difficulties obviously. (Politics of settlement, 
particularly when there is no benevolant entity to arbitrate and/or 
impose - before you ever get to the question of how to define an "area").


If it seems too difficult and the status quo is preferred - no worries, 
the hosts will figure out some kind of indirection. Bit less efficient 
than if ISPs would route natively/locally, but hey it won't require any 
difficult decisions and co-ordination in the ISP community.


And maybe that'd be for the best. ;)


Again, this fails with the asymmetric nature of IP routing.  On top it
fails on bandwidth issues.  What if super-cheap pron hoster X is in that
area doing streaming full-res HDTV to it's suckers?  I bet some participants
in your service area face some serious link saturation issues.  None of
the participants have any control or estimates over the traffic that is
and will be passing through them.  Traffic flows will just happen there.
Forget capacity planning.  You'd have a hard time finding ISP's interested
in that.

--
Andre

Re: IPv6 news

[Michael . Dillon]

> > Right, cause phone number portability is up and running for several 
sets 
> > of prefixes in various regions across the world[1], so there's 
> > definitely nothing we can learn from them. ;)
> 
> Well, we can learn from them that circuit switched networks are 
different
> than packet switched networks.  Beyond that not much.

I disagree. There are many parallels and in many ways the 
telephony operators are struggling with the same kinds of
problems that we are. NANPA has forecast that the North
American number plan will be exhausted within 20 years.
Just like the IPv4 address space.

Their plan is to extend the number plan by two digits
using 4-digit area codes and 4 digit central office
codes. Rather like IPv6's extended address length.
The new digits will be introduced at the same time
so that everyone will dial an extra digit at the end
of their existing area code, and another extra digit
at the beginning of their central office code. Today
you would dial (703)227-0660 to reach ARIN's help
desk. After the change you would dial (7030)0227-0660.
Full details here:
http://www.atis.org/inc/docs/finaldocs/020107029.doc

NANPA's website points to more information.
http://www.nanpa.com/index.html

There is also a North American Numbering Council 
that meets regularly and has several working groups.
http://www.nanc-chair.org/docs/documents.html

It is foolish to regard people outside the IP
networking industry as inferior. Good ideas can
come from anywhere and we can often understand our
own area of interest much better by comparing and 
contrasting with other similar areas of interest.

--Michael Dillon

Re: IPv6 news

[Andre Oppermann]

Paul Jakma wrote:

On Tue, 18 Oct 2005, Andre Oppermann wrote:

As we know from the Internet DFZ the routing table becomes very large.


However, it can be confined to that arbitrary area.


Yes, but it's a very cumbersum process.  You have to track this stuff
for all regions and countries.  They all vary how they do it.  For
example your ComReg publishes a couple of tables now and then with
new/changed information.  (Look for ComReg 04/35, 03/143R, etc.)

You can forget that X.25 stuff.  It's only used for SS7 message 
routing and doesn't have anything to do with call routing as such.


Ah, it was used for everything in that network actually - but that was a 
very very specialised telco network. (And they had started moving to IP 
when I last worked with them.)


SS7 over IP is quite popular these days.  However call routing != SS7
message routing.

Sure.  However this is the main difference between the TDM network and 
the Internet.  Due to this fact many things work on the phone network 
like carrier pre-selection, phone number portability, etc., that do 
not work on an IP network.


I'm not source how assymetric paths affect portability etc. Also, IP is 
well capable of that, and makes life easier.


IP routing is not symmetric whereas circuit switching is.  In a case
of individual IP address portability the return traffic always goes
back to the ISP who has that particular prefix.  No matter who 'opened'
the connection.  If I port my static dial-up IP to my new super FTTH
ISP then suddenly up to 100Mbit of return traffic have to pass from
Dial-Up ISP to FTTH ISP.  I'd say this screws the Dial-Up ISP pretty
royally.  And you too because he most likely doesn't have that much
capacity.


On the phone network the prefix information is not dynamically exchanged.


Uhm, sure it is.


Nope, it's not.  Can you name a phone prefix routing protocol?

There are number portability registries whose data you can download 
every night or so and then dump it into your own switch or IN platform.


The number portability registries can be updated infrequently, yes.

The telco prefix routing information however most definitely *is* routed 
dynamically. Maybe you don't have to participate in this routing (your 
not a telco?), but between the telcos - most definitely ;).


(If not, we were scammed for a fortune for dynamically routed redundancy 
of calls across a set of exchanges ;) ).


That works differently.  In the PSTN you always have multiple routes
to a destination.  If you have a direct trunk between two CO's then
it will fill that first.  When the direct trunk is full, the local
switch has got an overflow route towards a neighboring or higher
switch.  It can have multiple overflow routes with different priorities.
You can replace full trunk with dead trunk to get your redundancy.

However there is no dynamic call routing as we know it from BGP or
OSPF.  At least not directly.  Some switch vendors have developed
call optimization software which runs in some sort of central intelligence
center in the network and tries to optimize the trunk usage and priorities
based on statistical and historical data.


2a. The providers within the area have to figure out how to bill for
the difference of this traffic.


No.  Usually the tariff is set by the regulator based on some fixed
interconnection charge and network element usage.


How they figure it out (with or without a regulator) doesn't matter. It 
just has to be figured out. We don't have IP regulators, so for IP 
providers would have to figure it out all by themselves obviously. ;)


That'd be the stumbling block I suspect.


The stumbling block is that all IP packets return to the prefix
holder (the old ISP) and the end-user bandwidth is not fixed.


To summarize the differences between PSTN and Internet routing:

o  PSTN ports numbers only within regions/area codes


We're discussing what would be possible with area (rather than provider) 
assigned IP addresses. Ie, this is as possible for IP as PSTN, if $RIR 
decides to make some allocations in this way.


$RIR making allocations that way is not sufficient.  It would need
regulatory backing to enforce IP address portability.  Every established
carrier is not very interested in porting IP addresses to competitors.


o  PSTN routes the return path along the forward path (symetric)


I thought you said it didn't? No matter, IP is assymmetric.


IP is asymmetric and PSTN is symmetric.  There you have the first
major problem with IP in this szenario.

o  PSTN calls have pre-determined characteristics and performance 
(64kbit)


No bearing on routing.


Very much so.  See my Dial-Up vs. FTTH ISP example.


o  PSTN has static routing with periodic sync from porting database


The important point is that information to describe number->provider is 
exchanged betweeen providers in the area only. Whether it's done by 
dynamic protocols, email or post is an irrelevant detail, all that 
matters is that we have a way to d

Re: IPv6 news

[Paul Jakma]

On Tue, 18 Oct 2005, Paul Jakma wrote:

If you want to focus on the differences between IP and POTS/GSM, sure, 
they're completely different. However, the point is to examine the abstract 
model for how telcos manage to achieve number portability without 
global-scope exchange of subscriber information and see what, if any, 
techniques could apply to IP.


Eg, given some arbitrary area:

- RIR assigns a prefix to that area

- For that area, for the set of ISPs providing service in that
  area (the area-ISP set) which are all peered with each other (eg at some IX 
in or near the area
  concerned), each ISP:
- announces the area prefix as far and wide as they can
  (doing so will be an advantage for settlement with the
   other area-ISP set ISPs)
- exchanges very very specific routes of:

area-site -> AS

  with the other area-ISP set ISPs (if they peer locally,
  they can keep these very specific routes local too)

- keep track of how much traffic to the area-prefix is handed
  off to other area-ISP set ISPs (and to which, obviously),
  and how much is received.

- periodically, for every other area-ISP, reconcile traffic
  handed off / received and either send your or wait for
  their invoice as appropriate.

Fraught with some difficulties obviously. (Politics of settlement, 
particularly when there is no benevolant entity to arbitrate and/or 
impose - before you ever get to the question of how to define an 
"area").


If it seems too difficult and the status quo is preferred - no 
worries, the hosts will figure out some kind of indirection. Bit less 
efficient than if ISPs would route natively/locally, but hey it won't 
require any difficult decisions and co-ordination in the ISP 
community.


And maybe that'd be for the best. ;)

regards,
--
Paul Jakma  [EMAIL PROTECTED]   [EMAIL PROTECTED]   Key ID: 64A2FF6A
Fortune:
Nowlan's Theory:
He who hesitates is not only lost, but several miles from
the next freeway exit.

Re: IPv6 news

[Marshall Eubanks]

On Tue, 18 Oct 2005 10:49:36 +0100
 [EMAIL PROTECTED] wrote:
> 
> > I reread this and still don't see how geographical ip address allocation
> > is going to work if typical customer connections are network-centric
> > and any large area has number of competitive access providers 
> 
> Inside the city, you see lots of longer prefixes from that city's
> netblock. Outside the city you see only the single aggregate prefix.

> 
> > The only way I see that geographical addressing might have some 
> advantage 
> > is if the area is covered by large monopoly that connects everyone else 
> > there 
> 
> Monopoly? Not necessary. Yes, you need to have universal exchange
> of local traffic in the city but that can happen through private
> interconnects and multiple exchange points. No need for a monopoly.
> The major change is that providers which participate in geotopological
> addressing would have to interconnect with *ALL* other such providers
> in that city. This would mean more use of public exchange points.
> 
> Also, I think it makes sense to have a second regional layer
> of aggregation where you group neighboring cities that have
> a lot of traffic with each other. I think this would result
> in no more than 20-30 regions per continent.
> 
> --Michael Dillon
> 

I  think that levels of  multi-homing are likely to develop for small entities :

Multi-homing-0 : You  have two or more connnections, but no real sharing of 
information between
them. (I have this now at home, with a Cable modem and dial up for backup. They 
always appear to the
outside as two disjoint networks, and in fact never overlap in time.) I would 
argue that the vast
majority of residences and small offices are are likely to fall into this 
category; the goal is
really internal failover from the  preferred provider to the secondary, with 
automatic renumbering
courtesy of DHCP.

Multi-homing-1 : You have two or more connections, but can do no traffic 
engineering, and have to
assume an equal preference for each connection. Say there is some sort of 
geographical or
topological prefix. From the outside, they could  all be viewed as "belonging" 
to some preferred
carrier, or to a local exchange point, or a protocol could be created to do 
some sort of topogolocal
or geographical provider discovery. It seems to  me that this means accepting 
some sort of hot
potato routing, and  also some interaction between providers. (The routing 
would go something like,
this is a packet for Clifton, VA; Cox and Verizon cover Clifton Virginia; pick 
one of these and give
it to them and let them worry about the details.) Of course, this scheme  it 
would be highly likely
in such a scheme that outbound and inbound traffic for the same flow could use 
different providers.

Multi-homing-2 : What we would now consider as multi-homing, with  full control 
and full BGP.

Why would you want Multi-homing-1 ? Well, it should be cheaper than MH-2, with 
no user
administration but you should still get some 
load balancing and also fast failover if a circuit goes down. That would more 
than meet the needs of
most home offices. If BGP table growth is an issue, I think that some  sort of 
MH-1 is inevitable. I
think that inevitably means some  sort of 
geographical or topological based prefix, less-than-optimal routing for at 
least some packets, and
much less user control compared to MH-2.   Regional exchanges might be nice, 
but are not necessary.


Regards
Marshall  Eubanks

Re: And Now for Something Completely Different (was Re: IPv6 news)

[Paul Vixie]

# >> True enough, but unfortunately, it's not done in a way that we can make
# >> use of the identifier in the routing subsystem or in the transport
# >> protocols.
# >
# > The transport protocols, well they generally act on behalf of something
# > which can do the lookup and supply transport with right address, as long
# > the DNS server does not require "who"->"where" indirection ;).
# 
# The transport protocols unfortunately need the identifier in the packet to
# demux connections.

the idea of a "transport protocol" comes from the OSI Reference Model which
might not be the best conceptual fabric for re-thinking Internet routing.  we
know it's a "distributed system" and we know that various waypoints will or
will not have "state", but i don't think we know that there will always be a
"layer" that does what the "transport protocol" does in the OSIRM.  i mention
this because padlipsky's mantra about maps and territories came into my head
just now as i was listening to folks talk about what the "transport protocol"
had to have or had to provide.  there's only a "transport protocol" if we
decide to keep thinking in ISORM terms.

and with that, i do indeed wonder if this has stopped being operational and
if so, whether nanog wants to overlap THIS much with the irtf?

refs:

http://www.amazon.com/exec/obidos/tg/detail/-/0132681110/103-3252601-1266225

Re: IPv6 news

[Paul Jakma]

On Tue, 18 Oct 2005, Andre Oppermann wrote:

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.


Ah, yes, that I know.

I thought maybe you were referring to number -> GSM SIM IMSI mapping 
within a telco, or whatever is the equivalent for fixed-line. (How 
roaming is done is really interesting btw).




said default carrier.  On top of this forwarding doesn't come for 
free.


Of course not.

the call routing tables on my switches with that registry.  In a 
very competitive area this lead to 30-50% of all numbers being 
ported and thus showing up in my routing table.


Yep. Any geographic solution must consider that disaggregation will 
always tend towards 100%.


As we know from the Internet DFZ the routing table becomes very 
large.


However, it can be confined to that arbitrary area.

That's why number portability is normally only offered within the 
same area code or region.  So you can't take your NY fixed line 
phone number to LA.  Unless of course you have someone picking up 
the call in NY and transporting it to you in LA.


Yep, obviously ;).

You can forget that X.25 stuff.  It's only used for SS7 message 
routing and doesn't have anything to do with call routing as such.


Ah, it was used for everything in that network actually - but that 
was a very very specialised telco network. (And they had started 
moving to IP when I last worked with them.)


Outgoing are not affected because the TDM network always sets up parallel 
in/out path's. The return channel for your outgoing call doesn't come back 
through your former mobile operator.


Sure.  However this is the main difference between the TDM network 
and the Internet.  Due to this fact many things work on the phone 
network like carrier pre-selection, phone number portability, etc., 
that do not work on an IP network.


I'm not source how assymetric paths affect portability etc. Also, IP 
is well capable of that, and makes life easier.


On the phone network the prefix information is not dynamically 
exchanged.


Uhm, sure it is.

There are number portability registries whose data you can download 
every night or so and then dump it into your own switch or IN 
platform.


The number portability registries can be updated infrequently, yes.

The telco prefix routing information however most definitely *is* 
routed dynamically. Maybe you don't have to participate in this 
routing (your not a telco?), but between the telcos - most definitely 
;).


(If not, we were scammed for a fortune for dynamically routed 
redundancy of calls across a set of exchanges ;) ).



2. Providers must be prepared to carry other providers traffic into
   the area


Only one of them.  The 'default' carrier.  There are many phone networks
and carriers carrier who do not have 100% coverage.


Let me restate that:

2. One or more providers must be prepared to carry any
   providers traffic into the area

Same thing.

The incentive for providers to announce such an area-prefix to as 
many other providers outside of the area as possible would be to 
reduce settlement fees within the area for the smaller providers, and 
for the big ones -> make money.



2a. The providers within the area have to figure out how to bill for
the difference of this traffic.


No.  Usually the tariff is set by the regulator based on some fixed
interconnection charge and network element usage.


How they figure it out (with or without a regulator) doesn't matter. 
It just has to be figured out. We don't have IP regulators, so for IP 
providers would have to figure it out all by themselves obviously. ;)


That'd be the stumbling block I suspect.

Well, we can learn from them that circuit switched networks are 
different than packet switched networks.  Beyond that not much.


If you want to focus on the differences between IP and POTS/GSM, 
sure, they're completely different. However, the point is to examine 
the abstract model for how telcos manage to achieve number 
portability without global-scope exchange of subscriber information 
and see what, if any, techniques could apply to IP.



To summarize the differences between PSTN and Internet routing:

o  PSTN ports numbers only within regions/area codes


We're discussing what would be possible with area (rather than 
provider) assigned IP addresses. Ie, this is as possible for IP as 
PSTN, if $RIR decides to make some allocations in this way.



o  PSTN routes the return path along the forward path (symetric)


I thought you said it didn't? No matter, IP is assymmetric.


o  PSTN calls have pre-determined characteristics and performance (64kbit)


No bearing on routing.


o  PSTN has static routing with periodic sync from porting database


The important point is that information to describe number->provider 
is exchanged betweeen providers in the a

Re: IPv6 news

[Andre Oppermann]

Paul Jakma wrote:

On Tue, 18 Oct 2005, Andre Oppermann wrote:
On a local level however it's not more than a DNS name mapping to some 
real on-net identifier.


Within a telco?


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.

For every area code there is a 'default' carrier.  Usually this is
the incumbant.  They've got the obligation to forward inbound calls
to the true carrier of that particular number holder.  However this
only works if the target carrier has some kind of interconnect with
said default carrier.  On top of this forwarding doesn't come for
free.  Depending on my call volume with that area I have to look into
direct termination of ported numbers.  Usually the regulator or some
party designated by the regulator runs a number portability registry
with the true carrier information for every number.  If I want to
optimize my call routing I have to periodically synchronize the call
routing tables on my switches with that registry.  In a very competitive
area this lead to 30-50% of all numbers being ported and thus showing
up in my routing table.  As we know from the Internet DFZ the routing
table becomes very large.  Fortunatly for the TDM network I have to
do the routing table lookup only once when setting up the call, not
for every voice sample.  Thus I pay the lookup cost only once for
x minutes of voice traffic.  Very DNS like.  And because of the area
code hierarchy even more so.

That's why number portability is normally only offered within the same
area code or region.  So you can't take your NY fixed line phone number
to LA.  Unless of course you have someone picking up the call in NY and
transporting it to you in LA.

For non-US mobile networks the number portability works the same.  The
mobile network(s) have got their own area codes.

There's a myriad of ways to do it afaict. The case I know best though 
involved calls inbound to an operator specific prefix (there are a set 
of 4 or so major telco peering exchanges in Ireland, where the domestic 
and transit telcos /must/ be avilable for peering). The operator used 
custom software to map specific numbers to X.25 "addresses" (I forget 
the exact X.25 jargon) on their own network to deliver the calls to 
various locations on our network.


You can forget that X.25 stuff.  It's only used for SS7 message routing
and doesn't have anything to do with call routing as such.

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.

Outgoing are not affected because the TDM network always sets up 
parallel in/out path's. The return channel for your outgoing call 
doesn't come back through your former mobile operator.


I didn't know that, but sounds exactly what you want.


Sure.  However this is the main difference between the TDM network
and the Internet.  Due to this fact many things work on the phone
network like carrier pre-selection, phone number portability, etc.,
that do not work on an IP network.

Now compare this to the Internet and IP routing.  See some little 
differences and diffculties here and there?  Yea, I thought so.


There are huge differences in the details, obviously. The basic concepts 
though are at least interesting to consider, if not directly applicable 
to IP (technically at least - operationally/politically is another 
question):


1. Providers servicing these prefixes must peer and exchange the
   prefix information


On the phone network the prefix information is not dynamically exchanged.
There are number portability registries whose data you can download
every night or so and then dump it into your own switch or IN platform.


2. Providers must be prepared to carry other providers traffic into
   the area


Only one of them.  The 'default' carrier.  There are many phone networks
and carriers carrier who do not have 100% coverage.


2a. The providers within the area have to figure out how to bill for
the difference of this traffic.


No.  Usually the tariff is set by the regulator based on some fixed
interconnection charge and network element usage.

Conclusion: Applying the phone number portability to the Internet is 
broken by design.


Right, cause phone number portability is up and running for several sets 
of prefixes in various regions across the world[1], so there's 
definitely nothing we can learn from them. ;)


Well, we can learn from them that circuit switched networks are different
than packet switched networks.  Beyond that not much.

1. Does the US have number portability anywhere? If so, that would be a 
/huge/ region, and very interesting to examine to see how they manage it.


See above for an explanation.

To summarize the differen

Re: IPv6 news

[Paul Jakma]

On Tue, 18 Oct 2005, Andre Oppermann wrote:


We don't want them involved in Internet routing, do we?


Which, POTS telco's or ComReg? :) The latter does a good job afaict.


Do you have any idea how this works internally?  Apparently not.


I have had telco people vaguely explain some of the issues and 
abstracts of SS7 signalling involved in calls they were handling for 
"me" to me.


Phone numbers are an interesting species.  On a global level they 
are used for call routing.


Yep.

On a local level however it's not more than a DNS name mapping to 
some real on-net identifier.


Within a telco?

There's a myriad of ways to do it afaict. The case I know best though 
involved calls inbound to an operator specific prefix (there are a 
set of 4 or so major telco peering exchanges in Ireland, where the 
domestic and transit telcos /must/ be avilable for peering). The 
operator used custom software to map specific numbers to X.25 
"addresses" (I forget the exact X.25 jargon) on their own network to 
deliver the calls to various locations on our network.


Unfortunatly anyone calling your ported mobile number from outside 
the mobile networks ends up with the number range holder (you 
former number range holder)


The operator's prefix, yes.

who in turn has to forward the call to your current mobile 
operator.


Yep.

Outgoing are not affected because the TDM network always sets up 
parallel in/out path's. The return channel for your outgoing call 
doesn't come back through your former mobile operator.


I didn't know that, but sounds exactly what you want.

Now compare this to the Internet and IP routing.  See some little 
differences and diffculties here and there?  Yea, I thought so.


There are huge differences in the details, obviously. The basic 
concepts though are at least interesting to consider, if not directly 
applicable to IP (technically at least - operationally/politically is 
another question):


1. Providers servicing these prefixes must peer and exchange the
   prefix information

2. Providers must be prepared to carry other providers traffic into
   the area

2a. The providers within the area have to figure out how to bill for
the difference of this traffic.

Conclusion: Applying the phone number portability to the Internet 
is broken by design.


Right, cause phone number portability is up and running for several 
sets of prefixes in various regions across the world[1], so there's 
definitely nothing we can learn from them. ;)


1. Does the US have number portability anywhere? If so, that would be 
a /huge/ region, and very interesting to examine to see how they 
manage it.


regards,
--
Paul Jakma  [EMAIL PROTECTED]   [EMAIL PROTECTED]   Key ID: 64A2FF6A
Fortune:
"Plan to throw one away.  You will anyway."
- Fred Brooks, "The Mythical Man Month"

Re: IPv6 news

[Andre Oppermann]

Paul Jakma wrote:

On Mon, 17 Oct 2005, Andre Oppermann wrote:

We all know how well carrier phone number routing and number 
portability works, don't we?


EWORKSFORME (and everyone else here). Took a good bit of very firm 
pressure from ComReg, the telecoms wathdog/regulator here, to overcome 
negative reaction from the operators though.


We don't want them involved in Internet routing, do we?

(There's no such pressure which could be applied on IP operators, but 
same processes essentially could be applied at least for IP connectivity 
at national regulatory levels at least - trade /32's at INEX, the IX 
here and figure out billing. If only ComReg had the authority.. ;) ).


Do you have any idea how this works internally?  Apparently not.
Phone numbers are an interesting species.  On a global level they
are used for call routing.  On a local level however it's not more
than a DNS name mapping to some real on-net identifier.  Unfortunatly
anyone calling your ported mobile number from outside the mobile
networks ends up with the number range holder (you former number
range holder) who in turn has to forward the call to your current
mobile operator.   On a TDM network this works pretty OK as the
quality parameters are standardized and fixed (64kbit transparent
voice channel, call capacity, etc).  Outgoing are not affected
because the TDM network always sets up parallel in/out path's.
The return channel for your outgoing call doesn't come back
through your former mobile operator.

Now compare this to the Internet and IP routing.  See some little
differences and diffculties here and there?  Yea, I thought so.

Conclusion: Applying the phone number portability to the Internet
is broken by design.

--
Andre

Re: IPv6 news

[Michael . Dillon]

> I reread this and still don't see how geographical ip address allocation
> is going to work if typical customer connections are network-centric
> and any large area has number of competitive access providers 

Inside the city, you see lots of longer prefixes from that city's
netblock. Outside the city you see only the single aggregate prefix.

> The only way I see that geographical addressing might have some 
advantage 
> is if the area is covered by large monopoly that connects everyone else 
> there 

Monopoly? Not necessary. Yes, you need to have universal exchange
of local traffic in the city but that can happen through private
interconnects and multiple exchange points. No need for a monopoly.
The major change is that providers which participate in geotopological
addressing would have to interconnect with *ALL* other such providers
in that city. This would mean more use of public exchange points.

Also, I think it makes sense to have a second regional layer
of aggregation where you group neighboring cities that have
a lot of traffic with each other. I think this would result
in no more than 20-30 regions per continent.

--Michael Dillon

Re: IPv6 news

[Paul Jakma]

On Tue, 18 Oct 2005, william(at)elan.net wrote:

I reread this and still don't see how geographical ip address 
allocation is going to work if typical customer connections are 
network-centric


That's a "today's operator" view of customers though. Many customers 
view their network as being situated in one or more fixed geographic 
locations (not in terms of which provider gives them transit), which 
rarely change.


("Road warriors" just connect to HQ or their home site via VPN or 
whatever).


and any large area has number of competitive access providers 
(unless you're fine with multiple providers announcing aggregate 
summary in anycast fashion).


Yep, they'd have to. They'd also have to figure out the billing side 
of it for any traffic differentials.


Essentially, when seen globally - the providers would service the 
geographic /area/, not the customers.


When seen within this arbitrary area, you'd see routes for each 
customer and to which exact provider they'd have to go.


Would also encourage peering generally to occur as close as possible 
to the arbitrary areas as possible, one suspects (so the providers 
own routing table wouldn't have to carry the "detail" further than 
needed).


regards,
--
Paul Jakma  [EMAIL PROTECTED]   [EMAIL PROTECTED]   Key ID: 64A2FF6A
Fortune:
Between grand theft and a legal fee, there only stands a law degree.

Re: And Now for Something Completely Different (was Re: IPv6 news)

[Michael . Dillon]

> E.g prevously
> announced address-blocks that has disappeared from the global
> routing-table for more than X months should go back to the RIR-pool
> (X<=6).

In RFC 2050 section 3 a)
   the organization has no intention of connecting to
   the Internet-either now or in the future-but it still
   requires a globally unique IP address.  The organization
   should consider using reserved addresses from RFC1918.
   If it is determined this is not possible, they can be
   issued unique (if not Internet routable) IP addresses.

Seems to me that the Internet routing table contents
past and present are irrelevant. Note also that the 
so-called Internet routing table contents vary depending
on where you look at it. 

In any case, at the ARIN meeting in LA there will be
an Open Policy Hour for people to suggest things that 
the RIRs should do. More info here:
http://www.arin.net/ARIN-XVI/agenda/tuesday.html#policy

--Michael Dillon

Re: And Now for Something Completely Different (was Re: IPv6 news)

[Michael . Dillon]

> > check out "The Landmark Hierarchy: A New Hierarchy for Routing in Very 
Large
> > Networks"; Paul Tsuchiya; 1989.
> 
>great stuff... i have a hardcopy. is it online yet?

Just google for "landmark routing" and you will find lots
of papers and presentations that deal with the topic.

If OSPF area boundaries were more fluid, rather like
the period covered by a moving average... Of course,
this might not be so nice if it was done across 
AS boundaries.

--Michael Dillon

Re: IPv6 news

[william(at)elan.net]

I reread this and still don't see how geographical ip address allocation
is going to work if typical customer connections are network-centric
and any large area has number of competitive access providers (unless
you're fine with multiple providers announcing aggregate summary in
anycast fashion).

The only way I see that geographical addressing might have some advantage 
is if the area is covered by large monopoly that connects everyone else 
there (and its not to say that such situation does not exist in some 
countries, but I don't think this situation should be encouraged and 
forced to continue forever with network allocation policies).


On Tue, 18 Oct 2005 [EMAIL PROTECTED] wrote:


Here, the suggestion is that netblocks should
be allocated to cities, not to providers. Within


I am a multihomed customer and my ISPs are in two different cities. What
are my IP addresses going to be?


Your assumptions are flawed. I never suggested that there
would be a flag day. I never suggested that geotopological
addressing would work everywhere or solve all problems. I never
suggested that we should turn off the existing provider aggregatable
IP address allocations.

I just suggested an alternative way of issuing addresses so
that they are geotopologically aggregatable, not provider aggregatable.
There are sufficient reserved addresses in the IPv6 address space
to do this. We could start issuing geotopological netblocks and
try it for 5 years or so to see whether it works better or not.

In any case, you are located in Montreal which is such a major
city that I expect any ISP selling service (geotopologically) in
Montreal would use Montreal address space even if they backhauled
at layer two to some other city.

However, there will likely be lots of situations where people
in small towns roughly equidistant from two cities will choose
to multihome with links to separate cities. This will either have
to be done using provider-aggregated addresses or by using
addresses from one of the cities with a longer prefix inside
that city's routing table to direct the traffic to the
neighboring city. If this is suboptimal, it won't be by much
considering that these are neighboring cities.

I'm not suggesting any change to IPv6 stacks or to routing
protocols. I'm just suggesting that we could allocate the same
IPv6 addresses to operators in a way that allows geotopological
aggregation rather than the existing provider aggregation.
Combine this with local traffic exchange in every city and
you have a more robust Internet with lower overall latency
that will run with a smaller global routing table.

I know that some individual operators, such as the one
I work for, have very robust IP networks with low overall
latency. But when we talk about the Internet, then we include
all the private interconnects and public exchange points
and tromboning of traffic due to peering "issues", etc.

--Michael Dillon


--
William Leibzon
Elan Networks
[EMAIL PROTECTED]

Re: IPv6 news

[Michael . Dillon]

> > Here, the suggestion is that netblocks should
> > be allocated to cities, not to providers. Within
> 
> I am a multihomed customer and my ISPs are in two different cities. What
> are my IP addresses going to be?

Your assumptions are flawed. I never suggested that there
would be a flag day. I never suggested that geotopological
addressing would work everywhere or solve all problems. I never
suggested that we should turn off the existing provider aggregatable
IP address allocations.

I just suggested an alternative way of issuing addresses so
that they are geotopologically aggregatable, not provider aggregatable.
There are sufficient reserved addresses in the IPv6 address space
to do this. We could start issuing geotopological netblocks and
try it for 5 years or so to see whether it works better or not.

In any case, you are located in Montreal which is such a major
city that I expect any ISP selling service (geotopologically) in 
Montreal would use Montreal address space even if they backhauled
at layer two to some other city.

However, there will likely be lots of situations where people
in small towns roughly equidistant from two cities will choose
to multihome with links to separate cities. This will either have
to be done using provider-aggregated addresses or by using
addresses from one of the cities with a longer prefix inside 
that city's routing table to direct the traffic to the 
neighboring city. If this is suboptimal, it won't be by much
considering that these are neighboring cities.

I'm not suggesting any change to IPv6 stacks or to routing
protocols. I'm just suggesting that we could allocate the same
IPv6 addresses to operators in a way that allows geotopological
aggregation rather than the existing provider aggregation. 
Combine this with local traffic exchange in every city and
you have a more robust Internet with lower overall latency
that will run with a smaller global routing table.

I know that some individual operators, such as the one 
I work for, have very robust IP networks with low overall
latency. But when we talk about the Internet, then we include
all the private interconnects and public exchange points
and tromboning of traffic due to peering "issues", etc.

--Michael Dillon


--Michael Dillon

Re: IPv6 news

[Michael . Dillon]

> And who is going to force the ISPs to interconnect at the city level?

Customers, of course! Who else ever forces ISPs to
do anything?

> For competitive reasons there is no peering in my city.  The nearest
> peering points are several hundred miles away, in different directions,
> and even those are not shared in common by the local ISPs.

Doesn't make sense, does it? As the Internet becomes
more and more mission critical for more people, you will
see non-technical customers questioning the chaos. Once
the insurance companies realize that ISPs in some areas
are not providing proper resiliency, they will raise the
premiums for business insurance in those areas and this
will provide the economic incentive for customers to force
ISPs to build a sensible 21st century utility architecture.

--Michael Dillon

Re: IPv6 news

[Phillip Vandry]

On Mon, Oct 17, 2005 at 11:39:37AM +0100, [EMAIL PROTECTED] wrote:
> Here, the suggestion is that netblocks should
> be allocated to cities, not to providers. Within

I am a multihomed customer and my ISPs are in two different cities. What
are my IP addresses going to be?

This situation happens all the time, by the way. In fact, the closer
you get to smaller, consumer grade connectivity, the more you will
see backhauling below the network layer in providers' networks that will
make this happen.

-Phil