[trill] Eric Rescorla's No Objection on draft-ietf-trill-directory-assisted-encap-10: (with COMMENT)

Eric Rescorla <ekr@rtfm.com> Thu, 08 March 2018 04:41 UTC

Return-Path: <ekr@rtfm.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 D334A1201FA; Wed, 7 Mar 2018 20:41:58 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Eric Rescorla <ekr@rtfm.com>
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-trill-directory-assisted-encap@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: <152048411881.21355.2781874496381601721.idtracker@ietfa.amsl.com>
Date: Wed, 07 Mar 2018 20:41:58 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/trill/YizFOfCnPBBb8wc3CXZqnk7wuJY>
Subject: [trill] Eric Rescorla's No Objection on draft-ietf-trill-directory-assisted-encap-10: (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: Thu, 08 Mar 2018 04:41:59 -0000

Eric Rescorla has entered the following ballot position for
draft-ietf-trill-directory-assisted-encap-10: 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:
https://datatracker.ietf.org/doc/draft-ietf-trill-directory-assisted-encap/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I support Alvaro's DISCUSS and Kathleen's comment

I also think it would be useful to emphasize the need for some security on the
links between the egress and ingress nodes, although presumably that's a
standard TRILL consideration.

Finally
      nodes. Such spoofing cannot cause looping traffic because TRILL has a
     hop count in the TRILL header [RFC6325] so that, should there be a
      loop, a TRILL packet caught in that loop (i.e., an encapsulated
      frame) will be discarded.

Is it in fact the case that it cannot cause looping or merely that the loop is
contained by the hop count? Perhaps this is just a terminology issue and in
routing loop just means infinite loop?