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.
Tony
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.
I am also not speaking for the IETF (IAB), but the IAB has
undertaken the task of trying to bring a little of what's
happening in the IETF to the operator community (and
hopefully in the process engaging folks to come to the
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 from the IETF process.
That is one of the reasons we did the NANOG 35 IPv6
multihoming BOF (and are doing the same at the upcoming
apricot meeting).
So (and again, not speaking for the IAB), my perspective
is that we really need your insight and perspectives,
more generally, your help in solving some of the
difficult problems before us (a viable routing and
addressing architecture for IPv6 comes to mind).
All of that being said, I would be glad to facilitate
with the IETF in any way I can. Perhaps someone from the
NANOG PC/SC or Merit can contact me offline and we can
look at with our options are. Any takers?
Dave
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 concerns/requirements. :-/
I think this is as much an IETF issue as it is of the operator community. Operators need to devote time to IETF to make the work in the IETF most relevant to the operators needs.
Best regards,
Christian
Christian
> 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.
>
> I am also not speaking for the IETF (IAB), but the IAB has
> undertaken the task of trying to bring a little of what's
> happening in the IETF to the operator community (and
> hopefully in the process engaging folks to come to the
> 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 from the IETF process.
> That is one of the reasons we did the NANOG 35 IPv6
> multihoming BOF (and are doing the same at the upcoming
> apricot meeting).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 concerns/requirements. :-/
Well taken. And further, I would say manet is more the
rule than the exception in this respect. BTW, it took me
years to become facile with the (IETF) process (if I'm
even there now :-)). I can say that I had excellent
mentoring (Randy and perhaps a few others), so that
helped. Maybe we need something not as formal as an IETF
liaison relationship, but perhaps something like
that. More thinking required...
I think this is as much an IETF issue as it is of the operator
community. Operators need to devote time to IETF to make the work in
the IETF most relevant to the operators needs.
Yes, and this has always been an acute problem as long as
I've been around. People have day (night, weekend
jobs). Co-location of the meetings seems a possible way
to start attacking one aspect that problem, with the
understanding that perhaps travel isn't the biggest of
the problems, but it is a non-trivial issue for many of
us.
Thanks for the great comments.
Dave
David,
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 concerns/requirements. :-/Well taken. And further, I would say manet is more the
rule than the exception in this respect. BTW, it took me
years to become facile with the (IETF) process (if I'm
even there now :-)). I can say that I had excellent
mentoring (Randy and perhaps a few others), so that
helped. Maybe we need something not as formal as an IETF
liaison relationship, but perhaps something like
that. More thinking required...
Thanks for the feedback. I've been following manet as an interested party for a while, with no real mission other than tracking it for emerging technologies R&D. Lately, job is architecting municipal wireless networks (which is really far more than what most people think of when they think Sbux style WISP hotspots). And I'm looking at the IETF for what's been worked out so far with respect to wireless routing protocols for example, and I just can't help sitting here scratching my head about how I would ever use what they've come up with so far. And right now, I really can't without major modifications it seems. And I find that really sad actually.
And, don't get me wrong, but I'm not trying to bash them at all. I just think that real world operations needs and concepts like wholesale access aren't even anywhere near the radar screen it seems. And that somehow needs to be fixed. And, yes, municipal wireless is a roller coaster that's still gathering speed, so, expecting that everything's already grown and ready for us are thoroughly unrealistic. But! 
Right now the routing protocol on the mesh side will likely be proprietary for some time, which really isn't in the operator's best interest but that's what we have to work with. I/we have a substantial interest in this becoming more than an academic PhD thesis exercise, but something that can really be practically used in the real world.
Now, there is stuff in the MPLS community, for example, that I've followed more or less closely for the past 7 yrs that might actually be fruitful, but it too requires substantial tailoring. So, no worries about job security there.
I think this is as much an IETF issue as it is of the operator
community. Operators need to devote time to IETF to make the work in
the IETF most relevant to the operators needs.Yes, and this has always been an acute problem as long as
I've been around. People have day (night, weekend
jobs). Co-location of the meetings seems a possible way
to start attacking one aspect that problem, with the
understanding that perhaps travel isn't the biggest of
the problems, but it is a non-trivial issue for many of
us.
Agreed. I'm headed to the IEEE 802 plenary in a couple of weeks to start working standards body stuff for us as well, some of what needs to happen is lower layer stuff. The less trips and the more I can combine them, the more likely my management will look at my travel expense submissions in a favorable light ;-).. So, the more incentive we can provide with that, the better.
A while back, there was a desire to colo ARIN with NANOG. That's really cool to see happen. For me, no offense to anyone, I really couldn't care less at the moment. I'm on the opposite side of the spectrum, ARIN being a vehicle for operationalized networks rather than those who are about to be operationalized. So, perhaps NANOG should be paired up with other industry forums in some kind of rotation.. Anyone got ideas on this?
Best regards,
Christian
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 from the IETF process.
The problem with IETF and IPv6 is from my perspective, that operator
input is being rejected as unreasonable or just ignored (shim6). I've
stopped wasting time trying to bring operator's views/points across.
It's not welcome if it doesn't fit already existing views within IETF
regarding IPv6. I know that a lot of active IPv6 folks think the same
but hesitate to communicate that openly.
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 that things like shim6 is NOT what the ops folks
(the folks that have to actually work with the stuff IETF brings
forward) are looking for. And we know that it doesn't. It can't.
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 economics. That's aside all the
other administrative nightmares associated.
So (and again, not speaking for the IAB), my perspective
is that we really need your insight and perspectives,
more generally, your help in solving some of the
difficult problems before us (a viable routing and
addressing architecture for IPv6 comes to mind).
I firmly believe that this train for IPv6 is long gone. We should go
forward with IPv6 using the legacy routing architecture and start NOW
working on a complete real re-vamp with a PROPER locator/identifier
split - not an ugly hack ontop of the traditional IPv4/IPv6 like shim6
which doesn't deliver what ops folks need.
Nevertheless, I really welcome IAB's efforts in the matter.
Best regards,
Daniel
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 that things like shim6 is NOT what the ops folks
(the folks that have to actually work with the stuff IETF brings
forward) are looking for.
I think YOUR problem is that the chairs in an IETF WG gathers consensus of the members.
Additionally I would like to point out that on shim6 specifically I also meets representatives of fairly large providers that see new opportunities with shim6 or id/loc split solutions. To Dave's point that there are people "in IETF" that don't think there is an operator community I would like to add that there certainly is an operator community but their views are not homogenous. And neither is any other groups. Which makes the job of any IETF WG chair to judge consensus among the representatives in a particular WG to do just that, gather consensus and move forward.
And we know that it doesn't. It can't.
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 economics. That's aside all the
other administrative nightmares associated.
I would like to argue that TE in the general case is orthogonal to upstream/downstream/peering. I am not clear if you are trying to voice concern that you can not do TE, or that shim6 will not give you the ability to control how your customers does TE, or something else.
- kurtis -
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 around shim6 may be ok in 5 or 10 years if or when it is mature
with supporting technology to handle large networks, but not now. In the
meantime we need a policy that can accomodate the need for multihoming
of end-sites with *existing* technology. Without such a policy we will
have anarchy with LIRs making their own policies (fragmentation) and
people telling lies to qualify as a LIR to obtain independent blocks
(unless there's a way to delay v6 deployment until there is technology
available to back the current policy).
//per
David,
>>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 concerns/requirements. :-/
>
> Well taken. And further, I would say manet is more the
> rule than the exception in this respect. BTW, it took me
> years to become facile with the (IETF) process (if I'm
> even there now :-)). I can say that I had excellent
> mentoring (Randy and perhaps a few others), so that
> helped. Maybe we need something not as formal as an IETF
> liaison relationship, but perhaps something like
> that. More thinking required...Thanks for the feedback.
Any time.
I've been following manet as an interested
party for a while, with no real mission other than tracking it for
emerging technologies R&D. Lately, job is architecting municipal
wireless networks (which is really far more than what most people
think of when they think Sbux style WISP hotspots). And I'm looking
at the IETF for what's been worked out so far with respect to
wireless routing protocols for example, and I just can't help sitting
here scratching my head about how I would ever use what they've come
up with so far. And right now, I really can't without major
modifications it seems. And I find that really sad actually.
That is a perfect example of the reason why we need more
"reality clue" (or whatever) from the ops community in
the standards process (choose your SDO). IMO, of
course; others will (strenuously) differ with me.
And, don't get me wrong, but I'm not trying to bash them at all. I
just think that real world operations needs and concepts like
wholesale access aren't even anywhere near the radar screen it
seems. And that somehow needs to be fixed. And, yes, municipal
wireless is a roller coaster that's still gathering speed, so,
expecting that everything's already grown and ready for us are
thoroughly unrealistic. But!
Sure, understood.
Right now the routing protocol on the mesh side will likely be
proprietary for some time, which really isn't in the operator's best
interest but that's what we have to work with. I/we have a
substantial interest in this becoming more than an academic PhD
thesis exercise, but something that can really be practically used in
the real world.Now, there is stuff in the MPLS community, for example, that I've
followed more or less closely for the past 7 yrs that might actually
be fruitful, but it too requires substantial tailoring. So, no
worries about job security there.>>I think this is as much an IETF issue as it is of the operator
>>community. Operators need to devote time to IETF to make the work in
>>the IETF most relevant to the operators needs.
>
> Yes, and this has always been an acute problem as long as
> I've been around. People have day (night, weekend
> jobs). Co-location of the meetings seems a possible way
> to start attacking one aspect that problem, with the
> understanding that perhaps travel isn't the biggest of
> the problems, but it is a non-trivial issue for many of
> us.Agreed. I'm headed to the IEEE 802 plenary in a couple of weeks to
start working standards body stuff for us as well, some of what needs
to happen is lower layer stuff. The less trips and the more I can
combine them, the more likely my management will look at my travel
expense submissions in a favorable light ;-).. So, the more
incentive we can provide with that, the better.
I talked a bit with the (relatively new) IAD (IETF
Administrative types) about what might be done here. This
is something that will take some thought and if anything
comes of that, some serious planning.
A while back, there was a desire to colo ARIN with NANOG. That's
really cool to see happen. For me, no offense to anyone, I really
couldn't care less at the moment. I'm on the opposite side of the
spectrum, ARIN being a vehicle for operationalized networks rather
than those who are about to be operationalized. So, perhaps NANOG
should be paired up with other industry forums in some kind of
rotation.. Anyone got ideas on this?
Re NANOG/ARIN: The times I've been involved in the joint
meetings I've found them very useful.
Dave
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.
PI space for multihoming and AS number growth is a bad thing for scaling and economics, however you look at it.
Shim6 would hopefully curb the prefix growth very early in the growth curve as single entities won't need AS to multihome between two different ISPs.
I do believe in a completely new solution for multihoming than what we have today, shim6 is the first I've seen so far, I'm open to other suggestions though. Current way of doing it (AS+PI) gives me the creeps when I extrapolate into the future.
I am certainly no fan of the current rule-set and I have been known to look favourable to a more relaxed ruleset as an intermediary step. Personally I think we should drop the 200 customer rule and give a prefix to all LIRs for the timebeeing. Actually the RIPE community once decided that as the policy...
- kurtis -
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/maillists/nanog/historical/9509/msg00047.html
People had scaling problems back then because routers
were less powerful. They solved those scaling problems
without rushing to the vendors, checkbook in hand.
You might want to review some of the other discussion
on NANOG during that month, September 1995, to see
what people were saying about topological addressing.
PI space for multihoming and AS number growth is a bad thing for scaling
and economics, however you look at it.
I disagree. I think the Internet can scale the current
routing model to 8 million routes using proxy aggregation,
filtering and geo-topological allocation of IPv6 addresses to
multihomers.
Shim6 would hopefully curb the prefix growth very early in the growth
curve as single entities won't need AS to multihome between two
different
ISPs.
Who wants to use a technology that will not let them
get to Yahoo and other major websites? Shim6 is dead.
We either change the routing architecture entirely
or we find better ways to aggregate and filter so that
the global routing table only has routes that need to
be visible everywhere to everyone. Talk to Owen Delong
if you think we need to change the whole architecture.
In any case, creative thinking is what is needed. Not
scary linear extrapolations.
--Michael Dillon
Daniel,
> 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 from the IETF process.The problem with IETF and IPv6 is from my perspective, that operator
input is being rejected as unreasonable or just ignored (shim6). I've
stopped wasting time trying to bring operator's views/points across.
It's not welcome if it doesn't fit already existing views within IETF
regarding IPv6. I know that a lot of active IPv6 folks think the same
but hesitate to communicate that openly.
I understand your point, and hey, you're not the only one
who sees it this way (and IPv6 isn't the only area where
this problem is perceived to exist).
Suppose we stipulate that your perspective (which is
shared by many), namely that operator input is being
rejected/ignored, is true. Then if we agree that IPv6 is
here (for some value of "here", and as you mention
below), then we need to find a way to solve the problems
that we've been talking about here. My sense is that the
likely place to do that is in the IETF (being the SDO
that does this kind of work).
So if you agree with what I've said above, how do we
break the impasse and move forward? Like you, I'm
interested in forwarding our common set of goals, and it
seems pretty obvious that we need to find (or revive) a
scalable routing architecture for IPv6. So lets find a
way to do that (BTW, if I had the answer, I'd be the
first to provide it. This is pretty thorney, as you've
pointed out).
> 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 that things like shim6 is NOT what the ops folks
(the folks that have to actually work with the stuff IETF brings
forward) are looking for. And we know that it doesn't. It can't.
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 economics. That's aside all the
other administrative nightmares associated.
So I started writing up a I-D (the IETF coin of the
realm) on this topic, but got sidetracked making slides
for Apricot. I'd welcome anyone who wants to help me with
that document (my approach was to outline the issues as a
basis for bringing this discussion into the IETF). I
could use the help. BTW, the doc is called
Issues In Traffic Engineering with SHIM6
draft-meyer-shim6-and-te-00.txt
but I haven't published it yet. Again, anyone who wants
to contribute/write/whatever, insight/thoughts greatly
appreciated.
> So (and again, not speaking for the IAB), my perspective
> is that we really need your insight and perspectives,
> more generally, your help in solving some of the
> difficult problems before us (a viable routing and
> addressing architecture for IPv6 comes to mind).I firmly believe that this train for IPv6 is long gone. We should go
forward with IPv6 using the legacy routing architecture and start NOW
working on a complete real re-vamp with a PROPER locator/identifier
split - not an ugly hack ontop of the traditional IPv4/IPv6 like shim6
which doesn't deliver what ops folks need.Nevertheless, I really welcome IAB's efforts in the matter.
Thanks, that is much appreciated.
So on the theory that the best way to finish a task is
to start it, let's start working on the document I
mentioned above (if folks want to). If folks have other
ideas, lets get those on the table too.
Dave
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).
Date: Wed, 15 Feb 2006 16:31:56 +0100 (CET)
From: Mikael Abrahamsson
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.PI space for multihoming and AS number growth is a bad thing for scaling and
economics, however you look at it.
I'm going to suggest something horribly radical (or nostalgic,
depending how long one has been in the industry): inter-provider
cooperation.
Let's examine _why_ the routing table might become large. Lots of
smaller players multihoming, yes? Say two million small businesses
multihome using SBC and Cox. Must we have two million global ASNs and
routes?
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 very similar to a downstream using a private ASN to connect to
one upstream in two different locations. i.e., transit provider uses
the same ASN for all such customers, and certainly needn't pollute the
global table with longer prefixes.
We're dealing with _one_ routing policy: hand it to Cox, or hand it to
SBC. Why explode it into two million "different" policies?
Look at MPLS. It essentially hunts down congruent or similar routing
policies, slaps a tag on the packet, and routes based on that. Why not
explore options that get it right and coalesce from the get-go?
Note also that this is totally op-community. No new protocols required.
It can be done today without forklifts.
I thought I proposed this at 35. Maybe that was one of the open mic
sessions where time ran out...
Eddy
This is unworkable obviously: Think next about SBC and (say) Verizon customers, then what about those with Cox and Verizon, then SBC/Cox/Verizon. etc.
regards,
Date: Wed, 15 Feb 2006 19:02:11 +0000 (GMT)
From: Paul Jakma
> 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
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 "unworkable obviously"? No.
customers, then what about those with Cox and Verizon, then SBC/Cox/Verizon.
etc.
Yes, one ASN is required per cooperating pair. Just how many pairs do
you think there are? Now compare with the number of leaves that [would
[like to]] dual-home.
If you have 100 providers, each cooperating with every single one of the
others, that's
100 * 99 / 2 = 4950
different ASes. Noticeable, but still a long way from 4-octet ASN
territory. And guess what? Each downstream would need its own ASN
otherwise; this is just one ASN per cooperating pair.
How many transit ASes are there? And will each one share a downstream
with all of the others?
I'll hazard a guess that a transit cooperates with, on average, no more
than five different other transits. Ergo, linear scaling.
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.
Eddy
Edward B. DREGER wrote:
> Date: Wed, 15 Feb 2006 16:31:56 +0100 (CET)
> From: Mikael Abrahamsson> 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.
>
> PI space for multihoming and AS number growth is a bad thing for scaling and
> economics, however you look at it.I'm going to suggest something horribly radical (or nostalgic,
depending how long one has been in the industry): inter-provider
cooperation.Let's examine _why_ the routing table might become large. Lots of
smaller players multihoming, yes? Say two million small businesses
multihome using SBC and Cox. Must we have two million global ASNs
and routes?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 makes a lot of sense.
However, as one of those smaller players, who may be multihomed
using SBC and Cox, as your example says, I can fairly say
that I don't like renumbering very much, and sometimes one
finds there is a good business case to be made to switch providers,
In short, having an ASN is good for me, if not for the community
at large, so how to balance that?
Right now, gettin ONE upstream to issue a private asn can be
like an amatuer dental extraction, imagine 2 that don't like each other,
or more often are totally ambivalent with regards to the others
concerns/cares/policies/proceedures, et al. One says xxx00, and
the other xxx01, how am I supposed to sort this out?
This is very similar to a downstream using a private ASN to connect
to one upstream in two different locations. i.e., transit provider
uses the same ASN for all such customers, and certainly needn't
pollute the global table with longer prefixes.
mmmm, okay,
We're dealing with _one_ routing policy: hand it to Cox, or hand it
to SBC. Why explode it into two million "different" policies?
Are we? Or are we dealing with _one_ routing policy: handing
it to Cox AND handing it to SBC, who mediates? Right now, it
appears as if it would me, the end-user. I'm just not equipped for that.
Look at MPLS. It essentially hunts down congruent or similar
routing policies, slaps a tag on the packet, and routes based
that. Why not explore options that get it right and coalesce from
the get-go?
Note also that this is totally op-community. No new protocols
required.
It can be done today without forklifts.
Agreed. Good idea. Nice idea, very appealing, really.
I just don't know how it would play out in practice between
two providers, who as we have seen over recent short history
don't necessarily work and play well together.
[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!
PI space for multihoming and AS number growth is a bad thing for scaling
and economics, however you look at it.
agree!
Shim6 would hopefully curb the prefix growth very early in the growth
curve as single entities won't need AS to multihome between two different
ISPs.
agree!
[snip]
All is well if shim6 succeeds it seems ... 5-10 years into the future.
Do we all agree to postpone v6 till then?
If not there's a need for an intermediary solution. To me it seems like
people want 2 things:
1. A working solution. The only alternative with current technology is
PI end-site assignments.
2. Reasonable predictability. To make ever-lasting technologies and
policies may be the dream in some research communities. The rest of us
have to work with what we got and accept that we have to upgrade and
make substatial changes to our networks from time to time. An
alternative to satisfy those who fear the long term effect of a growing
routing-table could be temporary end-site assignments from dedicated
address-blocks. At some point in the future, when new-and-mature
technology exist, the RIR-community could decide on new policies and
decide to re-claim the entire block on e.g. a 24-month notice.
... just my $.02 compromise
//per
Date: Wed, 15 Feb 2006 14:37:44 -0500
From: Chip Mefford
> 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 makes a lot of sense.
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 suggest.
However, as one of those smaller players, who may be multihomed
using SBC and Cox, as your example says, I can fairly say
that I don't like renumbering very much, and sometimes one
finds there is a good business case to be made to switch providers,
In short, having an ASN is good for me, if not for the community
at large, so how to balance that?
Changing ASNs is easy for small, one-router installations. Renumbering
would still be necessary, but that's no different than the status quo.
i.e., my proposal does not make this worse. That said, let's think if
we can improve in that area.
Right now, gettin ONE upstream to issue a private asn can be
like an amatuer dental extraction, imagine 2 that don't like each other,
or more often are totally ambivalent with regards to the others
concerns/cares/policies/proceedures, et al. One says xxx00, and
the other xxx01, how am I supposed to sort this out?
RIR-issued public ASNs. I probably should have merged the "truly
radical" thread with this one.
> We're dealing with _one_ routing policy: hand it to Cox, or hand it
> to SBC. Why explode it into two million "different" policies?Are we? Or are we dealing with _one_ routing policy: handing
it to Cox AND handing it to SBC, who mediates? Right now, it
appears as if it would me, the end-user. I'm just not equipped for that.
Exactly. It's _one_ routing policy. Not equipped? A little SOHO
router could easily accept default and advertise a prefix or two via
BGP. Once upon a time a 2500 held a full table; consumer-grade routers
of today boast better CPU and RAM.
Okay, so consumers must flash new firmware or forklift their $100
router. Oh well.
I just don't know how it would play out in practice between
two providers, who as we have seen over recent short history
don't necessarily work and play well together.
In which case it's time for consumers to vote with their wallets. Or,
if that's not possible, perhaps the FCC and SEC (in the USA) need to
evaluate certain providers. Hence the "radical" aspect of the
suggestion.
Eddy