Re: [GROW] New Version Notification for draft-ymbk-grow-bgp-collector-communities-01.txt

[John Kemp <[e-mail]>]

On 9/8/15 8:15 AM, Job Snijders wrote:
> On Tue, Sep 08, 2015 at 05:05:48PM +0200, Randy Bush wrote:
>>>> I do not feel comfortable overloading locally administrated bits with
>>>> something that represents global significance. The 64xxx communites
>>>> come dangerously close to codepoints we use internally. I'd prefer
>>>> that the local portion of BGP Communities remains truely local.
>>>
>>> only problem is that completely blows the purpose of the exercise, a
>>> global tagging to help ops and researchers be more sure of what they
>>> are seeing in the collectors.
>>
>> i think i misunderstood you.  you are suggesting using 42-44 or
>> whatever, not 65000 space.  sure.  i do not care what the numbers
>> are.
> 
> I suggest to take the codepoint(s) from 0xFFFF0000 - 0xFFFFFFFF
> http://www.iana.org/assignments/bgp-well-known-communities/bgp-well-known-communities.xhtml
> as we then at least have made the most effort to avoid clashes with
> locally significant values.
> 
> At the very least I see operational value in having a well-known
> community to tag "customer" prefixes with, this is something I'd use
> internally, in public documentation and BCOPs/guides how to set up a BGP
> transit network. A "CUSTOMER" community could benefit a group braoder
> then the research community.
> 
> Kind regards,
> 
> Job

Only two comments I would add:

Are those three categories comprehensive?  Does this cover the case when
you have hybrid peering+transit arrangements, for example?

And more to the collector point, if we look at BMP mirroring,
the collection is indirect.  I don't think the peers themselves get
an opportunity to express export community tags for a typical
BMP monitoring setup..... :(  In which case I would put more emphasis
on more correct or more extensive RPSL and IX tagging, not collector
specific tagging...

John Kemp