Re: [trill] Alvaro Retana's No Objection on draft-ietf-trill-p2mp-bfd-08: (with COMMENT)

Donald Eastlake <> Thu, 25 January 2018 04:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 90FBB12E858; Wed, 24 Jan 2018 20:23:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xitOju82ETgj; Wed, 24 Jan 2018 20:23:15 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4003:c0f::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1351912E6A3; Wed, 24 Jan 2018 20:23:15 -0800 (PST)
Received: by with SMTP id p36so5637227otd.10; Wed, 24 Jan 2018 20:23:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=V1J8SdNiISD4OB9+SupWJ13MS4Yc+oIx6YZhc7De5oI=; b=S3T7Us2x7LYHRlVpLbdkKPoYkrxLxb2BtWtWY0mo0zdBJJV/Oz6HH1h+gSzPW9jqke znx/UNW4NenQ14hXNNddvUCR2AlzLOlJ7Ie8EzJKtBAOO1f99CgLrom/ZkIOaYc5yKwC WttI5/U/sfM8mtlL/eRImuQlVeZztOX0qCQk9SAuR1ZFWkHAlk0SBKw758OKTO7Dofti rTkKt8QZts3pghI4oeHMghCcTEI6b6gpDfmB5wdlixLQKBNBvJPJvHPZc/QTCcxjVgaA D3NNWFO56NGU/y8YjMoOflI3UiCemWr13HSBHgGy/AesPBNsX/F8dlsVyuGQ/Lp8wCqh +iNg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=V1J8SdNiISD4OB9+SupWJ13MS4Yc+oIx6YZhc7De5oI=; b=BW21DdUka5wXptPNpZf2iJZIwO2lM4B7slj6wgWzfozl0VPt8vlbMNUjJz/nJvm6QZ GBsy72vmjiAK71qY9EglR1VdD0QqOop0ohztKzvGFZLSSOus6AlfFIB1oQ/Vt5pG38Et +jGLJHTvEkBOOn+Q6ehB7sv4SS/0VRIS13X45QhCNkkUsrzYG3JPu+hTwov3UnJFZfsR oyuagUQpS5sPR+f+I+kb3tzQaWozckfXpwWydIlUsE1QWTc5za8N51MzowQsr0iBF+B4 Qe/Qi7CQIefnK6ALwZ2JN1gp/NYah0htHwFprIaiaxjjX6ZjtaZ9L/olAnX6Udx0hoOZ ppzA==
X-Gm-Message-State: AKwxytffMjO0xPr2I1zGYfpCkNO+XZ27Cc9fDwjdxATdrsUp3tUBvAkf nU8MWhKOQoHNRCVMpv/2DZAO6f/A0hWb7o92k3I=
X-Google-Smtp-Source: AH8x225aYckeLsgs6xzD8i0Ush/uyXOKMGOGbPOFVy2HUlqWFdm1N1c3ZNE4s5r5xU0wR07yX/5OSN1K0eT30KQIfIo=
X-Received: by with SMTP id t12mr10496703otf.135.1516854194363; Wed, 24 Jan 2018 20:23:14 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Wed, 24 Jan 2018 20:22:58 -0800 (PST)
In-Reply-To: <>
References: <>
From: Donald Eastlake <>
Date: Wed, 24 Jan 2018 23:22:58 -0500
Message-ID: <>
To: Alvaro Retana <>
Cc: The IESG <>,,, Susan Hares <>,
Content-Type: multipart/alternative; boundary="94eb2c1929b86e627e05639223fe"
Archived-At: <>
Subject: Re: [trill] Alvaro Retana's No Objection on draft-ietf-trill-p2mp-bfd-08: (with COMMENT)
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Developing a hybrid router/bridge." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 25 Jan 2018 04:23:16 -0000

Hi Alvaro,

On Tue, Jan 23, 2018 at 10:45 AM, Alvaro Retana <>

> Alvaro Retana has entered the following ballot position for
> draft-ietf-trill-p2mp-bfd-08: No Objection
> ...
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> (1) The first reference to I-D.ietf-bfd-multipoint appears in Section 5;
> please
> add one in the Introduction when Multipoint BFD is initially mentioned.

Sounds reasonable.

> (2) I think that using Normative Language (without quotation marks) to
> mention
> what is specified somewhere else can result in confusion as to which is the
> authoritative document.  This seems to be the case in Section 4: "If the M
> bit
> of the TRILL Header of the RBridge channel packet containing a BFD Control
> packet is non-zero, the packet MUST be dropped [RFC7175]."  The sentence
> sounds
> as if the behavior is specified in rfc7175, but that document says (in
> Section
> 3.2 (BFD Control Frame Processing)): "The following tests SHOULD be
> performed...Is the M bit in the TRILL Header non-zero?  If so, discard the
> frame."  Note that the behavior specified in rfc7175 doesn't use a
> "MUST".  The
> text in this document seems to be used to explain why a new message is
> needed,
> and not in a Normative way -- please clarify the text so that there is no
> inconsistency with respect to rfc7175.

I think it can be re-worded fairly easily to avoid being normative.

> (3) Section 5 says that the "processing in Section 3.2 of [RFC7175]
> applies...If the M bit is zero, the packet is discarded."  Section 3.2 has
> that
> "SHOULD" that I mentioned above, and it also mentions potential security
> issues, which are not referenced in this document.  Are there reasons to
> keep
> the "SHOULD" and not use "MUST" instead (for the p2mp case)?  If the same
> semantics as in rfc7175 are kept, then the Security Considerations should
> include the concerns.

I'm pretty sure this was supposed to imply MUST given the inconsistency
with reference to Section 4 as above. The wording is unconditional. It
appears from your point (2) above that the authors were thinking that, in
RFC 7175, the discard if the M bit was "wrong" was a MUST. So I think it
can be changed to use MUST in this draft and that would avoid having to
tweak the Security Considerations.

 Donald E. Eastlake 3rd   +1-508-333-2270 <(508)%20333-2270> (cell)
 155 Beaver Street, Milford, MA 01757 USA