Network Working Group R. Bush
Internet-Draft Internet Initiative Japan
Intended status: Standards Track J. Haas
Expires: March 25, 2021 J. Scudder
Juniper Networks, Inc.
A. Nipper
C. Dietzel
DE-CIX
September 21, 2020
Making Route Servers Aware of Data Link Failures at IXPs
draft-ietf-idr-rs-bfd-09
Abstract
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.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to
be interpreted as described in [RFC2119] only when they appear in all
upper case. They may also appear in lower or mixed case as English
words, without normative meaning.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
Bush, et al. Expires March 25, 2021 [Page 1]
Internet-Draft Making RSes aware of IXP Data Link FailuresSeptember 2020
This Internet-Draft will expire on March 25, 2021.
Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Next Hop Validation . . . . . . . . . . . . . . . . . . . . . 5
4.1. ReachAsk . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. LocReach . . . . . . . . . . . . . . . . . . . . . . . . 6
4.3. ReachTell . . . . . . . . . . . . . . . . . . . . . . . . 7
4.4. NHIB . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Advertising NH-Reach state in BGP . . . . . . . . . . . . . . 7
6. Client Procedures for NH-Reach Changes . . . . . . . . . . . 9
7. Recommendations for Using BFD . . . . . . . . . . . . . . . . 9
8. Other Considerations . . . . . . . . . . . . . . . . . . . . 10
9. Acknolwedgments . . . . . . . . . . . . . . . . . . . . . . . 10
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
11. Security Considerations . . . . . . . . . . . . . . . . . . . 10
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
12.1. Normative References . . . . . . . . . . . . . . . . . . 11
12.2. Informative References . . . . . . . . . . . . . . . . . 12
Appendix A. Summary of Document Changes . . . . . . . . . . . . 12
Appendix B. Other Forms of Connectity Checks . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction
In configurations (typically Internet Exchange Points (IXPs)) where
EBGP routing information is exchanged between client routers through
the agency of a route server (RS) [RFC7947], but traffic is exchanged
directly, operational issues can arise when partial data plane
connectivity exists among the route server client routers. Since the
Bush, et al. Expires March 25, 2021 [Page 2]
Internet-Draft Making RSes aware of IXP Data Link FailuresSeptember 2020
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.
To remedy this, two basic problems need to be solved:
1. Client routers must have a means of verifying connectivity
amongst themselves, and
2. Client routers must have a means of communicating the knowledge
of the failure (and restoration) back to the route server.
The first can be solved by application of Bidirectional Forwarding
Detection [RFC5880]. The second can be solved by exchanging BGP
routes which use the NH-Reach Subsequent Address Family Identifier
(SAFI) defined in this document.
Throughout this document, we generally assume that the route server
being discussed is able to represent different RIBs towards different
clients, as discussed in section 2.3.2.1 of [RFC7947]. 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.
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.
[I-D.ietf-idr-bgp-bestpath-selection-criteria] discusses enhancement
of the route resolvability condition of section 9.1.2.1 of [RFC4271]
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.
2. Definitions
o 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.
o 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 Section 3). In Section 5 we discuss the
Bush, et al. Expires March 25, 2021 [Page 3]
Internet-Draft Making RSes aware of IXP Data Link FailuresSeptember 2020
MP-BGP [RFC4760] 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 [RFC4271] and
attribute field of [RFC4760].
o RS: Route Server. See [RFC7947].
3. Overview
As with the base BGP protocol, we model the function of this
extension as the interaction between a conceptual set of databases:
o ReachAsk: The reachability request database. A database of next
hops (host addresses) for which data plane reachability is being
queried.
o ReachAsk-Out: A set of queries sent to the client.
o ReachAsk-In: A set of queries received from the route server.
o ReachTell: The reachability response database. A database of
responses to ReachAsk queries, indicating what is known about data
plane reachability.
o ReachTell-Out: The responses being sent to the route server.
o ReachTell-In: The response received from the client.
o LocReach: The local reachability database.
o NHIB: Next Hop Information Base. Stores what is known about the
client's reachability to its next hops.
Bush, et al. Expires March 25, 2021 [Page 4]
Internet-Draft Making RSes aware of IXP Data Link FailuresSeptember 2020
+--------------------------------------------------------+
| +------------+ +------------+ +------------+ |
| | Per- | | Configured | | Per- | |
| | Client | | indirect | | Client | |
| | NHIB | | peers | | RIB | |
| +-----^------+ +------------+ +-----+------+ |
| | \ | |
| +-----+------+ `-->-----v------+ |
| |ReachTell-In| |ReachAsk-Out| |
| +------^-----+ Route Server +-----+------+ |
+----------|----------------------------------|----------+
| |
| |
| |
| |
+----------|----------------------------------|----------+
| +------+------+ RS Client +-----v-----+ |
| |ReachTell-Out| |ReachAsk-In| |
| +------^------+ +-----+-----+ |
| | +------------+ | |
| | | | | |
| `----------+ LocReach <----------' |
| | | |
| +------------+ |
+--------------------------------------------------------+
Route Server, RS Client, and Reachability Ask and Tell databases with
In/Out Queues
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.
4. Next Hop Validation
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.
Bush, et al. Expires March 25, 2021 [Page 5]
Internet-Draft Making RSes aware of IXP Data Link FailuresSeptember 2020
4.1. ReachAsk
The route server maintains a ReachAsk database for each client that
supports this proposal, that is, for each client that has advertised
support (Section 5) for the NH-Reach SAFI. This database is the
union of:
o The set of next hops found in the associated per-client Loc-RIB
(see section 2.3.2.1 of [RFC7947]).
o The set of addresses of this client's indirect peers (Section 2).
o The RS MAY also add other entries, for example under configuration
control.
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 [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.)
The contents of the ReachAsk database are communicated to the client
using the NLRI format and procedures described in Section 5.