random idea: constraint communities

[Sean M. Doran]

Gosh, email on Ptomaine - growth of the routing table list, 
relevant to a discussion at the last BoF. :-) :-)

In order to solve Geoff's "action-at-a-distance" problem wrt leaked
longer prefixes, I was wondering if anyone could sanity-check an idea
that occurred to me in the shower today.

Well-known-community-PREFIX: 65535.  Suffix=ASN to which we DO NOT ANNOUNCE
                             65534.         ASN to which we DO ANNOUNCE

The semantics of the first community seems straightforward: routers
which see 65535:1755 will not announce the NLRI to AS 1755.
This is an anti-generalization of an existing well-known community,
and a consolidation of lots of ASN:XXX private communities that have
the same (but non-transitive, and non-global) semantics.

The problem is what to do in a router which cannot grok communities,
or these specific communities.  Perhaps routers in 1755 in this example
should discard prefixes they receive with 65535:1755 set.

WRT the 2nd prefix, we only announce to ASes explicitly enumerated
by 65534-prefixed communities; we do not announce to ASes not so enumerated.

The problem here is what happens if a router which does not constrain
reannouncement hears the NLRI because it is in an AS explicitly listed
with a 65534-prefixed community.  (i.e., a "leak")

I figure that these two tools should give people like Geoff a chance
to influence cooperative ASes some hops away from himself, by sending
them "tailored" (e.g. more-specifics) routing information without
that information necessarily becoming global.

	Sean.