I thought about something like this with extended communities before I wrote my draft. There is no order to communities. They can come in any order and routers can change the order. Routers will remove duplicate communities. So, you can only use any noun or verb once and, because there is no order, you need another word type to bind the verbs and the nouns. I quickly gave that up as way too hard.
Thanks, Jakob. > -----Original Message----- > From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Matthew Ringel > Sent: Wednesday, September 21, 2016 9:52 AM > To: Christopher Morrow <morrowc.li...@gmail.com> > Cc: i...@ietf.org; grow@ietf.org grow@ietf.org <grow@ietf.org> > Subject: Re: [GROW] [Idr] Request to adopt draft-heitz-idr-large-community - > Working Group Adoption call (9/6 to > 9/20) > > 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 > sequences. > > e.g. > Prepend once (verb: prepend, noun: 1) > Export to Chile (verb: export, noun: Chile) > Deny All (verb: deny, noun: all) > etc. > > 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. > > Cheers > =Matt > > * 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 > <morrowc.li...@gmail.com> wrote: > > +grow > > > > On Wed, Sep 21, 2016 at 12:02 PM, Robert Raszuk <rob...@raszuk.net> wrote: > >> > >> But it already there ... it is even WG document .. > >> > >> > >> https://datatracker.ietf.org/doc/draft-ietf-idr-registered-wide-bgp-communities/ > >> > >> > > > > 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) > > > > -chris > > > > > > > > _______________________________________________ > > GROW mailing list > > GROW@ietf.org > > https://www.ietf.org/mailman/listinfo/grow > > > > _______________________________________________ > GROW mailing list > GROW@ietf.org > https://www.ietf.org/mailman/listinfo/grow _______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
