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

Greg Mirsky <gregimirsky@gmail.com> Thu, 27 December 2018 23:05 UTC

Return-Path: <gregimirsky@gmail.com>
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 A00CE130E9D; Thu, 27 Dec 2018 15:05:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
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: 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 NGLV3NQay5WT; Thu, 27 Dec 2018 15:05:52 -0800 (PST)
Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (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 47C021294D0; Thu, 27 Dec 2018 15:05:49 -0800 (PST)
Received: by mail-lj1-x22f.google.com 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; d=gmail.com; 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; d=1e100.net; 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: <154545115049.20244.825410624604585914.idtracker@ietfa.amsl.com>
In-Reply-To: <154545115049.20244.825410624604585914.idtracker@ietfa.amsl.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Thu, 27 Dec 2018 15:05:37 -0800
Message-ID: <CA+RyBmX_5fE3bSXQYP-8POqomQaQRCQy+43i_FbLKj1FFwYpVQ@mail.gmail.com>
Subject: Re: Benjamin Kaduk's No Objection on draft-ietf-bfd-multipoint-19: (with COMMENT)
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: The IESG <iesg@ietf.org>, "Reshad Rahman (rrahman)" <rrahman@cisco.com>, draft-ietf-bfd-multipoint@ietf.org, rtg-bfd WG <rtg-bfd@ietf.org>, bfd-chairs@ietf.org
Content-Type: multipart/alternative; boundary="000000000000a80252057e08fcef"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/WGv9nwBo00csTo1S5EQa7N2HfYw>
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: 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!

Regards,
Greg

On Fri, Dec 21, 2018 at 7:59 PM Benjamin Kaduk <kaduk@mit.edu> 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 https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> 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
HMAC-MD5
   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
agree?