< draft-ietf-bfd-unsolicited-07.txt   draft-ietf-bfd-unsolicited-08.txt >
Network Working Group E. Chen Network Working Group E. Chen
Internet-Draft Palo Alto Networks Internet-Draft Palo Alto Networks
Intended status: Standards Track N. Shen Intended status: Standards Track N. Shen
Expires: 27 April 2022 Zededa Expires: 30 May 2022 Zededa
R. Raszuk R. Raszuk
NTT Network Innovations NTT Network Innovations
R. Rahman R. Rahman
24 October 2021 26 November 2021
Unsolicited BFD for Sessionless Applications Unsolicited BFD for Sessionless Applications
draft-ietf-bfd-unsolicited-07 draft-ietf-bfd-unsolicited-08
Abstract Abstract
For operational simplification of "sessionless" applications using For operational simplification of "sessionless" applications using
BFD, in this document we present procedures for "unsolicited BFD" BFD, in this document we present procedures for "unsolicited BFD"
that allow a BFD session to be initiated by only one side, and be that allow a BFD session to be initiated by only one side, and be
established without explicit per-session configuration or established without explicit per-session configuration or
registration by the other side (subject to certain per-interface or registration by the other side (subject to certain per-interface or
per-router policies). per-router policies).
We also introduce a new YANG module to configure and manage
"unsolicited BFD". The YANG module in this document conforms to the
Network Management Datastore Architecture (NMDA) [RFC8342].
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
Status of This Memo Status of This Memo
skipping to change at page 1, line 46 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 30 May 2022.
This Internet-Draft will expire on 27 April 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Revised BSD License text as
as described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Procedures for Unsolicited BFD . . . . . . . . . . . . . . . 3 2. Procedures for Unsolicited BFD . . . . . . . . . . . . . . . 3
3. State Variables . . . . . . . . . . . . . . . . . . . . . . . 4 3. State Variables . . . . . . . . . . . . . . . . . . . . . . . 4
4. YANG Data Model . . . . . . . . . . . . . . . . . . . . . . . 5 4. YANG Data Model . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Unsolicited BFD Hierarchy . . . . . . . . . . . . . . . . 5 4.1. Unsolicited BFD Hierarchy . . . . . . . . . . . . . . . . 5
4.2. Unsolicited BFD Module . . . . . . . . . . . . . . . . . 5 4.2. Unsolicited BFD Module . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7.1. BFD Protocol Security Considerations . . . . . . . . . . 9 7.1. BFD Protocol Security Considerations . . . . . . . . . . 10
7.2. YANG Module Security Considerations . . . . . . . . . . . 10 7.2. YANG Module Security Considerations . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . 11 8.1. Normative References . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . 12 8.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
The current implementation and deployment practice for BFD ([RFC5880] The current implementation and deployment practice for BFD ([RFC5880]
and [RFC5881]) usually requires BFD sessions be explicitly configured and [RFC5881]) usually requires BFD sessions be explicitly configured
or registered on both sides. This requirement is not an issue when or registered on both sides. This requirement is not an issue when
an application like BGP [RFC4271] has the concept of a "session" that an application like BGP [RFC4271] has the concept of a "session" that
involves both sides for its establishment. However, this requirement involves both sides for its establishment. However, this requirement
can be operationally challenging when the prerequisite "session" does can be operationally challenging when the prerequisite "session" does
not naturally exist between two endpoints in an application. not naturally exist between two endpoints in an application.
skipping to change at page 5, line 7 skipping to change at page 5, line 7
bfd.UnsolicitedRole bfd.UnsolicitedRole
The operational mode of BFD interface when configured for unsolicited The operational mode of BFD interface when configured for unsolicited
behaviour. Options can be either PASSIVE, ACTIVE or NULL (NULL - not behaviour. Options can be either PASSIVE, ACTIVE or NULL (NULL - not
initialized) for unsolicited BFD sessions. Default (not configured initialized) for unsolicited BFD sessions. Default (not configured
for unsolicited behaviour) MUST be set to NULL if present on the for unsolicited behaviour) MUST be set to NULL if present on the
interface. interface.
4. YANG Data Model 4. YANG Data Model
This section extends the YANG data model for BFD [I-D.ietf-bfd-yang] This section extends the YANG data model for BFD [RFC9127] to cover
to cover the unsolicited BFD. unsolicited BFD. We import [RFC8349] since the "bfd" container in
[RFC9127] is under "control-plane-protocol".
4.1. Unsolicited BFD Hierarchy 4.1. Unsolicited BFD Hierarchy
Configuration for unsolicited BFD parameters for IP single-hop
sessions can be done at 2 levels:
* Globally, i.e. for all interfaces. This requires support for the
"unsolicited-params-global" feature.
* For specific interfaces. This requires support for the
"unsolicited-params-per-interface" feature.
For operational data, a new "unsolicited" container has been added
for BFD IP single-hop sessions.
The tree diagram below uses the graphical representation of data
models, as defined in [RFC8340].
module: ietf-bfd-unsolicited module: ietf-bfd-unsolicited
augment /rt:routing/rt:control-plane-protocols augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh: /rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh:
+--rw unsolicited {bfd-unsol:unsolicited-params-global}? +--rw unsolicited {bfd-unsol:unsolicited-params-global}?
+--rw enable? boolean +--rw enabled? boolean
+--rw local-multiplier? multiplier +--rw local-multiplier? multiplier
+--rw (interval-config-type)? +--rw (interval-config-type)?
+--:(tx-rx-intervals) +--:(tx-rx-intervals)
| +--rw desired-min-tx-interval? uint32 | +--rw desired-min-tx-interval? uint32
| +--rw required-min-rx-interval? uint32 | +--rw required-min-rx-interval? uint32
+--:(single-interval) {single-minimum-interval}? +--:(single-interval) {single-minimum-interval}?
+--rw min-interval? uint32 +--rw min-interval? uint32
augment /rt:routing/rt:control-plane-protocols augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh /rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh
/bfd-ip-sh:interfaces: /bfd-ip-sh:interfaces:
+--rw unsolicited {bfd-unsol:unsolicited-params-per-interface}? +--rw unsolicited {bfd-unsol:unsolicited-params-per-interface}?
+--rw enable? boolean +--rw enabled boolean
+--rw local-multiplier? multiplier +--rw local-multiplier? multiplier
+--rw (interval-config-type)? +--rw (interval-config-type)?
+--:(tx-rx-intervals) +--:(tx-rx-intervals)
| +--rw desired-min-tx-interval? uint32 | +--rw desired-min-tx-interval? uint32
| +--rw required-min-rx-interval? uint32 | +--rw required-min-rx-interval? uint32
+--:(single-interval) {single-minimum-interval}? +--:(single-interval) {single-minimum-interval}?
+--rw min-interval? uint32 +--rw min-interval? uint32
augment /rt:routing/rt:control-plane-protocols augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh /rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh
/bfd-ip-sh:sessions/bfd-ip-sh:session: /bfd-ip-sh:sessions/bfd-ip-sh:session:
+--ro unsolicited +--ro unsolicited
+--ro role? bfd-unsol:unsolicited-role +--ro role? bfd-unsol:unsolicited-role
4.2. Unsolicited BFD Module 4.2. Unsolicited BFD Module
<CODE BEGINS> file "ietf-bfd-unsolicited@2021-10-24.yang" <CODE BEGINS> file "ietf-bfd-unsolicited@2021-11-23.yang"
module ietf-bfd-unsolicited { module ietf-bfd-unsolicited {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-bfd-unsolicited"; namespace "urn:ietf:params:xml:ns:yang:ietf-bfd-unsolicited";
prefix "bfd-unsol"; prefix "bfd-unsol";
// RFC Ed.: replace occurences of YYYY with actual RFC numbers // RFC Ed.: replace occurences of YYYY with actual RFC numbers
// and remove this note // and remove this note
import ietf-bfd-types { import ietf-bfd-types {
prefix "bfd-types"; prefix "bfd-types";
reference "RFC 9127: YANG Data Model for BFD"; reference
"RFC 9127: YANG Data Model for Bidirectional Forwarding Detection
(BFD)";
} }
import ietf-bfd { import ietf-bfd {
prefix "bfd"; prefix "bfd";
reference "RFC 9127: YANG Data Model for BFD"; reference
"RFC 9127: YANG Data Model for Bidirectional Forwarding Detection
(BFD)";
} }
import ietf-bfd-ip-sh { import ietf-bfd-ip-sh {
prefix "bfd-ip-sh"; prefix "bfd-ip-sh";
reference "RFC 9127: YANG Data Model for BFD"; reference
"RFC 9127: YANG Data Model for Bidirectional Forwarding Detection
(BFD)";
} }
import ietf-routing { import ietf-routing {
prefix "rt"; prefix "rt";
reference reference
"RFC 8349: A YANG Data Model for Routing Management "RFC 8349: A YANG Data Model for Routing Management
(NMDA version)"; (NMDA version)";
} }
organization "IETF BFD Working Group"; organization "IETF BFD Working Group";
contact contact
"WG Web: <https://tools.ietf.org/wg/bfd> "WG Web: <https://datatracker.ietf.org/wg/bfd/>
WG List: <rtg-bfd@ietf.org> WG List: <rtg-bfd@ietf.org>
Editors: Enke Chen (enchen@paloaltonetworks.com), Editors: Enke Chen (enchen@paloaltonetworks.com),
Naiming Shen (naiming@zededa.com), Naiming Shen (naiming@zededa.com),
Robert Raszuk (robert@raszuk.net), Robert Raszuk (robert@raszuk.net),
Reshad Rahman (reshad@yahoo.com)"; Reshad Rahman (reshad@yahoo.com)";
description description
"This module contains the YANG definition for BFD unsolicited "This module contains the YANG definition for BFD unsolicited
as per RFC YYYY. as per RFC YYYY.
skipping to change at page 7, line 13 skipping to change at page 8, line 12
to the license terms contained in, the Simplified BSD License to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC YYYY; see This version of this YANG module is part of RFC YYYY; see
the RFC itself for full legal notices."; the RFC itself for full legal notices.";
reference "RFC YYYY"; reference "RFC YYYY";
revision 2021-10-24 { revision 2021-11-23 {
description "Initial revision."; description
reference "RFC YYYY: Unsolicited BFD for Sessionless Applications."; "Initial revision.";
reference
"RFC YYYY: Unsolicited BFD for Sessionless Applications.";
} }
/* /*
* Feature definitions * Feature definitions
*/ */
feature unsolicited-params-global { feature unsolicited-params-global {
description description
"This feature indicates that the server supports global "This feature indicates that the server supports global
parameters for unsolicited sessions."; parameters for unsolicited sessions.";
} reference
"RFC YYYY: Unsolicited BFD for Sessionless Applications.";
}
feature unsolicited-params-per-interface { feature unsolicited-params-per-interface {
description description
"This feature indicates that the server supports per-interface "This feature indicates that the server supports per-interface
parameters for unsolicited sessions."; parameters for unsolicited sessions.";
reference
"RFC YYYY: Unsolicited BFD for Sessionless Applications.";
} }
/* /*
* Type Definitions * Type Definitions
*/ */
typedef unsolicited-role { typedef unsolicited-role {
type enumeration { type enumeration {
enum unsolicited-active { enum unsolicited-active {
description "Active role"; description "Active role";
} }
skipping to change at page 7, line 47 skipping to change at page 9, line 4
type enumeration { type enumeration {
enum unsolicited-active { enum unsolicited-active {
description "Active role"; description "Active role";
} }
enum unsolicited-passive { enum unsolicited-passive {
description "Passive role"; description "Passive role";
} }
} }
description "Unsolicited role"; description "Unsolicited role";
} }
/* /*
* Augments * Augments
*/ */
augment "/rt:routing/rt:control-plane-protocols/" augment "/rt:routing/rt:control-plane-protocols/"
+ "rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh" { + "rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh" {
if-feature bfd-unsol:unsolicited-params-global;
description description
"Augmentation for BFD unsolicited parameters"; "Augmentation for BFD unsolicited parameters";
container unsolicited { container unsolicited {
if-feature bfd-unsol:unsolicited-params-global;
description description
"BFD unsolicited top level container"; "BFD unsolicited top level container";
leaf enable { leaf enabled {
type boolean; type boolean;
default false; default false;
description description
"Enable BFD unsolicited globally for IP single-hop."; "BFD unsolicited enabled globally for IP single-hop.";
} }
uses bfd-types:base-cfg-parms; uses bfd-types:base-cfg-parms;
} }
} }
augment "/rt:routing/rt:control-plane-protocols/" augment "/rt:routing/rt:control-plane-protocols/"
+ "rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh/" + "rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh/"
+ "bfd-ip-sh:interfaces" { + "bfd-ip-sh:interfaces" {
if-feature bfd-unsol:unsolicited-params-per-interface;
description description
"Augmentation for BFD unsolicited on IP single-hop interface"; "Augmentation for BFD unsolicited on IP single-hop interface";
container unsolicited { container unsolicited {
if-feature bfd-unsol:unsolicited-params-per-interface;
description description
"BFD IP single-hop interface unsolicited top level "BFD IP single-hop interface unsolicited top level
container"; container";
leaf enable { leaf enabled {
type boolean; type boolean;
default false; default false;
description "Enable BFD unsolicited on this interface."; description
"BFD unsolicited enabled on this interface.";
} }
uses bfd-types:base-cfg-parms; uses bfd-types:base-cfg-parms;
} }
} }
augment "/rt:routing/rt:control-plane-protocols/" augment "/rt:routing/rt:control-plane-protocols/"
+ "rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh/" + "rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh/"
+ "bfd-ip-sh:sessions/bfd-ip-sh:session" { + "bfd-ip-sh:sessions/bfd-ip-sh:session" {
description description
"Augmentation for BFD unsolicited on IP single-hop session"; "Augmentation for BFD unsolicited on IP single-hop session";
skipping to change at page 9, line 29 skipping to change at page 10, line 33
XML: N/A; the requested URI is an XML namespace. XML: N/A; the requested URI is an XML namespace.
This document registers the following YANG module in the "YANG Module This document registers the following YANG module in the "YANG Module
Names" registry [RFC6020]: Names" registry [RFC6020]:
Name: ietf-bfd-unsolicited Name: ietf-bfd-unsolicited
Namespace: urn:ietf:params:xml:ns:yang:ietf-bfd-unsolicited Namespace: urn:ietf:params:xml:ns:yang:ietf-bfd-unsolicited
Prefix: ietf-bfd-unsolicited Prefix: bfd-unsol
Reference: RFC YYYY Reference: RFC YYYY
6. Acknowledgments 6. Acknowledgments
Authors would like to thank Acee Lindem, Greg Mirsky, Jeffrey Haas Authors would like to thank Acee Lindem, Greg Mirsky, Jeffrey Haas,
and Raj Chetan for their review and valuable input. Raj Chetan and Tom Petch for their review and valuable input.
7. Security Considerations 7. Security Considerations
7.1. BFD Protocol Security Considerations 7.1. BFD Protocol Security Considerations
The same security considerations and protection measures as those The same security considerations and protection measures as those
described in [RFC5880] and [RFC5881] normatively apply to this described in [RFC5880] and [RFC5881] normatively apply to this
document. With "unsolicited BFD" there is potential risk for document. With "unsolicited BFD" there is potential risk for
excessive resource usage by BFD from "unexpected" remote systems. To excessive resource usage by BFD from "unexpected" remote systems. To
mitigate such risks, the following measures are mandatory: mitigate such risks, the following measures are mandatory:
* Limit the feature to specific interfaces, and to a single-hop BFD * Limit the feature to specific interfaces, and to a single-hop BFD
with "TTL=255" [RFC5082]. For numbered interfaces source address with "TTL=255" [RFC5082]. For numbered interfaces, the source
of an incoming BFD packet should belongs to the subnet of the address of an incoming BFD packet should belong to the subnet of
interface from which the BFD packet is received. For unnumbered the interface on which the BFD packet is received. For unnumbered
interfaces the above check should be aligned with routing protocol interfaces the above check should be aligned with routing protocol
addresses running on such pair of interfaces. addresses running on such pair of interfaces.
* Apply "access control" to allow BFD packets only from certain * Apply "policy" to allow BFD packets only from certain subnets or
subnets or hosts. hosts.
* Deploy the feature only in certain "trustworthy" environment, * Deploy the feature only in certain "trustworthy" environment,
e.g., at an IXP, or between a provider and its customers. e.g., at an IXP, or between a provider and its customers.
* Adjust BFD parameters as needed for the particular deployment and * Adjust BFD parameters as needed for the particular deployment and
scale. scale.
* Use BFD authentication. * Use BFD authentication.
7.2. YANG Module Security Considerations 7.2. YANG Module Security Considerations
The YANG module specified in this document defines a schema for data The YANG module specified in this document defines a schema for data
that is designed to be accessed via network management protocols such that is designed to be accessed via network management protocols such
as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer
is the secure transport layer, and the mandatory-to-implement secure is the secure transport layer, and the mandatory-to-implement secure
transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer
is HTTPS, and the mandatory-to-implement secure transport is TLS is HTTPS, and the mandatory-to-implement secure transport is TLS
[RFC5246]. [RFC8446].
The NETCONF access control model [RFC6536] provides the means to The NETCONF access control model [RFC8341] provides the means to
restrict access for particular NETCONF or RESTCONF users to a restrict access for particular NETCONF or RESTCONF users to a
preconfigured subset of all available NETCONF or RESTCONF protocol preconfigured subset of all available NETCONF or RESTCONF protocol
operations and content. operations and content.
There are a number of data nodes defined in this YANG module that are There are a number of data nodes defined in this YANG module that are
writable/creatable/deletable (i.e., config true, which is the writable/creatable/deletable (i.e., config true, which is the
default). These data nodes may be considered sensitive or vulnerable default). These data nodes may be considered sensitive or vulnerable
in some network environments. Write operations (e.g., edit-config) in some network environments. Write operations (e.g., edit-config)
to these data nodes without proper protection can have a negative to these data nodes without proper protection can have a negative
effect on network operations. These are the subtrees and data nodes effect on network operations. These are the subtrees and data nodes
and their sensitivity/vulnerability: and their sensitivity/vulnerability:
/routing/control-plane-protocols/control-plane-protocol/bfd/ip-sh /routing/control-plane-protocols/control-plane-protocol/bfd/ip-sh
/unsolicited: /unsolicited:
* data node "enable" enables creation of unsolicited BFD IP single- * data node "enabled" enables creation of unsolicited BFD IP single-
hop sessions globally, i.e. on all interfaces. See Section 7.1. hop sessions globally, i.e. on all interfaces. See Section 7.1.
* data nodes local-multiplier, desired-min-tx-interval, required- * data nodes local-multiplier, desired-min-tx-interval, required-
min-rx-interval and min-interval all impact the parameters of the min-rx-interval and min-interval all impact the parameters of the
unsolicited BFD IP single-hop sessions. unsolicited BFD IP single-hop sessions.
/routing/control-plane-protocols/control-plane-protocol/bfd/ip-sh /routing/control-plane-protocols/control-plane-protocol/bfd/ip-sh
/interfaces/interface/unsolicited: /interfaces/interface/unsolicited:
* data node "enable" enables creation of unsolicited BFD IP single- * data node "enabled" enables creation of unsolicited BFD IP single-
hop sessions on a specific interface. See Section 7.1. hop sessions on a specific interface. See Section 7.1.
* data nodes local-multiplier, desired-min-tx-interval, required- * data nodes local-multiplier, desired-min-tx-interval, required-
min-rx-interval and min-interval all impact the parameters of the min-rx-interval and min-interval all impact the parameters of the
unsolicited BFD IP single-hop sessions on the interface. unsolicited BFD IP single-hop sessions on the interface.
Some of the readable data nodes in this YANG module may be considered Some of the readable data nodes in this YANG module may be considered
sensitive or vulnerable in some network environments. It is thus sensitive or vulnerable in some network environments. It is thus
important to control read access (e.g., via get, get-config, or important to control read access (e.g., via get, get-config, or
notification) to these data nodes. These are the subtrees and data notification) to these data nodes. These are the subtrees and data
nodes and their sensitivity/vulnerability: nodes and their sensitivity/vulnerability:
/routing/control-plane-protocols/control-plane-protocol/bfd/ip-sh /routing/control-plane-protocols/control-plane-protocol/bfd/ip-sh
/sessions/session/unsolicited: access to this information discloses /sessions/session/unsolicited: access to this information discloses
the role of the local system in the creation of the unsolicited BFD the role of the local system in the creation of the unsolicited BFD
session. session.
8. References 8. References
8.1. Normative References 8.1. Normative References
[I-D.ietf-bfd-yang]
Rahman, R., Zheng, L., Jethanandani, M., Pallagatti, S.,
and G. Mirsky, "YANG Data Model for Bidirectional
Forwarding Detection (BFD)", Work in Progress, Internet-
Draft, draft-ietf-bfd-yang-17, 2 August 2018,
<https://www.ietf.org/archive/id/draft-ietf-bfd-yang-
17.txt>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004, DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>. <https://www.rfc-editor.org/info/rfc3688>.
[RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C.
Pignataro, "The Generalized TTL Security Mechanism Pignataro, "The Generalized TTL Security Mechanism
(GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007, (GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007,
<https://www.rfc-editor.org/info/rfc5082>. <https://www.rfc-editor.org/info/rfc5082>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/info/rfc5246>.
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
<https://www.rfc-editor.org/info/rfc5880>. <https://www.rfc-editor.org/info/rfc5880>.
[RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881,
DOI 10.17487/RFC5881, June 2010, DOI 10.17487/RFC5881, June 2010,
<https://www.rfc-editor.org/info/rfc5881>. <https://www.rfc-editor.org/info/rfc5881>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
skipping to change at page 12, line 28 skipping to change at page 13, line 14
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>. <https://www.rfc-editor.org/info/rfc6241>.
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
<https://www.rfc-editor.org/info/rfc6242>. <https://www.rfc-editor.org/info/rfc6242>.
[RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration
Protocol (NETCONF) Access Control Model", RFC 6536,
DOI 10.17487/RFC6536, March 2012,
<https://www.rfc-editor.org/info/rfc6536>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>. <https://www.rfc-editor.org/info/rfc8040>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
<https://www.rfc-editor.org/info/rfc8340>.
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
Access Control Model", STD 91, RFC 8341,
DOI 10.17487/RFC8341, March 2018,
<https://www.rfc-editor.org/info/rfc8341>.
[RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for
Routing Management (NMDA Version)", RFC 8349,
DOI 10.17487/RFC8349, March 2018,
<https://www.rfc-editor.org/info/rfc8349>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[RFC9127] Rahman, R., Ed., Zheng, L., Ed., Jethanandani, M., Ed.,
Pallagatti, S., and G. Mirsky, "YANG Data Model for
Bidirectional Forwarding Detection (BFD)", RFC 9127,
DOI 10.17487/RFC9127, October 2021,
<https://www.rfc-editor.org/info/rfc9127>.
8.2. Informative References 8.2. Informative References
[I-D.ietf-idr-rs-bfd] [I-D.ietf-idr-rs-bfd]
Bush, R., Haas, J., Scudder, J. G., Nipper, A., and C. Bush, R., Haas, J., Scudder, J. G., Nipper, A., and C.
Dietzel, "Making Route Servers Aware of Data Link Failures Dietzel, "Making Route Servers Aware of Data Link Failures
at IXPs", Work in Progress, Internet-Draft, draft-ietf- at IXPs", Work in Progress, Internet-Draft, draft-ietf-
idr-rs-bfd-09, 21 September 2020, idr-rs-bfd-09, 21 September 2020,
<https://www.ietf.org/archive/id/draft-ietf-idr-rs-bfd- <https://www.ietf.org/archive/id/draft-ietf-idr-rs-bfd-
09.txt>. 09.txt>.
skipping to change at page 13, line 25 skipping to change at page 14, line 33
[RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder, [RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder,
"Advertisement of Multiple Paths in BGP", RFC 7911, "Advertisement of Multiple Paths in BGP", RFC 7911,
DOI 10.17487/RFC7911, July 2016, DOI 10.17487/RFC7911, July 2016,
<https://www.rfc-editor.org/info/rfc7911>. <https://www.rfc-editor.org/info/rfc7911>.
[RFC7947] Jasinska, E., Hilliard, N., Raszuk, R., and N. Bakker, [RFC7947] Jasinska, E., Hilliard, N., Raszuk, R., and N. Bakker,
"Internet Exchange BGP Route Server", RFC 7947, "Internet Exchange BGP Route Server", RFC 7947,
DOI 10.17487/RFC7947, September 2016, DOI 10.17487/RFC7947, September 2016,
<https://www.rfc-editor.org/info/rfc7947>. <https://www.rfc-editor.org/info/rfc7947>.
[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
and R. Wilton, "Network Management Datastore Architecture
(NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,
<https://www.rfc-editor.org/info/rfc8342>.
Authors' Addresses Authors' Addresses
Enke Chen Enke Chen
Palo Alto Networks Palo Alto Networks
Email: enchen@paloaltonetworks.com Email: enchen@paloaltonetworks.com
Naiming Shen Naiming Shen
Zededa Zededa
skipping to change at page 13, line 36 skipping to change at page 15, line 4
Enke Chen Enke Chen
Palo Alto Networks Palo Alto Networks
Email: enchen@paloaltonetworks.com Email: enchen@paloaltonetworks.com
Naiming Shen Naiming Shen
Zededa Zededa
Email: naiming@zededa.com Email: naiming@zededa.com
Robert Raszuk Robert Raszuk
NTT Network Innovations NTT Network Innovations
940 Stewart Dr 940 Stewart Dr
Sunnyvale, CA 94085 Sunnyvale, CA 94085
United States of America United States of America
Email: robert@raszuk.net Email: robert@raszuk.net
Reshad Rahman Reshad Rahman
Canada
Email: reshad@yahoo.com Email: reshad@yahoo.com
 End of changes. 44 change blocks. 
73 lines changed or deleted 115 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/