[trill] draft-ietf-trill-directory-assist-mechanism-10.txt
"Susan Hares" <shares@ndzh.com> Sun, 08 January 2017 23:06 UTC
Return-Path: <shares@ndzh.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 1B5F6129458; Sun, 8 Jan 2017 15:06:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.845
X-Spam-Level: **
X-Spam-Status: No, score=2.845 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no 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 kEol1yUHpwqr; Sun, 8 Jan 2017 15:06:08 -0800 (PST)
Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 291741200A0; Sun, 8 Jan 2017 15:06:05 -0800 (PST)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=70.194.7.201;
From: Susan Hares <shares@ndzh.com>
To: trill@ietf.org
Date: Sun, 08 Jan 2017 18:02:03 -0500
Message-ID: <001b01d26a03$3ac96910$b05c3b30$@ndzh.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_001C_01D269D9.51F8DF50"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AdJp/ay9nEwyTlv/Tzaj1/Mf9QDfeg==
Content-Language: en-us
X-Authenticated-User: skh@ndzh.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/trill/SUMuYIuHz0bg1bSxXEZz9Vsnqjc>
Cc: 'Donald Eastlake' <d3e3e3@gmail.com>, draft-ietf-trill-directory-assist-mechanisms@ietf.org, 'Radia Perlman' <radiaperlman@gmail.com>, 'Liyizhou' <liyizhou@huawei.com>, linda.dunbar@huawei.com
Subject: [trill] draft-ietf-trill-directory-assist-mechanism-10.txt
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.17
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: Sun, 08 Jan 2017 23:06:10 -0000
Donald, Yizhou, Linda, and Radia: Thank you for your work on draft-ietf-trill-directory-assist-mechanisms. Each draft improves the readability and nails down some of the potential edge cases. I believe we are nearing the end of this journey toward IESG approval. I am joining with you on this journey by doing a shepherd review at the end of IETF LC. Status: Ready to publication, with some editorial nits you should consider Here's my editorial nits on the latest version. Please address #2 - that deals with the "SEND" functionality and #6 #1, p. 5 paragraph 1, list item 3. - simple spelling error Old:/MAC addresses "nomrally" / New: /MAC Addresses normally/ #2. p. 17-22 - section 3 #2.a Overall - I think you need to include SEND messages in this Query messages. #2.b p17, section 3.0 paragraph 5 specific text change Old:/The requests to Pull Directory servers are typically derived from ingressed ARP [RFC826], ND [RFC4861], RARP [RFC903], or Draft frames with unknown unicast destination MAC addresses, intercepted by an ingress TRILL switch as described in Section 1.1/ New:/ The requests to Pull Directory servers are typically derived from ARP [RFC826], ND [RFC4861], RARP [RFC903], or SEND [RFC3971] messages or draft Layer 2 frames with unknown unicast destination MAC addresses intercepted by an ingress TRILL switch as described in Section 1.1/ Reason: SEND mechanisms need to be clearly specified in the draft. Suresh Krishnan mentioned this on the ARP optimization draft. #3 p. 19, section 3.2.1 paragraph 1, sentence 3 Old: /The priority of the channel message is a mapping of the priority of the frame being ingressed that caused the query with the default mapping depending, per Data Label, on the strategy (see Section 4 <https://tools.ietf.org/html/draft-ietf-trill-directory-assist-mechanisms-10 #section-4> ) or a configured priority (DirGenQPriority, Section 3.9 <https://tools.ietf.org/html/draft-ietf-trill-directory-assist-mechanisms-10 #section-3.9> ) for generated queries./ New:/ The priority of the channel message is a mapping of the priority of the ingress frame which caused the query combined with the default mapping per Data Label depending on the strategy for generated queries (see Section 4 <https://tools.ietf.org/html/draft-ietf-trill-directory-assist-mechanisms-10 #section-4> ) or a configured priority (DirGenQPriority, Section 3.9 <https://tools.ietf.org/html/draft-ietf-trill-directory-assist-mechanisms-10 #section-3.9> /. Reason: Clarify sentences. #4, p. 33 section 3.5.1 paragraph 3 Old:/ The Bridge shown might be a complex bridged LAN or might be absent if, as shown for End Station 1, End Station 2 was dual ported with point-to-point Ethernet links to RB1 and RB2./ New:/The Bridge shown might be a complex bridged LAN, a LAN without a bridge (as shown in End station 1), or connected via point-to-point links (as shown in End Station 2's which is connected through a bridge with point-to-point Ethernet links to RB1 and RB2./ Reason: Clarify the sentences #5, p. 33 section 3.5.1 paragraph 4 sentence 1. Old:./ Because an indirect Pull Directory server discards information it has cached from queries to an end station Pull Directory server if it loses adjacency to that server (Section 3.7 <https://tools.ietf.org/html/draft-ietf-trill-directory-assist-mechanisms-10 #section-3.7> ), if it knowns that such information may be cached at RBridge clients and has no other source for the information, it MUST send Update Messages to those clients withdrawing the information/ New: /Since an indirect Pull Directory server discards information it has cached from queries to an end station Pull Directory server if it loses adjacency to the server (Section 3.7), if it detects that information may be cached at RBridge clients and has no other source for the information, it MUST send Update Messages to those clients withdrawing the information/ Words changed - in bold Why: anthropomorphism - TRILL switches do not know. TRILL switches detect based on logic. Why: Because/since - both indicate causes, but "since" seems to indicate an ordering that this paragraph suggests. #6: p. 43, 4th paragraph beginning with Although some . Current text: /Although some of the ports sending TRILL ES-IS PDUs are on end stations and thus not on routers (TRILL switches), they nevertheless may make use of the Router Capability (#242) and MT-Capability (#222) IS-IS TLVs to indicate capabilities as elsewhere specified./ It would be good to indicate where these capabilities are specified. #7 p. 44, section 6 - Security considerations After the SEC-DIR review comes in, consider if the end-system engage requires some extra text on privacy related to the end-systems. Since Donald and Radia are much better at all types of security, please consider this as a "please check". Kathleen and Stephen are focused on this work.
- [trill] draft-ietf-trill-directory-assist-mechani… Susan Hares
- Re: [trill] draft-ietf-trill-directory-assist-mec… Donald Eastlake
- Re: [trill] draft-ietf-trill-directory-assist-mec… Donald Eastlake