[trill] Alvaro Retana's Discuss on draft-ietf-trill-smart-endnodes-10: (with DISCUSS)

Alvaro Retana <aretana.ietf@gmail.com> Mon, 05 March 2018 21:34 UTC

Return-Path: <aretana.ietf@gmail.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 B42A7126DC2; Mon, 5 Mar 2018 13:34:26 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Alvaro Retana <aretana.ietf@gmail.com>
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-trill-smart-endnodes@ietf.org, trill-chairs@ietf.org, shares@ndzh.com, trill@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.74.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <152028566673.31723.3025539385493024777.idtracker@ietfa.amsl.com>
Date: Mon, 05 Mar 2018 13:34:26 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/trill/xiJbdtx94Joos1JKJfBNydfPqJk>
Subject: [trill] Alvaro Retana's Discuss on draft-ietf-trill-smart-endnodes-10: (with DISCUSS)
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: Mon, 05 Mar 2018 21:34:27 -0000

Alvaro Retana has entered the following ballot position for
draft-ietf-trill-smart-endnodes-10: 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.)

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:


This document feels tightly coupled with
draft-ietf-trill-directory-assisted-encap, even though there are no
cross-references.  If I understand the mechanisms correctly, a Smart Endnode
(discussed in this draft) can then do directory assisted encapsulation
(described in draft-ietf-trill-directory-assisted-encap).  In fact, the
encapsulation/decapsulation seems to be the main motivation in defining a Smart

I think then that this document also falls short in the exploration of
potential issues, so I am also balloting DISCUSS.  The same cases that I
pointed at for draft-ietf-trill-directory-assisted-encap [1] are applicable
here -- with the added caveat that the Smart Endnode, in general, has other
sources of information (learning, etc.), which means that there are potentially
more doors to close.

The Multi-homing Scenario (Section 6) adds some complexity to the ability to
check whether the Ingress RBridge is set correctly in the encapsulation.  It
would be nice to explore this case a little further and highlight the issues as
the topologies get more complex.

As I wrote in [1], I don't think that there are easy mitigations for these
issues, but at least mentioning them so that operators are aware of the risk
would be enough to clear this DISCUSS.  Given that the authors partially
overlap, it may be a good idea to solve the issue in this document (which is
the general case) and then just have the other one point this way.