Comments on draft-ymbk-lsvr-lsoe-00
Toerless Eckert <tte@cs.fau.de> Fri, 23 March 2018 07:59 UTC
Return-Path: <eckert@i4.informatik.uni-erlangen.de>
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4E77129C56 for <rtgwg@ietfa.amsl.com>; Fri, 23 Mar 2018 00:59:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.961
X-Spam-Level:
X-Spam-Status: No, score=-3.961 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 smxxG7n_q61D for <rtgwg@ietfa.amsl.com>; Fri, 23 Mar 2018 00:59:42 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BDFC1289B0 for <rtgwg@ietf.org>; Fri, 23 Mar 2018 00:59:41 -0700 (PDT)
Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [131.188.34.77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 48AF758C4AE; Fri, 23 Mar 2018 08:59:38 +0100 (CET)
Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 298F9B0DDE9; Fri, 23 Mar 2018 08:59:38 +0100 (CET)
Date: Fri, 23 Mar 2018 08:59:38 +0100
From: Toerless Eckert <tte@cs.fau.de>
To: rtgwg@ietf.org
Subject: Comments on draft-ymbk-lsvr-lsoe-00
Message-ID: <20180323075937.GX30215@faui40p.informatik.uni-erlangen.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtgwg/z2VzqTcrO8Ny0skhkUEbOTlONfU>
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Routing Area Working Group <rtgwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtgwg/>
List-Post: <mailto:rtgwg@ietf.org>
List-Help: <mailto:rtgwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 Mar 2018 07:59:45 -0000
Randy, *: a) "UDP is unsuitable as it would require prior knowledge of IP level addressing, one of the key purposes of this discovery protocol" If at all, this is a property of using IP, not UDP. Please clarify. I also do not believe this to be a problem when simply relying on IPv6 link-local addresses. For example, ANIMA WG GRASP (draft-ietf-anima-grasp) is a protocol which in one instance (DULL) is used as a subnet discovery protocol relying on only IPv6 link-local and IANA assigned UDP port number. Please explain how you think this would be a problem when using IPv6 link local addresses. b) "LLDP is not suitable because ... It is also complex." One core reason for complexity of LLDP is likely that over time it has started to serve the purposes of multiple use-cases/communities. It would be good therefore to understand what scope your protocol proposal has. Which groups of use cases, especially beyond the DC-routing one should be allowed to define even the initial requirements and functionality of your protocol ? Should they at best be allowed to define only later extensions and be treated as second class citizens with every change/extension subject to fear of the unknown danger of breaking the initial/primary data-center use case ? If you want an isolated solution for your routing protocol link state in DC discovery, do you think each other use case should also come up with an IETF-LLDP-replacement of their own ? Should this decision be bsed simply on the size of use-case ? It is ok. if given a device requiring to support multiple use-cases that you ould run multiple such protocols in parallel ? Such as e.g.: multiple routing protocols Hello methods and then figure out 20 years laer we need BFD ? I have tried to figure out how to get solutions to work where CDP and LLDP are run in parallel and it was a terrible pain. Please clarify in the document. c) The IETF has attempted lately a bit to evolve from per-protocol manually defined and ASCII-graphic specified TLV formats to common encoding schemes, primarily CBOR. It would be lovely if you could evaluate whether that approach would not be better suited for long term evolution and ease of definition. ANIMA GRASP for example also uses it, like now several other protocols do as well. And there is a specification format (CDDL). And a working group, and tools, for verification, etc. pp. Please clarify in your document, especially when continuing to not wanting to use CBOR, why not (wanting to optimize on the initial implementating coding work and pushing down work the line is a perfect valid explanation for example). d) I suggest to consider a security model where devices meant to trust each other to exchange critical information such as link-state have a cryptographic trust model to do so. Especially when the chance for mis-wiring is so great as it is in a DC (e.g.: links often connecting to servers which likely are not in the same trust-domain a switches). You may want to take a look at the model defined by ANIMA WG, where each such device has a PKI certificate expressing such group membership, making it easy to authenticate mutual messages. IETF standard track procedures for zero-touch enrolment with such a cetificate (before having to get any routed IP addresses assigned) have also been defined (BRSKI), allowing to rely on the presence of such a certificate without any prior configuration work. I am sure the ANIMA WG will be happy to help in case you are interested in any of this. e) I have not tried to understand which messages require so low latency that the delay potentially incurred by a transport like TCP would be seen to be inadequate. It would be great if the document could include such discussion. Building yet another ad-hoc reliability scheme with retransmissions is yet another IMHO unnecessary piece of complexity unless well justified. I am also not a friend of the complexity of semantic fragmentation which might be required with datagram transport of large data structures. The document gives no good indication of expected size. 1500 seems to be too small... 8192 is sufficient ? Unless anybody else's use case comes around, at which point there is no space for extensions ? Cheers Toerless
- Comments on draft-ymbk-lsvr-lsoe-00 Toerless Eckert
- Re: Comments on draft-ymbk-lsvr-lsoe-00 Robert Raszuk
- Re: [Lsr] Comments on draft-ymbk-lsvr-lsoe-00 Donald Eastlake