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

Joerg Ott <> Mon, 25 May 2020 19:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 523E63A0903; Mon, 25 May 2020 12:27:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VxRD7s0llOxr; Mon, 25 May 2020 12:27:19 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B31233A08F0; Mon, 25 May 2020 12:27:18 -0700 (PDT)
Received: by (Postfix, from userid 107) id EF39E1C08A2; Mon, 25 May 2020 21:27:14 +0200 (CEST)
Received: (Authenticated sender: ott) by (Postfix) with ESMTPSA id 2FF841C088D; Mon, 25 May 2020 21:27:12 +0200 (CEST) (Extended-Queue-bit
To: Randy Bush <>
References: <> <> <> <>
From: Joerg Ott <>
Message-ID: <>
Date: Mon, 25 May 2020 21:27:11 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [Tsv-art] Tsvart early review of draft-ietf-lsvr-l3dl-03
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Review Team <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 25 May 2020 19:27:23 -0000

No worries, I am happy about any break I get...

On 23.05.20 20:32, Randy Bush wrote:
> 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?

Not really.  This all appears artificial if you need two or three
packets for app layer fragmentation.  Maybe one could write something
substantially improved along the lines of:
To prevent packet bursts, a sender SHOULD pace the transmission of
application layer fragmented data units as follows: A sender MAY
transmit up to K packets containing fragments in a burst and SHOULD
pace bursts ... (but how?)

>>>> 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.

Sold :-)

>>>> 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.

Count to N, raise an alert, pause.  Or something like this?

>>> pre-published text and xml are at
> still holds true

Thanks -- best,