Unsolicited Bidirectional Forwarding Detection (BFD) for Sessionless ApplicationsPalo Alto Networks3000 Tannery WaySanta ClaraCA95054United States of Americaenchen@paloaltonetworks.comZededa160 W Santa Clara StreetSan JoseCA95113United States of Americanaiming@zededa.comArrcus2077 Gateway PlaceSan JoseCA95110United States of Americarobert@raszuk.netEquinixCanadareshad@yahoo.com
rtg
bfd
For operational simplification of "sessionless" applications
using Bidirectional Forwarding Detection (BFD), in this document, we present procedures
for "unsolicited BFD" that allow a BFD session to be initiated
by only one side and established without explicit per-session
configuration or registration by the other side (subject to certain
per-interface or global policies).
We also introduce a new YANG module
to configure and manage "unsolicited BFD". The YANG module in this document
is based on YANG 1.1, as defined in RFC 7950, and conforms to the Network Management
Datastore Architecture (NMDA), as described in RFC 8342. This document augments RFC 9314.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by
the Internet Engineering Steering Group (IESG). Further
information on Internet Standards is available in Section 2 of
RFC 7841.
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
.
Copyright Notice
Copyright (c) 2023 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
() 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 Revised BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Revised BSD License.
Table of Contents
. Introduction
. Requirements Language
. Procedures for Unsolicited BFD
. State Variables
. YANG Data Model
. Unsolicited BFD Hierarchy
. Unsolicited BFD Module
. Data Model Example
. IANA Considerations
. Security Considerations
. BFD Protocol Security Considerations
. BFD Protocol Authentication Considerations
. YANG Module Security Considerations
. References
. Normative References
. Informative References
Acknowledgments
Authors' Addresses
Introduction
The current implementation and deployment practice for BFD
( and )
usually requires that BFD sessions be explicitly
configured or registered on both sides. This requirement is
not an issue when an application like BGP
has the concept of a "session" that involves both sides for its
establishment.
However, this requirement can be operationally challenging
when the prerequisite "session" does not
naturally exist between two endpoints in an application.
Simultaneous configuration and coordination
may be required on both sides for BFD to take effect. For example:
When BFD is used to keep track of the "liveness" of the next hop
of static routes. Although only one side may need the BFD
functionality, currently, both sides need to be involved in
specific configuration and coordination, and in some cases,
static routes are created unnecessarily just for BFD.
When BFD is used to keep track of the "liveness" of the
third-party next hop of BGP routes received from the Route Server
at an Internet Exchange Point (IXP). As the
third-party next hop is different from the peering address of
the Route Server, for BFD to work, currently, two routers peering
with the Route Server need to have routes and next hops from each
other (although indirectly via the Route Server).
Clearly, it is beneficial and desirable to reduce or eliminate
unnecessary configurations and coordination in these
"sessionless" applications using BFD.
In this document, we present procedures
for "unsolicited BFD" that allow a BFD session to be initiated
by only one side and established without explicit per-session
configuration or registration by the other side (subject to certain
per-interface or global policies).
Unsolicited BFD impacts only the initiation of BFD sessions. There is no change to all the other procedures specified in
, such as, but not limited to, the Echo function and Demand mode.
With "unsolicited BFD", there is potential risk for
excessive resource usage by BFD from "unexpected" remote systems.
To mitigate such risks,
several mechanisms are recommended in the Security Considerations
section.
The procedure described in this document could be applied to BFD for multihop paths .
However, because of security risks, this document applies only to BFD for single IP hops .
Compared to the "Seamless BFD" , this proposal involves
only minor procedural enhancements to the widely deployed BFD itself.
Thus, we believe that this proposal is inherently simpler in the
protocol itself and deployment.
As an example, it does not require the exchange of BFD
discriminators over an out-of-band channel before BFD session bring-up.
When BGP ADD-PATH is deployed at an IXP using a Route Server,
multiple BGP paths (when they exist) can be made available to the clients of the
Route Server, as described in .
Unsolicited BFD can be used by BGP route selection's route resolvability condition
() to exclude routes where the NEXT_HOP is not
reachable using the procedures specified in this document.
Requirements Language
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
when, and only when, they appear in all capitals, as shown here.
Procedures for Unsolicited BFD
With "unsolicited BFD", one side takes the "Active role"
and the other side takes the "Passive role", as
described in .
Passive unsolicited BFD support MUST be disabled by default and
MUST require explicit configuration to be enabled.
On the passive side, the following BFD parameters, from , SHOULD be configurable:
bfd.DesiredMinTxInterval
bfd.RequiredMinRxInterval
bfd.DetectMult
The passive side MAY also choose to use the values of the parameters listed above that
the active side uses in its BFD Control packets. However, the bfd.LocalDiscr value MUST be selected by the passive side
to allow multiple unsolicited BFD sessions.
The active side starts sending the BFD Control packets, as specified in
. The passive side does not send BFD Control packets initially;
it sends BFD Control packets only after it has received BFD Control packets from the active side.
When the passive side receives a BFD Control packet from the active side
with 0 as "Your Discriminator" and does not find an existing BFD session,
the passive side SHOULD create a matching BFD session toward the active side,
unless not permitted by local configuration or policy.
When the passive side receives an incoming BFD Control packet on a numbered interface,
the source address of that packet MUST belong to the subnet of the interface on which the BFD
packet is received, else the BFD Control packet MUST NOT be processed.
The passive side MUST then start sending BFD Control packets and perform the necessary
procedure for bringing up, maintaining, and tearing down the BFD session.
If the BFD session fails to get established within a certain amount of time
(which is implementation specific but has to be at least equal to the local failure detection time)
or if an established BFD session goes down, the passive side MUST stop
sending BFD Control packets and SHOULD delete the BFD session created until
BFD Control packets are initiated by the active side again.
When an unsolicited BFD session goes down, an implementation may retain
the session state for a period of time.
Retaining this state can be useful for operational purposes.
State Variables
This document defines a new state variable called Role:
bfd.Role
This is the role of the local system during BFD session initialization, as per .
Possible values are Active or Passive.
YANG Data Model
This section extends the YANG data model for BFD
to cover unsolicited BFD.
The new module imports the YANG modules described in
since the "bfd" container in is under
"control-plane-protocol".
The YANG module in this document conforms to the Network Management
Datastore Architecture (NMDA) .
Unsolicited BFD HierarchyConfiguration for unsolicited BFD parameters for IP single-hop sessions can be done at 2 levels:
globally, i.e., for all interfaces
for specific interfaces (this requires support for the "unsolicited-params-per-interface" feature)
If configuration exists at both levels, per-interface configuration takes precedence over global configuration.
For operational data, a new "role" leaf node has been added for BFD IP single-hop sessions.The tree diagram below uses the graphical representation of data models, as defined in .
module: ietf-bfd-unsolicited
augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh:
+--rw unsolicited?
+--rw local-multiplier? multiplier
+--rw (interval-config-type)?
+--:(tx-rx-intervals)
| +--rw desired-min-tx-interval? uint32
| +--rw required-min-rx-interval? uint32
+--:(single-interval) {single-minimum-interval}?
+--rw min-interval? uint32
augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh
/bfd-ip-sh:interfaces:
+--rw unsolicited
+--rw enabled? boolean
+--rw local-multiplier?
bfd-types:multiplier
{bfd-unsol:unsolicited-params-per-interface}?
+--rw (interval-config-type)?
{bfd-unsol:unsolicited-params-per-interface}?
+--:(tx-rx-intervals)
| +--rw desired-min-tx-interval? uint32
| +--rw required-min-rx-interval? uint32
+--:(single-interval) {bfd-types:single-minimum-interval}?
+--rw min-interval? uint32
augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh
/bfd-ip-sh:sessions/bfd-ip-sh:session:
+--ro role? bfd-unsol:role
Unsolicited BFD Module
module ietf-bfd-unsolicited {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-bfd-unsolicited";
prefix bfd-unsol;
import ietf-bfd-types {
prefix bfd-types;
reference
"RFC 9314: YANG Data Model for Bidirectional Forwarding
Detection (BFD)";
}
import ietf-bfd {
prefix bfd;
reference
"RFC 9314: YANG Data Model for Bidirectional Forwarding
Detection (BFD)";
}
import ietf-bfd-ip-sh {
prefix bfd-ip-sh;
reference
"RFC 9314: YANG Data Model for Bidirectional Forwarding
Detection (BFD)";
}
import ietf-routing {
prefix rt;
reference
"RFC 8349: A YANG Data Model for Routing Management
(NMDA Version)";
}
organization
"IETF BFD Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/bfd/>
WG List: <rtg-bfd@ietf.org>
Editors: Enke Chen (enchen@paloaltonetworks.com),
Naiming Shen (naiming@zededa.com),
Robert Raszuk (robert@raszuk.net),
Reshad Rahman (reshad@yahoo.com)";
description
"This module contains the YANG definition for unsolicited BFD,
as per RFC 9468.
Copyright (c) 2023 IETF Trust and the persons
identified as authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject
to the license terms contained in, the Revised BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC 9468; see
the RFC itself for full legal notices.";
reference
"RFC 9468: Unsolicited Bidirectional Forwarding Detection
(BFD) for Sessionless Applications";
revision 2023-08-31 {
description
"Initial revision.";
reference
"RFC 9468: Unsolicited Bidirectional Forwarding Detection (BFD)
for Sessionless Applications";
}
/*
* Feature definitions
*/
feature unsolicited-params-per-interface {
description
"This feature indicates that the server supports per-interface
parameters for unsolicited sessions.";
reference
"RFC 9468: Unsolicited Bidirectional Forwarding Detection (BFD)
for Sessionless Applications";
}
/*
* Type Definitions
*/
identity role {
description
"Base identity from which all roles are derived.
Role of local system during BFD session initialization.";
}
identity active {
base bfd-unsol:role;
description
"Active role.";
reference
"RFC 5880: Bidirectional Forwarding Detection (BFD),
Section 6.1";
}
identity passive {
base bfd-unsol:role;
description
"Passive role.";
reference
"RFC 5880: Bidirectional Forwarding Detection (BFD),
Section 6.1";
}
/*
* Augments
*/
augment "/rt:routing/rt:control-plane-protocols/"
+ "rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh" {
description
"Augmentation for unsolicited BFD parameters.";
container unsolicited {
description
"BFD IP single-hop unsolicited top-level container.";
uses bfd-types:base-cfg-parms;
}
}
augment "/rt:routing/rt:control-plane-protocols/"
+ "rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh/"
+ "bfd-ip-sh:interfaces" {
description
"Augmentation for unsolicited BFD on IP single-hop
interface.";
container unsolicited {
description
"BFD IP single-hop interface unsolicited top-level
container.";
leaf enabled {
type boolean;
default "false";
description
"Unsolicited BFD is enabled on this interface.";
}
/*
* The following is the same as bfd-types:base-cfg-parms, but
* without default values (for inheritance)
*/
leaf local-multiplier {
if-feature "bfd-unsol:unsolicited-params-per-interface";
type bfd-types:multiplier;
description
"Multiplier transmitted by the local system. Defaults to
../../unsolicited/local-multiplier.
A multiplier configured under an interface takes
precedence over the multiplier configured at the global
level.";
}
choice interval-config-type {
if-feature "bfd-unsol:unsolicited-params-per-interface";
description
"Two interval values or one value used for both transmit
and receive. Defaults to
../../unsolicited/interval-config-type. An interval
configured under an interface takes precedence over any
interval configured at the global level.";
case tx-rx-intervals {
leaf desired-min-tx-interval {
type uint32;
units "microseconds";
description
"Desired minimum transmit interval of control
packets.";
}
leaf required-min-rx-interval {
type uint32;
units "microseconds";
description
"Required minimum receive interval of control
packets.";
}
}
case single-interval {
if-feature "bfd-types:single-minimum-interval";
leaf min-interval {
type uint32;
units "microseconds";
description
"Desired minimum transmit interval and required
minimum receive interval of control packets.";
}
}
}
}
}
augment "/rt:routing/rt:control-plane-protocols/"
+ "rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh/"
+ "bfd-ip-sh:sessions/bfd-ip-sh:session" {
description
"Augmentation for unsolicited BFD on IP single-hop session.";
leaf role {
type identityref {
base bfd-unsol:role;
}
config false;
description
"Role.";
}
}
}
Data Model ExampleThis section shows an example on how to configure the passive end of unsolicited BFD:
We have global BFD IP single-hop unsolicited configuration with a local-multiplier of 2 and min-interval at 50 ms.
BFD IP single-hop unsolicited is enabled on interface eth0 with a local-multiplier of 3 and min-interval at 250 ms.
BFD IP single-hop unsolicited is enabled on interface eth1. Since there is no parameter configuration for eth1, it inherits from the global configuration.
<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">
<interface>
<name>eth0</name>
<type
xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type">
ianaift:ethernetCsmacd</type>
</interface>
<interface>
<name>eth1</name>
<type
xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type">
ianaift:ethernetCsmacd</type>
</interface>
</interfaces>
<routing xmlns="urn:ietf:params:xml:ns:yang:ietf-routing">
<control-plane-protocols>
<control-plane-protocol>
<type xmlns:bfd-types=
"urn:ietf:params:xml:ns:yang:ietf-bfd-types">
bfd-types:bfdv1</type>
<name>name:BFD</name>
<bfd xmlns="urn:ietf:params:xml:ns:yang:ietf-bfd">
<ip-sh xmlns="urn:ietf:params:xml:ns:yang:ietf-bfd-ip-sh">
<unsolicited>
<local-multiplier>2</local-multiplier>
<min-interval>50000</min-interval>
</unsolicited>
<interfaces>
<interface>eth0</interface>
<unsolicited>
<enabled>true</enabled>
<local-multiplier>3</local-multiplier>
<min-interval>250000</min-interval>
</unsolicited>
</interfaces>
<interfaces>
<interface>eth1</interface>
<unsolicited>
<enabled>true</enabled>
</unsolicited>
</interfaces>
</ip-sh>
</bfd>
</control-plane-protocol>
</control-plane-protocols>
</routing>
</config>
IANA Considerations
IANA has registered the following namespace URI in the "ns" subregistry within the "IETF XML Registry" :
URI:
urn:ietf:params:xml:ns:yang:ietf-bfd-unsolicited
Registrant Contact:
The IESG.
XML:
N/A; the requested URI is an XML namespace.
IANA has registered the following YANG module in the "YANG Module Names" registry :
Name:
ietf-bfd-unsolicited
Maintained by IANA:
N
Namespace:
urn:ietf:params:xml:ns:yang:ietf-bfd-unsolicited
Prefix:
bfd-unsol
Reference:
RFC 9468
Security ConsiderationsBFD Protocol Security Considerations
The same security considerations and protection measures as those described
in and apply
to this document.
In addition, with "unsolicited BFD", there is potential risk for excessive resource usage
by BFD from "unexpected" remote systems. To mitigate such risks, implementations of unsolicited BFD MUST:
Limit the feature to specific interfaces and to single-hop BFD sessions using the procedures from
. See for the details of these procedures.
Apply policy to process BFD packets only from certain subnets or hosts.
Deploy the feature only in an environment that does not
offer anonymous participation. Examples include an IXP,
where the IXP operator will have a business relationship with
all IXP participants, or between a provider and its customers.
BFD Protocol Authentication Considerations
Implementations of unsolicited BFD are RECOMMENDED to
use BFD authentication; see .
If BFD authentication is used, the strongest BFD authentication mechanism that is supported MUST be used.
In some environments, such as IXPs, BFD authentication cannot be used because of the lack of coordination for the operation of the two endpoints of the BFD session.
In other environments, such as when BFD is used to track the next hop of static routes, it is possible to use BFD authentication. This comes with the extra cost of configuring matching key chains between the two endpoints.
YANG Module Security ConsiderationsThe YANG module specified in this document defines a schema for data
that is designed to be accessed via network management protocols such as
NETCONF or RESTCONF .
The lowest NETCONF layer is the secure transport layer, and the
mandatory-to-implement secure transport is Secure Shell (SSH) . The lowest RESTCONF layer is HTTPS, and the
mandatory-to-implement secure transport is TLS .The Network Configuration Access Control Mode (NACM) provides
the means to restrict access for particular NETCONF or RESTCONF users to
a preconfigured subset of all available NETCONF or RESTCONF protocol
operations and content.There are a number of data nodes defined in this YANG module that are
writable/creatable/deletable (i.e., config true, which is the default).
These data nodes may be considered sensitive or vulnerable in some
network environments. Write operations (e.g., edit-config) to these data
nodes without proper protection can have a negative effect on network
operations. These are the subtrees and data nodes and their
sensitivity/vulnerability:
Data node "enabled" enables creation of unsolicited BFD IP single-hop sessions globally, i.e., on all interfaces.
See .
Data nodes "local-multiplier", "desired-min-tx-interval",
"required-min-rx-interval", and "min-interval" all impact the parameters of the unsolicited
BFD IP single-hop sessions. Write operations to these nodes change the
rates of BFD packet generation and detection time of the failures of a
BFD session.
Data node "enabled" enables the creation of unsolicited BFD IP single-hop sessions on a specific interface.
See .
Data nodes "local-multiplier", "desired-min-tx-interval",
"required-min-rx-interval", and "min-interval" all impact the parameters of the unsolicited
BFD IP single-hop sessions on the interface.
Some of the readable data nodes in this YANG module may be considered
sensitive or vulnerable in some network environments. It is thus
important to control read access (e.g., via get, get-config, or
notification) to these data nodes. These are the subtrees and data nodes
and their sensitivity/vulnerability:
Access to this information discloses the role of the local system in the creation of the unsolicited BFD session.
ReferencesNormative ReferencesKey words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.The IETF XML RegistryThis document describes an IANA maintained registry for IETF standards which use Extensible Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Description Framework (RDF) Schemas.The Generalized TTL Security Mechanism (GTSM)The use of a packet's Time to Live (TTL) (IPv4) or Hop Limit (IPv6) to verify whether the packet was originated by an adjacent node on a connected link has been used in many recent protocols. This document generalizes this technique. This document obsoletes Experimental RFC 3682. [STANDARDS-TRACK]Bidirectional Forwarding Detection (BFD)This document describes a protocol intended to detect faults in the bidirectional path between two forwarding engines, including interfaces, data link(s), and to the extent possible the forwarding engines themselves, with potentially very low latency. It operates independently of media, data protocols, and routing protocols. [STANDARDS-TRACK]Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)This document describes the use of the Bidirectional Forwarding Detection (BFD) protocol over IPv4 and IPv6 for single IP hops. [STANDARDS-TRACK]YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK]Network Configuration Protocol (NETCONF)The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK]Using the NETCONF Protocol over Secure Shell (SSH)This document describes a method for invoking and running the Network Configuration Protocol (NETCONF) within a Secure Shell (SSH) session as an SSH subsystem. This document obsoletes RFC 4742. [STANDARDS-TRACK]RESTCONF ProtocolThis document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol (NETCONF).Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.YANG Tree DiagramsThis document captures the current syntax used in YANG module tree diagrams. The purpose of this document is to provide a single location for this definition. This syntax may be updated from time to time based on the evolution of the YANG language.Network Configuration Access Control ModelThe standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) or the RESTCONF protocol requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF or RESTCONF protocol access for particular users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. This document defines such an access control model.This document obsoletes RFC 6536.A YANG Data Model for Routing Management (NMDA Version)This document specifies three YANG modules and one submodule. Together, they form the core routing data model that serves as a framework for configuring and managing a routing subsystem. It is expected that these modules will be augmented by additional YANG modules defining data models for control-plane protocols, route filters, and other functions. The core routing data model provides common building blocks for such extensions -- routes, Routing Information Bases (RIBs), and control-plane protocols.The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA). This document obsoletes RFC 8022.The Transport Layer Security (TLS) Protocol Version 1.3This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.YANG Data Model for Bidirectional Forwarding Detection (BFD)This document defines a YANG data model that can be used to configure and manage Bidirectional Forwarding Detection (BFD).The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA) (RFC 8342). This document updates "YANG Data Model for Bidirectional Forwarding Detection (BFD)" (RFC 9127).Informative ReferencesA Border Gateway Protocol 4 (BGP-4)This document discusses the Border Gateway Protocol (BGP), which is an inter-Autonomous System routing protocol.The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems (ASes) that reachability information traverses. This information is sufficient for constructing a graph of AS connectivity for this reachability from which routing loops may be pruned, and, at the AS level, some policy decisions may be enforced.BGP-4 provides a set of mechanisms for supporting Classless Inter-Domain Routing (CIDR). These mechanisms include support for advertising a set of destinations as an IP prefix, and eliminating the concept of network "class" within BGP. BGP-4 also introduces mechanisms that allow aggregation of routes, including aggregation of AS paths.This document obsoletes RFC 1771. [STANDARDS-TRACK]Bidirectional Forwarding Detection (BFD) for Multihop PathsThis document describes the use of the Bidirectional Forwarding Detection (BFD) protocol over multihop paths, including unidirectional links. [STANDARDS-TRACK]Seamless Bidirectional Forwarding Detection (S-BFD)This document defines Seamless Bidirectional Forwarding Detection (S-BFD), a simplified mechanism for using BFD with a large proportion of negotiation aspects eliminated, thus providing benefits such as quick provisioning, as well as improved control and flexibility for network nodes initiating path monitoring.This document updates RFC 5880.Advertisement of Multiple Paths in BGPThis document defines a BGP extension that allows the advertisement of multiple paths for the same address prefix without the new paths implicitly replacing any previous ones. The essence of the extension is that each path is identified by a Path Identifier in addition to the address prefix.Internet Exchange BGP Route ServerThis document outlines a specification for multilateral interconnections at Internet Exchange Points (IXPs). Multilateral interconnection is a method of exchanging routing information among three or more External BGP (EBGP) speakers using a single intermediate broker system, referred to as a route server. Route servers are typically used on shared access media networks, such as IXPs, to facilitate simplified interconnection among multiple Internet routers.Network Management Datastore Architecture (NMDA)Datastores are a fundamental concept binding the data models written in the YANG data modeling language to network management protocols such as the Network Configuration Protocol (NETCONF) and RESTCONF. This document defines an architectural framework for datastores based on the experience gained with the initial simpler model, addressing requirements that were not well supported in the initial model. This document updates RFC 7950.AcknowledgmentsThe authors would like to thank , , , , , , , ,
, , , , , , , , ,
and for their reviews and valuable input.Authors' AddressesPalo Alto Networks3000 Tannery WaySanta ClaraCA95054United States of Americaenchen@paloaltonetworks.comZededa160 W Santa Clara StreetSan JoseCA95113United States of Americanaiming@zededa.comArrcus2077 Gateway PlaceSan JoseCA95110United States of Americarobert@raszuk.netEquinixCanadareshad@yahoo.com