On Mon, Sep 07, 2015 at 03:23:35AM -0700, [email protected] 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 _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
