Re: Benjamin Kaduk's No Objection on draft-ietf-bfd-multipoint-19: (with COMMENT)

Greg Mirsky <> Thu, 27 December 2018 23:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A00CE130E9D; Thu, 27 Dec 2018 15:05:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NGLV3NQay5WT; Thu, 27 Dec 2018 15:05:52 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 47C021294D0; Thu, 27 Dec 2018 15:05:49 -0800 (PST)
Received: by with SMTP id x85-v6so17397368ljb.2; Thu, 27 Dec 2018 15:05:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gE+7jgWfV0FFXVF21XB7I0In+h3XuQI0hgjR5Hv9OjY=; b=CBOve3DmC8FG8h2wlpcj4gq15BlviE9OWm+u1igYtAKFWIocuJem9z/D6etDPRXtg0 V7NedfFKwvQ7dSYlEoyXG2crxFWxHOZQigax12bpndeEUzbNXP4buZ3m6R3tXawDFyyN FXAEwuufDMEs5VcVgZ2rHuuDAvMFzUtGdI7BjaORO/pdkoXT78KgwWbs6BkJ1QmwpWDp aG/ihV2koYDAO/fW0oAKVpz6wWAkrKY1wGFerzdrr330Ue8wOoK5HWw6QMmVHM3Vlm/n s9YHuq4GR0gEZ3OHqIBPVemqb7LbKzy1GmCguC3pq9IvLs4f4vJK/WbgUEvLeIRHoZLO EReQ==
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=gE+7jgWfV0FFXVF21XB7I0In+h3XuQI0hgjR5Hv9OjY=; b=apemrcZO9ifiOfjT0B5sCunT+5/bm3Uta0rU+Vi6rnCUl/qYTJzySUT2bbZStHobko NM01C+hVGd/3qOOp2v3hKWD2a+opZlAk6KiAaJyVkX6b7/dNo6+7ScwxllQcQlbwnSda ZmGd6NtnBqaCdLP4TH/9CCplqVUKLrGD+Th5KCNLr5FSbrJU+bzN4l/ojBHhA/NgNbLf oAPzTOfnZDeA9IbZr4HgmNAvODjenFiOfuDADyNjVF1Njl68G6p9gH6K1lSilGSIR0iC uSQ0bt1K/GTLimFCWKLNqCVLYhFGENyMWYPSRUJl0SMGpWNI8i4q+biYedufzJG1ndRS oXCQ==
X-Gm-Message-State: AJcUukdHg7C9DGW/9Vze43GNPtjqghuFPR+V/8Dlohdxhg+MhqDEKhPE 7lheDHTuEXpv/YeoGWsDE3tQZnJwsPyd8T1xOSg=
X-Google-Smtp-Source: ALg8bN7kM3PYSyTPiUW8pX/oTItmuk48qCjZiNNxJzte+Zuw7xCHHJ48mMRv3GtJiDyDaid7SI7nMHmm/yKGLCqzMTo=
X-Received: by 2002:a2e:92ca:: with SMTP id k10-v6mr14427338ljh.63.1545951947259; Thu, 27 Dec 2018 15:05:47 -0800 (PST)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Greg Mirsky <>
Date: Thu, 27 Dec 2018 15:05:37 -0800
Message-ID: <>
Subject: Re: Benjamin Kaduk's No Objection on draft-ietf-bfd-multipoint-19: (with COMMENT)
To: Benjamin Kaduk <>
Cc: The IESG <>, "Reshad Rahman (rrahman)" <>,, rtg-bfd WG <>,
Content-Type: multipart/alternative; boundary="000000000000a80252057e08fcef"
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 27 Dec 2018 23:05:56 -0000

Hi Benjamin,
thank you for the comments and suggestions. Please find my answers, notes
in-line and tagged GIM>>. Would you agree I roll them in when working with
the RFC Editor?

Happy New Year to All!


On Fri, Dec 21, 2018 at 7:59 PM Benjamin Kaduk <> wrote:

> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-bfd-multipoint-19: No Objection
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> Please refer to
> for more information about IESG DISCUSS and COMMENT positions.
> The document, along with other ballot positions, can be found here:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> Thank you for addressing my Discuss points!  The original Comment portion
> of my ballot is preserved below for posterity.
> I am told that the normal usage of the bare term "BFD" has the connotation
> of refering only to usages in an IP/UDP/MPLS encapsulation (exclusing
> pseudowires and other more "exotic" encapsulations), so I am not including
> this in my DISCUSS section.  However, it seems unusual to limit the scope
> of a document in some "random" subsection (here, Section 5.8) with no
> mention in the general Introduction or Abstract.  Is there an improvement
> to make here?
GIM>> Will add the following in the Introduction:
This document defines IP/UDP encapsulation of BFD Control message in
multipoint networks. Use of other types of encapsulation of the BFD Control
message are outside the scope of this document.

> Section 4
>    [...] If no
>    BFD Control packets are received by a tail for a detection time, the
>    tail declares the path to having failed.  For some applications this
>    is the only mechanism necessary; the head can remain ignorant of the
>    tails.
> It sounds like this might be better said as "the head can remain ignorant
> of the status of connectivity to the tails"?  (That is, the head needs to
> know at least something about the tails in order to send anything to them,
> so it is not fully ignorant.)
GIM>> Yes, agree. Would imagine that the head would stop sending BFD
control messages if there's no, at least, one tail.
Will update.

>    The head of a multipoint BFD session may wish to be alerted to the
>    tails' connectivity (or lack thereof).  Details of how the head keeps
>    track of tails and how tails alert their connectivity to the head are
>    outside scope of this document and are discussed in
>    [I-D.ietf-bfd-multipoint-active-tail].
> nit: "outside the scope"
GIM>> Thank you.

> Section 5.7
> It's a little unclear to me why tails must demultiplex on the identity of
> the
> multipoint path; (that is, why My Discriminator isinsufficient).
> Presumably this is just a failing on my end, of course.
GIM>> My Discriminator is not globally unique as it is allocated per
MultipointHead. Thus, it is possible, that a tail that belongs to several
multipoint paths, will receive BFD control packets from different heads but
with the same My Discriminator value.

>    [...] Bootstrapping BFD session to multipoint MPLS LSP in
>    case of penultimate hop popping may use control plane, e.g., as
>    described in [I-D.ietf-bess-mvpn-fast-failover], and is outside the
>    scope of this document.
> nit: some articles are missing here; maybe "a BFD session", "in the case
> of", and "the control plane".
GIM>> Thank you, agree to all three.

> Section 5.12.2
>    MultipointTail sessions MAY be destroyed immediately upon leaving Up
>    state, since tail will transmit no packets.
>    Otherwise, MultipointTail sessions SHOULD be maintained as long as
>    BFD Control packets are being received by it (which by definition
>    will indicate that the head is not Up).
> Would it be more clear to say "indicate that the head is not Up yet" to
> distinguish from the case in the first paragraph (where a non-Up state
> *transition*
GIM>> The second paragraph is to explain the behavior of a MultipointTail
if the MultipointHead acts as described in section 5.12.1. Perhaps we can
leave the text as is?

> Section 8
> It may be appropriate to make stronger statements about the weakness of MD5
> than were valid at the time of 5880's publication.  (SHA1 is also not doing
> so great, but I won't block this work on updating the hash function
> options.)
GIM>> Would the following text be acceptable (with both RFCs as
Informational reference):
  Updated Security Considerations for the MD5 Message-Digest and the
   Algorithm [RFC6151] and Security Considerations for the SHA-0 and
   SHA-1 Message-Digest Algorithm [RFC6194] refer to the recent escalating
series of
   attacks on MD5 and SHA-1 as the reason to consider stronger algorithms.

It would be good to either refer to the bit about shared keys in Section 6
> or just move it to this section entirely.
GIM>> Merge sections 6 and 8? Section 7 will be removed in the final text
and these sections become adjacent. Perhaps can leave them as is, would you