> 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 assume projects such as RIS and routeviews have many many BGP feeds, > you can infer meaning from the totality of those feeds agree, you can infer meaning. problem is you get it right only some of the time; and even then, you can not be sure. > if one ASN seemingly originates a /30, but another ASN seemingly > originates a larger block, and you observe a BGP adjacency between the > two ASNs, you can write it down as router2router linknet. maybe. but you *really* do not know. note that /30s are now in the table as allocated by rirs. and, despite our advice to the contrary, /64s are used both as internal p2p links and as customer allocations. lots'o papers have been written on these problems and researchers have spent a lot of time and energy showing that you can only approximate. bgp is such a great information hiding protocol. take your gorgeous star chart and sample a few dozen asns three or five hops out and get ground truth on their out-degree and compare. sigh. > I believe you should waive the requirement to include the collector > peer ASN as part of the BGP community. what asn should be in the community? or does this go with your also wanting to remove the community value? can we keep the colon? :) > The objective is to simplify what RFC 4384 attempted to document, I > would encourage the group to reduce the technicalities to a single > boolean option a prefix can be a customer route, or it is not. describe a rigorous formal algorithm for > Everything else should be deduced from what is already available in > the collected protocol data today. not an approximation, but a complete algorithm. a few decades of minds smarter than i have been unable to do so. so i eagerly await enlightenment. > For operators this should be easier to implement once i have to tag one flavor the other two are trivial. and it provides a nice check on my announcement filters > for researchers it might also be healthier as they cannot rely on > spoon-fed ground-truth. oddly enough, the ncc tries to make things easier for people, not be a test or hurdle. i know this does not hold for all regions, sadly enough. randy _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
