Re: [trill] Alexey Melnikov's Discuss on draft-ietf-trill-directory-assist-mechanisms-11: (with DISCUSS)

Donald Eastlake <> Thu, 19 January 2017 05:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 58ACE12940E; Wed, 18 Jan 2017 21:17:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.45
X-Spam-Status: No, score=-2.45 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_LOW=-0.7, SPF_PASS=-0.001] 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 0-B_1R0nFc1U; Wed, 18 Jan 2017 21:17:14 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 28965127071; Wed, 18 Jan 2017 21:17:14 -0800 (PST)
Received: by with SMTP id j13so29652938iod.3; Wed, 18 Jan 2017 21:17:14 -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=YP/aUNKchysR8zZwC8wKd/Gh1OlmjOBYNjULPwBAoNM=; b=Nfy1ejUBeh199xpaeLaGwNCFhWxzAeb83M1N0NyrJnbBaWhPiNFcRkRTVjhLhzkh2w JFxO9wxIAg166FR6zAlmNVA1yqUcPKLvr+gJNglIU/UYBbdL9AEunYNZaS27XzzvAc3v 1T+WAPvN9P8Mdp96kilkjO4HtaqgYfSmTg0uIrVAzabz5aVduWyB5bMpZlfEBtxtzifn oDYGIqkjB70U3gln3kHLG1qYAJCQUoWToM//pxpSzGzdKa1f0EV3d4PWEcNZiRgs+LO2 WeTB8O0+fw+1izDPr34wiyutZA8Dwbt0fv2FB+0wn8Q5PqPaBCVCAOeSZ1yavTob0XJk Pebw==
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=YP/aUNKchysR8zZwC8wKd/Gh1OlmjOBYNjULPwBAoNM=; b=FP5rU9M1Z348l9MFJO2/q+B/Bv76OQkpIrI8Y3WB2bKz9S8TgP0MenDqdutam7TDOh ipvG4mV9XdRyw9T4xulefKjWzfKvwfJvbJuLhxtUUUe9W4+3TQQG/HudCcbJDJ6Aw3ez QNBIOxDcZ8xCJ3JLiFz45A/s5qneGk5OiuIRl6x+EbMt+yCbSmEGAprYK3h2y3bHj23E DN0uTHGp1uyqIp2e0TLmiI5mYJHsDzvmmZwmguptckaQmNVlStUUgn24nN4UpqBFFb4F rRTKhvurXo1xlCMYWhCLkujJ7PTgwOaHlXevJYgA1tgXPXcCBwR24R1okGwIzM0EqLNf yWMw==
X-Gm-Message-State: AIkVDXIp86A5S+85U9qgsQD09PNa9sQjqtbbLZD5H3ZV2jQ23X5fms6sQTwNkSXK7cOhsAuvvhec7ZoQaTwncA==
X-Received: by with SMTP id y90mr6521876ioe.12.1484803033499; Wed, 18 Jan 2017 21:17:13 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Wed, 18 Jan 2017 21:16:58 -0800 (PST)
In-Reply-To: <>
References: <>
From: Donald Eastlake <>
Date: Thu, 19 Jan 2017 00:16:58 -0500
Message-ID: <>
To: Alexey Melnikov <>
Content-Type: text/plain; charset=UTF-8
Archived-At: <>
Cc: "" <>,, The IESG <>, "" <>, "" <>
Subject: Re: [trill] Alexey Melnikov's Discuss on draft-ietf-trill-directory-assist-mechanisms-11: (with DISCUSS)
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Developing a hybrid router/bridge." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 19 Jan 2017 05:17:15 -0000

Hi Alexey,

On Wed, Jan 18, 2017 at 2:14 PM, Alexey Melnikov <> wrote:
> Alexey Melnikov has entered the following ballot position for
> draft-ietf-trill-directory-assist-mechanisms-11: Discuss
> 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.)
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> In Section 3.1 there is a Version field. What are the condition(s) for
> bumping this version number? What backward compatibility guaranties are
> expected (if any)? How would version negotiation be done?

Well, I could say that the answers to all of your questions are about
the same for this Version field as they are for the RBridge Channel
Header version field [RFC7178], the TRILL Header version field
[RFC6325], and many other version fields in IETF protocols but you
probably wouldn't consider that a very good answer.

I suppose if text was being added along this lines, it should say that
the version number must be incremented for a specification that does
not just specify new field values where that is allowed in version
zero but cannot be correctly parsed beyond the version nibble. Since
the protocol is a request/response protocol, the responder should
indicate the highest version number they understand but the response
must be valid in the version number specified in the request including
the possibility of indicating a valid error saying that the version is
not implemented. Thus all implementations of version X would need to
be able to at least send such an error for all versions from 0 through
X-1. Then you would add an explicit suberror code in Section 3.6.3 for
unimplemented version. For a version zero implementation, that would
be returned for any higher version.

However, I don't expect an incremented version number to be needed
anytime soon. Was it your intent with this DISCUSS to get something
like the above added to the draft?

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