Subject: Comments on draft-ymbk-lsvr-lsoe-00

From: Toerless Eckert <[email-masked]>
Date: Fri, 23 Mar 2018 08:59:38 +0100

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

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 24 Mar 2018 11:57:25 +0100

Dear Authors,

Let me just ask one little question ....

It seems that ISIS protocol already meets a "Link State Over Ethernet"
definition so why to invent anything new here ?

If you don't like flooding properties of ISIS just disable it. Do not
flood. Do not run SPF in ISIS. Use ISIS only for p2p discovery.

You get for free out of the box all what you are trying to describe in the
subject document. Integrating open source ISIS code just for discovery (ie.
not worring about optimizations of flooding, back-off, timers, spf etc ...)
will be IMO much faster even using any apache license existing
implementation of ISIS.

Last - as Toerless already indicated - solving inevitable inconsistencies
of running LSOE, CDP & LLDP between various devices or in parallel on the
same links is something that should be addressed from day one. Unless you
assume that if someone is to use LSVR is will also have LSOE and any other
alternative discovery mechanisms will be disabled.

Best,
RR.

---

From: Donald Eastlake <[email-masked]>
Date: Sun, 25 Mar 2018 22:09:15 -0400

Hi,

> definition so why to invent anything new here ?

My thought also.

> If you don't like flooding properties of ISIS just disable it. Do not flood.
> Do not run SPF in ISIS.. Use ISIS only for p2p discovery.

IS-IS now explicitly supports link-scoped "flooding" as per RFC 7356
"IS-IS Flooding Scope Link State PDUs (LSPs)". It also support 16-bit
TLV lengths. See in particular Extended Level 1 Circuit Scope (E-L1CS)
in RFC 7356.

> will be IMO much faster even using any apache license existing

And authentication (RFC 5310).

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

> Last - as Toerless already indicated - solving inevitable inconsistencies of
> running LSOE, CDP & LLDP between various devices or in parallel on the same
> links is something that should be addressed from day one. Unless you assume
> that if someone is to use LSVR is will also have LSOE and any other
> _______________________________________________
> Lsr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsr
>