Re: [Tsv-art] Tsvart early review of draft-ietf-lsvr-l3dl-03

["Van De Velde, Gunter (Nokia - BE/Antwerp)" <[e-mail]>]

Hi Randy,

Wake-up call received. 

Can you refresh the draft-ietf-lsvr-l3dl-03 document and I'll launch WGLC on that document.

Can you refresh " draft-ymbk-lsvr-l3dl-signing " and " draft-ymbk-lsvr-l3dl-ulpc" and we'll launch a WG adoption call.

Brgds,
G/

-----Original Message-----
From: Randy Bush <[e-mail]> 
Sent: Wednesday, May 6, 2020 00:45
To: Joerg Ott via Datatracker <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: Re: Tsvart early review of draft-ietf-lsvr-l3dl-03

wow!  thanks!  great review.

unfortunately the wg has gone dormant, so we have let the l3dl drafts expire.  should it ever wake up, i will happly merge in your excellent suggestions.

again, thank you!

randy

> Reviewer: Joerg Ott
> Review result: Ready with Issues
> 
> 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
> 
> 
>