Re: [Sidrops] Call for SIDROPS WG Agenda Items

Tim Bruijnzeels <tim@nlnetlabs.nl> Thu, 12 July 2018 08:32 UTC

Return-Path: <tim@nlnetlabs.nl>
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D7FB1310A9 for <sidrops@ietfa.amsl.com>; Thu, 12 Jul 2018 01:32:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.001
X-Spam-Level:
X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nlnetlabs.nl
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 Sp_wT0ytXiOo for <sidrops@ietfa.amsl.com>; Thu, 12 Jul 2018 01:32:32 -0700 (PDT)
Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [185.49.140.10]) (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 E569013107B for <sidrops@ietf.org>; Thu, 12 Jul 2018 01:32:31 -0700 (PDT)
Received: by dicht.nlnetlabs.nl (Postfix, from userid 58) id DF506D42D; Thu, 12 Jul 2018 10:32:29 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1531384349; bh=QHJnVTldYV+ZQsoxLwBrsybQjd5IQAViqbccDT3x/xg=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=c1WI4JGYtlUiegToOwvxImd2AE9jX8bU6gt/S5JKlVHZfEry/zE9AF+MZZgB4GivW Pd8lQoyKYlZji/hehX5g5WwjRedzrrtT3iKLOjtCxVS91NJzsfTjk/eB/Go3CsWqbV BYkv8ysQq65uv8OhZU4YKYlS5ulcSBq5C2N7zBW0=
Received: from [IPv6:2a04:b900::1:f1db:51dc:e61d:a983] (unknown [IPv6:2a04:b900:0:1:f1db:51dc:e61d:a983]) by dicht.nlnetlabs.nl (Postfix) with ESMTPS id E9565D421; Thu, 12 Jul 2018 10:32:28 +0200 (CEST)
Authentication-Results: dicht.nlnetlabs.nl; dmarc=none header.from=nlnetlabs.nl
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\))
From: Tim Bruijnzeels <tim@nlnetlabs.nl>
In-Reply-To: <c41e1b16-93f2-4317-108d-b900fe964076@gmail.com>
Date: Thu, 12 Jul 2018 10:32:28 +0200
Cc: Alexander Azimov <aa@qrator.net>, Keyur Patel <keyur@arrcus.com>, "sidrops@ietf.org" <sidrops@ietf.org>, George Michaelson <ggm@algebras.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <DC540D90-31CA-4323-831D-D54FFB0938DC@nlnetlabs.nl>
References: <C0205A63-E2D5-4CD5-A109-08C61A1AEA6D@arrcus.com> <m21scsq8b8.wl-randy@psg.com> <6065B77B-9981-4273-82CD-A13C3151EA24@arrcus.com> <CAKr6gn1expF0syu69zpWhyERjvp72r169NhvudMNUSMd0A5D2A@mail.gmail.com> <D1A6D74E-ECEA-4080-90D3-0E19F1B9EE8E@arrcus.com> <CAHgCvCMcV15dMjUtGeDbzsz3eTJkvLNig7+9RV59Ch6+8c9YgA@mail.gmail.com> <D0933B81-699C-4AAD-ABA4-CCB33BA6317B@nlnetlabs.nl> <CAHgCvCOHrtEUSPwXt1JS9Wj0Aa76x_57aUzxsvY3Tb8CwZo1pQ@mail.gmail.com> <5ee309ea-a772-df45-96cc-152726e303a0@gmail.com> <CAHgCvCN-5K3FsaHx1OoyNL-zF5VAw6XvTT5T6OL1puGZfwXZhQ@mail.gmail.com> <c41e1b16-93f2-4317-108d-b900fe964076@gmail.com>
To: Andrei Robachevsky <andrei.robachevsky@gmail.com>
X-Mailer: Apple Mail (2.3445.8.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/lhQEI3R51uLbueIm08R-kSWeK0s>
Subject: Re: [Sidrops] Call for SIDROPS WG Agenda Items
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Jul 2018 08:32:43 -0000

Hi,

> On 12 Jul 2018, at 09:16, Andrei Robachevsky <andrei.robachevsky@gmail.com> wrote:
> 
> Alexander Azimov wrote on 11/07/2018 16:36:
> [...]
>> We can consider adding additional state 'unknown' or 'partial valid'. It
>> will have similar semantics to 'unknown' output of ROA validation
>> procedure. But as you know, the current practices are focussing on
>> dropping 'invalid' routes, there is no difference in processing
>> 'unknown' and 'valid' routes. 
> 
> Yes, and calling the "unknown" "valid" does not solve that problem :).
> 
> You have already defined "unverifiable", which has the same meaning as
> "unknown". I just do not see much difference between gaps in the ASPA
> chain and the presence of AS_TRANS.

It’s this paragraph in section 5 that threw me off a bit:

   If the output of the AS_PATH verification procedure is 'unverifiable'
   it means that AS_PATH can't be fully verified.  Such routes should be
   treated with caution and MAY be processed the same way as "invalid"
   routes.

'MAY be processed the same way as  “invalid” routes’ indicates a local choice, which is fine I believe. But, under partial deployment this can lead to routes being dropped a little too aggressively, no? Reading your comments in the email thread the advice during partial deployment would be to accept, rather than drop, right?






> 
> Thanks,
> 
> Andrei
>