>> 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 _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
