<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC4271 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4271.xml">
<!ENTITY RFC4272 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4272.xml">
<!ENTITY RFC4760 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4760.xml">
<!ENTITY RFC5880 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5880.xml">
<!ENTITY RFC5881 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5881.xml">
<!ENTITY RFC7880 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7880.xml">
<!ENTITY RFC7947 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7947.xml">
<!ENTITY I-D.ietf-idr-bgp-bestpath-selection-criteria SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-idr-bgp-bestpath-selection-criteria.xml">
<!ENTITY RFC7947 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7947.xml">
<!ENTITY BFD-UNSOL SYSTEM
"https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.draft-chen-bfd-unsolicited-02.xml">
]>
<?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 category="std" docName="draft-ietf-idr-rs-bfd-09">
	<front>
		<title abbrev="Making RSes aware of IXP Data Link Failures">Making
			   Route Servers Aware of Data Link Failures at IXPs</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="Jeffrey Haas" initials="J." surname="Haas">
			<organization>Juniper Networks, Inc.</organization>
			<address>
				<postal>
					<street>1133 Innovation Way</street>
					<city>Sunnyvale</city>
					<region>CA</region>
					<code>94089</code>
					<country>US</country>
				</postal>
				<email>jhaas@juniper.net</email>
			</address>
		</author>

		<author fullname="John G. Scudder" initials="J." surname="Scudder">
			<organization>Juniper Networks, Inc.</organization>
			<address>
				<postal>
					<street>1133 Innovation Way</street>
					<city>Sunnyvale</city>
					<region>CA</region>
					<code>94089</code>
					<country>US</country>
				</postal>
				<email>jgs@juniper.net</email>
			</address>
		</author>

		<author fullname="Arnold Nipper" initials="A." surname="Nipper">
			<organization abbrev="DE-CIX">DE-CIX Management GmbH</organization>
			<address>
				<postal>
					<street>Lichtstrasse 43i</street>
					<city>Cologne</city>
					<code>50825</code>
					<country>Germany</country>
				</postal>
				<email>arnold.nipper@de-cix.net</email>
			</address>
		</author>
		
		<author fullname="Christoph Dietzel" initials="C." surname="Dietzel">
			<organization abbrev="DE-CIX">DE-CIX Management GmbH</organization>
			<address>
				<postal>
					<street>Lichtstrasse 43i</street>
					<city>Cologne</city>
					<code>50825</code>
					<country>Germany</country>
				</postal>
				<email>christoph.dietzel@de-cix.net</email>
			</address>
		</author>

		<date/>

		<abstract>
			<t>
				When BGP route servers are used, the data plane is not
				congruent with the control plane. Therefore, peers at an
				Internet exchange can lose data connectivity without the
				control plane being aware of it, and packets are lost. This
				document proposes the use of a newly defined BGP Subsequent
				Address Family Identifier (SAFI) both to allow the route
				server to request its clients use BFD to track data plane
				connectivity to their peers' addresses, and for the clients to
				signal that connectivity state back to the route server.
			</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>
				In configurations (typically Internet Exchange Points (IXPs))
				where EBGP routing information is exchanged between client
				routers through the agency of a route server (RS) <xref
				target="RFC7947" />, but traffic is exchanged directly,
				operational issues can arise when partial data plane
				connectivity exists among the route server client routers.
				Since the data plane is not congruent with the control plane,
				the client routers on the IXP can lose data connectivity
				without the control plane - the route server - being aware of
				it, resulting in significant data loss.
			</t>
			<t>
				To remedy this, two basic problems need to be solved:
				<list style="numbers">
				<t>Client routers must have a means of verifying connectivity
				   amongst themselves, and</t>
				<t>Client routers must have a means of communicating the
				   knowledge of the failure (and restoration) back to the 
				   route server.</t>
				</list>
			</t>
			<t>
				The first can be solved by application of Bidirectional
				Forwarding Detection <xref target="RFC5880" />. The second can
				be solved by exchanging BGP routes which use the NH-Reach
				Subsequent Address Family Identifier (SAFI) defined in this
				document.
			</t>
			<t>
				Throughout this document, we generally assume that the route
				server being discussed is able to represent different RIBs
				towards different clients, as discussed in <xref
				target="RFC7947">section 2.3.2.1 of</xref>. If this is not
				the case, the procedures described here to allow BFD to be 
				automatically provisioned between clients still have value;
				however, the procedures for signaling reachability back to the
				route server may not.
			</t>
			<t>
				Throughout this document, we refer to the "route server", "RS"
				or just "server" and the "client" to describe the two BGP
				routers engaging in the exchange of information. We observe
				that there could be other applications for this extension. Our
				use of terminology is intended for clarity of description, and
				not to limit the future applicability of the proposal.
			</t>
			<t>
				<xref target="I-D.ietf-idr-bgp-bestpath-selection-criteria"/>
				discusses enhancement of the route resolvability condition of
				<xref target="RFC4271">section 9.1.2.1 of</xref> to include
				next hop reachability and path availability checks. This
				specification represents in part an instance of such,
				implemented using BFD as the OAM mechanism.
			</t>

		</section>
		<section anchor="definitions" title="Definitions">
			<t>
				<list style="symbols">
					<t>
						Indirect peer: If a route server is configured such
						that routes from a given client might be sent to some
						other client, or vice-versa, those two clients are
						considered to be indirect peers.
					</t>
					<t>
					    Indirect Peer's Address, IPA, next hop: We refer
					    frequently to a next hop. It should generally be
					    clear from context what is intended, almost always
					    an address associated with an indirect peer (the
					    exception, when an indirect peer sends a third
					    party next hop, is discussed in <xref
					    target="overview"/>). In <xref
					    target="advertising"/> we discuss the <xref
					    target="RFC4760">MP-BGP</xref> Next Hop field; this
					    is distinguished by its capitalization and should
					    also be clear from context. Later in that section
					    we define the Indirect Peer's Address field of the
					    NLRI, also called "IPA". It will be clear to the
					    reader that this refers to the "next hops"
					    discussed elsewhere in the document, but we don't
					    use the name "next hop" for this field to avoid
					    confusion with the pre-existing next hop path
					    attribute of <xref target="RFC4271"/> and
					    attribute field of <xref target="RFC4760"/>.
					</t>
					<t>
						RS: Route Server. See <xref target="RFC7947"/>.
					</t>
				</list>
			</t>
		</section>

		<section anchor="overview" title="Overview">
			<t>
				As with the base BGP protocol, we model the function of this
				extension as the interaction between a conceptual set of
				databases:
			</t>
			<t>
				<list style="symbols">
					<t>
						ReachAsk: The reachability request database. A
						database of next hops (host addresses) for which data
						plane reachability is being queried. 
					</t>
					<t>
						ReachAsk-Out: A set of queries sent to the client.
					</t>
					<t>
						ReachAsk-In: A set of queries received from the route
						server.
					</t>
					<t>
						ReachTell: The reachability response database. A
						database of responses to ReachAsk queries, indicating
						what is known about data plane reachability.
					</t>
					<t>
						ReachTell-Out: The responses being sent to the route
						server.
					</t>
					<t>
						ReachTell-In: The response received from the client.
					</t>
					<t>
						LocReach: The local reachability database. 
					</t>
					<t>
					    NHIB: Next Hop Information Base. Stores what is known
					    about the client's reachability to its next hops.
					</t>
				</list>
			</t>
			 
<figure title="Route Server, RS Client, and Reachability Ask and Tell
databases with In/Out Queues" align="center">
   <artwork><![CDATA[
+--------------------------------------------------------+
|   +------------+    +------------+    +------------+   |
|   |    Per-    |    | Configured |    |    Per-    |   |
|   |   Client   |    |  indirect  |    |   Client   |   |
|   |    NHIB    |    |   peers    |    |    RIB     |   |
|   +-----^------+    +------------+    +-----+------+   |
|         |                         \         |          |
|   +-----+------+                   `-->-----v------+   |
|   |ReachTell-In|                      |ReachAsk-Out|   |
|   +------^-----+     Route Server     +-----+------+   |
+----------|----------------------------------|----------+
           |                                  |           
           |                                  |           
           |                                  |
           |                                  |
+----------|----------------------------------|----------+
|   +------+------+       RS Client     +-----v-----+    |
|   |ReachTell-Out|                     |ReachAsk-In|    |
|   +------^------+                     +-----+-----+    |
|          |          +------------+          |          |
|          |          |            |          |          |
|          `----------+  LocReach  <----------'          |
|                     |            |                     |
|                     +------------+                     |
+--------------------------------------------------------+
   ]]></artwork>
 </figure>
 
			<t>
				In outline, the route server requests its client to track
				connectivity for all the potential next hops the RS might send
				to the client, by sending these next hops as ReachAsk
				"routes". The client tracks connectivity using BFD and reports
				its connectivity status to the RS using ReachTell "routes".
				Connectivity status may be that the next hop is reachable,
				unreachable, or unknown. Once the RS has been informed by the
				client of its connectivity, it uses this information to
				influence the route selection the RS performs on behalf of the
				client. Details are elaborated in the following sections.
			</t>
		</section>
		
		<section anchor="nh_validation" title="Next Hop Validation">
			<t>
				Below, we detail procedures where a route server tells its
				client router about other client next hops by sending it
				ReachAsk routes and the client router verifies connectivity to
				those other client routers and communicates its findings back
				to the RS using ReachTell routes. The RS uses the received
				ReachTell routes as input to the NHIB and hence the route
				selection process it performs on behalf of the client.
			</t>

			<section anchor="reachask" title="ReachAsk">
				<t>
					The route server maintains a ReachAsk database for each
					client that supports this proposal, that is, for each
					client that has <xref target="advertising">advertised
					support</xref> for the NH-Reach SAFI.  This database is
					the union of:
					
					<list style="symbols">
						<t>
							The set of next hops found in the
							associated per-client Loc-RIB (see <xref
							target="RFC7947">section 2.3.2.1 of</xref>).
						</t>
						<t>
							The set of addresses of this client's <xref
							target="definitions">indirect peers</xref>.
						</t>
						<t>
							The RS MAY also add other entries, for example
							under configuration control.
						</t>
					</list>
					
					We note that under most circumstances, the first (Loc-RIB
					next hops) set will be a subset of the second (indirect
					peers) set. For this not to be the case, a client would
					have to have sent a "third party" next hop <xref
					target="RFC4271"/> to the server. To cover such a case, an
					implementation MAY note any such next hops, and include
					them in its list of indirect peers. (This implies that if
					a third party next hop for client C is conveyed to client
					A, not only will C be placed in A's ReachAsk database, but
					A will be placed in C's ReachAsk database.)
				</t>
				
				<t>
					The contents of the ReachAsk database are communicated to
					the client using the NLRI format and procedures described
					in <xref target="advertising"/>.
				</t>
			</section>
			
			<section anchor="locreach" title="LocReach">
				<t>
					The client MUST attempt to track data plane connectivity
					to each host address depicted in the ReachAsk database. It
					MAY also track connectivity to other addresses. The use of
					BFD for this purpose is detailed in <xref
					target="client_procedures"/>. 
				</t>
				
				<t>
					For each address being tracked, its state is maintained by
					the client in a LocReach entry. The state can be:
					
					<list style="symbols">
						<t>Unknown. Connectivity status is unknown. This may be
						due to a temporary or permanent lack of feasible OAM
						mechanism to determine the status. </t>
						<t>Up. The address has been determined to be
						reachable.</t>
						<t>Down. The address has been determined to be 
						unreachable.</t>
					</list>
					
					The LocReach database is used as input for the ReachTell
					database; it MAY also be used as input to the client's
					route resolvability condition (<xref
					target="RFC4271">section 9.1.2.1 of</xref>).
				</t>
				
			</section>
			
			<section anchor="reachtell" title="ReachTell">
				<t>
					The ReachTell database contains an entry for every
					entry in the LocReach database.
				</t>
				
				<t>
					The contents of the ReachTell database are communicated to
					the server using the NLRI format and procedures described
					in <xref target="advertising"/>.
				</t>
			</section>
			
			<section anchor="nhib" title="NHIB">
				<t>
					The route server maintains a per-client Next Hop
					Information Base, or NHIB. This contains the information
					about next hop status received from ReachTell.
				</t>

				<t>
					In computing its per-client Loc-RIB, the RS uses the
					content of the related per-client NHIB as input to the
					route resolvability condition (<xref
					target="RFC4271">section 9.1.2.1 of</xref>). The next 
					hop being resolved is looked up in the NHIB and its state
					determined:

					<list style="symbols">
						<t>Up next hops are considered resolvable.</t>
						<t>Unknown next hops MAY be considered resolvable.
						They MAY be less preferred for selection.</t>
						<t>Down next hops MUST NOT be considered 
						resolvable.</t>
						<t>If a given next hop is not present in the NHIB, but
						is present in ReachAsk-Out, either the client has not
						responded yet (a transient condition) or an error
						exists. Similar to Unknown next hops, such routes
						MAY be considered resolvable; they MAY be
						less preferred.</t>
					</list>
				</t>
			</section>
		</section>
		
		<section anchor="advertising" title="Advertising NH-Reach state in BGP">
			<t>
				A new BGP SAFI, the NH-Reach SAFI, is defined in this
				document.  It has been assigned value TBD.  A route server
				or a route server client using the procedures in this
				document MUST advertise support for this SAFI, for the
				IPv4 and/or IPv6 Address Family Identifier (AFI). The use
				of this SAFI with any other AFI is not defined by this
				document.
			</t>
			<t>
				NH-Reach NLRI "routes" have a Length of Next Hop Network
				Address value of 0, therefore they have an empty Network
				Address of Next Hop field (<xref target="RFC4760">section
				3 of</xref>).
			</t>
			<t>
				Since as specified here, ReachTell "routes" from different
				clients populate distinct databases on the RS, there will
				generally be only a single path per "route"; this implies
				that route selection need not be performed (or
				equivalently, that it's trivial to perform).
			</t>
			<t>
				In the other direction, a client might peer with multiple
				route servers and receive differing sets of ReachAsk
				routes from them. An implementation MAY handle this
				situation by implementing a distinct ReachAsk and
				ReachTell per server, but it MAY also handle it by placing
				all servers' ReachAsk "routes" into a single ReachAsk, and
				sending the results to all servers from a single
				ReachTell. This would imply some route server(s) might get
				ReachTell results they had not asked for, but this is
				permissible in any case. Again, since the contents of
				ReachAsk are simply a set of host routes to be tested,
				route selection over a combined ReachAsk MAY be omitted.
			</t>
			<t>
				ReachAsk and ReachTell entries are exchanged using the
				NH-Reach NLRI encoding: 
			</t>
                        <figure title="NH-Reach NLRI Format" align="center"><artwork><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|Reserved |Sta|    Indirect Peer's Address (4 or 16 octets)   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.      ...  Indirect Peer's Address (4 or 16 octets) ...        .
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                                        ]]></artwork></figure>

			<t><list style="symbols">
				<t>T: Type is a one-bit field that can take the 
				   value 0, meaning the NLRI is a ReachAsk entry, or 1,
				   meaning it is a ReachTell entry.</t>
				<t>Reserved: These five bits are reserved. They MUST
				   be sent as zero and MUST be disregarded on 
				   receipt.</t>

				<t>Sta: State is a two-bit field used to signal the 
				   <xref target="locreach">LocReach</xref> state:
					<list style="symbols">
						<t>0 or 3: Unknown.</t>
						<t>1: Up.</t>
						<t>2: Down.</t>
					</list>
					Although either 0 or 3 is to be interpreted as
					"Unknown", the value 0 MUST be used on transmission.
					The value 3 MUST be accepted as an alias for 0 on
					receipt.
				</t>
				<t>The Indirect Peer's Address ("IPA") field is an IPv4 
				   or IPv6 host route, depending on whether the AFI is 
				   IPv4 or IPv6.</t>
			</list></t>

			<t>
				ReachAsk and ReachTell entries MUST NOT be propagated from
				one BGP peering session to another; the routes are not
				transitive.  
			</t>
			<t>
				The IPA field is the key for the NH-Reach NLRI type;
				the information encoded in the top octet is non-key
				information. It is possible in principle (although
				unlikely) for two NLRI to be validly present in an UPDATE
				message with identical IPA fields but different
				types. However, two NLRI with the same IPA field and
				different State fields MUST NOT be encoded in the same
				UPDATE message. If such is encountered, the receiver MUST
				behave as though the state "Unknown" was received for the
				IPA in question.
			</t>
		</section>

		<section anchor="client_procedures" 
				 title="Client Procedures for NH-Reach Changes">
			<t>
				When an entry is added to a route server client's
				ReachAsk-In for a route server peering session, the client
				will then attempt to verify connectivity to the host
				depicted by that entry.  The procedure described in this
				specification utilizes BFD.
			</t>
			<t>
				If no existing BFD session exists to this next hop, a BFD
				session is provisioned to that IP address and the LocReach
				<xref target="locreach">reachability state</xref> is set to
				Unknown. 
			</t>
			<t>
				If the client cannot establish a BFD session with an entry
				in its ReachAsk-In, the next hop remains in 
				LocReach with its Reachable state Unknown.
			</t>
			<t>
				Once the BFD session moves to the Up state, the LocReach
				reachability state is set to Up.  
			</t>
			<t>
				When the BFD session transitions out of the Up state to
				the Down state, the LocReach reachability state is set to
				Down.  
			</t>
			<t>
				If the BFD session transitions out of the Up state to the
				AdminDown state, the LocReach reachability state is set to
				Unknown.  
			</t>
			<t>
				When entries are removed from the route server client's
				ReachAsk-In for a route server peering session, the client
				MAY delay de-provisioning the BFD peering session.  If the
				client delays de-provisioning the session, it should
				remove it if the BFD session transitions to the Down or
				AdminDown states. 
			</t>
		</section>
		
		<section anchor="recommendations" title="Recommendations for Using BFD">
			<t>
				The RECOMMENDED way a client router can confirm the data
				plane connectivity to its next hops is available, is the
				use of BFD in asynchronous mode. Echo mode MAY be used if
				both client routers running a BFD session support this.
				The use of authentication in BFD is OPTIONAL as there is a
				certain level of trust between the operators of the client
				routers at a particular IXP. If trust cannot be assumed,
				it is recommended to use pair-wise keys (how this can be
				achieved is outside the scope of this document). The
				ttl/hop limit values as described in <xref
				target="RFC5881">section 5</xref> MUST be obeyed in order
				to shield BFD sessions against packets coming from outside
				the IXP.
			</t>
							
			<t>
				The following values of the BFD configuration of client
				routers (see <xref target="RFC5880">section 6.8.1</xref>)
				are RECOMMENDED:
				<list style='symbols'>
					<t>DesiredMinTxInterval: 1,000,000 (microseconds)</t>
					<t>RequiredMinRxInterval: 1,000,000 (microseconds)</t>
					<t>DetectMult: 3</t>
				</list>
			</t>
			<t>
				A client router administrator MAY select more appropriate
				values to meet the special needs of a particular
				deployment.
			</t>
		</section>

		<section anchor="other" title="Other Considerations">
			<t>
				For purposes of routing stability, implementations may wish to
				apply hysteresis ("holddown") to next hops that have
				transitioned from reachable to unreachable and back. 
			</t>
			<t>
				Implementations MAY restrict the range of addresses with which
				they will attempt to form BFD relationships. For example, an
				implementation might by default only allow BFD relationships
				with peers that share a subnetwork with the route server. An
				implementation MAY apply such restrictions by default.
			</t>
			<t>
			    In a route-server environment, use of this feature SHOULD
			    be restricted to consider only routes that are advertised
			    from within the IXP network.  This might include checks on
			    AS_PATH length.
			</t>
		</section>

		<section title="Acknolwedgments">
			<t>
				The authors would like to thanks Thomas King for his contributions
				toward this work.
			</t>
		</section>

		<section title="IANA Considerations">
			<t>
				IANA is requested to allocate a value from the Subsequent
				Address Family Identifiers (SAFI) Parameters registry for this
				proposal.  Its Description in that registry shall be NH-Reach
				with a Reference of this RFC.
			</t>
		</section>

		<section title="Security Considerations">
			<t>
				The mechanism in this document permits a route server client
				to influence the contents of the route server's Adj-Ribs-Out
				through its reports of next hop reachability state using the
				NH-Reach SAFI.  Since this state is per-client, if a route
				server client is able to inject NH-Reach routes for another
				route server's BGP session to a client, it can cause the route
				server to select different forwarding than otherwise expected.
				This issue may be mitigated using transport security on the
				BGP sessions between the route server and its clients.  See
				<xref target="RFC4272"/>.
			</t>
			<t>
				The NH-Reach SAFI enables the server to trigger creation of a
				BFD session on its client. A malicious or misbehaving server
				could trigger an unreasonable number of sessions, a potential
				resource exhaustion attack. The sedate default timers proposed
				in <xref target="recommendations"/> mitigate this; they also
				mitigate concerns about use of the client as a source of
				packets in a flooding attack. An implementation MAY also
				impose limits on the number of BFD sessions it will create at
				the request of the server.
			</t>
			<t>
				The reachability tests between route server clients themselves
				may be a target for attack.  Such attacks may include forcing
				a BFD session Down through injecting false BFD state.  A less
				likely attack includes forcing a BFD session to stay Up when
				its real state is Down.  These attacks may be mitigated using
				the BFD security mechanisms defined in <xref
				target="RFC5880"/>.
			</t>
		</section>
	</middle>

	<back>

		<references title="Normative References">
		&RFC2119;
		&RFC4271;
		&RFC4760;
		&RFC5880;
		&RFC5881;
		&RFC7947;
		</references>
		<references title="Informative References">
		&RFC4272;
		&I-D.ietf-idr-bgp-bestpath-selection-criteria;
		&RFC7880;
		&BFD-UNSOL;
		</references>

		<section title="Summary of Document Changes">
		    <t>
		    <list style="hanging" hangIndent="2">
			<t hangText="idr-06:">Refresh -05.</t>
		        <t hangText="idr-04 to idr-05:">Added reference to "BGP Bestpath 
		           Selection Criteria Enhancement" draft. Rename "next hop" field
		           of NLRI to "Indirect Peer's Address". Add suggestion about
		           AS_PATH length checks. </t>
			<t hangText="idr-03 to idr-04:">Note other forms of connectivity checks.</t>
		        <t hangText="idr-02 to idr-03:">Substantial rewrite. Introduce 
		           NLRI format that embeds state.</t>
			<t hangText="idr-01 to idr-02:">Move from BGP-LS to NH-Reach SAFI.
			   Lots of editorial changes.</t>
			<t hangText="idr-00 to idr-01:">Add BGP Capability.  Move from 
			   NH-Cost to BGP-LS.</t>
			<t hangText="ymbk-01 to idr-00:">No technical changes; adopted by 
			   IDR.</t>
			<t hangText="ymbk-00 to ymbk-01:">Clarifications to BFD procedures. 
			   Use BFD state as an input to BGP route selection.</t>

		    </list>
		    </t>
		</section>

		<section title="Other Forms of Connectity Checks">
			<t>
				RFC 5880/5881 BFD is a well-deployed feature.  For this reason, it
				was chosen as the connectivity check utilized for nexthop
				reachability by this document.  As other forms of BFD become more
				widely deployed, they may also be utilized to provide the
				connectivity check functionality.
			</t>
			<t>
				Examples of other such BFD mechanisms include:
				<list style="symbols">
					<t><xref target="RFC7880">Seamless BFD</xref></t>
					<t><xref target="I-D.chen-bfd-unsolicited">
					    Unsolicited BFD for Sessionless Applications</xref></t>
				</list>
			</t>
			<t>
				Implementations MUST support RFC 5880/5881 BFD to be compliant with
				this specification.  Implementations MAY support other forms of
				connectivity check, including those mechanisms listed above, so long
				as they provide the ability to fall-back to RFC 5880/5881 BFD.
			</t>
		</section>

	</back>

</rfc>
