The draft describes a peer/neighbour discovery mechanisms for large-scale L2/L3 topologies in data centres. The aim is provide a protocol by means of which the involved nodes can learn about other nodes connected to their (broadcast or point-to-point) L2 links and about their respectively support encapsulation schemes, identifiers, L2/L3 addresses, etc. This information is then provided to a higher layer for further processing.

The document is well written and fairly easy to follow, but could benefit from a bit of extra context and target application domain in the introduction. E.g., explaining explicitly who would talk L3DL to whom.

From a transport perspective, I see three potential issues that deserve clarification or reconsideration:

1. Section 10 spells out a default HELLO interval of 60 seconds. With a large broadcast domain, this may create quite a bit of traffic. While this may not be an issue in well-provisioned data center networks,  a remark about sensible value ranges and the implications may be worthwhile. Just to provide some guidelines to implementers (who want to offer choices) and operators (who pick them).

2. Section 10 also suggest that in response to HELLO messages nodes will issue OPEN PDUs to newly discovered peers. This appears to bear the clear risk of an OPEN implosion when many system come up at the same time. Shouldn't guidance be given to avoid repeated traffic surges and possible losses and thus unnecessary delays? (I noted that other places foresee exponential backoff when retransmitting OPEN and other ACKed PDUs).

3. When the protocol applies fragmentation, should there be a note on preventing bursts?

Other notes:
Section 7 on the checksum needs more detail. It also talks about a "suggested" algorithm but this should be clearly mandated or way to choose one by means of configuration for a complete data centre would need to be made explicit. I also assume that the pseudo code on p.11 would benefit from a leader '0' in 0xffffffff -> 0x0ffffffff, otherwise expansion to 64 bits might fill the high order bits with '1's, which is clearly not intended.

Section 11, p.17, second to last para ("If a properly authenticated...").  From the text, it is unclear what is meant by an "OPEN with the Serial Number of the last data received".

I am curious about the error code, providing 16 bits for additional explanation. Why not a text field?
Also wondering if repeated retries (due to failure, not lost packets) could yield fast repeated transmissions.

Section 15, should the KEEPALIVE interval have suggested (lower) bounds?
At the top of p.26, it says "One per second is the default", the previous page at the bottom refers to the inter-KEEPALIVE interval of ten seconds. Not sure if the two are the same, I suppose so. If they are, the numbers should match. If they are not, we'll need some extra text to explain the difference.

Nits:
There are two spellings of "Encapsulation", capitalised and lower case. Use one consistently.
p10, first para: comprise -> comprising