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

[Job Snijders <[e-mail]>]

On Mon, Sep 07, 2015 at 03:23:35AM -0700, [e-mail] wrote:
> A new version of I-D, draft-ymbk-grow-bgp-collector-communities-01.txt
> has been successfully submitted by Randy Bush and posted to the
> IETF repository.

>From the diff:

> 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?

> 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". ;-)

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.

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?

Even if it is deemed desirable to put the ASN in the community itself,
how will we deal with 32-bit ASNs? Have people sometimes use RFC5668,
and sometimes RFC1997-style communities?

Kind regards,

Job