One document matched: draft-jdurand-auto-bfd-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- A set of on-line citation libraries are maintained on the xml2rfc web site.
The next line defines an entity named RFC2629, which contains the necessary XML
for the reference element, and is used much later in the file. This XML contains an
anchor (also RFC2629) which can be used to cross-reference this item in the text.
You can also use local file names instead of a URI. The environment variable
XML_LIBRARY provides a search path of directories to look at to locate a
relative path name for the file. There has to be one entity for each item to be
referenced. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC4271 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4271.xml">
<!ENTITY RFC5880 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5880.xml">
<!ENTITY RFC5881 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5881.xml">
<!ENTITY nbsp " ">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<rfc
category="std"
ipr="trust200902"
docName="draft-jdurand-auto-bfd-00.txt" >
<?rfc strict="yes" ?>
<?rfc comments="no" ?>
<?rfc inline="no" ?>
<?rfc editing="no" ?>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc symrefs="no"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<front>
<title abbrev="AUTO-BFD">Path validation toward BGP next-hop with AUTO-BFD</title>
<author
fullname="Jerome Durand"
initials="J."
surname="Durand">
<organization abbrev="CISCO">CISCO Systems, Inc.</organization>
<address>
<postal>
<street>11 rue Camille Desmoulins</street>
<code>92782 CEDEX</code>
<city>Issy-les-Moulineaux</city>
<country>FR</country>
</postal>
<email>jerduran@cisco.com</email>
</address>
</author>
<author
fullname="David Freedman"
initials="D."
surname="Freedman">
<organization abbrev="Claranet">Claranet</organization>
<address>
<postal>
<street>21 Southampton Row, Holborn</street>
<city>London</city>
<code>WC1B 5HA</code>
<country>UK</country>
</postal>
<email>david.freedman@uk.clara.net</email>
</address>
</author>
<date year="2015" month="March"/>
<area>Routing</area>
<workgroup>Internet Engineering Task Force</workgroup>
<abstract>
<t>This document describes a solution called AUTO-BFD, that automatically initiates BFD sessions for BGP next-hops. This makes it possible to avoid blackholing scenarios when a BGP peer is not the BGP next-hop, especially on Internet eXchange Points (IXPs) when BGP Route-Servers are deployed. When they are configured with this mechanism, routers can automatically try to establish a new adjacency for every new BGP next-hop. BGP routes are then checked against the state of the BFD session for the corresponding next-hop.</t>
</abstract>
<note title="Foreword">
<t>A placeholder to list general observations about this document.</t>
</note>
<note title="Requirements Language">
<t>The key words "MUST", "MUST NOT",
"REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be
interpreted as described in <xref target="RFC2119">RFC 2119</xref>.
</t>
</note>
</front>
<middle>
<section anchor="Introduction" title="Introduction">
<t>Internet eXchange Points (IXPs) implement BGP Route-Servers (RS) <xref target="RouteServer" /> so that connected members do not need to configure BGP peerings with every other member to exchange routes. Through a single peering with the RS, a member can receive routes of all the other members peering with the RS. The RS redistributes routes and could simply be described as a Route-Reflector for eBGP peerings.</t>
<t>Usually, deployed RS do not modify the BGP next-hop of exchanged routes so traffic exchanged between IXP members does not pass through the RS, which keeps only a control-plane role, exactly as for a BGP RR. The drawback is that it may happen that a peering stays up between members and route-server while there is no connectivity between members. This results in black holes for members with no easy troubleshooting: usually upon such problem a member just shuts its connectivity to the IXP. This situation has happened several times on many different IXPs and many members do not want to peer with route-servers for this reason.</t>
<figure anchor="ProblemDescriptionSchema">
<artwork>
EBGP UP----> RS <-------EBGP UP
| | |
| | |
----------------IXP LAN---------------------
| | | |
V | | V
Member 1 <================> Member 2
BROKEN
CONNECTIVITY
</artwork>
</figure>
<t>This proposal intends to solve this situation with the automation of BFD adjacency creation when new BGP next-hops are discovered. When configured with this solution, routers can automatically try to establish a new adjacency for every new BGP next-hop. BGP routes are then checked against the BFD session states for the corresponding next-hop.</t>
</section>
<section anchor="Definition" title="Definitions and Accronyms">
<t><list style="symbols">
<t>BFD: Bidirectional Forwarding Detection protocol <xref target="RFC5880" /><xref target="RFC5881" /></t>
<t>BGP: Border Gateway Protocol <xref target="RFC4271" /></t>
<t>IXP: Internet eXchange Point</t>
<t>RR: Route Reflector (BGP Route-Reflector)</t>
<t>RS: Route Server (BGP Route-Server) <xref target="RouteServer" /></t>
</list>
</t>
</section>
<section anchor="Requirements" title="Solution Requirements">
<t>The following requirements apply to the solution described in this document:
<list style="symbols">
<t>The solution MUST be independent of the BGP route-server's configuration. In other words IXP members SHOULD be able to check each other's liveliness without anything configured on the route-server.</t>
<t>Solution MUST NOT imply a configuration per IXP member. Each IXP member SHOULD automatically discover other members and automatically start probing when this is possible.</t>
<t>The solution MUST accept situations when not all the IXP members do not implement it. In other words the implementation of this mechanism on one of the IXP member MUST NOT impact the other members.</t>
<t>The solution SHOULD rely on a widely adopted host liveliness verification protocol in the context of BGP peerings. The used host liveliness mechanism MUST be negotiated between members to avoid false positives.</t>
<t>The solution SHOULD be as simple as possible and SHOULD NOT require the design of a new protocol.</t>
</list>
</t>
<t>Based on these requirements, the following is suggested:
<list style="symbols">
<t><xref target="RFC5880">BFD</xref> (Bidirectional Forwarding Detection) is an appropriate liveliness verification mechanism that IXP members can use to check their mutual status. It is widely adopted in the Internet community for this use and its scalability on modern routers makes it suitable for IXPs. Also BFD integrates an initial negotiation phase that makes it appropriate to interdomain scenarios, when all routers are not configured with the same options.</t>
<t>IXP members cannot easily rely on an existing protocol to announce their mutual capability to support a host liveliness protocol. Since IXP members using BGP RS do not directly establish BGP peerings between them, any use of BGP to announce BFD capability would require solution support on the BGP RS which would prevent any usage on an IXP not implementing it. Solutions based on optional transitive BGP attribute have been studied <xref target="IDR-NH-liveliness" /> and showed some complexity and privacy challenges as it could force every member to disclose topology information globally to the downstreams of other IXP members.</t>
</list>
</t>
</section>
<section anchor="Solution" title="Solution Overview">
<t>The solution proposed in this document, named AUTO-BFD, is straightforward and relies on existing mechanisms. It works as follows:
<list style="symbols">
<t>AUTO-BFD is configured on the BGP peering to the BGP RS.</t>
<t>Every time a new BGP next-hop is received from this peering, AUTO-BFD triggers a new BFD session with this next-hop (or reinstates an existing session, see <xref target="BFDsessionAgeing"/>). The operation mode for this BFD session MUST be asynchronous. Timers can be locally configured. Optional security configuration can limit the number of authorized adjacencies or trigger BFD only for next-hops in a given prefix. Other optional configuration can define the BFD timers.</t>
<t>Routes coming from the AUTO-BFD enabled BGP neighbor are then checked based on the BGP next-hop and its BFD session state. Acceptance of routes is then subject to the administrative policy based on BFD session state. An example of such a policy can be found in appendix <xref target="ConfigAppendix" /></t>
</list>
</t>
</section>
<section anchor="BFDsessionAgeing" title="BFD Session Ageing">
<t>In order to maintain the relevance of AUTO-BFD sessions, it is required to prune sessions when they are not needed anymore. A router X may not simply prune BFD session toward Y when there are no more routes with corresponding next-hop Y as the BFD session may still be needed by the Y to accept route from X.</t>
<t>The following solution makes it possible to prune BFD sessions only when it is sure the remote end does not need it anymore. A per-session timer (bfd.AutoAge) is defined to determine an interval. This timer MAY derive its configuration from a global value in an implementation. The timer counts down until it expires, at which point, the relevant AUTO-BFD session is checked against next-hop information received from the AUTO-BFD configured BGP session to determine if there are still next hops received which relate to the session. Based on the information, the following occurs:
<list style="symbols">
<t>If next-hops for the remote system are still being received, bfd.LocalDiag should be set to XX, which will set the appropriate diagnostic code "XX - Continuing AUTO-BFD" (to be assigned by IANA) in the outgoing control packet, to indicate that the next hop continues to be seen and used by this system. At this point, the timer is reset and no further action is taken until it expires next.</t>
<t>If next-hops for the remote system are no longer being received, the following occurs:
<list style="symbols">
<t>If the session is still up (bfd.Sessionstate is UP) and a control packet arrives which would not change the state, but with the flag "XX - Continuing AUTO-BFD" set, this indicates that the remote system is still receiving routes with the local system as the next hop. In this case, the session MUST remain up, the timer is reset and no further action is taken until it expires next.</t>
<t>If the session is still up (bfd.Sessionstate is UP) and a control packet arrives which would not change the state, but does not set the "XX - Continuing AUTO-BFD" diagnostic flag, then we must consider that the remote system is no longer receiving routes with the local system as next hop. In this case, the bfd.LocalState should be set to 'AdminDown' and the session should be placed in an Administrative Down state.</t>
</list>
</t>
</list>
</t>
<t>When a session is first established (or indeed re-established as per <xref target="Solution"/>), it is important that the bfd.LocalDiag should be set to XX to ensure that control packets start to signal this state to the remote system.
</t>
</section>
<section anchor="OtherUseCases" title="Possible other use cases">
<t>While the primary focus of the authors is to solve the issue met with BGP route-servers on IXPs described in section <xref target="Introduction" />, the proposed solution may also apply to the following use cases:
<list style="symbols">
<t>IBGP Route-Reflector (RR): the scenario described for BGP RS could also apply for IBGP RR. The solution described in this draft could be used to validate received IBGP routes against real reachability of BGP next-hop (a router in same AS in case next-hop self is used, or the EBGP next-hop announcing the route.</t>
<t>Any EBGP peering: the proposed solution would enable automatic BFD auto-deployment on every EBGP peering. AUTO-BFD would automatically "harden" the peering without the need of any additional configuration.</t>
</list>
</t>
</section>
<section anchor="FutureWork" title="Future Work">
<t>Following points may need to be documented further in next versions of this document based on comments received by the community:
<list style="symbols">
<t>AUTO-BFD interoperability with manual BFD sessions.</t>
<t>S-BFD integration</t>
<t>Security considerations</t>
</list>
</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The authors would like to thank the following people for their comments and support: [TBD].</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This memo requests a code point from the registry for BFD diagnostic codes <xref target="RFC5880" />: XX -- Continuing Auto-BFD</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>TBD</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
&RFC4271;
&RFC5880;
&RFC5881;
<reference anchor="RouteServer" target="http://tools.ietf.org/id/draft-ietf-idr-ix-bgp-route-server-06.txt">
<front>
<title>Internet Exchange Route Server</title>
<author>
<organization/>
</author>
<date/>
</front>
</reference>
</references>
<references title="Informative References">
<reference anchor="IDR-NH-liveliness" target="https://tools.ietf.org/id/draft-jdurand-idr-next-hop-liveliness-00.txt">
<front>
<title>Path validation toward BGP next-hop</title>
<author>
<organization/>
</author>
<date/>
</front>
</reference>
</references>
<section anchor="ConfigAppendix" title="Configuration ">
<t>This configuration in classic Cisco IOS style will help reader understand the way AUTO-BFD can be integrated in current deployments.</t>
<figure anchor="ConfigOne">
<artwork>
router bgp 65001
neighbor 192.0.2.102 remote-as 65102
!
address-family ipv4 unicast
neighbor 192.0.2.102 activate
neighbor 192.0.2.102 auto-bfd
neighbor 192.0.2.102 route-map FROM-RS in
!
route-map FROM-RS permit 10
match next-hop bfd-session-state Up
set local-pref 120
route-map FROM-RS deny 20
match next-hop bfd-session-state Down Init
route-map FROM-RS permit 30
match next-hop bfd-session-state AdminDown
set local-pref 50
</artwork>
</figure>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:09:16 |