223 lines
7.5 KiB
XML
223 lines
7.5 KiB
XML
<?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" submissionType="IETF" docName="draft-ymbk-grow-bgp-collector-communities-02" ipr="trust200902" 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 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", "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>
|
|
|
|
</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 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.</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
|
|
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>
|
|
|
|
<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>
|
|
|
|
<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 this
|
|
document do not propose to differentiate peers from transit
|
|
providers.</t>
|
|
|
|
</section>
|
|
|
|
<section anchor="categories" title="Categories">
|
|
|
|
<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
|
|
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 also choose 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="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>
|
|
</section>
|
|
|
|
</middle>
|
|
|
|
<back>
|
|
|
|
<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>
|
|
<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>
|