COMMunities still confusing Dale

Marten,

  Thanks for your answers and your patience.  I think I am no longer
confused.

> I still think
> that community based policies should be avoided as much as possible,
> simply because they won't scale, and will provide more surprises than
> solutions. To me I think you are still thinking of the current NSFnet
> way of doing things. Personally I do not think there'll be communities
> with thousands of routes actually being used for routing. It'll be AS
> based more than anything else. Keeping communities is simply a pain.
> Add some aggregation, and community based routing is even more of a
> problem.

Setting up the initial software to do net-based policy is major job.
Operating it (e.g. the NACR process) is an ongoing expense as well, and
there are additional costs for the additional load that gets imposed
on the routers.  (Some of the AS690 config files are 5 meg).  On the 
other hand, you get an ability to fine-tune things, to make creative
solutions, and to control business situations that you probably don't
have with AS policy.  Given the cost of building a major commercial
network, the extra complexity to be able to control is isn't really
a lot.  But it is the NSPs/ISPs who will end up making the business case
decisions that will eventually decide this.

> Well, do you really think you will need communities with 40+ thousand
> nets? The reason for creating communities is because of different
> policies for various nets inside an AS. Will this still be necessary in
> post NSFnet days? I'd like to see communities more as an exception,
> rather than a rule .... Of course, this is my opinion.

I'm fairly sure that at least two of the ASs at the NAPs will have
net-based policies.  If even one does, then the NAP Route Servers
need to be able to handle that.

> Now, ripe-81++ does not (or should not) contain any details on how the
> ripe-81 style "guarded attributes" are maintained. We think it can be
> implemented through the Notification scheme, but you may have a
> different idea. I like Rick's idea, but it;s got a definate scaling
> problem (if you *really* need 40K+ communities). There's other
> ways (like "on-the-fly" addition of communities from files) or even
> more strict ones. We took the "light-weight" approach...

I appreciate the flexibility;  and the "on-the-fly" approach for whois 
output could turn out to be quite nice.  I do sense a need to document
this stuff somewhere;  perhaps a paragraph in the authorization paper
would do for this round.  We'll write a full document or a section of
one when we get whatever system we end up building up and running.

Thanks again for the answers.  I'll get back with a few more minor
notes on the texts later.

--Dale



-------- Logged at  Tue Oct 4 15:55:13 MET 1994  ---------