[trill] Alvaro Retana's No Objection on draft-ietf-trill-mtu-negotiation-06: (with COMMENT)

Alvaro Retana <aretana@cisco.com> Wed, 05 July 2017 07:33 UTC

Return-Path: <aretana@cisco.com>
X-Original-To: trill@ietf.org
Delivered-To: trill@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F530131A92; Wed, 5 Jul 2017 00:33:01 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Alvaro Retana <aretana@cisco.com>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-trill-mtu-negotiation@ietf.org, trill-chairs@ietf.org, shares@ndzh.com, trill@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.55.2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149923998135.3322.6478212107835480805.idtracker@ietfa.amsl.com>
Date: Wed, 05 Jul 2017 00:33:01 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/trill/H9V7Yx5CAdbrCH9fixMkLf2XueM>
Subject: [trill] Alvaro Retana's No Objection on draft-ietf-trill-mtu-negotiation-06: (with COMMENT)
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.22
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: Wed, 05 Jul 2017 07:33:02 -0000

Alvaro Retana has entered the following ballot position for
draft-ietf-trill-mtu-negotiation-06: No Objection

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.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:


Are there implementations of this optimization?  Have they shown the expected
improvements?  The mechanism seems ok, but the introductory text made we
wonder, specially the part about "*potentially* improving the efficiency of
link utilization and speeding link state convergence."  IOW, if the advantages
are not really know, then maybe a Standards Track document is premature.  I
really don't have a strong opinion, so I'm just wondering at this point.

Some nits:

1. There are some places where rfc2119 language is used that I think is out of
place because it is really just stating a fact or quoting what different
documents say (without actually using quotations); IOW, these are really not
normative statements defined in this document:

- "[RFC6325] describes the way RBridges agree on the campus-wide minimum
acceptable inter-RBridge MTU...all RBridges MUST format their LSPs..."

- "As specified in [RFC8139], RBridges MUST support..."

- "as required by [RFC7780], all RBridges MUST..."

2. From 2.1, these 2 sentences are redundant: "An originatingSNPBufferSize
APPsub-TLV occurring in any other fragment MUST be ignored. An
originatingSNPBufferSize APPsub-TLV occurring in any other fragment is ignored.