< draft-ietf-bfd-unsolicited-04.txt   draft-ietf-bfd-unsolicited-05.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: April 18, 2022 Zededa Expires: April 22, 2022 Zededa
R. Raszuk R. Raszuk
NTT Network Innovations NTT Network Innovations
R. Rahman R. Rahman
October 15, 2021 October 19, 2021
Unsolicited BFD for Sessionless Applications Unsolicited BFD for Sessionless Applications
draft-ietf-bfd-unsolicited-04 draft-ietf-bfd-unsolicited-05
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).
skipping to change at page 1, line 47 skipping to change at page 1, line 47
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 April 18, 2022. This Internet-Draft will expire on April 22, 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 Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 25 skipping to change at page 2, line 25
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified 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 . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Unsolicited BFD Hierarchy . . . . . . . . . . . . . . . . 5 4.1. Unsolicited BFD Hierarchy . . . . . . . . . . . . . . . . 5
4.2. Unsolicited BFD Module . . . . . . . . . . . . . . . . . 5 4.2. Unsolicited BFD Module . . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7.1. BFD Protocol Security Considerations . . . . . . . . . . 9 7.1. BFD Protocol Security Considerations . . . . . . . . . . 9
7.2. YANG Module Security Considerations . . . . . . . . . . . 9 7.2. YANG Module Security Considerations . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . 11 8.1. Normative References . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . 12 8.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
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
skipping to change at page 4, line 13 skipping to change at page 4, line 13
The BFD parameters can be either per-interface or per-router based. The BFD parameters can be either per-interface or per-router based.
It MAY also choose to use the parameters that the active side uses in It MAY also choose to use the parameters that the active side uses in
its BFD Control packets. The "My Discriminator", however, MUST be its BFD Control packets. The "My Discriminator", however, MUST be
chosen to allow multiple unsolicited BFD sessions. chosen to allow multiple unsolicited BFD sessions.
The active side starts sending the BFD Control packets as specified The active side starts sending the BFD Control packets as specified
in [RFC5880]. The passive side does not send BFD Control packets. in [RFC5880]. The passive side does not send BFD Control packets.
When the passive side receives a BFD Control packet from the active When the passive side receives a BFD Control packet from the active
side with 0 as "Your Discriminator", and it does not find an existing side with 0 as "Your Discriminator" and does not find an existing BFD
session with the same source address and the same "Discriminator" session, the passive side MAY create a matching BFD session toward
pairs as in the packet and "unsolicited BFD" is allowed on the the active side, if permitted by local configuration.
interface by local policy, it MUST create a matching BFD session
toward the active side (based on the source address and destination It would then start sending the BFD Control packets and perform
address in the BFD Control packet) as if the session were locally necessary procedure for bringing up, maintaining and tearing down the
registered. It would then start sending the BFD Control packets and BFD session. If the BFD session fails to get established within
perform necessary procedure for bringing up, maintaining and tearing certain specified time, or if an established BFD session goes down,
down the BFD session. If the BFD session fails to get established the passive side would stop sending BFD Control packets and MAY
within certain specified time, or if an established BFD session goes
down, the passive side would stop sending BFD Control packets and MAY
delete the BFD session created until the BFD Control packets is delete the BFD session created until the BFD Control packets is
initiated by the active side again. initiated by the active side again.
When on the passive side Unsolicited BFD sessions goes down an When an Unsolicited BFD session goes down, an implementation MAY
implementation MAY keep such session state for a configurable amount retain the session state for a period of time, which may be
of time. Temporarily keeping such local state may permit retrieving configurable. Retaining this state can be useful for operational
additional operational information of such session which went down. purposes.
The "Passive role" may change to the "Active role" when a local The "Passive role" may change to the "Active role" when a local
client registers for the same BFD session, and from the "Active role client registers for the same BFD session, and from the "Active role"
" to the "Passive role " when there is no longer any locally to the "Passive role" when there is no longer any locally registered
registered client for the BFD session. client for the BFD session.
3. State Variables 3. State Variables
This document defines a new state variable called Unsolicited Role. This document defines a new state variable called Unsolicited Role.
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
skipping to change at page 9, line 4 skipping to change at page 8, line 47
description description
"Augmentation for BFD unsolicited on IP single-hop session"; "Augmentation for BFD unsolicited on IP single-hop session";
container unsolicited { container unsolicited {
config false; config false;
description description
"BFD IP single-hop session unsolicited top level container"; "BFD IP single-hop session unsolicited top level container";
leaf role { leaf role {
type bfd-unsol:unsolicited-role; type bfd-unsol:unsolicited-role;
description "Role."; description "Role.";
} }
} }
} }
} }
<CODE ENDS> <CODE ENDS>
5. IANA Considerations 5. IANA Considerations
This documents makes no IANA requests. This documents makes no IANA requests.
6. Acknowledgments 6. Acknowledgments
Authors would like to thank Acee Lindem, Greg Mirsky and Raj Chetan Authors would like to thank Acee Lindem, Greg Mirsky, Jeffrey Haas
for their review and valuable input. and Raj Chetan 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:
 End of changes. 11 change blocks. 
27 lines changed or deleted 24 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/