Re: [babel] Shepherd Review of draft-ietf-babel-source-specific-04

Juliusz Chroboczek <jch@irif.fr> Wed, 10 April 2019 21:57 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 A52A9120610 for <babel@ietfa.amsl.com>; Wed, 10 Apr 2019 14:57:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 0y0MuU46vxBo for <babel@ietfa.amsl.com>; Wed, 10 Apr 2019 14:57:23 -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 F35D5120343 for <babel@ietf.org>; Wed, 10 Apr 2019 14:57:22 -0700 (PDT)
Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id x3ALvGdF026334 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 10 Apr 2019 23:57:16 +0200
Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/82085) with ESMTP id x3ALvHmv008996; Wed, 10 Apr 2019 23:57:17 +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 4C12876C64; Wed, 10 Apr 2019 23:57:20 +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 iEhUhpIaFCSG; Wed, 10 Apr 2019 23:57:14 +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 EDA4976C62; Wed, 10 Apr 2019 23:57:13 +0200 (CEST)
Date: Wed, 10 Apr 2019 23:57:13 +0200
Message-ID: <87ftqpwmkm.wl-jch@irif.fr>
From: Juliusz Chroboczek <jch@irif.fr>
To: Toke Høiland-Jørgensen <toke@toke.dk>
Cc: Donald Eastlake <d3e3e3@gmail.com>, Babel at IETF <babel@ietf.org>
In-Reply-To: <87wok1tvfx.fsf@toke.dk>
References: <CAF4+nEEfEvg_ktoudURqvCPshrA8SzL+TMGjQm6vUOFX65q==A@mail.gmail.com> <874l76xhto.wl-jch@irif.fr> <874l76w21k.fsf@toke.dk> <871s2axfei.wl-jch@irif.fr> <87y34iulxd.fsf@toke.dk> <87r2a9x3dd.wl-jch@irif.fr> <87wok1tvfx.fsf@toke.dk>
User-Agent: Wanderlust/2.15.9
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset="US-ASCII"
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Wed, 10 Apr 2019 23:57:16 +0200 (CEST)
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Wed, 10 Apr 2019 23:57:17 +0200 (CEST)
X-Miltered: at korolev with ID 5CAE66BC.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)!
X-Miltered: at potemkin with ID 5CAE66BD.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)!
X-j-chkmail-Enveloppe: 5CAE66BC.002 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/<jch@irif.fr>
X-j-chkmail-Enveloppe: 5CAE66BD.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 : 5CAE66BC.002 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000
X-j-chkmail-Score: MSGID : 5CAE66BD.000 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000
X-j-chkmail-Status: Ham
X-j-chkmail-Status: Ham
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/buWgb1-v4FkitA1hRm4O1xZ7jOA>
Subject: Re: [babel] Shepherd Review of draft-ietf-babel-source-specific-04
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, 10 Apr 2019 21:57:26 -0000

>>>> I see.  So your current behaviour can be described by
>>>> 
>>>>   MUST drop the enclosing TLV and MAY drop the whole packet
>>>> 
>>>> May the MUST be a SHOULD, or must it be a MUST?

>>> If it's a SHOULD, what is one supposed to do instead if deciding not to
>>> drop?

>> It's not required to detect the situation -- we're in nasal daemons
>> land.

> That sorta feels under-specified to me?

Babel is a distributed algorithm, and its correctness relies on all nodes
in a routing domain behaving correctly.  There are many ways in which
a buggy or malicious node can disrupt a Babel network, and an
implementation is not required to detect most of them.  (The most common
in production is a node that announces a route but doesn't actually
forward packets, e.g. due to a mis-configured firewall.)

What Donald is requesting here is that we add a requirement that every
implementation should detect one particular (and rather unlikely) instance
of incorrect behaviour, and work around it.  I don't necessarily agree
with this requirement, but I am willing to put it in if the implementation
cost is low enough.

Assuming we put that requirement in, should we mandate (MUST) that all
implementations detect that incorrect situation and work around it, or
should we merely recommend (SHOULD) that they do?  Please keep in mind
that the situation identified by Donald is rather unlikely to occur in
practice, while the implementation cost will be carried by all implementations.

-- Juliusz