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?
- Benjamin Kaduk's No Objection on draft-ietf-bfd-m… Benjamin Kaduk
- Re: Benjamin Kaduk's No Objection on draft-ietf-b… Greg Mirsky