On Mon, Sep 07, 2015 at 12:53:22PM +0200, Randy Bush wrote: > >> The ASN in the marking SHOULD be that of the collector peer. > > For my understanding, if AS 8283 feeds RIPE RIS, AS 8283 would be the > > 'collector peer' in the above context? > > yes > > >> The communities were selected from community values which were unused > >> at the time of this document and SHOULD be as follows: > >> > >> +----------------+-----------+ > >> | Category | Community | > >> +----------------+-----------+ > >> | Customer Cone | ASN:64994 | > >> | External Route | ASN:64995 | > >> | Internal Route | ASN:64996 | > >> +----------------+-----------+ > > > > I think it would be more honest if you phrase it as "The communities > > were choosen by rolling a big dice". ;-) > > except that would be a lie. the statement in the document is precise.
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. > > Why does the ASN need to be part of the BGP community? As data collector > > you already know the feeding ASN by looking at the first entry in the > > AS_PATH. > > normal practice. ah, well ok then. > > Wouldn't an even simpler method be to just tag all "external" routes > > with "NOPEER" [RFC3765], not expect any community on customer cone > > routes, and assume that prefixes with an AS_PATH length of 1 is are > > internal routes? > > no. as_path length of 1 covers my static space, from which i allocate > static customers. as path_length of 1 also covers any p2p and other > internal-only prefixes i might eak to the collector. I assume projects such as RIS and routeviews have many many BGP feeds, you can infer meaning from the totality of those feeds, 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. I believe you should waive the requirement to include the collector peer ASN as part of the BGP community. 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. Everything else should be deduced from what is already available in the collected protocol data today. For operators this should be easier to implement, for researchers it might also be healthier as they cannot rely on spoon-fed ground-truth. Kind regards, Job _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
