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
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
On Oct 15, 2005, at 9:08 PM, Paul Vixie wrote:
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."
Hmm.
Is VJ compression considered a violation of the "end-to-end"
On Sat, 15 Oct 2005, John Payne wrote:
> On Oct 15, 2005, at 3:29 PM, Tony Li wrote:
> >> 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 hav
Jordi,
On Oct 15, 2005, at 2:09 AM, JORDI PALET MARTINEZ wrote:
I don't think users need to be charged any extra for IPv6 if it
runs in the
same pipe as their actual IPv4 one.
If IPv6 is tunneled through IPv4 in such a way that the ISP doesn't
have to do anything special, then I suspect y
[EMAIL PROTECTED] (David Conrad) writes:
> On Oct 15, 2005, at 3:27 PM, Tony Li wrote:
> > When we explored site multihoming (not rehoming) in the ways that
> > you seem to suggest, it was effectively a set of coordinated NAT
> > boxes around the periphery of the site. That was rejected quit
On Sat, 15 Oct 2005, Tony Li wrote:
> >> The operational community needs to reach consensus on what its
> >> priorities are. We fought the CIDR wars to keep the routing
> >> subsystem working and the operational community were the primary
> >> backers of that. To not support scalable multihoming
From: Randy Bush <[EMAIL PROTECTED]>
To: "Scott Weeks" <[EMAIL PROTECTED]>
Cc: nanog@merit.edu
Subject: Re: Time for a real Internet highway (?)
Date: Sat, 15 Oct 2005 12:14:51 -1000
> > The internet is global and without boundries. The US
> > highway system is domestic with boundries.
>
> the h
Tony,
On Oct 15, 2005, at 3:27 PM, Tony Li wrote:
When we explored site multihoming (not rehoming) in the ways that
you seem to suggest, it was effectively a set of coordinated NAT
boxes around the periphery of the site. That was rejected quite
quickly.
What were the reasons for rejecti
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
> The internet is global and without boundries. The US
> highway system is domestic with boundries.
the history of the interstate bill is quite interesting.
among other things, it killed the trains, contributed to
the degredation of the inner cities, ... and guess which
industries lobbied it th
On Fri, 14 Oct 2005, Ben Butler wrote:
> Date: Fri, 14 Oct 2005 17:32:10 +0100
> From: Ben Butler <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: RE: IPv6 news - newbie
> [ ... ] I have no idea whether there is a market for v6 connectivity
> / hosting amongst UK businesses, I guess we wi
- Original Message Follows -
From: "Michael Painter" <[EMAIL PROTECTED]>
To: "NANGO"
Subject: Time for a real Internet highway (?)
Date: Fri, 14 Oct 2005 13:07:32 -1000
> I'd be very interested in what folks here think of this:
>
>
http://news.com.com/Time+for+a+real+Internet+highway/201
> Hello,
>
> We are looking for a OC3 -> 3xDS3 MUX. (If it can grow up to
> a OC12 ->
> 12xDS3 thats a plus)
> Sonet side will be 1+1 protected
>
> I have looked at the following equipment is there any other
> sonet muxes that
> i should look at?
>
> Adtran Opti-3
> Adtran OPTI-6100
> Cisco
On Oct 15, 2005, at 3:29 PM, Tony Li wrote:
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
On 15-Oct-2005, at 15:29, Tony Li wrote:
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
cont
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
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
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
On Sat, 15 Oct 2005 00:22:15 -0500
Nicholas Suan <[EMAIL PROTECTED]> wrote:
>
> Daniel Roesen wrote:
>
> >On Fri, Oct 14, 2005 at 10:45:33PM -0400, Todd Vierling wrote:
> >
> >
> >>Maybe to start -- but again, what kind of 6to4 traffic level are we
> >>expecting yet?
> >>
> >>
> >
> >Peak
On Sat, Oct 15, 2005 at 08:36:29PM +0930, Mark Prior wrote:
> It might be "closer" if we turned up IPv6 with Sprint but are they
> native yet?
Nope.
http://www.nanog.org/mtg-0405/augmentation.html and
http://www.nanog.org/mtg-0405/pdf/rockell.pdf
Although it's dated, I don't
On Fri, 14 Oct 2005, Tony Li wrote:
>
> >> 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-comple
On Fri, 14 Oct 2005, David Conrad wrote:
> Christopher,
>
(chris is fine, silly corp email doesn't let us have sane addresses :( )
> On Oct 14, 2005, at 9:32 PM, Christopher L. Morrow wrote:
> >> You know, if you describe it that way too many times, people who are
> >> only paying half-attenti
On Sat, 15 Oct 2005, Randy Bush wrote:
it sounds as if you have the mythical separation of locator and
identifier :-)/2. the problem is that there is likely to be a
shortage of those locators.
Yes ;^)
Note that it's not 6to4, it's a proper 2001:: /48 delegation via the
SIXXS tunnel-broker
> FWIW, my current IPv6 assignment is PI to a degree (where P == my
> first hop IPv4 provider), I can change this "first hop IPv4" provider
> to any other provider within my country and still retain my IPv6
> assignment.
it sounds as if you have the mythical separation of locator
and identifie
On Fri, 14 Oct 2005, Tony Li wrote:
The alternative is a multihoming scheme that does not require a
prefix per site.
Another alternative is to force-align allocation and topology in some
way /other/ than by "Providers" (geographical allocation in whatever
hierarchy, IX allocation, whatever)
# > if all you've got is a hammer, every problem looks like a nail.
#
# I guess the question was what is the problem IPng was supposed to solve?
that depends on who you ask. the pet problem i was dealing with at the time
was the necessary evil called CIDR. necessary because infinite routing ta
On 2005-10-15, Nicholas Suan <[EMAIL PROTECTED]> wrote:
>>I'm told there are 6to4 relays seeing in excess of 100mbps. Not bursts.
>>Can you imagine trying to handle 100mbps "internet mix" traffic process
>>switched? :-Z Not even talking about the peaks.
> They may be handling 100mbps but they als
> But I have also to admit that I'm shocked how few folks have the balls
> (or is it lazyness?) to express their opinion on IPv6 multihoming in the
> public, on the established fora for that stuff.
The probably got bored of having "it doesn't scale" shouted at them
> Almost zero feedback from e
On Sat, Oct 15, 2005 at 10:44:39AM +0200, Daniel Roesen wrote:
>
> Operators DO support scalable multihoming, but it has to deliver what
> they want/need. HOW this can be achieved is the task of the IETF and
> the REAL challenge. shim6 is only "the easy way out".
>
> Daniel
Easy... perh
On 14/10/2005, at 3:35 AM, Peter Lothberg wrote:
Here's a challange, have NTP server attached directly to
a good clock and a IPv6 network.
Is there anyone who can talk to it using IPv6 on the Nanog list?
(Time20.Stupi.SE, 2001:0440:1880:1000::0020)
yoyo$ ntpdate -q 2001:0440:1880:1000::002
On Fri, 14 Oct 2005 13:07:32 -1000
"Michael Painter" <[EMAIL PROTECTED]> wrote:
>
> I'd be very interested in what folks here think of this:
>
> http://news.com.com/Time+for+a+real+Internet+highway/2010-1028_3-5894664.html?tag=carsl
All I can see are two actual arguments for government interven
When I suggest to my customers to move to IPv6, I explicitly tell them that
planning is very important:
1) Initially (in some cases), your equipment may not have native support for
the core/access networks. Not a problem, when you upgrade your network for
other reasons (line cards, new IPv4 featu
I don't think users need to be charged any extra for IPv6 if it runs in the
same pipe as their actual IPv4 one.
Do we charge to our customers when we solve a bug or problem in our network
?
IPv6 was invented to solve a "bug" in IPv4: The lack of enough addresses.
Of course, now IPv6 could bring
On Fri, Oct 14, 2005 at 09:52:19PM -0700, Tony Li wrote:
> 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 requiremen
> there is no hope in having operators explain to ietf that the current path
> is fruitless? certainly they can be made to see the light, yes?
you have not spent much time with the ivtf, have you?
randy
36 matches
Mail list logo
