A Modest COMMunity Proposal

Marten, Tony,

  I have a very modest proposal for the COMMunity-handling code, which has
a slightly  complicated agenda behind it.  I believe this would be an 
implementation detail which would have no implication for any current
document.

  PROPOSAL:  That the RIPE DB code that reads COMMUNITY files be written
in such a way that only the IP/LEN at the beginning of each line be read;
that anything after that initial IP/LEN (and trailing whitespace) would
be considered as a comment by existing code.



  COMPLICATED RATIONALE:  We have this "DBSELECTOR" thing that we need
to implement in order to be able to do net-based policy (particularly
for AS690).  One possible architecture for the DBSELECTOR data format
would be to make it an extension to the COMMunity object.  The current
definition of the COMMunity object and its usage would not change
(except for declaring anything past the first whitespace character to
be of no interest to the code).  Any current COMMunity file would
fulfill its present funciton without changes.

  Those who had need, though, could add text tokens to the COMMunity lines,
which could be "grep'd" by the DBSELECTOR function.  Specifically, I could
create a COMM_AS690 file with the following format:

       #
       #  COMM_AS690 - Community Definition for ANSNet/NSFNet
       #
       #  Format:  IP/Len [metric:AS(NSS) [metric:AS(NSS)] ... ]]
       #
       6.0.0.0/8  1:568 2:19
       7.0.0.0/8  1:701(136) 2:701(134)
       ...

Our DBSELECTOR syntax could then be used to produce sets of networks, 
one set for each metric:AS(NSS) token that exists in the file.  If we
don't have a feature that gives us this kind of functionality, we may
be forced to create 300+ specially-named COMMunity files just to be
able to represent AS690 policy.  (And another 300+ for MCINet, and 
another for SPRINTNet, ... )

-----------------------------------

If you and Tony (and Daniel, when he gets back) consider this at all
reasonable, we could expand the discussion to more detail.  For instance,
this information also really needs to be copied into the public database
somewhere.  Currently, for AS690, it is in the about-to-be-retired nsf-in
attribute.  If we used the 300+ community approach, it would end up in
the Route object, as a series of community names:

   Route:  	6.0.0.0/8
   Communities: COMM_AS690_1:568 COMM_AS690_2:19 COMM_ASMCI_1:568 ...

It might be useful to create a new Route attribute specifically for these
AS-specific purposes:

   Route:  	6.0.0.0/8
   Communities: HEPNET COMM_AS690 COMM_ASMCI
   COMM_Details: COMM_AS690   1:568 2:19
   COMM_Details: COMM_AS<MCI> 1:567 2:53

There are a number of fundatmental issues which tie into this:  who owns
the data, how is it changed, (how often is it changed;  how expensive is
that operation), whether that info is fully public (e.g. contained in the
ftp of ripe.db), etc.  This is only one of a number of possible
implementations that I think it would be good for everyone on this list
to discuss (presumably mostly after the Lisbon meeting, since this would
not be part of RIPE-81++).

But since you are finishing up the next release of the code, I thought
I'd suggest the addition of the one inoccuous line to the code that reads
COMMunity files that would keep this approach from breaking things in the
future.

Thoughts?

--Dale





-------- Logged at  Thu Sep 8 21:54:52 MET DST 1994  ---------