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

Donald Eastlake <d3e3e3@gmail.com> Thu, 08 February 2018 16:39 UTC

Return-Path: <d3e3e3@gmail.com>
X-Original-To: trill@ietfa.amsl.com
Delivered-To: trill@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 981B612D7EF; Thu, 8 Feb 2018 08:39:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.75
X-Spam-Level:
X-Spam-Status: No, score=-1.75 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 AtVkxyHNn034; Thu, 8 Feb 2018 08:39:28 -0800 (PST)
Received: from mail-ot0-x242.google.com (mail-ot0-x242.google.com [IPv6:2607:f8b0:4003:c0f::242]) (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 003BD12D7ED; Thu, 8 Feb 2018 08:39:27 -0800 (PST)
Received: by mail-ot0-x242.google.com with SMTP id 73so4878108oti.12; Thu, 08 Feb 2018 08:39:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=t9n+VxZjzLwF/l/suprFQib5A2Ps+H0cMxyuQPu+1pM=; b=atioB46/yOiOi9HwzoUJvYBjUnDdEgMH3LQ/bGJ+KkCtDd6oMKLVIXsIU62MrtWagw VDxem1Uz27yfAjEuxUtOeMGc9rB0hhKM6z5ufm80Vckk6qqXVM1BXGU660r1Crq7kytc lKNvZeSjHu/GwABYA+nknr2W5COQksS7UOgF20whEJ49n5Fs0lybBzjpt+u3QJAJB2Rp PS2sqb/VeFyR9Xrc+iXYfKmPf6elEDGdYakuBzmX1F01Izf1l8W6f/IfSrS2DIns9OQK w00ydcQCS1idoCI8+LsqvBTvGKLjIeOmLxgB2wwuTeBp2KIqKM4lrd7gVwFFL2LZf6IE cexg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=t9n+VxZjzLwF/l/suprFQib5A2Ps+H0cMxyuQPu+1pM=; b=fGD/EFmMeMgyJhywOcdBWsJwSFvY1wNj3iSv6Av6qmlDsNlp3S3hZdQGnagEZcOlB7 NcNd14vfYxoXq0FYFNBpNpOlRb0+74uxgnFZ1Djswove0Ho7JtxT2YGDPnkId6jDdIfq p19o1i8A2AVYLDUhezO3hzk92F7I7v6CAgnwor8g5eMyMHGvyvzi38F437HzieaGB9gM RNb+etvbL4YyJDdQc66lNWZ8uQP3knLHE08+eBJu9W1dMI/Blin8I5iAtd8rL494Cmtv U+OHzzz2xnvzVN+pgxisGjA+hucctZXR9YmjpffQvUYr5mqv+kCM0ZsEBl/X4WRYA5QE c/1A==
X-Gm-Message-State: APf1xPA6B7O4adoVFQYjQsA4TlLcLSJKfI0SqGQABKZq5bfPDiAmCNs0 o0vaQMDZtQQPfaSpjNodUk0Df6nMb38LJfmj3LM=
X-Google-Smtp-Source: AH8x226uWD1PorNjmDo9m2bu/LPELnnY0QWk5aEqiQUyWopwdj9Io9JLBrQlMuxIT02AVbdYZ7rje9sHdQa1vCEkS2U=
X-Received: by 10.157.17.171 with SMTP id v40mr1024254otf.287.1518107967190; Thu, 08 Feb 2018 08:39:27 -0800 (PST)
MIME-Version: 1.0
Received: by 10.168.67.205 with HTTP; Thu, 8 Feb 2018 08:39:11 -0800 (PST)
In-Reply-To: <151802452668.4857.14724101557577914249.idtracker@ietfa.amsl.com>
References: <151802452668.4857.14724101557577914249.idtracker@ietfa.amsl.com>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Thu, 8 Feb 2018 11:39:11 -0500
Message-ID: <CAF4+nEHTKpt5SaLwcRD7gUpa0=8kETY2DaOaRwGKRZ1KbOV3fw@mail.gmail.com>
To: Alvaro Retana <aretana.ietf@gmail.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-trill-address-flush@ietf.org, Susan Hares <shares@ndzh.com>, trill-chairs@ietf.org, trill@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/trill/XfY_YgiE4NLe2wZQuA2JCvUVzx8>
Subject: Re: [trill] Alvaro Retana's No Objection on draft-ietf-trill-address-flush-05: (with COMMENT)
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Developing a hybrid router/bridge." <trill.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trill>, <mailto:trill-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/trill/>
List-Post: <mailto:trill@ietf.org>
List-Help: <mailto:trill-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trill>, <mailto:trill-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Feb 2018 16:39:29 -0000

Hi Alvaro,

On Wed, Feb 7, 2018 at 12:28 PM, Alvaro Retana <aretana.ietf@gmail.com> wrote:
> Alvaro Retana has entered the following ballot position for
> draft-ietf-trill-address-flush-05: No Objection
>
> ...
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> 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
 d3e3e3@gmail.com