On 16-feb-2006, at 0:15, Fred Baker wrote:
On Feb 15, 2006, at 9:13 AM, Edward B. DREGER wrote:
Of course not. Let SBC and Cox obtain a _joint_ ASN and _joint_
address
space. Each provider announces the aggregate co-op space via the
joint
ASN as a downstream.
Interesting. This is what
I looked at some of these models back in ~2000, but the dotcom boom
ended and I didn't get laid off from my day job, so I didn't go
trolling for venture capitalists, and my employer sold off their cable
companies - since then, the market economics have changed a lot, and
routers have started to su
> > Geo-topological addressing refers to RIRs reserving large
> > blocks of designated addresses for areas served my large
> > cities (over 100,000) population. When end users are located
> > in fringe areas roughly equidistant between two or more such
> > centers, the RIR simply asks the end user
On 16-Feb-2006, at 13:32, Edward B. DREGER wrote:
JA> I get the feeling that there's a lot of solutions-designing
going on in this
JA> thread without the benefit of prior problem-stating.
Problem:
Consumers want to multihome.
That sentence needs profound expansion before it's going to be
On Thu, 16 Feb 2006, Vince Fuller wrote:
to two popular "geo-topo" addressing domains, say the Bay Area and
the DC area. Let's say that 10.0.0.0/8 is the "geo-topo" address
block in the Bay Area and 172.16.0.0/12 is the "geo-topo" block in
the DC area. This provider has four customers in the
Uh-oh, two postings to NANOG in as many days... hopefully, this will be
my last.
> [[pushed the wrong button last time. This is the complete reply]]
Oh, the irony in that statement... this whole argument has certainly pushed
"the wrong button" for me.
>
> > - join a local IXP, which may be
On Thu, Feb 16, 2006 at 02:42:49PM -0500, James R. Cutler wrote:
> Since meeting Yakov years ago, I have always tried to teach network
> designers to consider addressing and topology together.
>
> It hasn't always worked. Many don't care about network population
> estimates and demographics, so
Since meeting Yakov years ago, I have always tried to teach network
designers to consider addressing and topology together.
It hasn't always worked. Many don't care about network population
estimates and demographics, some don't recognize those terms, and, a few
just want enough Class C network
On Thu, 16 Feb 2006, David Meyer wrote:
One of the first things I ever learned from Yakov (at the
first IETF I ever attended):
"Addressing can follow topology or topology can follow
addressing. Choose one."
So which one was it when you guys were developi
> It's a little more basic than that. I'm no graph theory expert and reading
> such stuff gives me a headache, but I do understand that abstraction
> (summarization or aggregation) of routing information is only possible if the
> identifiers that are used for numbering network elements (the
> "addr
JA> Date: Thu, 16 Feb 2006 12:44:27 -0500
JA> From: Joe Abley
JA> Personally, if I was going to multi-home, I would far prefer that my various
JA> transit providers don't cooperate at all, and have sets of peers and/or
JA> upstream transit providers that are as different as possible from each
JA>
I'm sure I'm going to regret posting this, if for no other reason than that
I will immediately start receiving more spam, and I suspect that I am just
re-stating things that TLi and others have been trying to state both here
and on PPML, but I guess I just can't resist today...
[Disclaimer: I don
On 15-Feb-2006, at 19:33, Edward B. DREGER wrote:
Want to dual-home to SBC and Cox? Great. You get IP space from
1.0.0/18
which is advertised via AS64511. Lots of leaf dual-homers do the
same,
yet there is ONE route in the global table for the lot of you. SBC
and
Cox intercon
JP> Date: Thu, 16 Feb 2006 12:05:35 -0500
JP> From: John Payne
JP> Are most of the multihomers REALLY a one router shop (implied by your
JP> renumbering is easy comment) - although shim6 could help there I guess.
Dual-homed leaves, particularly those who [would] use DSL and cable?
Yes. And it
On Feb 15, 2006, at 2:30 PM, Edward B. DREGER wrote:
The biggest problem is when customer's link to provider A goes down
and
inbound traffic must flow through provider B. This necessitates some
sort of path between A and B where more-specifics can flow.
Are most of the multihomers REALLY
On Wed, 15 Feb 2006, Mike Leber wrote:
>
> While there are not as many businesses and organizations as people on the
> planet, as an exercise imagine 4 billion prefixes.
At the moment mobile IP is not implemented using the global routing
infrastructure, because it can't scale to 4 billion prefixe
Mike Leber wrote:
In line with this... (I had to point this out in a different context on
another list before):
Networks announce prefixes because doing so makes them money. Networks
that listen to these prefixes do so because that makes them money.
Indeed. That is precisely the reason why
> Moreover, I'm convinced the problem isn't O(N^2) in practice. Someone
> with more math skills than any poster in this thread (self included)
> needs to weigh in, but... again...
Math skills are not needed. This is a technical
and business problem, not a mathematical one.
I tried to sell jus
Mikael Abrahamsson wrote:
On Thu, 16 Feb 2006, Alexei Roudnev wrote:
allocation. And what is a problem with 8M networks in next 8 years (if we
easily handle 200K just now)?
Each unit I buy that has to handle 1M routes instead of 256k routes
today costs $10-30k or more extra because of this
[[pushed the wrong button last time. This is the complete reply]]
> - join a local IXP, which may be a physical switch or
> virtualized by a set of bilateral agreements.
Why should they join an IXP if they already have
private peering arrangements?
> - outside the region, they advertise
> - join a local IXP, which may be a physical switch or
> virtualized by a set of bilateral agreements.
Why should they join an IXP if they already have
private peering arrangements?
> - outside the region, they advertise the prefix of the
> regional authority
Mixing government with
On Thu, 16 Feb 2006, Alexei Roudnev wrote:
allocation. And what is a problem with 8M networks in next 8 years (if we
easily handle 200K just now)?
Each unit I buy that has to handle 1M routes instead of 256k routes today
costs $10-30k or more extra because of this requirement. Yes, it's no
TED]>
Cc:
Sent: Wednesday, February 15, 2006 11:45 AM
Subject: Re: protocols that don't meet the need...
>
>
> On Wed, 15 Feb 2006 16:31:56 +0100 (CET), "Mikael Abrahamsson"
> <[EMAIL PROTECTED]> said:
> [snip]
> > The current routing model doesn
Edward B. DREGER:
> Want to dual-home to SBC and Cox? Great. You get IP space from
>
> 1.0.0/18
>
> which is advertised via AS64511. Lots of leaf dual-homers do
> the same, yet there is ONE route in the global table for the
> lot of you. SBC and Cox interconnect and swap packets when
On Wed, 15 Feb 2006, Joe Provo wrote:
> On Wed, Feb 15, 2006 at 06:51:16PM -0800, John A. Kilpatrick wrote:
> > On Thu, 16 Feb 2006, Edward B. DREGER wrote:
> >
> > >Stop. Examine. Think. Then respond.
>
> Something about history repeating applies. those who weren't around
> then should re-
On Wed, Feb 15, 2006 at 06:51:16PM -0800, John A. Kilpatrick wrote:
> On Thu, 16 Feb 2006, Edward B. DREGER wrote:
>
> >Stop. Examine. Think. Then respond.
Something about history repeating applies. those who weren't around
then should re-visit tli's ISPAC proposal from 96 and the associated
JAK> Date: Wed, 15 Feb 2006 18:51:16 -0800 (PST)
JAK> From: John A. Kilpatrick
JAK> Maybe I missed it, but is there something in your solution that keeps
JAK> dual-homed leaves from having to renumber when changing ISPs? In your
Note: I'm approaching this from a "something to do today" IPv4
st
On Thu, 16 Feb 2006, Edward B. DREGER wrote:
Stop. Examine. Think. Then respond.
[...]
Coop ASNs/IP save ASNs and aggregate routes. Full stop.
Maybe I missed it, but is there something in your solution that keeps
dual-homed leaves from having to renumber when changing ISPs? In your
PJ> Date: Wed, 15 Feb 2006 23:41:15 + (GMT)
PJ> From: Paul Jakma
PJ> reason you decided to strip my address from your reply.>
That portion did, but the rest of my message did not. VZW's 1xRTT
service was getting ugly, so I didn't re-paste your headers from the
original message.
PJ> > B
MK> Date: Wed, 15 Feb 2006 15:35:27 -0800
MK> From: Matthew Kaufman
MK> So this is a good proposal if I*(I-1)/2 < C where
MK> C = number of ASNs issued to dual-homed customers
MK> I = number of ASNs issued to "Transit Providers" said customers might select
MK> from
MK>
MK> (Note that it is bigge
Edward B. DREGER:
> ...Of course not. Let SBC and Cox obtain a _joint_ ASN and
> _joint_ address space. Each provider announces the aggregate
> co-op space via the joint ASN as a downstream
So this is a good proposal if I*(I-1)/2 < C where
C = number of ASNs issued to dual-homed customers
strange reason you decided to strip my address from your reply.>
On Wed, 15 Feb 2006, Edward B. DREGER wrote:
BTW, Paul, FixedOrbit reports 701 as having ~1500 peers and
downstreams. As interconnected as even they are, that's still a far
cry from the full-mesh O(N^2) situation you seemed to
then fine, I agree that a manet network run by an operator is in
scope. I was responding to the comments I have already gotten from
network operators who have dumped all over me when I mentioned manet.
On Feb 15, 2006, at 1:52 PM, Christian Kuhtz wrote:
Fred,
Hmm. Is self-organizing me
On Feb 15, 2006, at 9:13 AM, Edward B. DREGER wrote:
Of course not. Let SBC and Cox obtain a _joint_ ASN and _joint_
address
space. Each provider announces the aggregate co-op space via the
joint
ASN as a downstream.
Interesting. This is what has been called metropolitan addressing.
I'
On Wed, 15 Feb 2006, Daniel Roesen wrote:
It has no clue about upstream/downstream/peering, ASses etc. Those
things that actually make topology and economics. That's aside all the
other administrative nightmares associated.
Oki, let's step back a bit and look at shim6 from another angle, the
CA> Date: Wed, 15 Feb 2006 14:04:24 -0600
CA> From: Chris Adams
CA> Only one of our multihoming customers has a connection to someone we
CA> already have a connection with, so there's no path between our network
CA> and the rest.
I overlooked something:
You lack connections at the IP layer. Do
AO> Date: Wed, 15 Feb 2006 22:20:21 +0100
AO> From: Andre Oppermann
AO> $realworld always wins.
Translation: "Shift as much cost as you can to as many other entities
as you can."
$realworld says that is short-sighted. If selfishly saving $x increases
the overall economy's cost by $10x, it d
Fred,
Hmm. Is self-organizing mesh access network with (some) explicitly
mobile participants really that dissimilar from what the claimed goal
of manet is? Seems to me that's perfectly in scope.
Further, I think if you review the charter for the manet wg you could
be convinced they're
AO> Date: Wed, 15 Feb 2006 22:18:04 +0100
AO> From: Andre Oppermann
AO> So what? The newer 7200s have got NPE-G1's or soon NPE-G2's in them.
AO> Comes with 1G RAM default. It's not that your 7 year old NPE-150 can
AO> still participate in todays DFZ, is it? We're not going to explode
It'll be
The big question there is whether it is helpful for an operator of a
wired network to comment on a routing technology for a network that
is fundamentally dissimilar from his target topology. Not that there
is no valid comment - the security issues are certainly related. But
if you want to
Edward B. DREGER wrote:
PJ> Date: Wed, 15 Feb 2006 20:46:33 + (GMT)
PJ> From: Paul Jakma
PJ> Well you don't need to assign an ASN for Cox and SBC to announce a shared
PJ> prefix for a start off.
Technically true, but administratively not feasible. Coordinating
private ASNs would be simil
Edward B. DREGER wrote:
AO> Date: Wed, 15 Feb 2006 21:41:53 +0100
AO> From: Andre Oppermann
AO> Err, the problem is not the number of AS numbers (other than having to
AO> move to 32bit ones). The 'problem' is the number of prefixes in the
It's both.
AO> routing system. The control plane sca
PJ> Date: Wed, 15 Feb 2006 20:46:33 + (GMT)
PJ> From: Paul Jakma
PJ> Well you don't need to assign an ASN for Cox and SBC to announce a shared
PJ> prefix for a start off.
Technically true, but administratively not feasible. Coordinating
private ASNs would be similar to coordining RFC1918 s
AO> Date: Wed, 15 Feb 2006 21:41:53 +0100
AO> From: Andre Oppermann
AO> Err, the problem is not the number of AS numbers (other than having to
AO> move to 32bit ones). The 'problem' is the number of prefixes in the
It's both.
AO> routing system. The control plane scales rather well and direc
2^32 prefixes.
-ejay
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On
> Behalf Of Andre Oppermann
> Sent: Wednesday, February 15, 2006 2:42 PM
> To: Edward B. DREGER
> Cc: nanog@merit.edu
> Subject: Re: a radical proposal (Re: protocols t
On Wed, 15 Feb 2006, Marshall Eubanks wrote:
very limited. Here in Western Fairfax, basically just the two
mentioned. Why not create aggregation ASN that exploit that ?
Well you don't need to assign an ASN for Cox and SBC to announce a
shared prefix for a start off.
regards,
--
Paul Jakma
Edward B. DREGER wrote:
CA> Date: Wed, 15 Feb 2006 14:04:24 -0600
CA> From: Chris Adams
CA> There's a difference: computers (routers) handle the O(N^2) routing
CA> problem, while people would have to handle the O(N^2) cooperative AS
CA> problem.
0.1 ^ 2 < 5000
One must also consider the scala
PH> Date: Wed, 15 Feb 2006 21:14:03 +0100
PH> From: Per Heldal
PH> ...quite the opposite of what I ment to say. Most nanog'ers work in
PH> engineering. The problem is a lack of ops-people turning these
PH> xOG-groups ito xEG-groups instead.
Ah. That makes much more sense. :-)
PH> PS! I prefer
CA> Date: Wed, 15 Feb 2006 14:04:24 -0600
CA> From: Chris Adams
CA> There's a difference: computers (routers) handle the O(N^2) routing
CA> problem, while people would have to handle the O(N^2) cooperative AS
CA> problem.
0.1 ^ 2 < 5000
One must also consider the scalar coefficient.
CA> We ar
On Wed, 15 Feb 2006 16:56:51 + (GMT), "Edward B. DREGER"
<[EMAIL PROTECTED]> said:
[snip]
> Per, I'd like to take exception with your "exclude small companies"
> remark. This thread is about tighter engineering and ops involvement,
> so why shoot down those who have the two tightly coupled?
Hello;
On Feb 15, 2006, at 2:02 PM, Paul Jakma wrote:
On Wed, 15 Feb 2006, Edward B. DREGER wrote:
Of course not. Let SBC and Cox obtain a _joint_ ASN and _joint_
address space. Each provider announces the aggregate co-op space
via the joint ASN as a downstream.
This is unworkable ob
Once upon a time, Edward B. DREGER <[EMAIL PROTECTED]> said:
> No, it is not unworkable. Think through it a bit more. Although the
> problem is theoretically O(N^2), in practice it is closer to O(N). Note
> that _routing itself_ is theoretically an O(N^2) problem. Do we say
> that it is "un
CM> Date: Wed, 15 Feb 2006 14:37:44 -0500
CM> From: Chip Mefford
CM> ED> Of course not. Let SBC and Cox obtain a _joint_ ASN and _joint_
CM> ED> address space. Each provider announces the aggregate co-op space
CM> ED> via the joint ASN as a downstream.
CM>
CM> This makes a lot of sense.
BTW,
On Wed, 15 Feb 2006 16:31:56 +0100 (CET), "Mikael Abrahamsson"
<[EMAIL PROTECTED]> said:
[snip]
> The current routing model doesn't scale. I don't want to sit 5 years from
> now needing a router that'll handle 8 million routes to get me through
> the
> next 5 years of route growth.
agree!
>
Edward B. DREGER wrote:
> MA> Date: Wed, 15 Feb 2006 16:31:56 +0100 (CET)
> MA> From: Mikael Abrahamsson
>
> MA> The current routing model doesn't scale. I don't want to sit 5 years from
> MA> now needing a router that'll handle 8 million routes to get me through the
> MA> next 5 years of route
PJ> Date: Wed, 15 Feb 2006 19:02:11 + (GMT)
PJ> From: Paul Jakma
PJ> > Of course not. Let SBC and Cox obtain a _joint_ ASN and _joint_ address
PJ> > space. Each provider announces the aggregate co-op space via the joint
PJ> > ASN as a downstream.
PJ>
PJ> This is unworkable obviously: Think
On Wed, 15 Feb 2006, Edward B. DREGER wrote:
Of course not. Let SBC and Cox obtain a _joint_ ASN and _joint_
address space. Each provider announces the aggregate co-op space
via the joint ASN as a downstream.
This is unworkable obviously: Think next about SBC and (say) Verizon
customers,
On Wed, Feb 15, 2006 at 11:26:47AM -0600, Randy Bush wrote:
>
> > Funny that shim6 is being mentioned. The corresponding open mic session
> > at 35 showed how gathering people for 20 minutes of complaining can
> > effectively replace long, protracted email threads.
>
> and what was the effect
RB> Date: Wed, 15 Feb 2006 11:26:47 -0600
RB> From: Randy Bush
RB> and what was the effect in the ietf? zippo.
Exactly. I'm claiming that the meeting was a more effective vehicle
than a mailing list for the group of people involved -- NANOGers. I'm
also suggesting that, by extension, cross-
> Funny that shim6 is being mentioned. The corresponding open mic session
> at 35 showed how gathering people for 20 minutes of complaining can
> effectively replace long, protracted email threads.
and what was the effect in the ietf? zippo.
randy
MA> Date: Wed, 15 Feb 2006 16:31:56 +0100 (CET)
MA> From: Mikael Abrahamsson
MA> The current routing model doesn't scale. I don't want to sit 5 years from
MA> now needing a router that'll handle 8 million routes to get me through the
MA> next 5 years of route growth.
MA>
MA> PI space for multiho
So what? They are good for the customers, and then, scaling problems are
minor (esp. if you count
on decreasing of # of allocations per company).
> > PI space for multihoming and AS number growth is a bad thing for scaling
Funny that shim6 is being mentioned. The corresponding open mic session
at 35 showed how gathering people for 20 minutes of complaining can
effectively replace long, protracted email threads.
There was even unicast chatter about trying to coordinate NOGs with
engineering.
Per, I'd like to ta
Daniel,
On Wed, Feb 15, 2006 at 11:51:12AM +0100, Daniel Roesen wrote:
>
> On Tue, Feb 14, 2006 at 01:47:31PM -0800, David Meyer wrote:
> > IETF). Now, while many in the IETF argue that there is no
> > such thing as an "operator community", I personally see
> > it dif
> The current routing model doesn't scale. I don't want to sit 5 years
from
> now needing a router that'll handle 8 million routes to get me through
the
> next 5 years of route growth.
You might want to read a NANOG posting made by Sean Doran
back in September 1995
http://www.cctec.com/mailli
On 15 feb 2006, at 13.56, Per Heldal wrote:
It's the lack of reality in operational policies that is the real
source
of frustration in ops communities. People are picking on shim6 because
it is used as an argument to back the current policies at a time
when it
doesn't even have an early al
On Wed, 15 Feb 2006, Daniel Roesen wrote:
There is no way to do traffic engineering with any shim6-like system
like one can do with BGP as shim6 is a completely host-centric solution.
It has no clue about upstream/downstream/peering, ASses etc. Those
things that actually make topology and econo
On Tue, Feb 14, 2006 at 07:09:38PM -0500, Christian Kuhtz wrote:
>
> David,
>
> On Feb 14, 2006, at 5:07 PM, David Meyer wrote:
> >>Hmm, well, when there is lots of vendor and academia involvement, no,
> >>there's no operator community presented in number of things I'm
> >>following in the IETF.
It's the lack of reality in operational policies that is the real source
of frustration in ops communities. People are picking on shim6 because
it is used as an argument to back the current policies at a time when it
doesn't even have an early alpha-implementation to show for it. Policies
built ar
On 15 feb 2006, at 11.51, Daniel Roesen wrote:
That is one of the reasons we did the NANOG 35 IPv6
multihoming BOF (and are doing the same at the upcoming
apricot meeting).
Which is a good thing. But still, many IETF folks deny the fact that
they constantly hear tha
On Tue, Feb 14, 2006 at 01:47:31PM -0800, David Meyer wrote:
> IETF). Now, while many in the IETF argue that there is no
> such thing as an "operator community", I personally see
> it differently, and there are many of us who think that
> operator input is sorely missing fr
> opportunity for those who can't justify the extra trips to at least have
> some feedback to try and close the loop on protocol design.
Joint meetings are all well and good but are not necessary for
feedback. NANOG folks can join IETF mailing lists here
http://www.ietf.org/html.charters/wg-dir.h
On Tue, 14 Feb 2006, Tony Hain wrote:
A thought I had on the plane last night about the disconnect between the
NANOG and IETF community which leaves protocol development to run open-loop.
[Hm, what happened last night that I missed]
I rather thought today's talk (last one in morning) by Rand
David,
On Feb 14, 2006, at 5:07 PM, David Meyer wrote:
Hmm, well, when there is lots of vendor and academia involvement, no,
there's no operator community presented in number of things I'm
following in the IETF. Take manet, for example, I don't even know to
begin where to inject operator conc
On Tue, 14 Feb 2006 12:35:19 -0800, "Tony Hain" <[EMAIL PROTECTED]>
said:
>
> A thought I had on the plane last night about the disconnect between the
> NANOG and IETF community which leaves protocol development to run
> open-loop.
The real problem is that people have unrealistic expectations wr
Christian
> On Feb 14, 2006, at 4:47 PM, David Meyer wrote:
>
> > Tony/all,
> >
> >>I am not going to speak for the IETF, but why would they? Their
> >>meetings are
> >>already open, and to be globally fair the proposed coordinators
> >>would have
> >>to attend 3-5 extra meetings
trivial,
but it is worth considering.
Tony
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Tuesday, February 14, 2006 1:10 PM
To: Tony Hain
Cc: nanog@merit.edu
Subject: Re: protocols that don't meet the need...
On Tue, 14 Feb 2006 12:35:19 PST, Tony Hain sa
On Feb 14, 2006, at 4:47 PM, David Meyer wrote:
Tony/all,
I am not going to speak for the IETF, but why would they? Their
meetings are
already open, and to be globally fair the proposed coordinators
would have
to attend 3-5 extra meetings a year to cover all the ops groups.
> ---Original Message---
> From: [EMAIL PROTECTED]
> Subject: Re: protocols that don't meet the need...
> Sent: 14 Feb '06 13:10
>
> On Tue, 14 Feb 2006 12:35:19 PST, Tony Hain said:
> > Rather than sit back and complain about the results, why n
Dave
>
> Tony
>
> > -Original Message-
> > From: Eastgard, Tom [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, February 14, 2006 1:01 PM
> > To: Tony Hain; nanog@merit.edu
> > Subject: RE: protocols that don't meet the need...
> >
> > > --
ry 14, 2006 1:10 PM
> > To: Tony Hain
> > Cc: nanog@merit.edu
> > Subject: Re: protocols that don't meet the need...
> >
> > On Tue, 14 Feb 2006 12:35:19 PST, Tony Hain said:
> > > Rather than sit back and complain about the results, why not try to
> > &g
u
> Subject: Re: protocols that don't meet the need...
>
> On Tue, 14 Feb 2006 12:35:19 PST, Tony Hain said:
> > Rather than sit back and complain about the results, why not try to
> > synchronize meeting times. Not necessarily hotels, but within a
> reasonable
> > dis
On Tue, 14 Feb 2006 12:35:19 PST, Tony Hain said:
> Rather than sit back and complain about the results, why not try to
> synchronize meeting times. Not necessarily hotels, but within a reasonable
> distance of each other so the issue about ROI for the trip can be mitigated.
The IETF apparently ha
[EMAIL PROTECTED]
> Sent: Tuesday, February 14, 2006 1:01 PM
> To: Tony Hain; nanog@merit.edu
> Subject: RE: protocols that don't meet the need...
>
> > -Original Message-
> > From: Tony Hain [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, February 14, 2006 12:
A thought I had on the plane last night about the disconnect between the
NANOG and IETF community which leaves protocol development to run open-loop.
Rather than sit back and complain about the results, why not try to
synchronize meeting times. Not necessarily hotels, but within a reasonable
dist
85 matches
Mail list logo
