[trill] draft-ietf-trill-arp-optimization WG Last Call (11/15 - 12/6)
"Susan Hares" <shares@ndzh.com> Sat, 14 January 2017 00:43 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 7157E12957A for <trill@ietfa.amsl.com>; Fri, 13 Jan 2017 16:43:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.946
X-Spam-Level:
X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 krt8YESCFWEZ for <trill@ietfa.amsl.com>; Fri, 13 Jan 2017 16:43:40 -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 8731D1294EA for <trill@ietf.org>; Fri, 13 Jan 2017 16:43:40 -0800 (PST)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.36.90.185;
From: Susan Hares <shares@ndzh.com>
To: trill@ietf.org
Date: Fri, 13 Jan 2017 19:39:44 -0500
Message-ID: <00dc01d26dfe$b3f36800$1bda3800$@ndzh.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00DD_01D26DD4.CB1EE6A0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AdJt/qEeRDXjbkFHSnaNmsUQMopQxA==
Content-Language: en-us
X-Authenticated-User: skh@ndzh.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/trill/xMxINbUDrWCMl8nh0cFrcP0arB8>
Cc: 'Donald Eastlake' <d3e3e3@gmail.com>, akatlas@gmail.com
Subject: [trill] draft-ietf-trill-arp-optimization WG Last Call (11/15 - 12/6)
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: Sat, 14 Jan 2017 00:43:42 -0000
Re-forwarding to get the right link to the WG LC. Sue From: Susan Hares [mailto:shares@ndzh.com] Sent: Saturday, January 7, 2017 8:59 PM To: 'Donald Eastlake'; 'Liyizhou'; linda.dunbar@huawei.com; 'Radia Perlman'; 'Mohammed Umair' Cc: 'Alia Atlas' Subject: Donald Eastlake Donald, Yizhou, Linda, Radia, and Mohammed: I reviewed the TRILL ARP/ND optimization this evening (after my head finally clear from allergies). I do not believe you have answered Suresh Krishnans issues about SEND clearly. I see 80% of the logic, but no place where you clearly indicate when SEND should be used. I think you have answered 90% of Alvaros concerns, but Im concerned that without specific references to SEND and clear indication about the SEND messages. Heres a set of changes that I think might work to resolve. Cheerily, Sue ---------- #1 Page 5 section 4, title Old:/ Handling ARP/ND messages/ New:/Handling ARP/ND/SEND messages/ #2 change paragraph #3 to add SEND /in ND/ to /in ND and SEND/ #3 Could you as section 4.1, a short description about send that includes: 1) Why Send is needed, 2) How send interacts with ND, 3) Intermixing Topology is this topology allowed SEND ßà RBRIDGE ------RBRDGE ßàND [IMHO this is a.2 or could be part of a.5] 4) When SEND should be used #3 Could you add a section 4.2 1 paragraph that indicates why or why not the RBRIDGE would verify the address. #4 section 4.1 (change to section 4.3) Add send by OLD%ARP/ND% to New%ARP/ND/SEND% #5 section 4.2 (change to section 4.4) 5.1 Paragraph 2, item a) change ARP/ND request to ARP/ND/SEND request Change a.2 from ARP/ND to ARP/ND/SEND Change a.5 from ARP/ND to ARP/ND/Send request 5.2 paragraph 3 item b) Change sentence 1: Old% ARP/ND% New% ARP/ND/SEND% Change sentence 3 end Old:/targets private key and only action b.1/ New/targets private key therefore only action b.1/ 5.2 paragraph 4 item c) Change sentence 1: OLD%ARP/ND% NEW%ARP/ND/SEND% 5.3 paragraph 5) item d) Include in the DAD [RFC4862] the ND and SEND version #6 describe what happens if SEND CGA option does not exist in send, or fails This can be a new section or a re-written section 7 or a sub-section to section 7. Describe what happens SEND CGA exists, does not exist, or fails due to the wrong key. This could also go in a revised section 4.1 Section 8 expand this to include the SEND functionality. Thanks