Last gasp on Communities

Pardon me for dragging up this "Community" issue one last time.  I think
Marten's comments below do make this all clear, but I'll take this last
chance again to make sure that I'm not misunderstanding, now that the
documentation is about to become final.

  If I want to create a community:

     1) I must create and register the Community object.
     2) I then ask the maintainers of the Route objects which should
	  be in that community to add my new community name to their
	  Route comm-list attributes.
     3) I get a mail message each time the new community name is added to
	  or deleted from any Route object.

If this is correct, you might want to add a few sentences like these to
the Auth document.  (Or, if this doesn't belong in the Auth document,
it really ought to be written down somewhere, including in the upcoming
training courses).

--Dale


>  * 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  Tue Oct 4 16:36:56 MET 1994  ---------