Re: [babel] Mirja Kühlewind's Discuss on draft-ietf-babel-rfc6126bis-12: (with DISCUSS and COMMENT)

Juliusz Chroboczek <jch@irif.fr> Wed, 14 August 2019 16:51 UTC

Return-Path: <jch@irif.fr>
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A087A120BAD; Wed, 14 Aug 2019 09:51:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 pPZ-kci1wtt3; Wed, 14 Aug 2019 09:51:25 -0700 (PDT)
Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (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 D878F120B9F; Wed, 14 Aug 2019 09:51:24 -0700 (PDT)
Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id x7EGpJAL011255; Wed, 14 Aug 2019 18:51:19 +0200
Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 72764475E8; Wed, 14 Aug 2019 18:51:22 +0200 (CEST)
X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr
Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id mj9F58e8LnRT; Wed, 14 Aug 2019 18:51:21 +0200 (CEST)
Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 72376475E3; Wed, 14 Aug 2019 18:51:20 +0200 (CEST)
Date: Wed, 14 Aug 2019 18:51:19 +0200
Message-ID: <87imqzu1vc.wl-jch@irif.fr>
From: Juliusz Chroboczek <jch@irif.fr>
To: Mirja Kuehlewind <ietf@kuehlewind.net>
Cc: draft-ietf-babel-rfc6126bis@ietf.org, d3e3e3@gmail.com, babel-chairs@ietf.org, The IESG <iesg@ietf.org>, babel@ietf.org
In-Reply-To: <1A2B2C1B-1536-4E75-A8D7-C5612FB8AEDA@kuehlewind.net>
References: <156517737995.8257.5538554979559246700.idtracker@ietfa.amsl.com> <877e7m8b88.wl-jch@irif.fr> <1A2B2C1B-1536-4E75-A8D7-C5612FB8AEDA@kuehlewind.net>
User-Agent: Wanderlust/2.15.9y
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Wed, 14 Aug 2019 18:51:19 +0200 (CEST)
X-Miltered: at korolev with ID 5D543C07.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)!
X-j-chkmail-Enveloppe: 5D543C07.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/<jch@irif.fr>
X-j-chkmail-Score: MSGID : 5D543C07.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000
X-j-chkmail-Status: Ham
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/dMVrT9owBAGzRIeac2Fe_8zE9rs>
Subject: Re: [babel] Mirja Kühlewind's Discuss on draft-ietf-babel-rfc6126bis-12: (with DISCUSS and COMMENT)
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "A list for discussion of the Babel Routing Protocol." <babel.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/babel>, <mailto:babel-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/babel/>
List-Post: <mailto:babel@ietf.org>
List-Help: <mailto:babel-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/babel>, <mailto:babel-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Aug 2019 16:51:29 -0000

> I really don’t want to request to enforce a 3 second limit. However,
> I would like this draft to specify a limit or at minimum discuss
> suitable values for specific scenario.

Appendix B specifies values that were found to be useful in etwo kinds of
realistic scenarios.

The protocol structurally enforces minimum values of 10ms (time intervals
are carried on the wire in units of 10ms).  Values that small are not
unrealistic over gigabit Ethernet (a full-size frame over GBE is sent in 12µs).

>>> More concretely I think there are these cases that need more guidance:
>> 
>> I agree.  I've added a short discussion of packet pacing at the end of
>> 3.1, and I refer to it at suitable places.

> Thanks. I was also hoping that you could make any recommendation on how
> to implement that e.g. a fixed delay of a certain (default) value or
> based on some other knowledge. If that is a SHOULD and no further
> implementation example is given, I would be afraid that the risk is high
> that people simple don’t implement this part.

You do realise it's a very high bar you're setting?

There exist standard techniques for packet pacing (static delay, dynamic
delay, deadline-first scheduling, etc.).  I hope you're not requesting
that I transform this document in a tutorial about packet scheduling.

I'll point out that RFC 5340 does not explain how to pace Dijkstra
recomputation.  There's a good discussion of the issue in Gredler's book
about IS-IS.  I have no idea whether Gredler's book reflects the behaviour
of modern implementations.

>>> - Section 3.7.2. (Triggered Updates) advises to send a message multiple
>>> times for redundancy in case of loss. 5 and 2 are mentioned as example
>>> values. Please provide a normative default value and a normative maximum
>>> value here.

>> Done for the normative max and recommendation to avoid tail loss.
>> I haven't made the default values normative.

> Why not? 

What exact problem are we trying to solve here?  Do you expect that the
current non-normative language will cause issues?

>>> - In section 4.1.1 the update interval needs a lower limit (e.g. 3 seconds)
>> 
>> I strongly disagree.  Sub-second convergence after a mobility event is
>> required in some networks.

> (See above) Maybe then 0.1 seconds is a suitable minimum value…?

As mentioned above, the protocol structurally imposes a lower bound of
10ms, which is not unrealistic over GBE.

>>> and a recommend default value would be could as well (Note that there
>>> are other part in section 3 where the update value is discussed as well).

>> Appendix B.

> I think this needs normative language in the body of the document.

I'm sorry, Mirja, I disagree.  See my comments about GBE above.

>>> - Section 3.8.2.4. mentions network load when requests are sent to all
>>> neighbours after reboot. Please provide more guidance about how to pace out
>>> these requests.

>> I've removed this section altogether.

> Why?

The mechanism is not essential, and we're unable to give more precise
guidance that applies across a wide range of networks.  I prefer to remove
the mechanism rather than give bad advice.

-- Juliusz