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

[Randy Bush <[e-mail]>]

> 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