Re: [trill] Alvaro Retana's No Objection on draft-ietf-trill-address-flush-05: (with COMMENT)

Donald Eastlake <> Thu, 15 March 2018 00:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1D25212D7E5; Wed, 14 Mar 2018 17:32:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.048
X-Spam-Status: No, score=-1.048 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_COMMENT_SAVED_URL=1.391, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_HTML_ATTACH=0.01] 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 4Bmlj2Au-7ib; Wed, 14 Mar 2018 17:32:44 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c0b::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D55AA12D77E; Wed, 14 Mar 2018 17:32:43 -0700 (PDT)
Received: by with SMTP id d13-v6so6894329itf.0; Wed, 14 Mar 2018 17:32:43 -0700 (PDT)
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=wA7N6vIgMgeW2Ma0I9JwKfpDAzNEcrpQhUxWUz7gStU=; b=MW1afWZ3tXFtjCS2Rqh7HlmYeH2/g29VRZfaOq2VlR1w56vPmsxOoI19ZWQl8Gm/p6 6CMZyFpwlatmy5DfwhKRJ81q2Uc9BIIqI0wFL57E/B2l4iWGJLwp116UXCWWPDzDtbuL BAL81IQ2JcJIz30/W/4PTljOhKhBlIgPpWaHXre8eoAe2LBynKw2SJnbjbsklcySPmcs uASm7f4RrqRiZEGsGAwP28OBrdv4k8wnBcyQvBWfRJ7kJXsvso/NidlXRH1EGTk4zeR2 UyA2Iey812tN/CcFqPak4HUyFEcJjfMIkISbHDOypWhi8Ii+W0PODEjbachfpnw1Wlr0 OX2w==
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=wA7N6vIgMgeW2Ma0I9JwKfpDAzNEcrpQhUxWUz7gStU=; b=jqED3g1bsh7A6PLdgrFSxAtpu9dRf8d3PIWfVU+rcs6GABVH0uRxKhX7squhFYWK7+ dJhiFGEmc4hQLrV5JcCYFbqqwEbA47YOGHKhEJ1Ot4FcOQyAI7Anre6gYGkIXGWLx3Oi aR2mSQpK3wiQFZiEWlOXKWVAS2+6QJeH5l98dL/bB7QrJ0SAT7MvtIF/XxNlA0AVU7kM Qm34HViTNEtUjfqdXLJ2K7YOfSNxxkiFbR6/O3kZYUme28ekas83B3HHy+H2HhEy7mXg nkuq5ZZGezSAfZFijgFrHFoSqNM9pAQpVoh410Svg536HLqXiNeg4IgIU28c4mZpMzXM vS/w==
X-Gm-Message-State: AElRT7GYLOUDq7Sg9PMdH3LvotUtVac30bhAV/0rD4nbwZGtUfz+VQps W7RKi+SDXEIW6bBmutBIteGz/+5VAY9Clu9C2Rg=
X-Google-Smtp-Source: AG47ELtxW5kkX3IQZeKUJX/m+aLCMdpc4OjCSN2avNqr3NO7zTg/nu0xZxtIgoGyoVC/ySrdhX6iP7viGhrMOXswUyY=
X-Received: by 2002:a24:108c:: with SMTP id 134-v6mr4018329ity.94.1521073963079; Wed, 14 Mar 2018 17:32:43 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 14 Mar 2018 17:32:27 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: Donald Eastlake <>
Date: Wed, 14 Mar 2018 20:32:27 -0400
Message-ID: <>
To: Alvaro Retana <>
Cc: The IESG <>,, Susan Hares <>,, trill IETF mailing list <>
Content-Type: multipart/mixed; boundary="0000000000003f68c5056768a1e7"
Archived-At: <>
Subject: Re: [trill] Alvaro Retana's No Objection on draft-ietf-trill-address-flush-05: (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, 15 Mar 2018 00:32:52 -0000

Hi Alvaro,

Attached is a candidate -06 version of draft-ietf-trill-address-flush
(my internal version 39) intended to resolve your comments. Also
attached is a diff against the currently posted -05. Can you take a
looks and see if your comments are satisfied?

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

On Thu, Feb 8, 2018 at 11:39 AM, Donald Eastlake <> wrote:
> Hi Alvaro,
> On Wed, Feb 7, 2018 at 12:28 PM, Alvaro Retana <> wrote:
>> Alvaro Retana has entered the following ballot position for
>> draft-ietf-trill-address-flush-05: No Objection
>> ...
>> ----------------------------------------------------------------------
>> ----------------------------------------------------------------------
>> I have some non-blocking comments/questions:
>> (1) Why are the 2 VLAN Block encodings needed?  More important, when should
>> each be used?  Section 2.2 says that "All RBridges implementing the Address
>> Flush RBridge Channel message MUST implement types 1 and 2, the VLAN types...",
>> but I didn't see anything about the VLAN Block Only Case (2.1).  I'm wondering
>> if there will be cases where the support won't match and the message will then
>> be ineffective.
> I suppose some wording could be added but the idea is that the VLAN
> Block Only Case is part of the basic message and always has to be
> implemented, as opposed to the extensible list of TLV types. The
> message is structured so that you can't use both the VLAN Block Only
> Case and the extensible TLV structure to specify VLANs at the same
> time. The VLAN Block Only Case is expected to be common and
> corresponds more closely to deployed code.
>> (2) In the 2.2.* sections, the description of some of the TLVs says (when the
>> Length is incorrect) that "...the Address Flush message MUST be discarded if
>> the receiving RBridge implements Type x".  What if that type is not supported
>> -- I would assume you still want to discard?  BTW, the Type 5 description
>> doesn't qualify dropping based on the type support.
> If the Type is not implemented, then how would you know that the
> length is not valid? How would you currently code a length validity
> check for types to be specified in the future as part of the
> extensibility of the message? But, since there is a length field, you
> can always skip over a TLV you don't understand. The qualification
> based on type support should be there for Type 5 also. (Of course, in
> the real world, I think inconsistent Address Flush message type
> support in a TRILL campus will be very rare.)
>> (2a) Other descriptions (type 1,2,6) just talk about ignoring (not discarding).
>>  Is there an intended difference in the behavior?
> There is no intended difference between "ignoring" and "discarding" an
> Address Flush message. (Types 1, 2, and 6 are the mandatory to support
> types so there is no conditional on support.)
>> (3) Section 2 says that "Address Flush protocol messages are usually sent as
>> multi-destination packets...Such messages SHOULD be sent at priority 6".  It is
>> not clear to me whether unicast packets (mentioned later) should also have the
>> same priority.
> Yes, probably throwing in "including unicast Address Flush messages"
> would clarify.
> Thanks,
> Donald
> ===============================
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  155 Beaver Street, Milford, MA 01757 USA