Re: A question on OAM section in draft-ietf-opsawg-l3sm-l3nm
Jeffrey Haas <jhaas@pfrc.org> Wed, 01 September 2021 12:38 UTC
Return-Path: <jhaas@slice.pfrc.org>
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 1600C3A0D58; Wed, 1 Sep 2021 05:38:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 wsPG6qkCQozj; Wed, 1 Sep 2021 05:38:07 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 606933A0D56; Wed, 1 Sep 2021 05:38:07 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 0125C1E2D4; Wed, 1 Sep 2021 08:38:05 -0400 (EDT)
Date: Wed, 01 Sep 2021 08:38:05 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: mohamed.boucadair@orange.com
Cc: Greg Mirsky <gregimirsky@gmail.com>, "draft-ietf-opsawg-l3sm-l3nm@ietf.org" <draft-ietf-opsawg-l3sm-l3nm@ietf.org>, opsawg <opsawg@ietf.org>, rtg-bfd WG <rtg-bfd@ietf.org>
Subject: Re: A question on OAM section in draft-ietf-opsawg-l3sm-l3nm
Message-ID: <20210901123805.GF2820@pfrc.org>
References: <CA+RyBmUUbdsUz1=R=+Oq8K5uCVTHNUXA5P9ZMQ6qnnCEA_LgLA@mail.gmail.com> <5697_1630325964_612CCCCC_5697_162_1_787AE7BB302AE849A7480A190F8B9330353E5905@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <20210831213046.GD2820@pfrc.org> <25527_1630478925_612F224D_25527_493_1_787AE7BB302AE849A7480A190F8B9330353E6E4D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <25527_1630478925_612F224D_25527_493_1_787AE7BB302AE849A7480A190F8B9330353E6E4D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/GlrmlEudoky0iPGcTO7RkDkSLoI>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 01 Sep 2021 12:38:14 -0000
Med, On Wed, Sep 01, 2021 at 06:48:43AM +0000, mohamed.boucadair@orange.com wrote: > Hi Jeff, > > Actually, except local-multiplier that we call detection-multiplier, the > same names are used in both drafts. We can fix that one. Certainly a start. > Please note that we are not using the interval-config-type choice given > that the single case can be covered by setting desired-min-tx-interval and > required-min-rx-interval to the same value. This is true. It's also true that that style entered the BFD YANG model because a unified-only mechanism is what some vendors have implemented. If their implementations don't cover the split mode you're requiring them to create a deviation. > It is then straightforward to > map it the device module depending whether single-minimum-interval feature > is supported or not. We don't want to complicate the network view of the > service with such device-level features. There is always a tension between service models and the needs of the underlying device model. That said, you're losing the benefits of work already done. As an example, you're missing the default detection multiplier because you're doing the work yourself rather than leveraging other work. This means you're requiring the model users to always provision a paramter that is usually left as a default. Clearly the BFD Working Group can't force you to use our work in your model, especially if there are features that aren't a clean fit. That said, when it comes IETF review time, the choice to go-it-alone will be noted so that the YANG doctors can do an appropriately thorough audit. The BFD Working Group is also happy to help with review once it's time. -- Jeff
- A question on OAM section in draft-ietf-opsawg-l3… Greg Mirsky
- RE: A question on OAM section in draft-ietf-opsaw… mohamed.boucadair
- Re: A question on OAM section in draft-ietf-opsaw… Greg Mirsky
- RE: A question on OAM section in draft-ietf-opsaw… mohamed.boucadair
- Re: A question on OAM section in draft-ietf-opsaw… Jeffrey Haas
- RE: A question on OAM section in draft-ietf-opsaw… mohamed.boucadair
- Re: A question on OAM section in draft-ietf-opsaw… Jeffrey Haas
- RE: A question on OAM section in draft-ietf-opsaw… mohamed.boucadair
- Re: A question on OAM section in draft-ietf-opsaw… Greg Mirsky
- Re: A question on OAM section in draft-ietf-opsaw… Jeffrey Haas
- RE: A question on OAM section in draft-ietf-opsaw… mohamed.boucadair
- Re: A question on OAM section in draft-ietf-opsaw… Greg Mirsky
- RE: A question on OAM section in draft-ietf-opsaw… mohamed.boucadair