Re: [trill] Adam Roach's No Objection on draft-ietf-trill-address-flush-05: (with COMMENT)
Donald Eastlake <d3e3e3@gmail.com> Thu, 15 March 2018 00:31 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 42D6512D77E; Wed, 14 Mar 2018 17:31:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.348
X-Spam-Level:
X-Spam-Status: No, score=-0.348 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_NONE=-0.0001, SPF_PASS=-0.001, T_HTML_ATTACH=0.01] 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 UCG-qPLU4JKk; Wed, 14 Mar 2018 17:31:42 -0700 (PDT)
Received: from mail-it0-x242.google.com (mail-it0-x242.google.com [IPv6:2607:f8b0:4001:c0b::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 B73FB12D77B; Wed, 14 Mar 2018 17:31:38 -0700 (PDT)
Received: by mail-it0-x242.google.com with SMTP id w63-v6so6873216ita.3; Wed, 14 Mar 2018 17:31:38 -0700 (PDT)
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=e5XPICXfvJj9ve6ZHPgNUx0LGUQZgh1r9VkgFvxDPtY=; b=RD+W/DPeFbZPW10jr8gni8kiYv8AwicHQkcuZXd/duyriRDVMYHwrf3wtGsFbeA3uR Y+nB7G7w0GdtryoEg4/AdQy5lOkWJVsOijyKXdShUfo3vHkAScYnYxYyKN/K0gzPSiYr j1LFKMa/DTOY4jiTsMwDB31narLzqF0tpvFqbuLki3G0SxCMn0ar03vqjmNjNF3gHIQY 4+axEF9FYsNXtWtIICPdO4K40Qhj79wvaXqfxhTKAiC0LiLHh8P01JHoBQ47sre3X5BO jkgtPLvOjNEPsaNz6wnDacYQLRe8WsHfqvWdTNlVK4RLFyVcB0ktreuAc2ol18B9W/jg gRUA==
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=e5XPICXfvJj9ve6ZHPgNUx0LGUQZgh1r9VkgFvxDPtY=; b=Hb5R3MhsPG894NqMXyN+V4UETIMMivUE5m/eAXJQqAArbd77uG1MVR9epxlexBOiTP 6nLRzCuyAmErmA3uIhowxqbNlPU7igMPidYP1Ku8oqswpfcyq8E478a72QRg+cS2qdBq AE65rjswtoPJGltuPqhFDdM+go3G68HIW2NwJ11UyhDi+f/TclLRI+CPS34/9gu3Qccv vPZLCapXgb7XLMpXeN3TIPq1f289Wpv7KY7ak09LLvXXyEaEM7mPsGK562coj4rR70Bu yWoRQx7OGmvV4UvxhC2CQ+krB8YnQlggI3jvIciOhkX5tRVkMVYZx4hBzraRC0/63QMX eDuQ==
X-Gm-Message-State: AElRT7E61o8W/+/4iLaXrC2+DGVxvEyQuGguqTJZlwp84ukYAxMIRmq8 LGwzhaHbRqQMuDyV0mR0wK+NCM9BT8ytJTD5PIA=
X-Google-Smtp-Source: AG47ELsPjWFVMaTxjkSRzDr+YeZnpN2jrQfpaBt+CP6x6H2NZGnuyIYmqRMb+3G3JJzT3Mu3T9Tl6L8s7mUmfLnJ9z8=
X-Received: by 2002:a24:108c:: with SMTP id 134-v6mr4016098ity.94.1521073897791; Wed, 14 Mar 2018 17:31:37 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.58.193 with HTTP; Wed, 14 Mar 2018 17:31:22 -0700 (PDT)
In-Reply-To: <CAF4+nEEiwzzhKfRcciqx-40acD0Fge7GOK36miyh7psXM0k_fg@mail.gmail.com>
References: <151806425843.17204.5605050960821568285.idtracker@ietfa.amsl.com> <CAF4+nEEiwzzhKfRcciqx-40acD0Fge7GOK36miyh7psXM0k_fg@mail.gmail.com>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Wed, 14 Mar 2018 20:31:22 -0400
Message-ID: <CAF4+nEFOH2qC_xPtQygYLDb9Avbf12wUKhC=zghJwK-Y9CiHrA@mail.gmail.com>
To: Adam Roach <adam@nostrum.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 mailing list <trill@ietf.org>
Content-Type: multipart/mixed; boundary="0000000000005b23730567689d23"
Archived-At: <https://mailarchive.ietf.org/arch/msg/trill/KFG0N3C3aLdjovhMFSf1Evf5rIE>
Subject: Re: [trill] Adam Roach'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, 15 Mar 2018 00:31:48 -0000
Hi Adam, 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? Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com On Fri, Feb 9, 2018 at 11:42 AM, Donald Eastlake <d3e3e3@gmail.com> wrote: > Hi Adam, > > On Wed, Feb 7, 2018 at 11:30 PM, Adam Roach <adam@nostrum.com> wrote: >> Adam Roach has entered the following ballot position for >> draft-ietf-trill-address-flush-05: No Objection >> >> ... >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> Thanks to everyone who contributed to writing this document. >> >> I'm concerned that the interaction between the various extensible Address Flush >> message TLVs isn't very clearly spelled out. As far as I can tell, the text that >> attempts to describe the interactions is: >> >>> If the set of MAC addresses accumulated from parsing the address >>> flush message is null, the message applies to all MAC addresses. >>> If the flag indicating the presence of an All Data Labels TLV is >>> true, then the address flush message applies to all Data Labels and >>> the set of Data Labels and block of Data labels specified has no >>> effect. If the flag indicating the presence of an All Data Labels TLV >>> is false, then the address flush messages applies only to the set of >>> Data Labels accumulated from parsing the message; if that set is >>> null, the address flush message does nothing. > > The TLVs are all parsed accumulated a possibly null set of Data > Labels, an "All Data Labels flag", and a possibly null set of MAC > addresses. > >> Based on this (and the fact that their implementation is optional), I infer >> that the MAC address TLVs are intended to further restrict the addresses >> indicated by TLV types 1 through 5, rather than expand upon them. > > That's right. > >> I'm less >> sure about whether they have any impact on Type 6. I would expect that they >> do, but the text above ("applies to all Data Labels") kind of sounds like they >> don't. > > Type 6 only affects the Data Labels that are being flushed. It has no > effect on the set of MAC addresses which set defaults to "all". > >> What would seem to make sense here (inasmuch as it provides maximal flexibility) >> is: >> >> if (TLV7 ∪ TLV8 = {}) >> Addresses to Flush = (TLV1 ∪ TLV2 ∪ TLV3 ∪ TLV4 ∪ TLV5 ∪ TLV6) >> else >> Addresses to Flush = (TLV1 ∪ TLV2 ∪ TLV3 ∪ TLV4 ∪ TLV5 ∪ TLV6) ∩ (TLV7 ∪ TLV8) > > That's correct but not complete. If the set of Data Labels indicated > by any of TLV1 though TLV5 that are present is null, the the Address > Flush applies to the Data Label after the TRILL Header and Inner MAC > addresses. It also seems quite confusing to have TLV7 and 8 as if they > were the same sort of thing as the other TLVs when they are MAC > addresses and the others all relate to . > > Every entry that is flushed consists of a nickname, a Data Label, and > a MAC address. Nicknames are handled the same way for both the VLAN > Block only case and the extensible case. The complete set of entries > that is flushed is the cross product of a set of nicknames, a set of > Data Labels, and a set of MAC addresses, where the set of Data Labels > and/or MAC addresses can be "all". > >> If that's the intention, I think the normative explanation needs to be clearer. >> If that's not the intention, I sill think the normative explanation needs to be >> clearer. > > We'll see what we can do to clarify. > >> My remaining comments are editorial. >> --------------------------------------------------------------------------- > > I'm fine with the changes below and have provided and explanation of "RB1". > > Thanks, > Donald > =============================== > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@gmail.com > >> Please expand the following acronyms upon first use and in the title; >> see https://www.rfc-editor.org/materials/abbrev.expansion.txt for guidance. >> >> - TRILL >> - TC >> - TCN >> - MSTP >> >> While the following terms are defined in cited documents, you may wish to also >> consider expanding them in this document's acronym list for the convenience of >> the reader: >> >> - MAC >> - FCS >> >> Finally, please explain the use of "RB1" in the Introduction. > > It's use in this case is pretty much non-existent... :-) A typical > style in TRILL document is to say "A TRILL switch RB1 ..." Then later > you can just reference RB1 rather than having to talk about it in some > more complex say. (Usually there is also an RB2, RB3, ... but not > always.) Since the "RB1" is never referenced again in this case, it > can just be deleted. > >> --------------------------------------------------------------------------- >> >> §1: >> >>> Another example is based on Appendix A.3 of [RFC6325] ("Wiring Closet >>> Topology") presents a bridged LAN connected to a TRILL network via >>> multiple RBridge ports. >> >> This should be either: >> >> Another example, based on Appendix A.3 of [RFC6325] ("Wiring Closet >> Topology"), presents a bridged LAN connected to a TRILL network via >> multiple RBridge ports. >> >> or... >> >> Another example is based on Appendix A.3 of [RFC6325] ("Wiring Closet >> Topology"), which presents a bridged LAN connected to a TRILL network >> via multiple RBridge ports. >> >> --------------------------------------------------------------------------- >> >> §1.1: >> >>> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", >>> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this >>> document are to be interpreted as described in [RFC2119]. >> >> This document makes use of lowercase versions of these terms as well; please >> consider using the RFC 8174 boilerplate. >> >> --------------------------------------------------------------------------- >> >> §2.2: >> >>> VLANs/FGLs if it occurs in any TLV in the address flush message. A >>> MAC addresses might be indicated more than once due to overlapping >> >> "A MAC address..." or "MAC addresses..." >> >> >> --------------------------------------------------------------------------- >> >> §2.2: >> >>> MAC addresses if it occurs in any TLV in the address flush message. >>> If the set of MAC addresses accumulated from parsing the address >>> flush message is null, the message applies to all MAC addresses. >>> If the flag indicating the presence of an All Data Labels TLV is >>> true, then the address flush message applies to all Data Labels and >> >> The staggered indenting here looks a bit odd. Were these intended to be a >> bulleted list?
- [trill] Adam Roach's No Objection on draft-ietf-t… Adam Roach
- Re: [trill] Adam Roach's No Objection on draft-ie… Donald Eastlake
- Re: [trill] Adam Roach's No Objection on draft-ie… Donald Eastlake