COMMunities still confusing Dale

Hi Dale,

 * Ripe-181 still says (p 27):
 * 
 *     The community tags can only be created and updated by the "guardian"
 *     of the community and not by those directly responsible for the 
 *     particular network.  This ensures that community guardians remain
 *     in control of community membership.
 * 
 * This still seems to imply some mechanism with the functionality of a
 * guardian file, where the owner of the community decides which Route
 * objects are stamped with the community name.

I think we have overlooked this bit of ripe-81++, it needs to be
changed to reflect the bits in the Authorisation paper.

 * Auth (p 9) says:
 * 
 *     Note that this rule changes the level of membership control
 *     exercised by community and AS guardians have with respect
 *     to the "guardian file" method.  Control is now by notification
 *     after the fact.
 * 
 * This implies that anyone entering or modifying a Route object can
 * mark it as belonging to any community he wishes--and that the community
 * owner just gets email afterword.  It also sounds to me (without further
 * explanation somewhere) as though someone wanting to create a new
 * community would have to find all of the owners of all of the routes
 * that should belong to that community, and would have to contact them
 * out-of-band with messages saying "I've just created this new community
 * COMM_GOODGUYS, would you mind editing all of the following routes to
 * include COMM_GOODGUYS in their comm-list attribute?".  To create the
 * NSFNET community in your example, we would have to make out-of-band
 * requests to the 464 ASs that are currently submit have registered
 * NSFNET routes in the PRDB, asking each of them to modify their
 * entries

Basically yes, they would have to. Or, with the current implementation
of the authorisation, just send it in with the correct community,
and the proper maintainer will receive the request. 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.

 * for us.  It would also imply that the Guardians still need to keep a
 * file of who they think *should* be members of their community, though
 * now this file has moved from being a Guardian File hosted on a Routing
 * Registry machine to being something that keep privately for their own
 * use.

Yes.

 * Am I still misunderstanding?  Is there a section of the new drafts
 * that

Noop.

 * I've missed, or a new document that will explain this that will be out
 * soon?  Sorry to be pushy on this;  we need to be coding this functionality
 * this week in order to configure the Route Servers, and we're trying as
 * hard as we can to do it within the RIPE-181 framework.
 * 
 * If I do have this right, the Community structure seems unusable for
 * storing net lists for use in local configuration generation.  The best
 * solution I can see for adding the functionality we need would be the
 * one Rick suggested Friday:  add a new object for that purpose which
 * could be used with the experimental DBSELECTOR to come up with specific
 * net lists.  This is essentially what Laurent has implemented in alc,
 * except that those lists are in private files that only alc knows about,
 * rather than being part of the Routing Registry that is visible through
 * whois, ftp dumps, etc.  Again, assuming I'm not still misunderstanding
 * the new community implementation, does this sound like the most
 * RIPE-181-like implmentation we can come up with for storing local
 * routing info for our 40K registered routes, while still making that
 * information available as part of the registry?  Any other ideas?

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.

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...

-Marten



-------- Logged at  Mon Sep 19 00:59:22 MET DST 1994  ---------