nick,
> that would be difficult, as there is no way of exchanging exact
> semantics. I.e. one provider's opinion on how a specific community
> tag should be implemented might differ from their peer's.
>
> If the aim of this + other similar drafts is to create a set of
> standardised community tags, then presumably this will also
> standardise on the semantics for all of them. If that's going to
> happen, then settling on specific values will reduce overall
> complexity.
any help making the, admittedly terse, semantics in the draft more
rigorous and clear?
Customer Cone: One's own prefixes and the closure of those to whom
transit is provided including routes announced by BGP customers,
static prefixes used for non-BGP customers, datacenter routes,
etc.
External Routes: Routes learned from peers and transit providers
which the ISP would normally announce to customers but not to
peers. Often, ISPs do not announce such routes to collectors.
But, as there is no general practice, this category is important
to mark.
Internal Routes: ISPs occasionally announce to the collector
Internal point to point and other routes they would not normally
announce to customers, peers, or transit providers.
randy
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow
