-02 submitted

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

@@ -11,7 +11,7 @@
 <?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">
+<rfc consensus="yes" category="bcp" submissionType="IETF" docName="draft-ymbk-grow-bgp-collector-communities-02" ipr="trust200902" obsoletes="4384">
 
 <front>
 
@@ -50,23 +50,23 @@
   <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>
+    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.</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>
+    <t>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 <xref target="RFC2119"/> <xref target="RFC8174"/> when,
+    and only when, they appear in all capitals, as shown here.</t>
 
     </note>
 
@@ -77,52 +77,53 @@
   <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
+    and <xref target="rviews">Route Views</xref> 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), 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>
+    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.</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>
+    this was due to its unnecessary complexity.  This document proposes
+    two much simpler marking schemes 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>
+    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>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.</t>
 
     <t>An ISP is expected to announce customer routes to their
-      customers, and announce customer routes to their external peers
-      and transits.</t>
+    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>
+    expose the business relationships with external providers.  So this
+    document do not propose to differentiate peers from transit
+    providers.</t>
 
     </section>
 
   <section anchor="categories" title="Categories">
 
-    <t>We define only three categories of announcements:
+    <t>We consider 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
@@ -151,11 +152,11 @@
     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>
+    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>
+    <t>ASs which do not peer with collectors MAY also choose to use
+    these markings.</t>
 
     <texttable anchor='markings'>
       <preamble></preamble>
@@ -169,6 +170,16 @@
 
     </section>
 
+  <section anchor="alt" title="Alternative Signaling">
+
+    <t>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.</t>
+
+    </section>
+
   <section anchor="iana" title="IANA Considerations">
     <t>As the number of categories is intentionally minimal, an IANA
       registry should not be needed.</t>
@@ -181,6 +192,7 @@
   <references title="Normative References">
 
     <?rfc include="reference.RFC.2119.xml"?>
+    <?rfc include="reference.RFC.8174.xml"?>
 
     <reference anchor="ris" target="https://www.ripe.net/analyse/internet-measurements/routing-information-service-ris/routing-information-service-ris">
       <front>