--- 1/draft-ietf-bfd-unsolicited-04.txt 2021-10-19 17:13:09.161161077 -0700 +++ 2/draft-ietf-bfd-unsolicited-05.txt 2021-10-19 17:13:09.189161778 -0700 @@ -1,22 +1,22 @@ Network Working Group E. Chen Internet-Draft Palo Alto Networks Intended status: Standards Track N. Shen -Expires: April 18, 2022 Zededa +Expires: April 22, 2022 Zededa R. Raszuk NTT Network Innovations R. Rahman - October 15, 2021 + October 19, 2021 Unsolicited BFD for Sessionless Applications - draft-ietf-bfd-unsolicited-04 + draft-ietf-bfd-unsolicited-05 Abstract For operational simplification of "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 be established without explicit per-session configuration or registration by the other side (subject to certain per-interface or per-router policies). @@ -36,21 +36,21 @@ 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." - This Internet-Draft will expire on April 18, 2022. + This Internet-Draft will expire on April 22, 2022. Copyright Notice Copyright (c) 2021 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 @@ -58,30 +58,30 @@ 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. Procedures for Unsolicited BFD . . . . . . . . . . . . . . . 3 3. State Variables . . . . . . . . . . . . . . . . . . . . . . . 4 - 4. YANG Data Model . . . . . . . . . . . . . . . . . . . . . . . 5 + 4. YANG Data Model . . . . . . . . . . . . . . . . . . . . . . . 4 4.1. Unsolicited BFD Hierarchy . . . . . . . . . . . . . . . . 5 4.2. Unsolicited BFD Module . . . . . . . . . . . . . . . . . 5 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7.1. BFD Protocol Security Considerations . . . . . . . . . . 9 7.2. YANG Module Security Considerations . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 - 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 + 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 8.2. Informative References . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction The current implementation and deployment practice for BFD ([RFC5880] and [RFC5881]) usually requires BFD sessions be explicitly configured or registered on both sides. This requirement is not an issue when an application like BGP [RFC4271] has the concept of a "session" that involves both sides for its establishment. However, this requirement @@ -143,43 +143,41 @@ 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 its BFD Control packets. The "My Discriminator", however, MUST be chosen to allow multiple unsolicited BFD sessions. The active side starts sending the BFD Control packets as specified in [RFC5880]. The passive side does not send BFD Control packets. 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 - session with the same source address and the same "Discriminator" - pairs as in the packet and "unsolicited BFD" is allowed on the - interface by local policy, it MUST create a matching BFD session - toward the active side (based on the source address and destination - address in the BFD Control packet) as if the session were locally - registered. It would then start sending the BFD Control packets and - perform necessary procedure for bringing up, maintaining and tearing - down the BFD session. If the BFD session fails to get established - within certain specified time, or if an established BFD session goes - down, the passive side would stop sending BFD Control packets and MAY + side with 0 as "Your Discriminator" and does not find an existing BFD + session, the passive side MAY create a matching BFD session toward + the active side, if permitted by local configuration. + + It would then start sending the BFD Control packets and perform + necessary procedure for bringing up, maintaining and tearing down the + BFD session. If the BFD session fails to get established 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 initiated by the active side again. - When on the passive side Unsolicited BFD sessions goes down an - implementation MAY keep such session state for a configurable amount - of time. Temporarily keeping such local state may permit retrieving - additional operational information of such session which went down. + When an Unsolicited BFD session goes down, an implementation MAY + retain the session state for a period of time, which may be + configurable. Retaining this state can be useful for operational + purposes. The "Passive role" may change to the "Active role" when a local - client registers for the same BFD session, and from the "Active role - " to the "Passive role " when there is no longer any locally - registered client for the BFD session. + client registers for the same BFD session, and from the "Active role" + to the "Passive role" when there is no longer any locally registered + client for the BFD session. 3. State Variables This document defines a new state variable called Unsolicited Role. bfd.UnsolicitedRole The operational mode of BFD interface when configured for unsolicited behaviour. Options can be either PASSIVE, ACTIVE or NULL (NULL - not initialized) for unsolicited BFD sessions. Default (not configured @@ -382,22 +379,22 @@ } 5. IANA Considerations This documents makes no IANA requests. 6. Acknowledgments - Authors would like to thank Acee Lindem, Greg Mirsky and Raj Chetan - for their review and valuable input. + Authors would like to thank Acee Lindem, Greg Mirsky, Jeffrey Haas + and Raj Chetan for their review and valuable input. 7. Security Considerations 7.1. BFD Protocol Security Considerations The same security considerations and protection measures as those described in [RFC5880] and [RFC5881] normatively apply to this document. With "unsolicited BFD" there is potential risk for excessive resource usage by BFD from "unexpected" remote systems. To mitigate such risks, the following measures are mandatory: