On Oct 24, 2005, at 5:12 AM, Mark Tinka wrote:
That's a little dangerous! That means all ISP's are in the
same AS. More than likely, as the days go by, there will
be filtering issues as well as BGP policy issues, since a
route reflector approach essentially makes all ISP's one
ISP.
AFAIK all ISPs have their own AS numbers. The exchange has its own AS
number as well. ISP routers receive updates from the IX router, and
send updates to their peers. Each ISP set their router up and should
have (were told to and shown how to) set up ingress and egress route
advertisement filters for their BGP advertisements.
GIX can always move to a hybrid model. These are the training wheels
and my guess is that ISPs will go how and where they really want to.
GIX should just try and make life easier for them and to keep the
network stable, fast and secure as possible, recognizing that they
may have different needs and priorities.
This is the model the KIXP (.ke) took, and have since been
trying to rectify the situation. Forget scaling, this is
just not the way to do it.
Very interesting. I need to understand the issues behind these
things, from the point of view of the network operator. How have they
been trying to rectify the situation, and what is the situation that
needs to be rectified? How many ISPs are at the Kenya exchange?
I worked with some .gh folk on this, and thought they'd be
taking the more typical approach.
Which is ... hybrid? Full mesh?
The full mesh approach will work for the cases where
you have operators who know exactly what they are
doing.
Well, the requirements in the initial stages of the
exchange point are not entirely heavy that you need a
degree in the thing :), but I know folk in .gh who are
capable of running BGP at a basic level.
Well, one of the guys who had problems that I saw knew the Cisco
commands down cold but wasn't able to understand the concepts behind
BGP really well, so it was a bit like on autopilot but off course.
I'm sure he will pick up fast once he has a cookbook, or receive
implementation support from a more senior person.
Me, on the other hand was an equally lost soul, I had never touched a
router before, so I was a little intimidated and frustrated. e.g what
is the name of the interface I just plugged my cable into, or I want
to ping/traceroute and just don't know its built in, or I like to
edit config files with comments, not eyeball the output of 'sh run'
where you have to enter some nook and cranny in the command structure
to change something. I don't even understand why am arguing with you :-)
Maybe I should just edit these things in a normal machine and shoot
it all at once to the router. I saw someone with a very cool Mac OS X
(which is what I run now) tool that made it work like a context
sensitive file editor, so maybe that's just a hassle when working on
the command line. One of these days, maybe I'll get an IOS router, so
that I can understand them better.
Peering with each other is like peering with a single
router, except that you are repeating the configuration
for different peers, and have more long term flexibility.
Yes. Also more hurdles along the way, approval here, negotiation
there. My problem is that our organizational processes move slowly.
Maybe its different in East/South Africa, but I'd rather not have to
contend with approvals, decisions etc because it wastes time and
makes people have to drive to other offices several times etc. So no
red tape. Full speed ahead - crash if you want to, it's your car.
If you want to run things more your way, why not filter out what you
don't want? I see that complexity or tedium could emerge from either
N peers having to configure N - 1 peers, or some peers having to
contend with filtering from a set of N(N - 1) routes.
So it's either a complexity problem or a coordination problem. Do I
have the tradeoff right in my imagination?
But it also invites undue meddling via industry
politics.
Please elaborate, not sure I understand what you mean
here.
I guess it is the same reason it took so long to have an exchange.
Business distrust, lack of cooperation etc make ISPs tend to be
insular unto themselves rather than to interweave into a local network.
Since the dynamics are to throw them apart from each other, we should
make it easier to make them cooperate enough (at least in the one
limited area, the exchange, where the priority is utilizing local
bandwidth where possible).
So it makes sense to have peering by default in such a scenario. You
aren't chaining them to each other but you are making it a PITA to
instead not peer. I'd rather it was their PITA than everyone's.
I think it is a good idea to make it peer by
default, not the other way around.
This is another issue that has raised a lot of debate.
Should peering be mandatory, or not? At one of the
workshops we did for .bw (their BINX is now up and
running), one of the ISP's refused to peer with the
other, and as much as they were being urged to by their
ISPA, the last time I checked they hadn't reconsidered.
Yes. These are the kind of stunts that amaze me. Peering is a basic
decision that is really a no brainer. These are decisions that I
think are taken without real understanding or as cynical,
grandstanding brinkmanship in some hardball business environment.
If they won't peer, then why are they at the exchange at all? In
fact, why an exchange in the first place?
The shameful thing is that is exactly what it will take to allow them
to grow into 'mini telcos'. We should be building up our local
interconnectivity so that we become attractive as a destination.
A river delta is very rich for farming, and so is a well connected IX
(and by extension, local internet) is the analogy I would like to use
here.
Different networks will peer for different reasons. To be
free and fair, forcing an ISP to peer with another isn't
going help the IXP's cause.
My observation here is that the big ISPs used peering to lock out the
little guys. They peered with each other only, was what ended up
happening. That doesn't make any sense to me except if it was more an
argument of who should control the peering point while all understand
the need to and benefit from peering. I don't think though that
policy should be like an iron fist on this. More like, do what you
want to, but don't disrupt what we are doing.
I can't seem to understand your point of view. What experiences have
you had that make you see it this way? Or is it that you prefer to
maintain as much control of operations as possible in order to
deliver the best service within your capacity? If so, then what
policies would you advocate and put in place? Also, I'd like to look
at this more from a policy perspective rather than a technical
perspective.
-- G.
_______________________________________________
LUG mailing list
[email protected]
http://kym.net/mailman/listinfo/lug
%LUG is generously hosted by INFOCOM http://www.infocom.co.ug/
The above comments and data are owned by whoever posted them (including
attachments if any). The List's Host is not responsible for them in any way.
---------------------------------------
