>Well said Howard, I always believe reading Halabi's book only makes
>understand BGP and know how to configure it on Cisco. But there is no way
>you can play a peer router in a NAP just based on that knowledge. You will
>mostly screw it up.
>As you said, most of things are not documented, it is really hard to find
>good reference on how to setup an ISP from scratch.
At a certain level, this is good. At another level, it is bad.
I was chatting yesterday with a colleague. Both of us have medical
backgrounds, and made an analogy between heart surgery and ISP-level
routing. It's been statistically demonstrated beyond any serious
challenge that your outcome as a heart surgery patient depends on how
often the surgeon AND the whole team/hospital does the procedure.
It's completely unreasonable to assume that a primary physician will
be trained in such procedures, and it is also unreasonable to assume
that an "occasional" heart surgeon will be good at it.
It's one thing to set up a local ISP or a multihomed enterprise, and,
even there, there is a need for what I'll call maturity of networking
experience. How many people post questions here, asking how to "load
share," without any indication of what problem they are trying to
solve, the source (if any of their address space), the nature of
their applications, etc.? If you can't define what problem you are
trying to solve, how would you recognize a good solution?
>Looking forward to your book. I would suggest that if you could put more
>real cases/examples of setup peer routers, verify/update peer policy and
>trouble-shooting routing problems.
While my focus is more planning than operations, I'll probably have
some of this. My inclination would be to use registry-based tools
(e.g., PRTraceroute) that emphasize policy, with specific
single-vendor examples at a much lower priority.
>Also it would be great if you could,
>based on your wide contact in the industry, give us something like this, for
>example:
>This is how UUnet updates their peer policy everyday, they use a Perl script
>to grap daily updates from whois.radb.net database, and automatically update
>their peer routers. The script looks like this:xxxx. Other ISPs do it other
>ways like xxxx uses xxx and xxx uses xxx.
Interesting that you mention UUnet as an example. Several
observations: first, the procedures that a large "tier 1" uses may
not be relevant to smaller providers. Second, many of these
procedures are considered proprietary, although I consider that a
little silly given the movement of senior routing engineers.
UUnet Europe did present some of their routing policy procedures at
the RIPE meeting last year. A great deal of this was controlled by
data base technologies. They created, for example, a hierarchy of
AS-SETs with which a router could peer, roughly at intercontinental,
continental, regional, and local levels. A routing engineer at a
certain level could only peer to a predefined set of AS. The data
base software let them distinguish between who could modify the sets,
who could delegate access (of various sorts) to these sets, and who
could use the sets.
I would hesitate to try to define the actual scripts, because they
tend to be very provider-specific (e.g., being very tied to their
ordering/provisioning systems). I have presented some script
prototypes for managing customer addressing and related topics; see
my ARIN October 1999 and subsequent NANOG addressing presentations.
>
>I bet most of people, especially who works for ISPs but not at the top
>level, would pay their money for.
>
>Just my 2 cents.
>KY
_________________________________
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
