Zaheduzzaman Sarker's Discuss on draft-ietf-bfd-unsolicited-11: (with DISCUSS and COMMENT)

Zaheduzzaman Sarker via Datatracker <noreply@ietf.org> Wed, 14 December 2022 19:32 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: rtg-bfd@ietf.org
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 26188C14F723; Wed, 14 Dec 2022 11:32:46 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Zaheduzzaman Sarker via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-bfd-unsolicited@ietf.org, bfd-chairs@ietf.org, rtg-bfd@ietf.org, Jeffrey Haas <jhaas@pfrc.org>, jhaas@pfrc.org
Subject: Zaheduzzaman Sarker's Discuss on draft-ietf-bfd-unsolicited-11: (with DISCUSS and COMMENT)
X-Test-IDTracker: no
X-IETF-IDTracker: 9.3.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Zaheduzzaman Sarker <Zaheduzzaman.Sarker@ericsson.com>
Message-ID: <167104636614.47387.14544637650303450586@ietfa.amsl.com>
Date: Wed, 14 Dec 2022 11:32:46 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/egSd7OJ0rnMUXaiKGI3tT7CjKAQ>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.39
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-bfd/>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Dec 2022 19:32:46 -0000

Zaheduzzaman Sarker has entered the following ballot position for
draft-ietf-bfd-unsolicited-11: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bfd-unsolicited/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thanks for working on this specification.

Thanks to Magnus Westerlund for the TSVART review, based on that review and my
own read, I am supporting both Lars's and Roman's discuss.

On top of that, as this document claims - "with "unsolicited BFD" there is
potential risk for excessive resource usage by BFD from "unexpected" remote
systems". This translates to me as potential injection of huge amount of
traffic which is lacking a self-regulation mechanism in this specification. To
large degrees the traffic volume could have random effects on the routing plane
and what links are considered up etc. We can hide all these by saying "Deploy
the feature only in certain "trustworthy" environment"", then I am completely
missing the definition of "trustworthy" environment". I would like to discuss
that.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Additional comments -

* This document also says - "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." I am missing any discussion
on the reduced functionality or any indication if the selected period time has
any advantages or disadvantages. To be honest, without proper discussion or
indication of some default values, I would remove the entire sentence or if
this is just an additional implementation advice, I would drop the normative
MAY.