[trill] draft-ietf-

"Susan Hares" <shares@ndzh.com> Sat, 14 January 2017 00:20 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 984701295D9 for <trill@ietfa.amsl.com>; Fri, 13 Jan 2017 16:20:39 -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 xPwSkHlPWiTF for <trill@ietfa.amsl.com>; Fri, 13 Jan 2017 16:20:37 -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 9EDFC1293E8 for <trill@ietf.org>; Fri, 13 Jan 2017 16:20:37 -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:16:41 -0500
Message-ID: <00b901d26dfb$7bee9d60$73cbd820$@ndzh.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00BA_01D26DD1.931A6A20"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AdJt+2S/+Ovyvd7ORr6DNHwmJWiWuA==
Content-Language: en-us
X-Authenticated-User: skh@ndzh.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/trill/pXIeRH3ZepWB8rLn8OdhDLypepw>
Cc: 'Donald Eastlake' <d3e3e3@gmail.com>, mohamed.boucadair@orange.com, 'Radia Perlman' <radiaperlman@gmail.com>, 'Liyizhou' <liyizhou@huawei.com>, linda.dunbar@huawei.com
Subject: [trill] draft-ietf-
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:20:39 -0000

Forwarding to trill list this conversation.  It appears I missed sending
this last weekend. 

 

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 Krishnan’s
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 Alvaro’s concerns, but I’m concerned that without specific references to
SEND and clear indication about the SEND messages. 

 

Here’s 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:/target’s private key and only action b.1/

New/target’s 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