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

[Randy Bush <[e-mail]>]

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

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

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

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

should work

randy