Re: Mirja Kühlewind's Discuss on draft-ietf-bfd-multipoint-18: (with DISCUSS)

Greg Mirsky <gregimirsky@gmail.com> Thu, 05 July 2018 21:16 UTC

Return-Path: <gregimirsky@gmail.com>
X-Original-To: rtg-bfd@ietfa.amsl.com
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55B2B131074; Thu, 5 Jul 2018 14:16:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oSod9xUfcFDh; Thu, 5 Jul 2018 14:16:11 -0700 (PDT)
Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AF99130FD0; Thu, 5 Jul 2018 14:15:36 -0700 (PDT)
Received: by mail-lj1-x22d.google.com with SMTP id q127-v6so7051212ljq.11; Thu, 05 Jul 2018 14:15:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8BBS/UiI7yyoaayByEL6zUlb1qE9QGtOYWk9ArZ+B8E=; b=aOqZm7NYYUG+cuAFZTGK/VFlgsnr8x98f6kix+tLYcV85aAGT0MWdZllnyH1MGXkl9 CWHe2mbThpr5shxlD8JQdhxkT9lonPwO03pJS7SXG5zxvMAgKa1M9UybElU5KutOvw5E 8+GaYBLTWFj7qXIvSTr8jzZH3HrllXLBbwkKgxCX+bTGiDYLELRI+XdS6N49tcT6rSwT aLzSoIh/GwBeP1EJ9DgnSTgqn6MsF8pXNTO567iCZ7KYyPMFDW0alu4yOxs7vrU8WV7U VNiXZaDGm86n/Lo0dxvLcAfbfACb/SzD+TfiyRB2LTz5PPnMkKKKk+0WY8P4fAW0srDZ CpVA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8BBS/UiI7yyoaayByEL6zUlb1qE9QGtOYWk9ArZ+B8E=; b=TlAi+vjh8ZITnPQZkmKvHX9QdqxnRtV3Alj57zQSGxBB7rF1Lx7267QUuI4foeh645 UHbZCXj8fQP9DecCpXIyYT2L1UeOgO0/KjxjROJZyeHsgDksEgzWFGZIASGnKdZTkKXR TEgUFTFdN64VLkB9/OpCKRzLXNTxKnSA//U2b2Gx+LIXCu+PnyFseokYVkcraEoHl2pc Ym2qDnP0iHxn3DqY9DgU2xA8niOleRz1W6MDD9zvOYtGbKxP7DYMLcaGjHA9VxyGVH7a ScfeaDrm0diXhrQIhXHTer+x0hrjiawm/DJ/cdXrKdg1X0la54EYoTtbATIBjgroWvvr WaRA==
X-Gm-Message-State: APt69E0tn2ItqgsOcbJ1itLqvQsA0IgMqdughH/c3AVydvdzkN+qbYP4 8LnYnnsLXzGKHecUqZChItNsGHcaYMDgH0dOoGQ=
X-Google-Smtp-Source: AAOMgpc1EvpZz4eiifKDWS0sG8+tL+hsOpZUINtWsx8k9lqKd5ZunbTETfaZdqW7BmpkHLMCTFPB37mhkB/zEOVgU5Q=
X-Received: by 2002:a2e:9a95:: with SMTP id p21-v6mr4891189lji.60.1530825334815; Thu, 05 Jul 2018 14:15:34 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a2e:709:0:0:0:0:0 with HTTP; Thu, 5 Jul 2018 14:15:33 -0700 (PDT)
In-Reply-To: <0AAFC485-F80F-4362-B876-4F3AB371810A@kuehlewind.net>
References: <153064270085.5078.5189673902650964259.idtracker@ietfa.amsl.com> <CA+RyBmX0vYfWG=y3idNPw9=58LOwm7V0LqkzJvXgSk2sdFJb+w@mail.gmail.com> <0AAFC485-F80F-4362-B876-4F3AB371810A@kuehlewind.net>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Thu, 05 Jul 2018 14:15:33 -0700
Message-ID: <CA+RyBmVYK2+eXDu0tRWVEh1U=-q+UbjwHwVgQdH7soxB+JHgkw@mail.gmail.com>
Subject: Re: Mirja Kühlewind's Discuss on draft-ietf-bfd-multipoint-18: (with DISCUSS)
To: "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>
Cc: Reshad Rahman <rrahman@cisco.com>, draft-ietf-bfd-multipoint@ietf.org, rtg-bfd@ietf.org, The IESG <iesg@ietf.org>, bfd-chairs@ietf.org
Content-Type: multipart/alternative; boundary="0000000000004b7e5f0570470c0b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/buvuL_Rz9NJUEyjKAL_Xdau9_Nw>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
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: Thu, 05 Jul 2018 21:16:23 -0000

Hi Mirja,
thank you for the clarification. I believe that the required action and use
of MUST, in this case, is too strong as it defeats the purpose of FM OAM by
hiding the problem rather than detecting and signaling it.

Regards,
Greg

On Thu, Jul 5, 2018 at 1:26 PM, Mirja Kuehlewind (IETF) <ietf@kuehlewind.net
> wrote:

> Hi Greg,
>
> just one thing quickly
>
> > Am 05.07.2018 um 21:27 schrieb Greg Mirsky <gregimirsky@gmail.com>:
> >
> > 2) See sec 7 of RFC 8085
> > "When BFD is used across multiple hops, a congestion control mechanism
> >    MUST be implemented, and when congestion is detected, the BFD
> >    implementation MUST reduce the amount of traffic it generates. "
> > GIM>> I couldn't find this in RFC 8085 and had to broaden my search. I
> believe that thsi quote is from RFC 7880 Seamless BFD. I'm puzzled why this
> specification, when talking about challenges S-BFD may face, switches to
> requirement for BFD. Doesn't look right. And more, increasing transmission
> interval to avoid packet drop defeats the purpose of using proactive defect
> detection mechanism. The purpose of the fault management is to detect
> failures, not to avoid the detection. If active OAM generates excess of
> traffic, then other OAM mechanisms can be considered and used. But
> loosening OAM is not, in my view, proper way to address network problem as
> it rather hides them, not detets and reports as it intended to do.
> This quote is from RFC5880. The BFD base spec. Sorry that was copy and
> past error!