IETF Logo Mail Archive

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

Alexander Azimov <a.e.azimov@gmail.com> Fri, 15 May 2020 14:33 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 5AEBF3A0A49 for <sidrops@ietfa.amsl.com>; Fri, 15 May 2020 07:33:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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] 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 Ff-PZpOdp6tX for <sidrops@ietfa.amsl.com>; Fri, 15 May 2020 07:32:59 -0700 (PDT)
Received: from mail-oi1-x232.google.com (mail-oi1-x232.google.com [IPv6:2607:f8b0:4864:20::232]) (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 21D3E3A099E for <sidrops@ietf.org>; Fri, 15 May 2020 07:32:59 -0700 (PDT)
Received: by mail-oi1-x232.google.com with SMTP id c12so2399805oic.1 for <sidrops@ietf.org>; Fri, 15 May 2020 07:32:59 -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=yNnSbszmjdz5ijAFGXP9OpgS6cxapkczHfGA51gOaII=; b=TQHb2au877fiVy65mYRofgvS8LpWaYrX21f/rK83fYYE/+vgGsLJ7lRxJTw0SsM1q7 uzq/8zPr/YEZSk84QCG2ZemxxRNQKrfhLJyusB1ZW6esbTzjdxiUM/gPJ95IdYqBa+5q 3vJqwOdq+QiEdoeTdTRMKeazTh+F1diaENOEQI4sBo2wF/Szy5fteCcBTh4GOtUH3SJ/ nvLqLkNgSoHxFxqoFSVYhIR6i3dF3dpE3ATMK59LCLK6m0aHUF/N5Bqezhz9T+eA2gLl EjkZmskXa9LtcpYuhMB0SURfHkdbXZMjihxc5zkGkK53/jIZ+Ld8zxBkKUr9/zy1Lhte rZRw==
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=yNnSbszmjdz5ijAFGXP9OpgS6cxapkczHfGA51gOaII=; b=OcLyRGcmelpswGI8S+RVv4jMJ/b7752feko0Lm6FJgHsUQT+ZZX/iGdktCBReoujD7 hEV0UaojI6DWYgex5zDafBWEPla2L84pqWHMZibA4mql8pH/9LL03fRnQC8KrT2ux6mn f31OG++KPljIN/emoFVJtfvrkNeyvCzLOEMBR0wxwOWD3MjnitCPJJC7w0e0cdKNd/73 vsAE7bLmcq2sqCzChJ+sz7WIMoyguKjcJJ+/k/Butnzx5GYQS2wrkLKo4u1Jr+6zJFtw YEH8EegZL/RR5jhqPlprr5Fp1zEkuaqDIYmHNSd+ZS2luz+pZ6JnLV6jRHUNf2As1GG5 ccSw==
X-Gm-Message-State: AOAM5316Y15PYFW2gSTvpneF7KfYXE+iGqqO2I3xA6NiX4GeN//CBqv/ WLi0ZPqOWJNFL+Ph+1PAd3hQKtv7mBflLhItwKs=
X-Google-Smtp-Source: ABdhPJzfqTKrbn8qM3MDpy5Ywe6gH45K2WtERdSB+9UAjEKxQCW4ZTPflO0eSmg4Wzrd3KV13jE0dxbYPHfl2pUw8T0=
X-Received: by 2002:aca:318f:: with SMTP id x137mr2442131oix.4.1589553178309; Fri, 15 May 2020 07:32:58 -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>
In-Reply-To: <C01B0098369B2D4391851938DA6700B717A2CABA@DGGEML532-MBX.china.huawei.com>
From: Alexander Azimov <a.e.azimov@gmail.com>
Date: Fri, 15 May 2020 17:32:47 +0300
Message-ID: <CAEGSd=AbOu88VBqjR90+O1H39Pq-1cf+xRb971tZXxSLmL8Ntw@mail.gmail.com>
To: "Guyunan (Yunan Gu, IP Technology Research Dept. NW)" <guyunan@huawei.com>
Cc: Jay Borkenhagen <jayb@braeburn.org>, SIDR Operations WG <sidrops@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000008b791705a5b0b079"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/EhoEgL2fN-E9VXAFm_he2aOfFDM>
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, 15 May 2020 14:33:00 -0000

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?

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.


-- 
Best regards,
Alexander Azimov

v2.23.0 | Report a Bug | By Email