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