IETF Logo Mail Archive

Re: [OPSAWG] A question on OAM section in draft-ietf-opsawg-l3sm-l3nm

Greg Mirsky <gregimirsky@gmail.com> Sat, 28 August 2021 19:03 UTC

Return-Path: <gregimirsky@gmail.com>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E581B3A16B1; Sat, 28 Aug 2021 12:03:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 khjK1MbLeKH7; Sat, 28 Aug 2021 12:03:08 -0700 (PDT)
Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com [IPv6:2a00:1450:4864:20::62b]) (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 2E7573A169E; Sat, 28 Aug 2021 12:03:08 -0700 (PDT)
Received: by mail-ej1-x62b.google.com with SMTP id me10so21368656ejb.11; Sat, 28 Aug 2021 12:03:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XTwSS6hjlKG3x0objesZyYksv2WYziWZtJrnA9kqoNk=; b=cUBTYhu9myVqJ7mwivTVKWytsSlZGgJOuJ9NcD22EXhKYXG/l1FVS/hV0NS3yIV5Z6 WT7N1KjBLgdtbhBtD3OwfFr9wULrqiat5lIogCDVwoYaM5kdLb3+T/shu5jCNEoKju3Q amb+XKjVUKDdhWigYwLV0CpL7hmoK1ydarF781CsAxk1guYKF4+qjDKxbeBmxGjqijaa Ya/AuLHnuU9vR4CB6XHYhC20LNSx7u+qxDNb31nQEzQiVrZHFlG1kZBD6Q9LVmDnyREO 6fB9iGSKb5M8JdlE0evzBrAo2rkyneCfljaBDEKUYaHJ/1iJWrg7xHGjxZhW9kTjkZeJ I3fA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XTwSS6hjlKG3x0objesZyYksv2WYziWZtJrnA9kqoNk=; b=ThGRl7g2n2kJqEjLF4uW4WUZR1K8L3K2Uex0KkuYQ0Jm88xRtcXhRZ3CFCjUXNCtkP ClJ3v9jFojNrYSU2U8sShT/40ia3H9Nu8bcjy/Dkj01yCFIfJqbZlf37HWqTVc2H+9Ob NhQ1iZ5V+CLmAwqH87oetZx1En5NaaEAILCh35wt80JyKMEZAvihE5vvP9MY/h82DRA9 S2CXvDa3/23TtsImcuT5BJ09QtIm5/1msNH9A7M/yMCl5+iIknxlgVaH4JEMcWBUr09e dYiOf38M7kINwj2b6z9SdeNRN/YjpSHJUET+4pkHhkid5vuFfz91yjn86SaLet0aIZCB 4CeA==
X-Gm-Message-State: AOAM5329K0cW0lfdXb0yWGC9b9pBfIPBnx2gWv06oyLTXw4/s4lQkL8g LYyQAt79PX6ZmaKGhLcdGdII5hx3uuAsRZIWeFU=
X-Google-Smtp-Source: ABdhPJz3pNupnOjql6vtEtbRlek/UpS36u8M+Uk3jhFENWclV+W+sQmGYKgvwg5FGqOopTbBnM0YrV4zpYYfpKwBfyk=
X-Received: by 2002:a17:906:6bc5:: with SMTP id t5mr16824925ejs.340.1630177384448; Sat, 28 Aug 2021 12:03:04 -0700 (PDT)
MIME-Version: 1.0
References: <CA+RyBmUUbdsUz1=R=+Oq8K5uCVTHNUXA5P9ZMQ6qnnCEA_LgLA@mail.gmail.com> <DB7PR07MB554631283198A53DDBC3C603A2C99@DB7PR07MB5546.eurprd07.prod.outlook.com>
In-Reply-To: <DB7PR07MB554631283198A53DDBC3C603A2C99@DB7PR07MB5546.eurprd07.prod.outlook.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Sat, 28 Aug 2021 12:02:53 -0700
Message-ID: <CA+RyBmV6A1FtYVuLGkptr6nm6YGGrtE0w-PvtBYEVkSRanSjDA@mail.gmail.com>
To: tom petch <ietfa@btconnect.com>
Cc: "draft-ietf-opsawg-l3sm-l3nm@ietf.org" <draft-ietf-opsawg-l3sm-l3nm@ietf.org>, opsawg <opsawg@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ebc7a905caa33f7c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/olhF7xnXEcaTtdw-lKMlKSptTXo>
Subject: Re: [OPSAWG] A question on OAM section in draft-ietf-opsawg-l3sm-l3nm
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 28 Aug 2021 19:03:14 -0000

Hi Tom,
I understand that the missref that the BFD YANG data model got into for so
long caused some frustration and uncertainty. As of late, the authors, WG
Chairs and the AD have taken actions to untangle the situation and progress
most of the data models leaving a smaller part in missreff. I don't have
first-hand information on how close to the publication of the updated main
body of the BFD YANG data model is. I hope it is not too far.
I have several questions about the BFD container
in draft-ietf-opsawg-l3sm-l3nm. I hope I can use the opportunity and ask
them even we're past the LC phase:

   - Which mode of a BFD session is assumed for the model? For example, is
   it Asynchronous or Demand; with Echo or without; single-hop or multi-hop?
   - Which BFD session types the data model is required to support? For
   example, "classic" RFC 5880, S-BFD per RFC 7880, or BFD for multipoint
   networks?
   - What behavior of a BFD system is controlled by the holdtime? Can you
   point to the text in RFC 5880 that defines the expected behavior?


Regards,
Greg

On Sat, Aug 28, 2021 at 5:07 AM tom petch <ietfa@btconnect.com> wrote:

> From: Rtg-bfd <rtg-bfd-bounces@ietf.org> on behalf of Greg Mirsky <
> gregimirsky@gmail.com>
> Sent: 28 August 2021 03:56
>
> Dear Authors,
> thank you for your work on this document. I've read the draft and have a
> question, and a suggestion. Section 7.6.4<
> https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-l3sm-l3nm#section-7.6.4>
> describes how BFD is controlled in vpn-common. I've noticed that you use
> references to RFC 5880. While that is the basis for all subsequent BFD
> documents, for BFD YANG data model draft-ietf-bfd-yang<
> https://datatracker.ietf.org/doc/draft-ietf-bfd-yang/> may be more
> useful.
>
> <tp>
> Greg
>
> I think that the authors have got this one right (although I disagree with
> much else as I have commented on Last Call:-(,   If you look at the history
> of bfd-yang you will see that nothing has happened to it for over three
> years despite concerted efforts to get it moving, so in the interests of
> this becoming an RFC within the next three years (!), I would not want to
> see the reference changed.
>
> Tom Petch
>
> Perhaps the container oam can re-use grouping base-cfg-parms.
> What are your thoughts?
>
> Regards,
> Greg
>

v2.23.0 | Report a Bug | By Email