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 _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
