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

[Job Snijders <[e-mail]>]

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