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

Randy Bush <randy@psg.com> Sat, 23 May 2020 18:32 UTC

Return-Path: <randy@psg.com>
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 67CBA3A0D2B; Sat, 23 May 2020 11:32:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 97NOq6HaUgTb; Sat, 23 May 2020 11:32:49 -0700 (PDT)
Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CA993A0CD6; Sat, 23 May 2020 11:32:49 -0700 (PDT)
Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from <randy@psg.com>) id 1jcYwv-0002S9-SO; Sat, 23 May 2020 18:32:46 +0000
Date: Sat, 23 May 2020 11:32:42 -0700
Message-ID: <m2y2pibiyd.wl-randy@psg.com>
From: Randy Bush <randy@psg.com>
To: Joerg Ott <ott@in.tum.de>
Cc: tsv-art@ietf.org, lsvr@ietf.org, draft-ietf-lsvr-l3dl.all@ietf.org
In-Reply-To: <c1712c72-fcf1-f2d5-e5ab-f8f4eb3f911d@in.tum.de>
References: <158870511665.7532.2079643708622987385@ietfa.amsl.com> <m2sggclma3.wl-randy@psg.com> <c1712c72-fcf1-f2d5-e5ab-f8f4eb3f911d@in.tum.de>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset="US-ASCII"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsvr/3hLz1nnCGG39UgKaw3Ct7TwxFzY>
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: Sat, 23 May 2020 18:32:54 -0000

sorry to take a while to get back to this.  your review is really
appreciated.

i think we converged on most things.  the following seemed open.

>>> 3. When the protocol applies fragmentation, should there be a note on
>>> preventing bursts?
>> 
>> likely part of this is our fault, as we did not mean 'fragmentation' in
>> the classic "oops!  we found a hop with a small mtu."
> 
> I didn't take it to mean classic fragmentation but rather ALF-style
> operation.  Still, this could generate bursts depending on how much
> information there is to 'fragment'.

yes, it is app level framing.  perhaps we should call it that explicitly
or even segmentataion or some term less well known.

do you perhaps have a specific suggestion?

>>> Section 7 on the checksum needs more detail.
>> 
>> could you be more specific re in what area?
> 
> Let me go back:
> 
> The code is fine (and certainly a good idea).  I was kind of expecting
> the code to be described in text, but given the code is there, the
> concise description is fine.  Except that I got confused by
> "repeat until zero".  What should be zero?  Looking at the code, surely
> not the result.

:)

    Sum up 32-bit unsigned ints in a 64-bit long, then take the
    high-order section, shift it right filling on the left with zeros,
    rotate, add it in, repeat until the high order 32 bits are all zero.

>>> Also wondering if repeated retries (due to failure, not lost packets)
>>> could yield fast repeated transmissions.
>> 
>> could you be specific about what you think could be improved in
> 
> I was trying to decipher my handwriting on the tablet, and it appears to
> say "wait before retry to prevent fast loops", scribbled on the bottom
> of p.22.  I had to go back tot he text and I believe this refers back to
> p.18, first para:
> 
> "The Key is specific to the operational environment.  A failure to
>    authenticate is a failure to start the L3DL session, an ERROR PDU
>    MUST BE sent (Error Code 3), and HELLOs MUST be restarted."
> 
> If you have a systematic auth failure, this would cause HELLOs to be
> restarted.  Without any jittering (now you introduced some above),
> you could, in principle, get a loop:
> 
> HELLO -> OPEN -> (Auth) ERROR -> HELLO -> OPEN -> (Auth) ERROR -> ...
> 
> So misconfig could be bad unless there is some delay built in.

so i added

    Although delay and jitter in responding with an OPEN were specified
    above, beware of load created by long strings of authentication
    failures and retries.

but i am unsure of what action to recommend.

>> pre-published text and xml are at https://git.rg.net/randy/draft-l3dl

still holds true

randy