IETF Logo Mail Archive

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

Guyunan <guyunan@huawei.com> Wed, 20 May 2020 07:53 UTC

Return-Path: <guyunan@huawei.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 91B1D3A3B47 for <sidrops@ietfa.amsl.com>; Wed, 20 May 2020 00:53:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 NB1xtK2NRDtq for <sidrops@ietfa.amsl.com>; Wed, 20 May 2020 00:53:54 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 C4D5E3A3B46 for <sidrops@ietf.org>; Wed, 20 May 2020 00:53:53 -0700 (PDT)
Received: from lhreml740-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 6B70E992BE5D8ABFFBEB; Wed, 20 May 2020 08:53:49 +0100 (IST)
Received: from lhreml740-chm.china.huawei.com (10.201.108.190) by lhreml740-chm.china.huawei.com (10.201.108.190) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Wed, 20 May 2020 08:53:49 +0100
Received: from DGGEML422-HUB.china.huawei.com (10.1.199.39) by lhreml740-chm.china.huawei.com (10.201.108.190) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1913.5 via Frontend Transport; Wed, 20 May 2020 08:53:48 +0100
Received: from DGGEML532-MBX.china.huawei.com ([169.254.8.202]) by dggeml422-hub.china.huawei.com ([10.1.199.39]) with mapi id 14.03.0487.000; Wed, 20 May 2020 15:53:45 +0800
From: Guyunan <guyunan@huawei.com>
To: Alexander Azimov <a.e.azimov@gmail.com>
CC: Jay Borkenhagen <jayb@braeburn.org>, SIDR Operations WG <sidrops@ietf.org>
Thread-Topic: [Sidrops] question on draft-ietf-sidrops-aspa-verification-04
Thread-Index: AdYdy08vebzctU/sRBSjzmRHyKjH2ACpL0yAALmBBzAA2L1MAAAdy1hgAArDfQAANA3jsACVy1GAAP3RyoA=
Date: Wed, 20 May 2020 07:53:45 +0000
Message-ID: <C01B0098369B2D4391851938DA6700B717A35EC8@DGGEML532-MBX.china.huawei.com>
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>
In-Reply-To: <CAEGSd=AbOu88VBqjR90+O1H39Pq-1cf+xRb971tZXxSLmL8Ntw@mail.gmail.com>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.108.203.151]
Content-Type: multipart/alternative; boundary="_000_C01B0098369B2D4391851938DA6700B717A35EC8DGGEML532MBXchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/_h-o1SziT11ZwlT2NdhW0A6cM8U>
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: Wed, 20 May 2020 07:53:56 -0000

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

v2.23.0 | Report a Bug | By Email