Presuming that the existing BGP community space is all we have to work
with right now, and that we're operating networks right now, so we
need something that works right now, it might be better to look at
what we can do as a level of abstraction right now.
Thinking about the data to be communicated, we're looking at verb/noun
Prepend once (verb: prepend, noun: 1)
Export to Chile (verb: export, noun: Chile)
Deny All (verb: deny, noun: all)
Collect enough nouns and verbs, and it follows that you can have a
language, where the specific communities might be in a common database
(e.g. PeeringDB*), and networks can say that they support a (yet to be
specified) standard 10-15 verbs with some set of nouns. Most
networks will not have a need for (say) "Export to Chile", but being
able to construct it in a standard way is the important part.**
Having sorted through more than a few BGP community documents from
large networks, constructing a set of operators that covers most cases
probably involves 5-10 networks.
* No affiliation beyond satisfied user.
**It necessarily follows that standard nouns and verbs need standard
definitions. Not everyone means the same thing when they say
"Export." That would likely be the subject of a different draft.
On Wed, Sep 21, 2016 at 12:10 PM, Christopher Morrow
> On Wed, Sep 21, 2016 at 12:02 PM, Robert Raszuk <rob...@raszuk.net> wrote:
>> But it already there ... it is even WG document ..
> i'm unclear how this is helping this dicussion.
>> On Wed, Sep 21, 2016 at 2:05 PM, Nick Hilliard <n...@foobar.org> wrote:
>>> Robert Raszuk wrote:
>>> > If something as you admit is critical to operators to run the network
>>> > shouldn't it be maintained by IANA registry rather then sit on private
>>> > web sites ?
>>> if you are seriously suggesting this, then we look forward to your
>>> Internet Drafts.
> I think nick/jared/gert/jzp/mikael (all operators) have all said that
> registering the usecases today isn't helpful, that some of these usecases
> are not public (by design) and that they have evolved over time.
> I'd like to see the generalized set of these captured in a
> document/reference though, which is something grow can / should do ... and
> then use that as the requirements set going forward (updated as Gert/etc
> find new requirements of use to their networks). Getting focused on
> byzantine corner cases isn't helpful, so generally useful requirements
> should be a goal. This should make the IDR side of life simpler and it
> should help vendors stop telling me, mikael, jared all: "Hey you're the
> first to ever ask for this, wow!" (because actually we've had to configure
> these things between us... so we know we're all asking for this 'feature' -
> insert feature-du-jour-discussion)
> GROW mailing list
GROW mailing list