211 lines
7.1 KiB
XML
211 lines
7.1 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" 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>
|