[trill] Benjamin Kaduk's practice ballot (No Objection) on draft-ietf-trill-smart-endnodes-10: (with COMMENT)

Benjamin Kaduk <kaduk@mit.edu> Thu, 08 March 2018 03:33 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 1F918126DEE; Wed, 7 Mar 2018 19:33:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 NIlOPymfTkUh; Wed, 7 Mar 2018 19:33:45 -0800 (PST)
Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (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 57BD6126BF7; Wed, 7 Mar 2018 19:33:44 -0800 (PST)
X-AuditID: 12074425-779ff700000063e8-cc-5aa0af159c43
Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 4E.8C.25576.61FA0AA5; Wed, 7 Mar 2018 22:33:42 -0500 (EST)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id w283Xarh032200; Wed, 7 Mar 2018 22:33:38 -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 w283XWA5032450 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 7 Mar 2018 22:33:35 -0500
Date: Wed, 7 Mar 2018 21:33:33 -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-smart-endnodes@ietf.org
Message-ID: <20180308033332.GZ27850@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+NgFnrHIsWRmVeSWpSXmKPExsUixG6noiu2fkGUwYr1RhY7DhxltpjxZyKz xZ83r1gsfp64zGzxfvJ2NgdWjyVLfjJ5zH59nTWAKYrLJiU1J7MstUjfLoErY831ecwFc1Ur zq6Yw9jA2CXbxcjJISFgIvG7ewlTFyMXh5DAYiaJrzunM0I4GxglGue8Z4FwzjBJtHWvYwdp YRFQkVj59DQTiM0GZDd0X2YGsUUEZCS+tE8Bs5kFciWONV4CqxcWKJB4uHonI4jNK6AjMXnG RSYIW1Di5MwnLBD1WhI3/r0EinMA2dISy/9xgIRFBZQl9vYdYp/AyDcLSccsJB2zEDoWMDKv YpRNya3SzU3MzClOTdYtTk7My0st0rXQy80s0UtNKd3ECA5KF9UdjHP+eh1iFOBgVOLhPfBz fpQQa2JZcWXuIUZJDiYlUV7frAVRQnxJ+SmVGYnFGfFFpTmpxYcYJTiYlUR4uZYB5XhTEiur UovyYVLSHCxK4rweJtpRQgLpiSWp2ampBalFMFkZDg4lCV7ZdUCNgkWp6akVaZk5JQhpJg5O kOE8QMMtQWp4iwsSc4sz0yHypxh1OW68eN3GLMSSl5+XKiXO27oWqEgApCijNA9uDiiZSGTv r3nFKA70ljCvEMgoHmAigpv0CmgJE9CS83fngCwpSURISTUwTjPxXjFnKnP7wdVHTvn92851 yiJ585blu885797JfuD8rX9CkX+Spzg8rhWfeOTqjApPgQWulbmP9NV7F+35XhOzbHmW/eNG Ka1tty0OrosWjV+mPcV799TrTAePex8/2e1gpn3AOI9Pb+n2pqXTOKtij/IGyakFP3p+O33r fTcWr8Sb7SHL9ymxFGckGmoxFxUnAgD33cQzAQMAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/trill/rM7T67iMUxbUpIXaa0I7ww-2lNU>
Subject: [trill] Benjamin Kaduk's practice ballot (No Objection) on draft-ietf-trill-smart-endnodes-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: Thu, 08 Mar 2018 03:33:46 -0000

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


I'm confused at what exactly constitutes a "Smart-Hello" -- Section
4.1 says that it "is a type of TRILL ES-IS PDU, which is specified
in [RFC8171]".  The reference does not use the term, so I assume
that the reference is just for ES-IS PDUs.  So, reading on, the
payload consists of TRILL IS-IS TLVs.  Quoting judiciously:
   [...] Both types of Smart-Hellos MUST include a
   Smart-Parameters APPsub-TLV as follows inside a TRILL GENINFO TLV:
[...]
   [...] If
   no Smart Parameters APPsub-TLV appears in a Smart-Hello, that Smart-
   Hello is ignored.

The first makes me think that the presence of Smart-Parameters makes
a Smart-Hello, but he second implies that a Smart-Hello can exist
without one (even if it would always be ignored).


If just the presence of a particular Smart-foo implies that an
entire TRILL GENINFO is a Smart-Hello, then I'm concerned about the
reuse of existing TLVs for subtly different purposes, like the
Neighbor TLV becoming the "Smart Endnode neighbor list"?  This could
be problematic for implementations that do not support Smart-Hello
messages, which would then misinterpret the Neighbor TLV, etc.


I'm also a little unclear on the story for authentication and
protection against the injection of bogus messages.  The
Authentication TLV can be used for the Smart-Hellos, which is good
(but why is it not required?), and I suppose I can't complain
terribly hard about the security model of "if you're authorized to
send, you're authorized to send anything" which is to large extent
universally deployed.  But, we only say that the Edge RBrige "MAY
filter the encapsulation frame based on the inner source MAC and
Data Label as specified for the Smart Endnode." -- why can this not
be a MUST, to prevent spoofing/injection?   In a similar vein,
stronger conditions could be imposed if hybrid ports are disallowed,
but I don't know how feasible that is (or what actual hybrid port
deployments look like).


In Section 5.2:

   The attached edge RBridge processes and forwards TRILL Data packets
   based on the endnode property rather than for encapsulation and
   forwarding the native frames the same way as the traditional
   RBridges.

This left me confused for quite some time.  Is the "for
encapsulation" supposed to be "by encapsulating"?

   o  If receiving a unicast TRILL Data packet with RB1's nickname as
      egress from the TRILL campus, and the destination MAC address in
      the enclosed packet is a MAC address that has been listed by a
      "Smart Endnode", RB1 leaves the packet encapsulated to that Smart
      Endnode.  The outer Ethernet destination MAC is the destination
      Smart Endnode's MAC address, the inner destination MAC address is
      either the Smart Endnode's MAC address or some other MAC address
      that the Smart Endnode advertised in its Smart Hello, and the
      outer Ethernet source MAC address is the RB1's port MAC address.

This is describing modifications that RB1 makes to the received
Ethernet frame containing and encapsulated TRILL Data packet, right?
It might be more clear to describe this as a transformation than a
declarative statement about the nature of the Ethernet frame.
Perhaps

NEW:
   o  If receiving a unicast TRILL Data packet with RB1's nickname as
      egress from the TRILL campus, and the destination MAC address in
      the enclosed packet is a MAC address that has been listed by a
      "Smart Endnode", RB1 leaves the packet in an encapsulated
      form, targetted to that Smart Endnode.  It changes the outer
      Ethernet destination MAC to the destination Smart Endnode's
      MAC address, the inner destination MAC address remains as
      either the Smart Endnode's MAC address or some other MAC
      address that the Smart Endnode advertised in its Smart Hello,
      and the outer Ethernet source MAC address used for the last
      hop is the RB1's port MAC address.


In Section 6

   [...] The
   solution for the MAC flip-flopping issue is to set a multi- homing
   bit in the RSV field of the TRILL data packet.

I think this is supposed to be the 'M' bit that is allocated in the
Smart-MAC APPsub-TLV?

   [...] (An alternative solution
   would be to use the ESADI protocol to distribute multiple attachments
   of a MAC address of a multi-homing group, The ESADI is deployed among
   the edge RBridges (See section 5.3 of [RFC7357])).

This seems like a teaser of an aside that seems like it should either get
expounded upon, for example with a comparison against using the M
bit as previously described, or removed.

-Benjamin