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

"Zhangmingui (Martin)" <> Fri, 05 May 2017 09:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4C8DF1294C9 for <>; Fri, 5 May 2017 02:55:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KU3lFg7v_gNw for <>; Fri, 5 May 2017 02:55:36 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0B5E3127444 for <>; Fri, 5 May 2017 02:55:35 -0700 (PDT)
Received: from (EHLO ([]) by (MOS 4.3.7-GA FastPath queued) with ESMTP id DMI06546; Fri, 05 May 2017 09:55:33 +0000 (GMT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 5 May 2017 10:55:33 +0100
Received: from ([]) by ([]) with mapi id 14.03.0235.001; Fri, 5 May 2017 17:55:29 +0800
From: "Zhangmingui (Martin)" <>
To: Donald Eastlake <>, "" <>
Thread-Topic: [trill] Comments on draft-ietf-trill-p2mp-bfd-04
Thread-Index: AQHSxQdcT+ISDQ1K+Uy92Z00IbeDJ6HlgMTA
Date: Fri, 5 May 2017 09:55:28 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_4552F0907735844E9204A62BBDD325E7A64B6F02NKGEML515MBSchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.590C4C16.0072, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 795d8827cf35a0076f8a536c12a7a86b
Archived-At: <>
Subject: Re: [trill] Comments on draft-ietf-trill-p2mp-bfd-04
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Developing a hybrid router/bridge." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 05 May 2017 09:55:38 -0000

Hi Donald,

Appreciate your comments. We authors agree with you and an update version based on your comments will be submitted soon.


From: trill [] On Behalf Of Donald Eastlake
Sent: Friday, May 05, 2017 2:50 AM
Subject: [trill] Comments on draft-ietf-trill-p2mp-bfd-04


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
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<>]7>]. Multi-hop sessions are expected to be configured by the network manager."

Editorial Comments
Section 1

   [I-D.ietf-bfd-multipoint-active-tail<>]l>].  If the tail loses

   connectivity of the new RBridge Channel message from the

   head, the

   [I-D.ietf-bfd-multipoint-active-tail<>]l>].  If the tail loses

   connectivity as detected by not receiving the new RBridge

   Channel message from the head, the

Section 5

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

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

 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA<>