resurrected from antiquity

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 *~

draft-ymbk-grow-bgp-collector-communities.xml

@@ -0,0 +1,211 @@
+<?xml version="1.0"?>
+<!-- <!DOCTYPE rfc SYSTEM "rfc2629.dtd"> -->
+<?rfc comments="yes"?>
+<?rfc compact="yes"?>
+<?rfc inline="yes"?>
+<?rfc sortrefs="yes"?>
+<?rfc subcompact="yes"?>
+<?rfc symrefs="yes"?>
+<?rfc toc="yes"?>
+<?rfc tocdepth="3"?>
+<?rfc tocindent="yes"?>
+<?rfc tocompact="yes"?>
+
+<rfc consensus="yes" category="bcp" docName="draft-ymbk-grow-bgp-collector-communities-02" submissionType="IETF" ipr="noDerivativesTrust200902" obsoletes="4384">
+
+<front>
+
+  <title>Marking Announcements to BGP Collectors</title>
+
+  <author fullname="Randy Bush" initials="R." surname="Bush">
+    <organization>Internet Initiative Japan</organization>
+    <address>
+      <postal>
+        <street>5147 Crystal Springs</street>
+        <city>Bainbridge Island</city>
+        <region>Washington</region>
+        <code>98110</code>
+        <country>US</country>
+        </postal>
+      <email>randy@psg.com</email>
+      </address>
+    </author>
+
+  <author fullname="Emile Aben" initials="E.M.J." surname="Aben">
+      <organization>RIPE NCC</organization>
+      <address>
+	<postal>
+	  <street>Singel 258</street>
+	  <city>Amsterdam</city>
+	  <!-- <region>NL.NH</region> -->
+	  <code>1016 AB</code>
+	  <country>NL</country>
+	  </postal>
+	<email>emile.aben@ripe.net</email>
+	</address>
+      </author>
+
+  <date />
+
+  <abstract>
+
+    <t>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.</t>
+
+    </abstract>
+
+  <note title="Requirements Language">
+
+    <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
+      NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
+      are to be interpreted as described in
+      <xref target="RFC2119"/> only when they appear in all upper
+      case.  They may also appear in lower or mixed case as English
+      words, without normative meaning.</t>
+
+    </note>
+
+  </front>
+
+<middle>
+
+  <section anchor="intro" title="Introduction">
+
+    <t>BGP route collectors such as <xref target="ris">RIPE RIS</xref>
+      and
+      <xref target="rviews">Route Views</xref> 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.</t>
+
+    <t>In 2006, <xref target="RFC4384"/> 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 <xref target="RFC4384"/>.</t>
+
+    </section>
+
+  <section anchor="rationale" title="Rationale">
+
+    <t>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.</t>
+
+    <t>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.</t>
+
+    <t>An ISP is expected to announce customer routes to their
+      customers, and announce customer routes to their external peers
+      and transits.</t>
+
+    <t>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.</t>
+
+    </section>
+
+  <section anchor="categories" title="Categories">
+
+    <t>We define only three categories of announcements:
+      <list style="hanging">
+	<t hangText="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.</t>
+	<t hangText="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.</t>
+	<t hangText="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.</t>
+        </list>
+      </t>
+
+    </section>
+
+  <section anchor="signal" title="Signaling">
+
+    <t>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.</t>
+
+    <t>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:</t>
+
+      <t>ASs which do not peer with collectors MAY chose to use these
+        markings.</t>
+
+    <texttable anchor='markings'>
+      <preamble></preamble>
+        <ttcol align='left'>Category</ttcol>
+        <ttcol align='left'>Community</ttcol>
+          <c>Customer Cone</c>   <c>ASN:64994</c>
+          <c>External Route</c>  <c>ASN:64995</c>
+          <c>Internal Route</c>  <c>ASN:64996</c>
+        <postamble>Community Markings</postamble>
+      </texttable>
+
+    </section>
+
+  <section anchor="iana" title="IANA Considerations">
+    <t>As the number of categories is intentionally minimal, an IANA
+      registry should not be needed.</t>
+    </section>
+
+  </middle>
+
+<back>
+
+  <references title="Normative References">
+
+    <?rfc include="reference.RFC.2119.xml"?>
+
+    <reference anchor="ris" target="https://www.ripe.net/analyse/internet-measurements/routing-information-service-ris/routing-information-service-ris">
+      <front>
+	<title>RIPE Routing Information Service (RIS)</title>
+	<author/>
+	<date/>
+      </front>
+    </reference>
+
+    <reference anchor="rviews" target="http://www.routeviews.org/">
+      <front>
+	<title>University of Oregon Route Views Project</title>
+	<author/>
+	<date/>
+      </front>
+    </reference>
+
+    </references>
+
+  <references title="Informative References">
+
+    <?rfc include="reference.RFC.4384.xml"?>
+
+    </references>
+
+  </back>
+
+</rfc>