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

Joerg Ott <ott@in.tum.de> Wed, 06 May 2020 05:30 UTC

Return-Path: <ott@in.tum.de>
X-Original-To: lsvr@ietfa.amsl.com
Delivered-To: lsvr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5C253A0D72; Tue, 5 May 2020 22:30:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.197
X-Spam-Level:
X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 qZberTSCV1PJ; Tue, 5 May 2020 22:30:42 -0700 (PDT)
Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.in.tum.de [131.159.0.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 489483A0C4A; Tue, 5 May 2020 22:30:40 -0700 (PDT)
Received: by mail.in.tum.de (Postfix, from userid 107) id CD60B1C084C; Wed, 6 May 2020 07:30:37 +0200 (CEST)
Received: (Authenticated sender: ott) by mail.in.tum.de (Postfix) with ESMTPSA id 12B491C0843; Wed, 6 May 2020 07:30:34 +0200 (CEST) (Extended-Queue-bit tech_kfyli@fff.in.tum.de)
To: Randy Bush <randy@psg.com>, Joerg Ott via Datatracker <noreply@ietf.org>
Cc: tsv-art@ietf.org, lsvr@ietf.org, draft-ietf-lsvr-l3dl.all@ietf.org
References: <158870511665.7532.2079643708622987385@ietfa.amsl.com> <m2lfm6m26i.wl-randy@psg.com>
From: Joerg Ott <ott@in.tum.de>
Message-ID: <f2c4eda8-1459-5ffb-66a0-6be22e6032f7@in.tum.de>
Date: Wed, 6 May 2020 07:30:31 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <m2lfm6m26i.wl-randy@psg.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsvr/I4ftLWbYnzPUylLg3gNiGVmTQVc>
X-Mailman-Approved-At: Wed, 06 May 2020 00:35:35 -0700
Subject: Re: [Lsvr] [Tsv-art] Tsvart early review of draft-ietf-lsvr-l3dl-03
X-BeenThere: lsvr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Vector Routing <lsvr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsvr>, <mailto:lsvr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsvr/>
List-Post: <mailto:lsvr@ietf.org>
List-Help: <mailto:lsvr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsvr>, <mailto:lsvr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 May 2020 05:30:45 -0000

Oops.  I was told this was an "early" review, not a "late" one :-)
Was a good read in any case...

Cheers,
Jörg

On 06.05.20 00:45, Randy Bush wrote:
> 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
>>
>>
>>
> 
> _______________________________________________
> Tsv-art mailing list
> Tsv-art@ietf.org
> https://www.ietf.org/mailman/listinfo/tsv-art
>