[trill] Benjamin Kaduk's practice ballot (No Objection) on draft-ietf-trill-directory-assisted-encap-10 (with COMMENT)

Benjamin Kaduk <kaduk@mit.edu> Wed, 07 March 2018 17:04 UTC

Return-Path: <kaduk@mit.edu>
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 E682812D94A; Wed, 7 Mar 2018 09:04:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.23
X-Spam-Level:
X-Spam-Status: No, score=-4.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 dqQU7UkQXB6d; Wed, 7 Mar 2018 09:04:20 -0800 (PST)
Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 754F3126D45; Wed, 7 Mar 2018 09:04:19 -0800 (PST)
X-AuditID: 12074424-8d1ff70000003673-6e-5aa01b9052ac
Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 5C.18.13939.19B10AA5; Wed, 7 Mar 2018 12:04:17 -0500 (EST)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id w27H4Cew002385; Wed, 7 Mar 2018 12:04:13 -0500
Received: from mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w27H47iJ010276 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 7 Mar 2018 12:04:10 -0500
Date: Wed, 7 Mar 2018 11:04:07 -0600
From: Benjamin Kaduk <kaduk@mit.edu>
To: The IESG <iesg@ietf.org>
Cc: trill-chairs@ietf.org, trill@ietf.org, shares@ndzh.com, draft-ietf-trill-directory-assisted-encap@ietf.org
Message-ID: <20180307170407.GQ27850@mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.9.1 (2017-09-22)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLIsWRmVeSWpSXmKPExsUixG6nrjtRekGUwbZtRhZnF9pYzPgzkdni z5tXLBY/T1xmtng/eTubA6vHkiU/mTxmv77OGsAUxWWTkpqTWZZapG+XwJXx8OctloJnEhWT 2u4wNzCeE+5i5OSQEDCR2Pj2KmsXIxeHkMBiJokdy1ayQDgbGCWe9bcwQzhnmCTm7TjOBNLC IqAicWz7fmYQmw3Ibui+DGaLCMhIfGmfAmYzC5RL9O9dzQ5iCwtUSlya/AAsziugI/Fs3x0W CFtQ4uTMJywQ9VoSN/69BJrPAWRLSyz/xwESFhVQltjbd4h9AiPfLCQds5B0zELoWMDIvIpR NiW3Sjc3MTOnODVZtzg5MS8vtUjXXC83s0QvNaV0EyM4JF1UdjB293gfYhTgYFTi4ZX4Mz9K iDWxrLgy9xCjJAeTkijvaqYFUUJ8SfkplRmJxRnxRaU5qcWHGCU4mJVEeJ+AlPOmJFZWpRbl w6SkOViUxHk9TLSjhATSE0tSs1NTC1KLYLIyHBxKErwVUkBDBYtS01Mr0jJzShDSTBycIMN5 gIY3gtTwFhck5hZnpkPkTzHqctx48bqNWYglLz8vVUqc95MkUJEASFFGaR7cHFAqkcjeX/OK URzoLWHeiSCjeIBpCG7SK6AlTEBLzt+dA7KkJBEhJdXAuOfqM7mrrT0l7FH+eckFtyY//+Fu a+p6z3f223sxk1pPvE1UeBSz8ji33ea7ngb6XsLXN5q9Yz70qHpSbNOxmuQDiZ8/qpeYHs9d 2trG3/Xo1w/PlSvk9bZZ2544OKfuUdAiW5/62+vEzk7wnN3dJXJqcuzam2c1TWdkZNp71n3U PNCU8NX9qRJLcUaioRZzUXEiAN8K9S8AAwAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/trill/QsAJRsl_1T5NhLR8-Dzd90zp43w>
Subject: [trill] Benjamin Kaduk's practice ballot (No Objection) on draft-ietf-trill-directory-assisted-encap-10 (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: Wed, 07 Mar 2018 17:04:22 -0000

[incoming AD ramping up on document review; please treat as No
Objection with COMMENT]


RBridge is not defined in the document and it looks like only
"RBridge Channel" is marked as "well-known" in
https://www.rfc-editor.org/materials/abbrev.expansion.txt (but not
"RBridge" itself); perhaps I am misreading that page.


The qualitative differences in behavior between the cases where the
directory is known to (not) be complete seem worth mentioning in the
Introduction.  Maybe something like:

    When the directory is known to be complete, additional efficiency
    gains are possible: TRILL-ENs can drop packets for which there is no
    valid destination, and RBridges that know that all attached end
    nodes pre-encapsulate packets, unencapsulated packets can be dropped
    as well.

or does that exclude the MAC address ingress filtering that the
RBridge can perform?


I would have benefitted from a legend for Figure 1.  At first I was
confused as to the difference between the 'T' nodes and the
vSwitches (and thus whether the vSwitches were outside the TRILL
Domain).


I'm not sure I understand the possible consequences of the TRILL-EN
spoofing the ingress nickname as that of the AF while still being
able to send it to/through any RBridge on its local link.  Is the
ingress nickname only used for return routing, in which case it
seems like the consequence is just that the AF just gets some extra
load, or are there other uses of it?  (This seems related to
Alvaro's DISCUSS.)


Section 5.1:

   For a large Data Center with hundreds of thousands of virtualized
   servers, setting the TRILL boundary at the servers' virtual switches
   will create a TRILL domain with hundreds of thousands of RBridge
   nodes, which has issues of TRILL Nickname exhaustion and challenges
   to IS-IS. On the other hand, setting the TRILL boundary at
   aggregation switches that have many virtualized servers attached can
   limit the number of RBridge nodes in a TRILL domain, but introduces
   the issue of very large MAC&VLAN <-> Edge RBridge mapping tables to
   be maintained by RBridge edge nodes.

I could use a little more text on how the large MAC&VLAN <-> Edge
RBridge mapping issue is avoided.


Security considerations:

OLD:
   The mechanism described in this document requires TRILL-ENs to be
   aware of the MAC address(es) of the TRILL edge RBridge(s) to which
   the TRILL-EN is attached and the egress RBridge nickname from which
   the destination of the packets is reachable. 

Do they need to know as a prerequisite, or do they learn this
information during the course of operation?  Maybe

NEW:
   The mechanism described in this document involve TRILL-ENs
   learning the MAC address(es) of the TRILL edge RBridge(s) to which
   the TRILL-EN is attached and the egress RBridge nickname from which
   the destination of the packets is reachable. 

Though it seems like this is just a subset of directory access,
which itself involves a lot of information about the TRILL topology.
Maybe it's better to phrase things in terms of that directory access
itself?

-Benjamin