On Wed, Sep 21, 2016 at 1:24 PM, Gert Doering <g...@space.net> wrote:
> Having this hard-coded in RFCs and code in routers is both far too
> complex to implement, and far too limited at the same time (what if
> I only want "North Chile" but that isn't in the implementation?) -
> which is why I'm opting for the most simple approach: an opaque string
> of bytes of a fixed length, displayed in 4:4:4 format, and all the
> "what do I want to do with these?" flexibility and complexity goes
> into the routing policy specified by the operator in their router
> config.
My thoughts were more along the standardization of verbs, for exactly
the reason you specify. "Export" remains a verb (and very susceptible
to being standardized), and nouns like "Chile", "North Chile",
"Santiago", or the "Las Condes district of Santiago", are nouns that
can be specified, provider by provider, and don't need to be put in an
RFC, except as examples.
We (AS 20940) work with a large amount of networks. Knowing that
"Export" means the same thing to everyone, and I just have to look up
the right noun, means a lot less operational hassle, and a lot less
shuffling through BGP community documents. "Do they support
Blackholing?" is a yes/no "Do they support the verb, and what nouns?"
question, as opposed to having to shuffle through 20 pages to cobble
something together that might end up being Blackholing.
In short, looking at the problem as a set of verbs/nouns, and then
defining and standardizing a "minimum supported subset" of verbs, and
recommending ways to do a taxonomy of nouns (e.g. integers for
prepending, how to state a geo region) is entirely standard-worthy.
Cheers
=Matt
[Words are mine, not my employer's.]
On Wed, Sep 21, 2016 at 1:24 PM, Gert Doering <g...@space.net> wrote:
> Hi,
>
> On Wed, Sep 21, 2016 at 12:51:30PM -0400, Matthew Ringel wrote:
>> 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.**
>
> This is nice to have, and having a recommendation document that
> shows operators "look, these are what people *typically* have been
> doing with communities, and *that* is how to set the community
> values to achieve things" would be a great help when building a new
> policy framework.
>
> Having this hard-coded in RFCs and code in routers is both far too
> complex to implement, and far too limited at the same time (what if
> I only want "North Chile" but that isn't in the implementation?) -
> which is why I'm opting for the most simple approach: an opaque string
> of bytes of a fixed length, displayed in 4:4:4 format, and all the
> "what do I want to do with these?" flexibility and complexity goes
> into the routing policy specified by the operator in their router
> config.
>
> We (AS5539) use about ~20 community values under 5539:<x> today, and
> we do not see any need for much more complex policies (we're a fairly
> leafish AS and only limited regional coverage) - so, I see no need to
> ask my vendors for a wide list of automatic and all-encompassing features
> in their automatic community / policy handling. I want something they
> can implement easily, and give me a if/match/set language to achieve
> my policy, in a way that it works with 32bit ASes.
>
> OTOH, my upstreams (2914) use a very complex and strongly regionalized
> framework ("blackhole outside the country that this route was
> received in"), and they seem to be happy with 4:4:4 as well and
> not having "everything built-in and applied automatically", so the
> -large draft seems to work for make small and large network operators
> alike.
>
> Gert Doering
> -- NetMaster
> --
> have you enabled IPv6 on something today...?
>
> SpaceNet AG Vorstand: Sebastian v. Bomhard
> Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann
> D-80807 Muenchen HRB: 136055 (AG Muenchen)
> Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
_______________________________________________
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow
