Re: [pim] draft-ietf-pim-bfd-p2mp-use-case WGLC

Stig Venaas <> Tue, 24 November 2020 19:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AF4D23A1873 for <>; Tue, 24 Nov 2020 11:33:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id AZvnhc2c-da4 for <>; Tue, 24 Nov 2020 11:33:01 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::42e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F40883A1869 for <>; Tue, 24 Nov 2020 11:33:00 -0800 (PST)
Received: by with SMTP id y7so19472527pfq.11 for <>; Tue, 24 Nov 2020 11:33:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Hcw30Fyz2IJ0hTMU7L9ufqyOGeW1y0bdRAf8yUT7K64=; b=kaTm0YZhrsUoCltyJINGpFVDCPuRIOLJjNyr4/EcWelGk9PoCggnUVQ+mYYU0Ke+u0 qbJUupm3kHvegsoUo7nN6EpETVnhysSoX1SYU17kxWXhxlJEw2SzQdpVsi0ibtnDy6qZ g2ggJ5bDUoSxAZIpgjmXsrM7icsiulVAlVoGTSphBfjCBtU5/nF5+YTJA6dKYz+mQVYU h2+Yx6prMmToVYJjhQSfsE64PYL0HIRB5MDVn6xlCB8eOtA0lu4N1dqzPN17Rx7SVzEa Sm641PTR9OMoXnGVM+11JhXe/yB3lbVyaQhAnYdHBmO0flptdzZH7mkgIKOEUdkGvXxe Tsrg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Hcw30Fyz2IJ0hTMU7L9ufqyOGeW1y0bdRAf8yUT7K64=; b=mvlXePvlB2uzN6aSfx9htWTuf7aV37uDFqV+dUDXOem86hNezGSOOwRkUtFz42E2pB HtvrLra0UJ4w7q5yydHeLaThckvcS9yxW/XYKonEpceRpt5VpNUsI2d2Cqq0rDD+2oKO beBk5jAhQidFRmtFKsUm2spQWbvrhsvSUAAEj3RG02IlUDc+ZWTs9jjr5U9uIGnAGHMk yaVIEm2wAs7+ar7rmC353VzuCq1Ey/6Ps0KzbLusrBTcsvwcr5zGHgzVRBds1GSJgRPX 62RIG5e00LayNz0FfpwGYJaAKVroaefm9UU5QtCPsJZRxo6lLUiZCtGOdpRCDzVIrjgp OKlw==
X-Gm-Message-State: AOAM533pbVPlxHZiEq3fkgniEBoD7X/nkThqd6H/lCq2U4vDYGxp97Bt wswmFjhFRwBVYMb6U5rtG2VJw/I7Ygu9HCKMrIiNsg==
X-Google-Smtp-Source: ABdhPJwafkG7+i/WH0VbSBirrXyzsnp/EOuChyC4yQafdHV4eC35DJBZu78+VVNnxb7TDRdswVvoIvb6TWRMxrijVIg=
X-Received: by 2002:a63:7847:: with SMTP id t68mr4938073pgc.422.1606246380385; Tue, 24 Nov 2020 11:33:00 -0800 (PST)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Stig Venaas <>
Date: Tue, 24 Nov 2020 11:32:49 -0800
Message-ID: <>
To: Michael McBride <>
Cc: "" <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [pim] draft-ietf-pim-bfd-p2mp-use-case WGLC
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Protocol Independent Multicast <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 24 Nov 2020 19:33:05 -0000


Apologies for being a bit behind the deadline, I have a few WGLC comments.

I believe the document is nearly ready for publication. I just have a
few minor comments that I think should be considered. Although my
comments may seem lengthy, I think it might just be a matter of adding
a few sentences.

In the intro where p2p BFD is mentioned, I think it would be good to
mention that there are PIM-SM implementations making use of p2p BFD,
and then maybe point out why p2mp BFD is better suited for this. I see
you mention that p2mp BFD precisely characterizes the pim deployment
scenario, and I agree with that, but maybe could add more details why
p2mp is better. I think this is important as it will indicate why
existing pim BFD implementations should move to p2mp BFD.

Typo here:
p2mp: Pont-to-Multipoint

A few comments on section 3.1.

I imagine there could be some confusion whether the BFD TLV applies to
regular BFD or only p2mp BFD. Can you clarify this?

If I read this correctly, any PIM router can be configured to use p2mp
and one doesn't need to be BDR or DR to use this. Perhaps it is good
to add a sentence saying that any PIM-SM router may announce the BFD
TLV, and other PIM-SM routers MAY monitor it. Basically, even though
the section name is about DR/BDR monitoring, it can also be used to
monitor other neighbors. I think it is good to include this, as this
is done by BFD implementations today. I can imagine that there will be
other use-cases now or in the future, for monitoring neighbors that
are not DR/BDR.

Security considerations:
Is it worth stating how this relates to PIM authentication? If PIM-SM
is configured to require neighbors to be authenticated, then this
would only apply to authenticated neighbors. It looks like p2mp BFD
also has its own authentication mechanism? Should that be considered
used for PIM? Is there value in doing that if PIM authentication is


On Fri, Nov 6, 2020 at 1:10 PM Michael McBride
<> wrote:
> Hello people of pim,
> Today begins a two week wglc of
> Please share your opinions on the readiness of this draft to be sent to the iesg.
> Thanks,
> mike
> _______________________________________________
> pim mailing list