Re: [pim] AD Review of draft-ietf-pim-bfd-p2mp-use-case-05

Alvaro Retana <aretana.ietf@gmail.com> Wed, 25 August 2021 20:54 UTC

Return-Path: <aretana.ietf@gmail.com>
X-Original-To: pim@ietfa.amsl.com
Delivered-To: pim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6199F3A0CBB; Wed, 25 Aug 2021 13:54:07 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 18Zy3TZDapTv; Wed, 25 Aug 2021 13:54:01 -0700 (PDT)
Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) (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 A14EA3A0CC4; Wed, 25 Aug 2021 13:54:01 -0700 (PDT)
Received: by mail-ed1-x529.google.com with SMTP id q3so1086294edt.5; Wed, 25 Aug 2021 13:54:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc:content-transfer-encoding; bh=OqM6j4AKvjRHAy+zyp5SSlk0NFKU3mctj4Q6n6+0R/c=; b=Prg0RvPKXpsUA2YCA+P7HF29H2gOX4wmdvZi8qTfDI1IAV6JUw0ZAirI5cdhT3Jnhl Zpf4ipOK2VRqWzr6Mkhgsdl5pyw1d4ocE5apDEZvXhZv7fbfW7Hj8Ko7FKfcy9hER/lM FW2HJ5QHqh6R8ywqTHLGnNDbhn1z+hTSPO1fGON1LoN8/anwnhcQJ+Fo9GSds49sTwRH qLtJac7pIe9v1Hj5RnUDJj2ztVO1VQ4XHegj4rymz8neYGpZfn6jBNmg786HCfX+Y1vi irKiHXhCSS6v5XJpaocEqMQAKOOc6bk2DIw0QUtrHpGHoQYjeyTAQhsyCSasL56RrkKQ bpiQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc:content-transfer-encoding; bh=OqM6j4AKvjRHAy+zyp5SSlk0NFKU3mctj4Q6n6+0R/c=; b=svqJsT0NjrvVS5hOW4vnlLfoxr7Ith3HUfhWPJ3DOym9de4+tzngyekeHPaDp7khUA j50cd7oGjshUe3xWXYfvEIHWy7me58HZ26w6NNlLuOjHQ3VMhlBpJeo+AWmRltCTshy5 x3pTveYjcBxL0yZIaxpvU5ApA0IVJ0LmlmVeoPwhrjRWUXwd51Ig3q8SXcyXzOhLIXkY mxHyeR3B6oUeUU02HWz2Th38BUDceVNAFaSqYQ8qpiKqv7NLbrKmvAYWUnOJNf/v5ktO VEFjqiy8RdnIB4AC+eJLt+qysvmw7vSv6xHd5LhDzuR+a+V5HkxNXSSOcBWP+2/+2Gf2 /OTA==
X-Gm-Message-State: AOAM5310OxdMinrReKwnGInEgT1qjqMyFdCOdU4Lmu8wS3Ht+DUgx+dw K+30wp5wL1/xuCFiZ8hl5adlWfA6hHCqy8Ty6DSUT1Nv
X-Google-Smtp-Source: ABdhPJzUkS5QbLng5mEedsc6u5Gf0PxLcvpgUWR1jfblr1U9Dy3sU5dRCXA7iEkHK6E8GsJ2TXXnZF5z7f7cDyY2E2c=
X-Received: by 2002:a05:6402:40d4:: with SMTP id z20mr458039edb.314.1629924838810; Wed, 25 Aug 2021 13:53:58 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 25 Aug 2021 13:53:57 -0700
From: Alvaro Retana <aretana.ietf@gmail.com>
In-Reply-To: <202108241134368248558@zte.com.cn>
References: <202108241134368248558@zte.com.cn>
MIME-Version: 1.0
Date: Wed, 25 Aug 2021 13:53:57 -0700
Message-ID: <CAMMESszN_=6wL83s8MxPt79yZ1HXWPSxzOKfJFCZnr4+S=CDHw@mail.gmail.com>
To: gregory.mirsky@ztetx.com
Cc: pim-chairs@ietf.org, draft-ietf-pim-bfd-p2mp-use-case@ietf.org, mmcbride7@gmail.com, pim@ietf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/pim/Bi7Dm_zdOCOGvGTk-knjYvhWDus>
Subject: Re: [pim] AD Review of draft-ietf-pim-bfd-p2mp-use-case-05
X-BeenThere: pim@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Protocol Independent Multicast <pim.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pim>, <mailto:pim-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pim/>
List-Post: <mailto:pim@ietf.org>
List-Help: <mailto:pim-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pim>, <mailto:pim-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Aug 2021 20:54:17 -0000

On August 23, 2021 at 11:34:50 PM, gregory.mirsky@ztetx.com wrote:


Greg:

Hi!

> thank you for your review, comments, and suggestions. I'm working on
> updating the document and preparing the -07 version. I have a question
> related to the scope of the draft. You have identified the essential part of
> the proposal -  a new PIM Hello option to bootstrap a p2mp BFD session.
> Indeed, any PIM  router can use it for advertising its My Discriminator to
> other PIM routers on the shared segment. Then, as I can imagine, depending
> on the role of that PIM router and the configuration on each neighbor, the
> state of the advertising PIM router can be monitored. After detecting the
> failure of the monitored router, we can expect that the monitoring PIM
> router will take the same actions as if the failure was detected according
> to RFC 7761.

Right.


> Thus, it does appear that for all possible uses of p2mp BFD in PIM-SM, all
> that is needed is the new PIM Hello option and reference to the
> corresponding section in RFC 7761.

In general, there's no need to point at specific sections.  In all
cases the BFD timeout indicates a neighbor failure and rfc7761 is
clear about what to do in that case.


> But there might still be value in analyzing each case of using p2mp BFD in
> PIM-SM separately (even as a small informational document), as you've noted
> in:
>
> In the general case... If tracking the sender of a Join, for example,
> the effect would be more significant: an outage would exist until the
> next Join is received.

Honestly, I think that's about the extent of the additional analysis:
a sentence or two.  IOW, I don't think there's value in a separate
document that would just cover that (specially when compared to the
effort of going through the process, etc.).



> Would you agree that the scope of this document includes the definition of
> a new PIM Hello option BFD Discriminator to bootstrap a p2mp BFD session and
> a description of using that option monitoring PIM DR/BDR as a use case
> example?

Well -- that's the point that I've been trying to make: the
applicability is general, the additional considerations (if any) are
minimal, etc..

I would like the scope of this document to be the definition of the
new Hello option + a general description of the applicability to PIM
(all of PIM, not just the DR).   An example is ok.

Just one more thing.  In my comments I keep ignoring the BDR because
the documents that define it are not done yet and I would like to
avoid holding up the publication of this draft.  Note that the general
applicability description (if made general enough) would cover the BDR
function as well -- after all the BDR is also a PIM router that others
can monitor.


If I'm still not being clear, I think we should plan on a f2f
conversation.  Please take a look at my calendar:
https://doodle.com/mm/alvaroretana/book-a-time


Thanks!

Alvaro.