[trill] Comments on draft-ietf-trill-p2mp-bfd-04

Donald Eastlake <d3e3e3@gmail.com> Thu, 04 May 2017 18:50 UTC

Return-Path: <d3e3e3@gmail.com>
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 9768E12714F for <trill@ietfa.amsl.com>; Thu, 4 May 2017 11:50:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.251
X-Spam-Level:
X-Spam-Status: No, score=0.251 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 FZzqi7e-k-wm for <trill@ietfa.amsl.com>; Thu, 4 May 2017 11:50:27 -0700 (PDT)
Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F6E01200C1 for <trill@ietf.org>; Thu, 4 May 2017 11:50:27 -0700 (PDT)
Received: by mail-it0-x22d.google.com with SMTP id c15so6575576ith.0 for <trill@ietf.org>; Thu, 04 May 2017 11:50:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=d04cOsIb/5JgGSohNGuFwS0hMBu1ETycMI3Lz8n3abk=; b=Zw8n4jJNXpUuq2HXNxbJ2pxtJFUZyOHA1290tvAhdhPI+8grIgcE+LCqJXSCy8LZpC wP8mrxmsKyJwH6ha7WTGcD73PXa/kH0UoG5InW87yU2V/R6gCXUbaRq/FxCsT1o/z0uq I+AeTYqu04o/aRLe/8gJMHxoseUDuqItHaqzzjymaUVJCjus80QGp9I2B8P8z7uImbSU APp6y9UJ11aGLWt4ZuB0byMSoLPRUoP/BT9zaym+QINdN6Kvcpi/Z5KDx89SrQArVLyE pWQ8LuGIVOzdlNV6ot4X30BvBsJAN2edZCkTk5RJL1FlN4iR6Nj7ArIPSR9OTsgE+oZq PlrA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=d04cOsIb/5JgGSohNGuFwS0hMBu1ETycMI3Lz8n3abk=; b=R2xbHKGboP7NuHbz5y9FvC+vSich5/JCsWA7uTaGhhaC9hExOHy3xlXF5FIS8Yzfn9 ud1exzauGkCFP4rgpaEioLcd8jg4s4SkbCnjkqh9RH/+CTa09/g4CuOAx6cuy3hLXgDL rHEvVPI86QIedURq+v6x+3BdelUrJ+82aJkRyDQCBo1uOUkuVrssJNI+uPL4M+2XNFi5 +3NcFdYS9CKE8h0Hz7aITReDn72bN5S67HQqQ0ph1LOo7yF+OMSW1VtQ3bHoYFkOQdLe AKTFDhYasvPR9fvRCUabqplYAJE94QpeLIeq3I9I7Rm+/Hj6vlbH6sQ2+8QUQFMbwNqd Lrzw==
X-Gm-Message-State: AN3rC/5DnsP0B2KKgeyHvSRK3A8t1N/oM4feJAi/4/cP7KdRvdF9R0gf M6ZAeUU692DQqaJJP7VEzoBIEsE6cNKlAuA=
X-Received: by 10.36.122.80 with SMTP id a77mr3820274itc.83.1493923826346; Thu, 04 May 2017 11:50:26 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.36.79 with HTTP; Thu, 4 May 2017 11:50:10 -0700 (PDT)
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Thu, 4 May 2017 14:50:10 -0400
Message-ID: <CAF4+nEG_Z9K3KM9sOhJhx3C9cuVEA1=KK9=iS5BrDRceOMSaNw@mail.gmail.com>
To: "trill@ietf.org" <trill@ietf.org>
Content-Type: multipart/alternative; boundary=001a1145ae02fde776054eb73e4f
Archived-At: <https://mailarchive.ietf.org/arch/msg/trill/7pPaIYGZkc5AA6dydt-Z_MY6R98>
Subject: [trill] Comments on draft-ietf-trill-p2mp-bfd-04
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, 04 May 2017 18:50:30 -0000

Hi,

I've reviewed this document and have one new technical comment, two
editorials, and I repeat with suggested text a technical comment I had in
my recent message supporting.

*Technical Comments*

1. The Security Considerations section has a minor problem in that it
refers to RFC 7978 for security. RFC 7978 tells you how to do
point-to-point authentication and encryption but for multi-destination
cases like p2mp it provides only authentication. And, I believe, the
multipoint BFD draft provides authentication so it is not really necessary
to do it at the extended RBridge Channel message level. I suggest replacing
the first two paragraphs of the Security Considerations section with the
following:

"Multipoint BFD provides its own authentication but does not provide
encryption (see Security Considerations in [I-D.ietf-bfd-multipoint]). As
specified in this document, the point-to-multipoint BFD payloads are
encapsulated in RBridge Channel messages which have been extended by
[RFC7978] to provide security. However, [RFC7978], while it provides both
authentication and encryption for point-to-point extended RBridge Channel
messages, provides only authentication for multipoint RBridge Channel
messages. Thus, there is little reason to use the [RFC7978] security
mechanisms at this time. However, it is expected that a future document
will provide for group keying; when that occurs, the use of RBridge Channel
security will also be able to provide encryption and may be desirable."


2. As mentioned in
https://www.ietf.org/mail-archive/web/trill/current/msg07746.html
the bootstrapping section (Section 3) could be read to imply that multi-hop
multi-point BFD sessions could be bootstrapped with adjacency but I think
that only works for one-hop BFD sessions. I suggest that the first sentence
of Section 3 be replaced by the following two sentences:

"The TRILL adjacency mechanism bootstraps the establishment of one-hop
TRILL BFD
sessions [RFC7177 <https://tools.ietf.org/html/rfc7177>]. Multi-hop
sessions are expected to be configured by the network manager."


*Editorial Comments*
Section 1
OLD

   [I-D.ietf-bfd-multipoint-active-tail
<https://tools.ietf.org/html/draft-ietf-trill-p2mp-bfd-04#ref-I-D.ietf-bfd-multipoint-active-tail>].
If the tail loses
   connectivity of the new RBridge Channel message from the

   head, the

NEW

   [I-D.ietf-bfd-multipoint-active-tail
<https://tools.ietf.org/html/draft-ietf-trill-p2mp-bfd-04#ref-I-D.ietf-bfd-multipoint-active-tail>].
If the tail loses
   connectivity as detected by not receiving the new RBridge

   Channel message from the head, the


Section 5
OLD

   addition to this combination, TRILL P2MP BFD that requires the tail

NEW

   addition to this combination, TRILL P2MP BFD requires that the tail


Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e3e3@gmail.com