commit ad51fe351f549cb9d14da07a84c982c4c80d341e Author: Randy Bush Date: Thu Feb 17 12:32:13 2022 -0800 resurrected from antiquity diff --git a/Makefile b/Makefile new file mode 100644 index 0000000..7e54364 --- /dev/null +++ b/Makefile @@ -0,0 +1,19 @@ +# +# Makefile for I-D's and RFCs +# $Id: Makefile,v 1.1.1.1 2002-11-11 05:11:48 randy Exp $ +# + +# Your nroff document is called foo.txt. Change below as appropiate. +NAME=draft-ymbk-grow-bgp-collector-communities +DEST=psg.com:public_html +RSY=rsync --rsh ssh -v -a -l -H -p -t -x --delete + +all: $(NAME).xml + xml2rfc $(NAME).xml --html --text + +rsy: + $(RSY) $(NAME).html $(DEST) + $(RSY) $(NAME).txt $(DEST) + +clean: + rm -f *.html *.txt *~ diff --git a/draft-ymbk-grow-bgp-collector-communities.xml b/draft-ymbk-grow-bgp-collector-communities.xml new file mode 100644 index 0000000..98771b7 --- /dev/null +++ b/draft-ymbk-grow-bgp-collector-communities.xml @@ -0,0 +1,211 @@ + + + + + + + + + + + + + + + + + + Marking Announcements to BGP Collectors + + + Internet Initiative Japan +
+ + 5147 Crystal Springs + Bainbridge Island + Washington + 98110 + US + + randy@psg.com +
+ + + + RIPE NCC +
+ + Singel 258 + Amsterdam + + 1016 AB + NL + + emile.aben@ripe.net +
+ + + + + + + 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. + + + + + + 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. + + + + + + + +
+ + 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. + + 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 . + +
+ +
+ + 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. + + 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. + + An ISP is expected to announce customer routes to their + 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. + +
+ +
+ + We define 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. + + 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. + + ISPs occasionally announce to the collector Internal point to + point and other routes they would not normally announce to + customers, peers, or transit providers. + + + +
+ +
+ + 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. + + 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: + + ASs which do not peer with collectors MAY chose to use these + markings. + + + + Category + Community + Customer Cone ASN:64994 + External Route ASN:64995 + Internal Route ASN:64996 + Community Markings + + +
+ +
+ As the number of categories is intentionally minimal, an IANA + registry should not be needed. +
+ + + + + + + + + + + + RIPE Routing Information Service (RIS) + + + + + + + + University of Oregon Route Views Project + + + + + + + + + + + + + + + +