From 73a895962505209fb07cfa37e0821678c2e212ae Mon Sep 17 00:00:00 2001 From: Randy Bush Date: Thu, 17 Feb 2022 13:10:18 -0800 Subject: [PATCH] -02 submitted --- draft-ymbk-grow-bgp-collector-communities.xml | 114 ++++++++++-------- 1 file changed, 63 insertions(+), 51 deletions(-) diff --git a/draft-ymbk-grow-bgp-collector-communities.xml b/draft-ymbk-grow-bgp-collector-communities.xml index 98771b7..32de9a5 100644 --- a/draft-ymbk-grow-bgp-collector-communities.xml +++ b/draft-ymbk-grow-bgp-collector-communities.xml @@ -11,7 +11,7 @@ - + @@ -50,23 +50,23 @@ When BGP route collectors such as RIPE RIS and Route Views are - used by operators and researchers, currently one can not tell if a - path announced to a collector is from the ISP's customer cone, an - internal route, or one learned from peering or transit. This - greatly reduces the utility of the collected data. This document - specifies the use of BGP communities to differentiate the kinds of - views being presented to the collectors. + used by operators and researchers, currently one can not tell if the + collection of paths announced to a collector represents the ISP's + customer cone, includes internal routes, includes paths learned from + peerings or transits. This greatly reduces the utility of the + collected data. This document specifies the use of BGP communities + to differentiate the kinds of views being presented to the + collectors. - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL - NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" - are to be interpreted as described in - only when they appear in all upper - case. They may also appear in lower or mixed case as English - words, without normative meaning. + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14 when, + and only when, they appear in all capitals, as shown here. @@ -77,58 +77,59 @@
BGP route collectors such as RIPE RIS - and - Route Views are used by both - operators and researchers. Unfortunately, one can not tell if a - path announced to a collector is from the ISP's customer cone - (one's own prefixes and the closure of those to whom transit is - provided; i.e. what one would announce to a peer), an internal - route, or an external route learned via peering or transit. This - greatly reduces the utility of the collected data, and has been a - cause of much pain over the years. This document specifies the - use of BGP communities to differentiate between these - categories. + and Route Views are used by both + operators and researchers. Unfortunately, one can not tell paths + announced to a collector are solely from the ISP's customer cone + (one's own prefixes and the closure of those to whom transit is + provided; i.e. what one would announce to a peer), include internal + routes (e.g. inter-router links), or external paths learned via + peering or transit. This greatly reduces the utility of the + collected data, and has been a cause of much pain over the years. + This document suggests the use of BGP communities to differentiate + between these categories. In 2006, attempted a similar goal but - failed to gain traction in the operational community. We believe - this was due to its unnecessary complexity. This document - proposes a much simpler marking scheme and, if published, will - obsolete . + failed to gain traction in the operational community. We believe + this was due to its unnecessary complexity. This document proposes + two much simpler marking schemes and, if published, will obsolete + .
When an operator uses a collector to look at an ISP's - announcement of a prefix, it is very useful to know if the ISP - also announced it to their customers and/or peers/transits. - Researchers want to differentiate similarly in order to understand - expected route propagation. + announcement of a prefix, it is very useful to know if the ISP also + announced it to their customers and/or peers/transits. Researchers + want to differentiate similarly in order to understand expected + route propagation. - One usually wishes to ignore any internal-only routes an ISP may - announce to the collector, as they would not be announcing them to - peers, transits, or customers. + One usually wishes to ignore any internal-only routes, e.g. + inter-router point-to-point links, an ISP may announce to the + collector, as they would not be announcing them to peers, transits, + or customers. I.e. they would not be used operationally. An ISP is expected to announce customer routes to their - customers, and announce customer routes to their external peers - and transits. + customers, and announce customer routes to their external peers and + transits. In general, one does not need to differentiate whether the ISP - will announce to peers or transits; and the ISP may not wish to - expose the business relationships with external providers. So we - do not propose to differentiate peers from transit providers. + will announce to peers or transits; and the ISP may not wish to + expose the business relationships with external providers. So this + document do not propose to differentiate peers from transit + providers.
- We define only three categories of announcements: + We consider only three categories of announcements: 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. + provided including routes announced by BGP customers, static + prefixes used for non-BGP customers, datacenter routes, + etc. Routes learned from peers and transit providers which the ISP would normally announce to customers but not to peers. Often, @@ -146,16 +147,16 @@
BGP announcements to route collectors SHOULD be marked with - communities indicating into which category the announcement falls. - As most collector peers already use community markings similar to - these, but ad hoc, the additional effort should be trivial. + communities indicating into which category the announcement falls. + As most collector peers already use community markings similar to + these, but ad hoc, the additional effort should be trivial. The ASN in the marking SHOULD be that of the collector peer. The - communities were selected from community values which were unused - at the time of this document and SHOULD be as follows: + communities were selected from community values which were unused at + the time of this document and SHOULD be as follows: - ASs which do not peer with collectors MAY chose to use these - markings. + ASs which do not peer with collectors MAY also choose to use + these markings. @@ -169,6 +170,16 @@
+
+ + Alternatively, should marking at the path granularity be + considered too revealing, the collector peer could announce a single + well-known prefix, for example 10.10.10.10/10, with one or more of + the community markings as above, describing the set of paths being + announced to the collector. + +
+
As the number of categories is intentionally minimal, an IANA registry should not be needed. @@ -181,6 +192,7 @@ +