At the risk of continuing this bad flashback...
> A Cisco "CRS-1 16-SLOT LINE-CARD CHASSIS ROUTE PROCESSOR" comes with
> 4 GB of route memory default size. Juniper's T320 and T640 come with
> 2 GB of main memory default size. That should take them to some higher
> number of routes.
No, sorry,
> This isn't trivial to do, but it isn't rocket science either!
True, but you ARE suggesting that Cisco produce a binary patch, to a
possibly compressed image.
I think you should really think long and hard before you conclude that
you really want that. IMHO, the risk/reward ratio as compared t
> Practically, what this means is that the government will be asking broadband
> providers
> - as well as companies that manufacture devices used for broadband
> communications – to build insecure backdoors into their networks,
> imperiling the privacy and security of citizens on the Internet.
>>>It also hobbles technical innovation by forcing companies involved in
>>>broadband to redesign their products to meet government requirements.
>>
>>As opposed to hobbling innovation by meeting customer requirements?
>
>
> who's paying the bill? and sorry to hear from a vendor that meeting
> i opine that some features are innovation and others not. i.e.,
> x.25 support on modern kit seems a not innovative and a waste of
> resources i would rather see applied elsewhere.
Probably a fairer characterization.
> but every feature has its cost in complexity and resources to build
> a
>>I'm sorry, but this is simply an unsupportable statement. What is
>>required of routers is that the provider be able to configure the device
>>to make copies of certain packets to a monitoring port. Assuming that
>>the monitoring port is duly managed, how does this qualify as "insecure"?
>
>
> Whilst this thread is open... perhaps someone can explain to me how
> shim6 is as good as multihoming in the case of redundancy when one of
> the links is down at the time of the initial request, so before any
> shim-layer negotiation happens.
>
> I must be missing something, but there's a goo
> Or, on top of that, how traffic engineering can be performed with shim6..
>
> -igor
> (firmly in the shim6 does not adress *most* of the issues camp)
Shim6 doesn't do what most end user sites would like to think of as
traffic engineering.
For a multihomed site, traffic engineering is about i
> Waitaminute - isn't the whole *purpose* of layer 3
> that the network makes these routing decisions?
>
> If there are N routers in an ISP, I would expect the
> ISP to connect to X endsystems, where 10N < X < 1000N.
> How does knowing about X endsystems scale better than
> knowing about N int
> The rules today have not resulted in and overly huge number of
> multihomers.
I suspect that is a matter of perspective. Even if 10% of all sites are
multihomed, and we continue in the IPv4 multihoming model, then we will
end up with slow exponential growth of the routing table which
eventu
On Sep 17, 2005, at 8:57 PM, David Hubbard wrote:
Just curious, do most vendors' hardware need to hit the
cpu when doing policy-based routing? I found one of my
border routers' cpu's on the bad end of a DDoS but once
I turned off a not necessarily required setup to force
some outbound traffic
That's not at all surprising. PBR would be pretty hard to push
into a hardware forwarding path.
Not impossible, but certainly challenging.
Doesn't the SUP-720(PFC3B) support (some forms of) PBR in hardware ?
As has been pointed out to me privately, the SUP-720 does flow cache
PBR s
.com is an abomination, as are the other gTLDs to a lesser
extent. .gov,
.mil, .edu, .info, and .biz need to be shifted under .us
immediately, and
everyone under .com, .net, and .org needs to be gradually moved
under the
appropriate part of the real DNS tree. I can live with .int
contin
Actually, I think you've got it backwards. .us and all of the other
country-specific TLDs are the last vestiges of nationalism.
The problem is that all gTLD are controlled only in the US (even more
than the root is). So, they are international only in name.
Obviously, I feel that that need
In general I agree with you. The primary exception being that if
national
political interests want to press for local rules about specific
strings
(like XXX) then those national interests belong in their designated
part of
the name space. Polluting the global space with nationally
incons
On Sep 29, 2005, at 2:08 PM, Randy Bush wrote:
Saudi Arabia, Iran, Northern Nigeria, and China are not likely to
have the same liberal views as, say, the Netherlands or Denmark.
Saudi Arabia and China, like some other nations, extensively filter
their Internet connection and have created go
On Oct 7, 2005, at 11:54 AM, Paul Vixie wrote:
[EMAIL PROTECTED] (Daniel Golding) writes:
Take-away: Do not single home. I'm shocked folks aren't figuring
this out.
If you are a webhoster or enterprise and your business model can
not support
multiple Internet pipes, than you have a subopt
in a pay-me-now-or-pay-me-later scenario, you have to pick "now"
vs. "later".
(it's a pity that the internet, for all its power, cannot alter
that rule.)
It should be noted that if one opts for 'later', you can do quick and
dirty games with NAT. Do not renumber, change providers and put
But I think the discussion is mood. IETF decided on their goal, and
it's superfluous trying to change that. While watching shim6 we carry
on hoping that we'll get IPv6 multihoming going in the conventional,
proven, working, feature-complete way we're used to... until IETF
there is no hope in
Perhaps that middle ground is a mix of these 2 things?
Perhaps. But what we currently seem to believe is that current
routing table growth is dominated by traffic engineering and
multihoming. If future routing is to scale better than today, then
we need some strong forces that push fo
So the IETF identified 4 reasons to multihome. Of those 4, shim6
ignores at least 2 of them (operational policy and cost), and so
far as I can see glosses over load sharing.
If you have a solution that satisfies all requirements, you should
contribute it. Shim6 is indeed a partial solu
Daniel,
The alternative is a multihoming scheme that does not require a
prefix per site. But that doesn't match the stated requirement of
'conventional', 'proven', 'working' [sic], 'feature-complete'.
Those weren't the "stated requirements" on an alternative multihoming
scheme,, but only t
I don't have an acceptable solution... however, I am getting tired
of shim6 being pushed as *the* solution to site rehoming, when at
best it's an end node rehoming solution.
Well, sorry. When we explored site multihoming (not rehoming) in the
ways that you seem to suggest, it was effe
but when similar things were proposed
at other meetings, somebody always said "no! we have to have end-
to-end,
and if we'd wanted nat-around-every-net we'd've stuck with IPv4."
Is VJ compression considered a violation of the "end-to-end"
principle?
Or perhaps I misunderstand (yet again
I don't want to speak for Daniel, nor other operators really, but a
solution that doesn't allow an operator to traffic engineer
internally or
externally is just not workable. For the same reasons quoted in
your other
messages to me: "Increased reliance on the Internet"
There's nothing in
Shifting the NAT to end system removed the objection to NAT, tho
it's not entirely clear why. Shifting NAT to the end system also
happened to simplify the entire solution as well.
Except for the part about having to rewrite all existing
implementations to take full advantage of the techn
Certainly does. Apparently this or a similar idea was suggested
back in
1997, and is the root origin of the 64 bits for host address space,
according to Christian Huitema, in his IPv6 book -
http://www.huitema.net/ipv6.asp.
A google search found the draft :
"GSE - An Alternate Addressing Arc
Doesn't NAT, or more specifically the most commonly used, NAPT, create
hard state within the network, which then makes it violate the
end-to-end argument ? Also, because it has to understand transport and
application layer protocols, to be able to translate embedded
addresses,
doesn't this a
How is a split between locator / identifier any different logicaly
from the existing ipv4 source routing?
IPv4 source routing, as it exists today, is an extremely limited
mechanism for specifying waypoints along the path to the destination.
This is completely orthogonal to a real identi
...the necessary evil called CIDR. evil because it locked customers
into their providers, entrenched the existing large providers
against future providers, and made it hard or impossible for the
average endusing company to multihome.
Uh, perhaps I'm being dense, but how does moving masking o
Paul,
This is completely orthogonal to a real identifier/locator split,
which would divide what we know of as the 'address' into two
separate spaces, one which says "where" the node is,
topologically, and one which says "who" the node is.
Hmm, no idea whether it's a good idea or not, bu
Fred,
If we are able to reduce the routing table size by an order of
magnitude, I don't see that we have a requirement to fundamentally
change the routing technology to support it. We may *want* to (and
yes, I would like to, for various reasons), but that is a different
assertion.
Th
Daniel,
If we're going to put the world thru the pain of change, it seems
that we should do our best to ensure that it never, ever has to
happen again.
That's the goal here? To ensure we'll never have another protocol
transition? I hope you realize what a flawed statement that is. We
can't
Fred,
So the routing problem was looked at, and making a fundamental
routing change was rejected by both the operational community and
the routing folks.
No, IPv6 doesn't fix (or even change) the routing of the system,
and that problem will fester until it becomes important enough to
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
addre
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 risin
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.
Trans
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 wheth
PS: Btw, anyone can give me a hint on where to discuss new ideas for
e.g. routing schemes (and finding out whether it's an old idea)?
You might start with the routing-discussion mailing list:
http://www.rtg.ietf.org/
Please expect that your idea has been discussed before. We're an old
Daniel,
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.
Th
the internet model is to expect and route around failure.
You cannot stop the last mile backhoes.
Tony
On Oct 23, 2005, at 11:33 PM, Alexei Roudnev wrote:
One question - which percent of routing table of any particular
router is
REALLY used, say, during 1 week?
I have a strong impression, that answer wil not be more than 20%
even in
biggerst backbones, and
will be (more likely) below 1
I understand BGP flapping to be announcements followed by
withdraws over a short period. I am seeing a peer with a large
number of announcements and the normal number of withdraws. Is
there a term to describe what I am seeing? I'd like to understand
what is happening, but I've been loo
Do we *really* want to do anything to encourage a higher burn rate
of AS numbers
before we've deployed 32-bit AS number support?
The only way to get 32-bit AS number support deployed is to run out
of AS numbers in
the 16 bit space.
Tony
On Nov 13, 2005, at 9:09 AM, Scott Bradner wrote:
"bridge where you can, route where you must." -- i forgot
where this
came
from? Radia?
Cabletron
And before that, Vitalink.
;-)
Tony
An alternative for sbgp design could be that aggregating ASN would
create special self-signing cert for such aggregate block and that
cert would have special attribute(s) indicating list of all sub-
blocks and reference
to all certs that "make" this aggregate block. Then verifying router
What good is 6Mbit DSL from my ISP (say, SBC for example) if only a
small
portion of the net (sites that pay for non-degraded access) loads at a
reasonable speed and everything else sucks?
One might argue that in such a situation, the end user is getting
less value than they
did previousl
The telephone companies are asking for the same ability to sell
multiple
services over the same physical line. Cable companies didn't make
their
Internet service slower when they add more private services, why do
people expect the telephone companies to make their Internet service
worse whe
I guess you missed all those trenches being dug in Verizon land to
install
fiber to the home. I guess you missed all the network upgrades in
ATT/SBC
and Bellsouth land to shorten their copper loop distances.
Sounds like they are manufacturing more bandwidth and the zero sum
game
is getti
>>the certificates are carried ... in soBGP in a new BGP message.
>
>
> btw, am i supposed to be cheered by yet another overloading of
> bgp?
Well gee Randy, I think you would have been happy. Here we are carrying
related data in the same place. And, in the long run, the
authentication inf
> i receive a bgp announcement from a new peer, but the announcement
> was originated two weeks ago (shockers! a stable route); was the
> asserted path to my new peer valid when the announcement was
> originated two weeks ago? once your mind starts down such paranoid
> paths, the void opens befo
> -- You must not rely on routing to secure routing.
I would like to point out that this goal is unnecesary.
First, we need to understand that for ANY solution to be deployable, it
must be incrementally deployable. We do not get an Internet-wide flag
day for BGP. The Internet must continue t
Randy,
> wrong. as deployment will be expensive and long, we will have one chance to
> deploy. so need a serious solution set for what we have to consider to be a
> very serious attack model. plan for attacks against the routing system as
> smart, well-researched, constant, ... as the best we
Pekka,
First of all, if you are assuming that NO ISPs make use of prefix
filters, then you would be incorrect. There are those that try very
hard to make use of such filters. However, we do not have 100%
deployment of those filters.
Since we will never see 100% deployment of such filters, we
Steve,
> I know all the issues up there are real, since I've occasionally heard
> about them happening. I understand the devastating consequences of
> somebody finding a sufficiently well connected unfiltered BGP session
> and using it to announce some important prefixes. I fully agree that i
Daniel,
Well, I wish I could have been part of the discussions that you had, as
what you report is at variance with what I've heard.
Fundamentally, there is a serious scalability issue with doing
everything at configuration generation time. Since one cannot predict
with certainty what AS path
Daniel, Todd,
> The most significant problem is hijacking of IP address space for various
> purposes. That's it. Solve that in the SIMPLEST way possible, lets implement
> it (because everyone sees the problem) than we can either iteratively
> improve the solution or start working on the next s
Todd,
>>- Forged AS paths and AS path segments
>
>
> ditto, provided that you have long enough AS path segments in your
> list of valid prefixes. if you have a long enough memory of routes
> and a fast enough system, it's trivial to produce weighted lists of
> the likelihood of a given prefix
>>Members aren't looking for Operator experience (sic). Members are
>>looking for talks that do not suck.
>
> (sic) is a matter of interpretation, and, you already said the talks
> suck. The PC said they don't get enough talks. Some of the talks are
> going to be filler.
Put more constructiv
> And finally, "we're doing it", "we're not doing it", "Surprise, we did it"
> is a crappy way to "notify" the community that they're about to piss in
> the global pool. At least there was some level of notification, but why
> bother if you're not going to stick to what you publicize?
One might
One minor (operational! -- gasp) addition:
More modern copies of ntpd have a '-g' option that will allow
the clock to jump once at boot time.
Tony
On May 20, 2004, at 12:27 PM, Randy Bush wrote:
sorry to take you away from discussing spam with an actual
tech note, but twice this morning i have hit
It needs to be set of trusted time sources that is as reliable as you
feel is necessary.
If you're feeling extremely paranoid, then you can use the -g flag to
peer with a number
of your private stratum 1 sources and then let the sanity checking do
its job to
avoid any bogochimers.
Tony
On May
Well, that's pretty impressive. Since you're not using Juniper or
Cisco, whose
gear are you using?
Tony
On May 25, 2004, at 12:58 PM, Matthew Kaufman wrote:
So you never run any production code that was compiled with gcc?
And, let me guess, your web servers all run IIS?
Matthew Kaufman
[EMAIL P
No, that's compiled with gcc too. ;-)
Tony
On May 25, 2004, at 2:02 PM, Christian Malo wrote:
procket ? :)
-chris
On Tue, 25 May 2004, Tony Li wrote:
Well, that's pretty impressive. Since you're not using Juniper or
Cisco, whose
gear are you using?
Tony
On May 25, 2004, at 12
Agreed. I am surprised that noone else have brought that up. I
understand that the software is built in a way that might not make
sense to port to all Cisco platforms, but it would be nice to have on
at least the GSRs.
I've heard the rumor that that would be the first port that they would
undertak
No. The BFR was the development name for Tony Li's last Cisco project
and morphed into the GSR. The processor card in at least early GSRs had
a BFR sticker on them.
Pardon, but I need to set the record straight here... It was not by
any stretch of the imagination 'my' project. There were dozens
With the current facilities as they are, a simple calculation shows
that
actual communications traffic will exceed the backbone's maximum
capacity as
soon as five years from now.
Since when is this is a good indicator? If we ignore any of the growth
in facility capacity in the last 5 years, woul
f property that was "sold" to Cisco ;-)
/John
At 5:46 PM -0700 6/17/04, Wayne E. Bouchard wrote:
So does this mean that Tony Li now works for Mr. Chambers again? :-)
On Thu, Jun 17, 2004 at 05:21:58PM -0700, John Curran wrote:
"SAN JOSE, Calif., June 17, 2004 - Cisco Systems, Inc., t
At the high end, you might want to look at Ixia.
Tony
On Jun 18, 2004, at 2:39 PM, Vicky wrote:
Hi there,
Just wondering what folks out there have used or are using (such as
smartbits, etc) for measuring the performance (benchmark) limits for
engineering and qa testing. I'm looking at doing end-
Various people I've asked about this have said they wouldn't use the .0
or .255 addresses themselves, though couldn't present any concrete info
about why not; my experience above would seem to suggest a reason not
to
use them.
The .255 address is very likely to be a broadcast address from a
ne
Is it really important to know the link speeds? What good does it do
without knowing
about the loading on those links?
I would MUCH rather have an empty T1 than have to contend with a very
oversubscribed OC-768.
Tony
On Jul 1, 2004, at 5:25 PM, Cody Lerum wrote:
DNS can sometimes give you a
On Jul 5, 2004, at 5:00 PM, Patrick W Gilmore wrote:
On Jul 5, 2004, at 2:02 PM, vijay gill wrote:
Throwing ethernet cables over the ceiling does not scale.
Sure it does. The question is: "How far does it scale?" Nothing
scales to infinity, and very, very few things do not scale past the
degen
On Jul 6, 2004, at 5:27 PM, Brad Gould wrote:
Does anyone know any useful contacts for .mil?
I have what looks to be filter issue with them, being some, but not
all,
of 203.122.192.0/18 not being able to access some sites (www.usmc.mil
for one). Its a reasonable "new" IP range allocation.
I've
You mean that they're not near any *known* fault lines. Remember
Northridge?
If you're in CA or NV, you *are* near a fault line, no matter where you
are.
http://quake.wr.usgs.gov/recenteqs/Maps/122-39.htm
http://quake.wr.usgs.gov/recenteqs/latest.htm
Tony
On Jul 16, 2004, at 3:53 PM, Jonathan
On Aug 4, 2004, at 10:53 PM, Paul Jakma wrote:
On Wed, 4 Aug 2004, Alexei Roudnev wrote:
I am sorry, but I do not make a theory - I just repors practical
results. 2 CPU systems are much more stable than 1 CPU system, in my
experience. You are free to find an explanatiion, if you want -:).
The th
Did they arrest the crew? They have grounds on negligence
charges...
Tony
On Aug 23, 2004, at 3:12 PM, David Lesher wrote:
Speaking on Deep Background, the Press Secretary whispered:
Via:
http://www.hindustantimes.com/news/181_965656,00050002.htm
Sri Lanka court holds back Indian ship, seeks $5
However, there is text in the RFC 2453 that states that RIP can use
this message to request specific networks also. It also states that
such a request can only be made by a diagonistic software and cannot
be used for routing. My doubt is, how can a diagnostic software, use
the services of RIP for
I tried configuring my router this way but all I got were syntax
errors...
Can we PLEASE move on?
Thanks,
Tony
On Sep 25, 2004, at 2:10 PM, Alexei Roudnev wrote:
Hmm.
It was not developing countries, who claimed _free trade_; it was
_developed
counrties_. When free trade was coming, it caus
I wanna know why Peter Packet doesn't have a Swedish accent!
;-)
Tony
For those not familiar, BitTorrent is a file sharing app that is
commonly
used for exchanging full movies. As such, folks are moving gigabyte
files regularly and it's not surprising that this is detectable.
Shuffling .mp3's around would be trivial by comparison.
Tony
On Nov 5, 2004, at 6:34 AM,
Daniel Senie wrote:
There are basically two issues: the forwarding table and BGP
processing. Information in the forwarding table needs to be found
*really* fast. Fortunately, it's possible to create datastructures
where this is possible, to all intends and purposes, regardless of the
size of t
I am not sure that 254 is a good maximum number. Perhaps someone "in the
know" can enlighten all of us as to why they chose to stop at 254 instead of
255.
I can think of at least one vendor who decremented TTL prior to letting the
packet
come up to the RP. Further, the same vendor would dro
What's very amusing is reading section 5 of the draft, wherein the
author
distributes credit to a number of parties. If Cisco were to file a
patent
at this point and not include those parties (including other companies),
the patent validity would be at risk by reason of excluding a
contributo
It certainly looks (approximately) genuine, with Kirk's normal coding
style and
normal calls to IOS infrastructure routines.
Tony
On May 15, 2004, at 1:21 PM, John Kinsella wrote:
For those not on bugtraq...I can't hit securitylab.ru, so would be
curious if anybody has more info or confirmation.
Routing slots aren't the only resource you're consuming. In
general, many of the prefixes coming out of a given AS have common
attributes, e.g. path, MEDs, etc. Those attributes are stored only
once (at least in the BGP implementation I know) even if they're
used by hundreds of prefixes
Also, from a research standpoint I'm curious as to why this
organization thinks they need ARIN IP space to do what they do.
Most of us know that's probably not true. I keep pretty close tabs
on ongoing research in network location based services, dns
mapping, online advertising, etc
Marshall,
> That's after 6 years.
>
> I would be surprised if Shim6 going into actual deployed boxes was any
> faster. So, if Shim6 was finalized today, which it won't be, in 2010 we
> might have 70% deployment and in 2012 we might have 90% deployment.
>
> I actually think that 2012 would be
> I'm more confident that we'll find an answer
> to the IDR problem sooner than we'll convince people to act in the good
> of the community at their own expense.
The solution to the IDR problem is to have a scalable routing
architecture. Unfortunately, that involves change from the status quo,
>> The alternative, of course, is to wait for IDR to implode and let the
>> finger-pointing begin.
>
> ... which is what I expect to happen. A few folks will see it coming,
> design a fix, and everyone will deploy it overnight when they discover
> they have no other choice. Isn't that about wha
Stephen Sprunk wrote:
> Who exactly has been trying to find scalable routing solutions?
Well, for the last decade or so, there's been a small group of us who
have been working towards a new routing architecture. Primary
influences in my mind are Chiappa, O'Dell, Hain, Hinden, Nordmark,
Atkin
> IBM and Georgia Institute of Technology are experimenting
> with silicon-
> germanium, it is said here:
>
> http://tinyurl.com/g26bu
>
> I find this interesting having just attended NANOG 37 where some
> manufacturers of network devices told us in a panel that network
> heat problems
> > I also suspsect that the community is not ready to transition to
> > liquid-cooled systems.
>
> I rather assumed 'at room temperature' implied a standard heat sink
> and fan.
>
>
> Perhaps there's not enough information in that article to draw a
> conclusion from.
There are a few bits t
> > Has anyone ever managed to open a dialogue with symantec
> (or comcast)
> > about that fscked up proprietary RBL they are using?
> >
> > We're on the verge of just giving up on comcast
>
> I know Sender Verification Callback has its issues, but maybe it
> would make sense to only accept
3)
What's wrong with treating assignments like property and setting up a market
to buy and sell them? There's plenty of precedent for this:
Mineral
rights, mining claims, Oil and gas leases, radio spectrum.
If a given
commodity is truly scarce, nothing works as
> What you see in BGP is not necessarily what you get for
> actual routing.
> This isn't the only situation where advertisements do not
> match actual
> routing. Consider traffic engineering systems such as the
> Internap FCP (old
> NetVMG). Imagine I have two upstreams (A and B) and yo
On Jul 23, 2007, at 12:48 PM, Xin Liu wrote:
I have a question about unrecognized BGP path attribute. According to
RFC4271, when a BGP router sees an UPDATE with an unrecognized
optional and transitive path attribute, it should retain the
attribute, and if the path is selected, it should propa
On Dec 26, 2007, at 8:26 AM, Leo Bicknell wrote:
In a message written on Tue, Dec 25, 2007 at 12:43:45AM -0500,
Kevin Loch wrote:
RA is a shotgun. All hosts on a segment get the same gateway. I
have
no idea what a host on multiple segments with different gateways
would
do. Hosting env
...and aggregated calendars:
- http://www.icann.org/general/calendar/
- http://www.isoc.org/isoc/conferences/events/
I've been maintaining an integrated calendar across our related
meetings for awhile now. For folks using iCal or compatible tools,
you can subscribe via the webcal link
On Jan 16, 2008, at 1:37 PM, Mike Donahue wrote:
Anyway, it's all getting (for us) pretty complicated. We're a fairly
small firm and just want an Ethernet handoff with our IP block on it.
Sprint didn't blink at the request, but AT&T... We're getting a good
rate from AT&T for the IP services
> 8 years ago today was the beginning of the end.
No, it was the end of the beginning.
Tony
1 - 100 of 104 matches
Mail list logo
