Re: [Sidrops] question on draft-ietf-sidrops-aspa-verification-04

Alexander Azimov <a.e.azimov@gmail.com> Fri, 05 June 2020 15:27 UTC

Return-Path: <a.e.azimov@gmail.com>
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 982533A07BB for <sidrops@ietfa.amsl.com>; Fri, 5 Jun 2020 08:27:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 PHwmep3qJNol for <sidrops@ietfa.amsl.com>; Fri, 5 Jun 2020 08:27:41 -0700 (PDT)
Received: from mail-oo1-xc2b.google.com (mail-oo1-xc2b.google.com [IPv6:2607:f8b0:4864:20::c2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E1AB3A07B9 for <sidrops@ietf.org>; Fri, 5 Jun 2020 08:27:41 -0700 (PDT)
Received: by mail-oo1-xc2b.google.com with SMTP id 18so2055820ooy.3 for <sidrops@ietf.org>; Fri, 05 Jun 2020 08:27:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nMCYwJoXuVsoJ/TLgKMyWWc5T7u6eLqOjjI6D9xSQbw=; b=qy20zaHT6AKxjQFhkw+RI7xdi5xvakrDuSJ/Ofw/8wJ5ZPXOZU9NR0ybz507zRqc1C OYGVwGaOp3d8sNaQZVV2Wk67FusNR95P0AUkQ4zH/bzu+jKGhmWZZBQi6C81yqJM070U wFB5h9wBpL1hmya7U7fpoJ7+5G8HEA/fk6t00SW6wFvl0WkF2jXbmoA68T/Jpqx12gmO 7Ym4SyCCt+NG2PW6+tfhS9RSYVvAfq1KEEp5W+oIp+7JGJlRI67b09nb3iUHBFOi6hxV 7xOzYdsg/sZy1OZXyKKD2fkgwCuFB7M720mEZxZ3AcPY0FgylBuCpjZ7XTkvv4w+/Qcw QVcA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nMCYwJoXuVsoJ/TLgKMyWWc5T7u6eLqOjjI6D9xSQbw=; b=HJ2Wq4FYkqC4GHpk54fPok4W7YYdCIYHk1JXokgbQrAnH+YLO0nPjWL8OHGRC1JpsS OCRELe9JG3F+s7eeH6idotCa3l80tVfMv0ygsadjgFMMZW0HWzgTn5sGyqLSDPojDBzZ 2Rh9SX+KmV0kgxO57DWwDvX52sU/B7gIud61px830mxPqiKl8sqfPMmRWLRFwTYsMZve /uyqM/A4/bxyRhu3DY1xFdLZ6JHJCNGCis8nP7rQURkClCFLLrbx2VgeToEAsC+bC6ip vO1whtVE26jNdDw16wJw9uLp3uQU0+p8oYuPfOMtlItlH2dJ84fziSrCFtz+3NZhC5lw Ggeg==
X-Gm-Message-State: AOAM531s02wG+GdWMWXZM0Iw9kxNpU8QCzuNYmCtWfgxe6ont9t7lL0u z5H4UsD/90fni+hTV8UJfswGpj698Xb76Rh10VQ=
X-Google-Smtp-Source: ABdhPJyoIUhLfnW0OpEsA+jYgDdqoWl1h9OY5YOijc3RwhGI4xbu6wh0sZK5ZbGAez/qGjTJTD89jJilKrxm9amAHbg=
X-Received: by 2002:a4a:e6d2:: with SMTP id v18mr8122127oot.34.1591370860488; Fri, 05 Jun 2020 08:27:40 -0700 (PDT)
MIME-Version: 1.0
References: <C01B0098369B2D4391851938DA6700B7179F9EAB@dggeml512-mbs.china.huawei.com> <CAEGSd=APMCnnd5mrnMKtti-QWy1m7r5JfJsf7HynZqyXWwsZHg@mail.gmail.com> <C01B0098369B2D4391851938DA6700B717A0C386@DGGEML532-MBX.china.huawei.com> <CAEGSd=Bk3Lgte1L0KKP_GU+ieDpETvLk1JTVTLZTv-Z5NrVUoQ@mail.gmail.com> <C01B0098369B2D4391851938DA6700B717A28020@DGGEML532-MBX.china.huawei.com> <24249.23930.126312.2484@oz.mt.att.com> <C01B0098369B2D4391851938DA6700B717A2CABA@DGGEML532-MBX.china.huawei.com> <CAEGSd=AbOu88VBqjR90+O1H39Pq-1cf+xRb971tZXxSLmL8Ntw@mail.gmail.com> <C01B0098369B2D4391851938DA6700B717A35EC8@DGGEML532-MBX.china.huawei.com>
In-Reply-To: <C01B0098369B2D4391851938DA6700B717A35EC8@DGGEML532-MBX.china.huawei.com>
From: Alexander Azimov <a.e.azimov@gmail.com>
Date: Fri, 05 Jun 2020 18:27:29 +0300
Message-ID: <CAEGSd=Dorh5dNaxdS73YaeJXv+5iHBf3B2GbzkE9_5N3fsN3iQ@mail.gmail.com>
To: Guyunan <guyunan@huawei.com>
Cc: Jay Borkenhagen <jayb@braeburn.org>, SIDR Operations WG <sidrops@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000d86b3c05a757e611"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/ENsaB9V97Ks3FQ6gFa9HcPshWcM>
Subject: Re: [Sidrops] question on draft-ietf-sidrops-aspa-verification-04
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
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: Fri, 05 Jun 2020 15:27:43 -0000

Yanun, sorry for the late response.

Your suggestion to ignore the first ASN in the path if the prefix is
received from IXP with its ASN in the path sounds reasonable for me.
It will improve the quality of ingress filtering by IXP members. I will add
it to the todo list for the next version.

ср, 20 мая 2020 г. в 10:53, Guyunan <guyunan@huawei.com>:

> Alex,
>
>
>
> Please see inline.
>
>
>
> *From:* Alexander Azimov [mailto:a.e.azimov@gmail.com]
> *Sent:* Friday, May 15, 2020 10:33 PM
> *To:* Guyunan <guyunan@huawei.com>
> *Cc:* Jay Borkenhagen <jayb@braeburn.org>; SIDR Operations WG <
> sidrops@ietf.org>
> *Subject:* Re: [Sidrops] question on
> draft-ietf-sidrops-aspa-verification-04
>
>
>
> Jay, Yunan,
>
>
>
> Thank you for the suggestion. The mutual transit sounds good to me too.
>
>
>
> Yunan: All right, so let’s assume in one case, the IXP does not prepend
> its own ASN, meaning the RS and one of its RS clients receives the same
> AS_Path, right? According to Section 5.1 (see below) and Section 5.2 (see
> below), I’m wondering why the detection rules are different for this RS
> (obeying Section 5.1) and this RS client (obeying Section 5.2) regarding
> the same AS_Path.
>
> I think I got your point. You are asking why can't we process prefixes
> from RS likewise prefixes from peers, right?
>
>
>
> Yunan: Right.
>
>
>
> The reason is that I've tried to describe the policy that will be
> applicable in general, so it covers the worst-case scenario when IX places
> it ASN in the path. It possible to say that we can apply one policy if IX
> is present and another policy if it is not, but this will
> introduce additional complexity with operational dependencies on IX
> configuration.
>
>
>
>
> Yunan: So let me try to clear things up here. Do you mean there are
> possibly two cases: 1. IXP ASN is placed in the path 2. IXP ASN is not
> placed in the path? For case 2, the handling is supposed to be the same as
> processing prefixes from peers, right? For case 1, what is the possible
> handing procedure? Removing the IXP ASN first and then treat like prefixes
> from peers?
>
>
>
>
>
> --
>
> Best regards,
>
> Alexander Azimov
>


-- 
Best regards,
Alexander Azimov