<?xml version="1.0" encoding="utf-8"?>
<?xml-model href="rfc7991bis.rnc"?>
<!DOCTYPE rfc [
        <!ENTITY nbsp    "&#160;">
        <!ENTITY zwsp   "&#8203;">
        <!ENTITY nbhy   "&#8209;">
        <!ENTITY wj     "&#8288;">
]>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude"
     ipr="trust200902" submissionType="IETF" category="info" consensus="true" version="3" docName="draft-ietf-grow-routing-ops-terms-03">
    <front>
        <title abbrev="BGP TERMS">Currently Used Terminology in Global Routing Operations</title>
        <seriesInfo name="Internet-Draft" status="standard" value="draft-ietf-grow-routing-ops-terms-03"/>
        <author fullname="Tobias Fiebig" initials="T." surname="Fiebig">
            <organization abbrev="TUW">TU Wien</organization>
            <address>
                <postal>
                    <street>Treitlstr. 3</street>
                    <city>Wien</city>
                    <code>1040</code>
                    <country>Austria</country>
                </postal>
                <phone>+43 676 930 22 52</phone>
                <email>tobias.fiebig@tuwien.ac.at</email>
            </address>
        </author>
        <author fullname="Wolfgang Tremmel" initials="W." surname="Tremmel">
            <organization abbrev="DE-CIX">DE-CIX Management GmbH</organization>
            <address>
                <postal>
                    <street>Lindleystr. 12</street>
                    <city>Frankfurt</city>
                    <code>60314</code>
                    <country>Germany</country>
                </postal>
                <phone>+49 69 1730 902 0</phone>
                <email>wolfgang.tremmel@de-cix.net</email>
            </address>
        </author>

        <area>ops</area>
        <workgroup>Global Routing Operations</workgroup>

        <abstract>
            <t>
                Operating the global routing ecosystem entails a diverse set of interacting components, while operational practice evolved over time.
                In that time, terms emerged, disappeared, and sometimes changed their meaning.
            </t>
            <t>
                To aid operators and implementers in reading contemporary drafts, this document provides an overview of terms and abbreviations used in the global routing operations community.
                The document explicitly does not serve as an authoritative source of correct terminology, but instead strives to provide an overview of practice.
            </t>
        </abstract>
    </front>

    <middle>
        <section  anchor="sec-introduction">
            <name>Introduction</name>
            <t>
                The practical operation of the global routing ecosystem entails a diverse set of interacting components, while operational practice evolved over time.
                In that time, terms emerged, disappeared, and sometimes changed their meaning.
            </t>
            <t>
                To aid operators and implementers in reading contemporary drafts, this document provides an overview of terms and abbreviations used in the global routing operations community.
            </t>
            <section  anchor="ssec-feedback">
                <name>Providing input on the draft:</name>
                <t>
                    While this draft is being edited, you may provide suggestions for additional abbreviations and terms to be included at:
                </t>
                <t>
                    https://files.measurement.network/apps/forms/s/CMXjrtCPD8QyG6CAWmSLmg4y
                </t>
            </section>
            <section>
                <name>Requirements Language</name>
                <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>
            </section>
        </section>

        <section  anchor="sec-scope-of-the-document">
            <name>Scope of the Document</name>
            <t>
                This document is explicitly descriptive, i.e., provides a collection of terms that are currently being used along with the context and definitions with which their use was observed.
                It is not an authoritative source of terminology, and only provides a snapshot of how certain terms have been used at the time of publication.
                As such, any terms and summaries in this document are subject to change.
            </t>
        </section>
        <section  anchor="sec-acronyms">
            <name>Acronyms</name>
            <t>
                The following acronyms are commonly used in the context of global routing operations:
            </t>
            <dl newline="true" spacing="normal">
                <dt>ACL:</dt>
                <dd>Access Control List</dd>

                <dt>ASN:</dt>
                <dd>Autonomous System Number</dd>

		<dt>BGP:</dt>
		<dd>Border Gateway Protocol</dd>

                <dt>ASPA:</dt>
                <dd>Autonomous System Provider Authorization</dd>

                <dt>BFD:</dt>
                <dd>Bidirectional Forwarding Detection</dd>

                <dt>CE:</dt>
                <dd>Customer Edge Router</dd>

                <dt>DFZ:</dt>
                <dd>Default Free Zone</dd>

                <dt>EGP:</dt>
                <dd>Exterior Gateway Protocol</dd>

                <dt>EIGRP:</dt>
                <dd>Enhanced Interior Gateway Routing Protocol</dd>

                <dt>GRT:</dt>
                <dd>Global Routing Table</dd>

                <dt>ICMP:</dt>
                <dd>Internet Control Message Protocol</dd>

                <dt>IGP:</dt>
                <dd>Interior Gateway Protocol</dd>

                <dt>IRR:</dt>
                <dd>Internet Routing Registry</dd>

                <dt>IXP:</dt>
                <dd>Internet Exchange Point</dd>

                <dt>LIR:</dt>
                <dd>Local Internet Registry</dd>

                <dt>MED:</dt>
                <dd>Multi Exit Discriminator</dd>

                <dt>MPLS:</dt>
                <dd>Multiprotocol Label Switching</dd>

                <dt>NIR:</dt>
                <dd>National Internet Registry</dd>

                <dt>OSPF:</dt>
                <dd>Open Shortest Path First</dd>

                <dt>RIR:</dt>
                <dd>Regional Internet Registry</dd>

                <dt>NLRI:</dt>
                <dd>Network Layer Reachability Information</dd>

                <dt>OTC:</dt>
                <dd>Only To Customer BGP Attribute</dd>

                <dt>P:</dt>
                <dd>Provider Router</dd>

                <dt>PE:</dt>
                <dd>Provider Edge Router</dd>

                <dt>PMTUD:</dt>
                <dd>Path MTU Discovery</dd>

                <dt>uRPF:</dt>
                <dd>Unicast Reverse Path Forwarding</dd>

                <dt>VRF:</dt>
                <dd>Virtual Routing and Forwarding</dd>

                <dt>RPKI:</dt>
                <dd>Resource Public Key Infrastructure</dd>

                <dt>ROA:</dt>
                <dd>Route Origin Authorization</dd>

                <dt>ROV:</dt>
                <dd>Route Origin Validation</dd>
            </dl>
        </section>
        <section  anchor="sec-terms">
            <name>Used Terminology by Topic</name>
            <t>
                This section describes terms used in the context of global routing operations, grouped by topic.
                Terms may have a different meaning depending on the context in which they are used.
                Hence, terms may appear in multiple subsections with different descriptions.
            </t>
            <section  anchor="sec-terms-general">
                <name>General Terms</name>
                <t>
                    This section describes general terms used in the context of global routing operations, regardless of context.
                </t>
                <dl newline="true" spacing="normal">
                    <dt>Autonomous System:</dt>
                    <dd>A connected group of one or more IP prefixes run by one or more network operators which has a SINGLE and CLEARLY DEFINED routing policy.</dd>

                    <dt>Autonomous System Number:</dt>
                    <dd>A 32-bit number uniquely identifying an Autonomous System.</dd>

                    <dt>AS Confederation Identifier:</dt>
                    <dd>is according to <xref target="RFC5065" format="default"/> an externally visible autonomous system number that identifies a BGP confederation as a whole.</dd>

                    <dt>Bidirectional Forwarding Detection:</dt>
                    <dd>BFD is a protocol used by BGP to check if a configured neighbor is reachable. Packets are sent rapidly between two systems (rapidly means in the 100ms time range). If no packets are received from the neighbor for a given time, the neighbor is considered to be no longer reachable. This lack of reachability is then signaled to other protocols like BGP. BFD is defined in <xref target="RFC5880" format="default"/>. Its application for IPv4 and IPv6 is defined in <xref target="RFC5881" format="default"/>. <xref target="RFC5882" format="default"/> is about the general application of BFD and <xref target="RFC5883" format="default"/> describes BFD on multihop paths.</dd>

		    <dt>BGP:</dt>
		    <dd>Border Gateway Protocol, Version 4 <xref target="RFC4271"/>.  BGP is the routing protocol used for Internet (IPv4 and IPv6) routing.  It is also used by many other applications.</dd>

                    <dt>BGP Path Attribute:</dt>
                    <dd>BGP update messages for prefixes contain not only the AS-Path but also other attributes. BGP Path Attributes fall into four different categories: well-known mandatory, well-known discretionary, optional transitive, optional non-transitive.</dd>

                    <dt>Well-known mandatory BGP Path Attribute:</dt>
                    <dd>A BGP Path Attribute that needs to be understood by all BGP implementations and must be included in all BGP routes.</dd>

                    <dt>Well-known discretionary BGP Path Attribute:</dt>
                    <dd>A BGP Path Attribute that needs to be understood by all BGP implementations but is not required to be included in BGP routes.</dd>

                    <dt>Optional transitive BGP Path Attribute:</dt>
                    <dd>Optional transitive BGP Path Attributes are conditionally carried in BGP routes based on their defining feature.  Implementations that do not understand an optional transitive Path Attribute are expected to propagate the attribute to their neighbors.</dd>

                    <dt>Optional non-transitive BGP Path Attribute:</dt>
                    <dd>Optional non-transitive BGP Path Attributes are conditionally carried in BGP routes based on their defining feature.  Implementations that do not understand an optional non-transitive Path Attribute will discard them and they are not propagated to their neighbors as a result.</dd>

                    <dt>Enhanced Interior Gateway Routing Protocol:</dt>
                    <dd>EIGRP is an IGP defined by Cisco in the 1980s to distribute routing information within a network. It was later openly specified in <xref target="RFC7868" format="default"/>.</dd>

                    <dt>Exterior Gateway Protocol:</dt>
                    <dd>EGP was a predecessor to BGP. First defined in 1982 in <xref target="RFC827" format="default"/>, it became obsolete once BGP was widely used (around 1994). Additionally, as a general term, it is used for protocols used to exchange routing information between ASes. In that meaning, BGP is currently the only EGP.</dd>

                    <dt>Interior Gateway Protocol:</dt>
                    <dd>An IGP is a protocol running inside an Autonomous System. It is typically used to distribute the IP addresses of router interfaces.</dd>

                    <dt>IS-IS:</dt>
		    <dd>The Intermediate System to Intermediate System protocol is an IGP running directly on top of layer 2. It is typically used to distribute interface addresses within a network.  IS-IS was originally defined by OSI in ISO DP 10589.  It was later published in the IETF in <xref target="RFC1195"/>.</dd>

                    <dt>Local Internet Registry:</dt>
                    <dd>An LIR is an organization/company which receives IP address resources or Autonomous System Numbers as an allocation from a Regional Internet Registry and assigns these resources to end users.</dd>

                    <dt>Open Shortest Path First:</dt>
		    <dd>OSPF is a link state routing protocol. It is used as an IGP. It was first specified in <xref target="RFC2328"/>.</dd>

                    <dt>Regional Internet Registry:</dt>
                    <dd>An RIR is an entity responsible for allocating IP addresses and AS numbers to NIRs and LIRs. There are currently five RIRs: Afrinic, APNIC, ARIN, LACNIC, and RIPE NCC. Each is responsible for a different region.</dd>

                    <dt>Routing Information Protocol:</dt>
		    <dd>RIP is an old and by now obsolete protocol which was used to distribute routing information. RIP is no longer in use. It was originally defined in <xref target="RFC1058"/>.</dd>

                    <dt>RIPE:</dt>
                    <dd>RIPE is shorthand for Réseaux IP Européens, which is the community of network operators in the RIPE NCC's service region. See also RIPE NCC.</dd>

                    <dt>RIPE NCC:</dt>
                    <dd>The RIPE NCC, sometimes also just called the NCC, is the RIR for 75 countries spanning Europe, parts of central Asia, and the Middle East.</dd>

                    <dt>Operator:</dt>
                    <dd>Individual, group of people, or organizational unit responsible for operating BGP speakers, i.e., making administrative changes, as well as defining and setting policies for all BGP speakers within an organization.</dd>

                    <dt>Router:</dt>
                    <dd>In this document, router always refers to a BGP speaker.</dd>

                    <dt>Customer Edge (CE) Router:</dt>
                    <dd>Router at the customer's premises, may be connected to PE routers.</dd>

                    <dt>Cone:</dt>
                    <dd>The set of ASes who are either direct downstreams of an AS, or in the cone of any of those ASes. Depending on the context this also includes the joint set of prefixes that may be originated by ASes in a cone.</dd>

                    <dt>Global Routing Table:</dt>
                    <dd>The set of all routes for an address family that have been received from external BGP Neighbors.</dd>

                    <dt>Route Selection:</dt>
		    <dd>The process when a BGP speaker applies the locally configured policy to select the best route from multiple available options according to that policy. See "Decision Process" in <xref target="RFC4271"/>.</dd>

                    <dt>Network Layer Reachability Information:</dt>
                    <dd>General description for network destinations. Often called "prefixes".</dd>

                    <dt>Default Free Zone:</dt>
                    <dd>Part of the Internet where routers do not carry default routes.</dd>

                    <dt>Round Trip Time:</dt>
                    <dd>The Round Trip Time between two hosts is the time measured (typically in seconds or milliseconds) that it takes from sending out a packet until receiving a reply.</dd>

                    <dt>TCP:</dt>
                    <dd>The Transmission Control Protocol is part of the TCP/IP protocol stack. It is a connection oriented protocol taking care that everything which is sent is also received.</dd>

		    <dt>TCP-AO:</dt>
		    <dd>The Transmission Control Protocol Authentication Option <xref target="RFC5925"/> is used to provide authentication and integrity for BGP.</dd>

                    <dt>TCP-MD5:</dt>
		    <dd>MD5 is a hashing algorithm, used to generate a checksum over given data. In the context of BGP, it typically refers to the obsolete TCP-MD5 feature <xref target="RFC2385"/>. It has been replaced by TCP-AO.</dd>

                    <dt>Time To Live:</dt>
                    <dd>The TTL is a counter in the IPv4 header which is decreased every time a packet is forwarded by a router. If this counter hits zero, the packet is discarded and an ICMP Time Exceeded message is sent back to the originator of the packet. It was replaced by the Hop Limit field in IPv6.</dd>

                </dl>
            </section>
            <section  anchor="sec-terms-relationships">
                <name>Neighbor Relation Terms</name>
                <t>
                    This section lists terms used to describe relationships between different ASes.
                </t>
                <dl newline="true" spacing="normal">
                    <dt>AS Confederation:</dt>
                    <dd>According to <xref target="RFC5065" format="default"/> a collection of autonomous systems represented and advertised as a single AS number to BGP speakers that are not members of the local BGP confederation.</dd>

                    <dt>ICMP:</dt>
                    <dd>Internet Control Message Protocol - this protocol is used to signal errors when forwarding packets.</dd>

                    <dt>Cone:</dt>
                    <dd>The set of ASes who are either direct downstreams of an AS, or in the cone of any of those ASes. Depending on the context this also includes the joint set of prefixes that may be originated by ASes in a cone.</dd>

                    <dt>Network edge:</dt>
                    <dd>Last routers under the control of an operator connected to routers of other networks.</dd>

                    <dt>Mutual Transit:</dt>
                    <dd>When two directly connected ASes both advertise a full BGP table to each other. (See: <xref target="I-D.ietf-sidrops-aspa-verification" format="default"/>)</dd>

                    <dt>Upstream Provider / Transit Provider:</dt>
                    <dd>In a direct relationship between two ASes the one announcing either the full BGP routing table to the other or allowing the other to point a default route to itself. (See: <xref target="RFC9234" format="default"/>, also known as the provider in a customer-provider relationship.)</dd>

                    <dt>Downstream Customer:</dt>
                    <dd>In a direct relationship between two ASes the one receiving a full BGP table from the other or pointing a default route to the other. (See: <xref target="RFC9234" format="default"/>, also known as the customer in a customer-provider relationship.)</dd>

                    <dt>Peer:</dt>
                    <dd>Two directly connected ASes who only advertise routes they originate or learned from their downstreams to each other. (See: <xref target="RFC9234" format="default"/>)</dd>

                    <dt>Providing Transit:</dt>
                    <dd>Forwarding packets destined for addresses in an advertised prefix, while advertising a full BGP table or default route to the neighbor.</dd>

                    <dt>Providing Upstream:</dt>
                    <dd>See: Providing Transit</dd>

                    <dt>Provider (P) Router:</dt>
                    <dd>A router within the core of a provider's network, usually implying the use of MPLS within the provider's network. Connected to other P and PE routers.</dd>

                    <dt>Provider Edge (PE) Router:</dt>
                    <dd>Like Network Edge, usually implying the use of MPLS within the provider's network. Connected to other PE, P, and CE routers.</dd>

                    <dt>Depeering:</dt>
                    <dd>Removing sessions with a neighboring AS.</dd>

                    <dt>Neighbor:</dt>
                    <dd>An AS to which an established BGP session exists.</dd>
                </dl>
            </section>
            <section  anchor="sec-terms-routing">
                <name>Routing Terms</name>
                <t>
                    This section describes terms specific to technical aspects of routing.
                </t>
                <dl newline="true" spacing="normal">
                    <dt>BGP Speaker:</dt>
                    <dd>A device exchanging routes with other BGP speakers using the BGP protocol.</dd>

                    <dt>Full Table:</dt>
                    <dd>A routing table containing a route to all prefixes in the GRT but not the default route.</dd>

                    <dt>Exporting a Prefix:</dt>
                    <dd>Advertising a prefix to a neighbor.</dd>

                    <dt>Importing a Prefix:</dt>
                    <dd>Accepting a prefix advertised by a neighbor and considering it for route selection and import into the local AS' routing table.</dd>

                    <dt>Network edge:</dt>
                    <dd>Last routers under the control of an operator.</dd>

                    <dt>Originating a Prefix:</dt>
                    <dd>Announcing a prefix with only your AS in the AS-Path.</dd>

                    <dt>Propagating a Prefix:</dt>
                    <dd>Advertising a prefix you have received from another AS and adding your AS to the AS_PATH before announcing the prefix to further neighboring ASes.</dd>

                    <dt>BGP Neighbor:</dt>
                    <dd>Also just 'Neighbor'. Two BGP speakers that exchange NLRI using the BGP protocol are neighbors.</dd>

                    <dt>Peer:</dt>
                    <dd>A BGP neighbor, if not used to describe the peering relationship.</dd>

                    <dt>Prepending:</dt>
                    <dd>Adding one or more instances of an AS number to the left-hand side of the AS_PATH, typically to influence route selection.</dd>

                    <dt>Traffic Engineering:</dt>
                    <dd>Making changes to properties of imported and exported NLRI to influence route selection, and thereby the flow of traffic.</dd>

                    <dt>Converging:</dt>
                    <dd>Used to describe the process of a BGP speaker learning and evaluating all routes from its neighbors, and finding the preferred route for each destination.
                        Reconverging is often also used to describe an ongoing selection process reevaluating all routes sent by neighbors, e.g., after a loss of connectivity to one or multiple neighbors.</dd>

                    <dt>Route Reflector:</dt>
                    <dd>A Route Reflector is an iBGP speaker which sends all prefixes it receives out to its Route Reflector Clients. It is a central component for network designs that do not use a full mesh for iBGP speakers.</dd>

                    <dt>Route Reflector Client:</dt>
                    <dd>A Route Reflector CLient is an iBGP speaking node with usually only one iBGP connection to a Route Reflector.</dd>

                    <dt>Default Route:</dt>
                    <dd>The default route is a route which covers every destination for which there is no specific route in the routing table. The destination of the default-route is often called the default destination or the gateway of last resort.</dd>

                    <dt>Blackholing:</dt>
                    <dd>As a general term, blackholing refers to packets silently being dropped, i.e., without the sender being notified via an ICMP or ICMP6 message. For the additional meaning in the context of network security, please see below.</dd>

                    <dt>Multi Exit Discriminator:</dt>
                    <dd>MED is a metric in BGP which is used to signal neighboring ASes with multiple entry points to the network which inbound traffic path for a prefix is preferred.</dd>

                    <dt>Local Preference:</dt>
                    <dd>The local preference is the first evaluated BGP Attribute in the best path selection process when comparing multiple NLRI for the same prefix. It is an integer value, and NLRI with a higher local preference will be preferred. It is redistributed via iBGP inside an Autonomous System}</dd>

                    <dt>MPLS:</dt>
		    <dd>Multiprotocol Label Switching is a procedure to make routing decisions faster. When a packet enters a network it will get a label attached signaling which route it should take to its destination and which priority it has.</dd>

                    <dt>L2VPN:</dt>
		    <dd>A Layer 2 Virtual Private Network connects two physically distant networks in a way that makes them appear to be one. Packets between hosts in those 2 connected networks can communicate as if on the same layer 2 network via switching.</dd>

                    <dt>Router:</dt>
                    <dd>Generally a term for a system forwarding network traffic on Layer 3. In the context of BGP, this usually refers to a BGP speaker.</dd>
                </dl>
            </section>
            <section  anchor="sec-terms-security">
                <name>Security Terms</name>
                <t>
                    This section describes terms used in the context of routing security.
                </t>
                <dl newline="true" spacing="normal">
                    <dt>Route Flapping:</dt>
                    <dd>A route that is constantly announced and withdrawn or otherwise sees constant change.</dd>

                    <dt>BGP Hijack / Route Hijack:</dt>
                    <dd>A route hijack occurs when an AS announces a route that it is not authorized to announce, causing traffic to be diverted from its intended route or destination. A route hijack may result from either accidental misconfiguration or malicious action.</dd>

                    <dt>Route Leak:</dt>
                    <dd>The propagation of one or more routing announcements beyond their intended scope, in violation of intended routing policies. Route leaks may be accidental or malicious. (See <xref target="RFC7908" format="default"/>.)</dd>

                    <dt>Update Storm:</dt>
                    <dd>A continuous high volume stream of BGP Updates sent to one or multiple neighbors.</dd>

                    <dt>Cascading Update Storm:</dt>
                    <dd>When an update storm traverses beyond directly connected neighbors.</dd>

                    <dt>Blackholing:</dt>
                    <dd>Announcing prefixes grouped by a specific community to inform all neighbors observing the announcement that traffic to the destination should be dropped.</dd>

                    <dt>ROA:</dt>
                    <dd>Route Origin Authorization - a cryptographically signed object in the RPKI through which an IP address block holder authorizes an Autonomous System to originate routes to one or more prefixes. A prefix entry may optionally specify a maximum prefix length. (See <xref target="RFC9582" format="default"/>.)</dd>

                    <dt>RPKI:</dt>
                    <dd>Resource Public Key Infrastructure represents the allocation hierarchy of IP address space and Autonomous System numbers and supports cryptographically verifiable statements about Internet number resources and their use. (See <xref target="RFC6480" format="default"/>.)</dd>

                    <dt>RPKI validator:</dt>
                    <dd>An RPKI validator is a piece of software that fetches RPKI certificates and ROAs from RPKI publication points, checks the signatures of the certificates and ROAs.</dd>

                    <dt>RPKI-RTR Protocol:</dt>
                    <dd>The RPKI to Router Protocol is used to communicate a validator's view on the RPKI to routers, providing and maintaining a list of certified prefixes and their allowed originating AS numbers. RTR may be an independent daemon, or can also be integrated in an RPKI validator.</dd>

                    <dt>DDOS:</dt>
                    <dd>A distributed denial of service (DDOS) attack is an attack against a system via the Internet. The attacker uses multiple (sometimes millions of) network sources to send more traffic towards the attacked system than it can handle. Collateral damage is quite often the network infrastructure to which the attacked system is connected to.</dd>

                </dl>
            </section>
        </section>

        <section  anchor="sec-iana-considerations">
            <name>IANA Considerations</name>
            <t>
                This document does not require any IANA actions.
            </t>
        </section>
        <section  anchor="sec-security-considerations">
            <name>Security Considerations</name>
            <t>
                This document describes currently used terminology and does not make recommendations.
                As such, it does not have security considerations.
            </t>
        </section>
    </middle>

    <back>
        <references>
            <name>References</name>
            <references>
                <name>Normative References</name>
                <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.2119.xml"/>
                <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8174.xml"/>
            </references>
            <references>
                <name>Informative References</name>
                <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.827.xml"/>
                <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.1058.xml"/>
                <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.1195.xml"/>
                <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.2328.xml"/>
                <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.2385.xml"/>
                <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.4271.xml"/>
                <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.5065.xml"/>
                <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.5880.xml"/>
                <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.5881.xml"/>
                <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.5882.xml"/>
                <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.5883.xml"/>
                <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.5925.xml"/>
				<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.6480.xml"/>
                <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7454.xml"/>
                <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7868.xml"/>
				<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7908.xml"/>
                <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.9234.xml"/>
				<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.9582.xml"/>
                <reference anchor="I-D.ietf-sidrops-aspa-verification" target="https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-aspa-verification-17">
                    <front>
                        <title>BGP AS_PATH Verification Based on Autonomous System Provider Authorization (ASPA) Objects</title>
                        <author initials="A." surname="Azimov" fullname="Alexander Azimov">
                            <organization>Yandex</organization>
                        </author>
                        <author initials="E." surname="Bogomazov" fullname="Eugene Bogomazov">
                            <organization>Qrator Labs</organization>
                        </author>
                        <author initials="R." surname="Bush" fullname="Randy Bush">
                            <organization>Internet Initiative Japan and Arrcus, Inc.</organization>
                        </author>
                        <author initials="K." surname="Patel" fullname="Keyur Patel">
                            <organization>Arrcus</organization>
                        </author>
                        <author initials="J." surname="Snijders" fullname="Job Snijders">
                            <organization>Fastly</organization>
                        </author>
                        <author initials="K." surname="Sriram" fullname="Kotikalapudi Sriram">
                            <organization>USA National Institute of Standards and Technology</organization>
                        </author>
                        <date month="September" day="23" year="2025"/>
                    </front>
                    <seriesInfo name="Internet-Draft" value="draft-ietf-sidrops-aspa-verification-23"/>
                </reference>

            </references>
        </references>
        <section anchor="acknowledgements" numbered="false" toc="default">
            <name>Acknowledgements</name>
            <t>
                This document is based on <xref target="RFC7454" format="default"/> and we thank the original authors for their work.
            </t>
            <t>
                We thank the following people for reviewing this draft and suggesting changes:
            </t>
            <ul spacing="normal">
                <li>
                    Gert Doerring
                </li>
                <li>
                    Jeff Haas
                </li>
                <li>
                    Nick Hilliard
                </li>
                <li>
                    Geng Nan
                </li>
                <li>
                    Martin Pels
                </li>
                <li>
                    Job Snijders
                </li>
                <li>
                    Berislav Todorovic
                </li>
                <li>
                    Maximilian Wilhelm
                </li>
                <li>
                    Emile Aben
                </li>
                <li>
                    Doris Hauser
                </li>
            </ul>
        </section>
    </back>
</rfc>
