Re: [Sidrops] [GROW] IXP Route Server question

Zhuangshunwan <zhuangshunwan@huawei.com> Sat, 12 March 2022 01:43 UTC

Return-Path: <zhuangshunwan@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 90FBF3A0D31; Fri, 11 Mar 2022 17:43:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable 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 qNBsrWatpIJR; Fri, 11 Mar 2022 17:43:26 -0800 (PST)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22DAA3A0D3E; Fri, 11 Mar 2022 17:43:26 -0800 (PST)
Received: from fraeml703-chm.china.huawei.com (unknown [172.18.147.206]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4KFlsH0vv1z67ZTx; Sat, 12 Mar 2022 09:41:55 +0800 (CST)
Received: from kwepeml500004.china.huawei.com (7.221.188.141) by fraeml703-chm.china.huawei.com (10.206.15.52) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2308.21; Sat, 12 Mar 2022 02:43:20 +0100
Received: from kwepeml500004.china.huawei.com (7.221.188.141) by kwepeml500004.china.huawei.com (7.221.188.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Sat, 12 Mar 2022 09:43:19 +0800
Received: from kwepeml500004.china.huawei.com ([7.221.188.141]) by kwepeml500004.china.huawei.com ([7.221.188.141]) with mapi id 15.01.2308.021; Sat, 12 Mar 2022 09:43:19 +0800
From: Zhuangshunwan <zhuangshunwan@huawei.com>
To: "Sriram, Kotikalapudi (Fed)" <kotikalapudi.sriram=40nist.gov@dmarc.ietf.org>, Nick Hilliard <nick@foobar.org>
CC: "grow@ietf.org" <grow@ietf.org>, "sidrops@ietf.org" <sidrops@ietf.org>
Thread-Topic: [GROW] IXP Route Server question
Thread-Index: AdgzI9AepbPeSUXIRROpCLpxuIKvkgAD5f2AAD5dAsAAYRU1MA==
Date: Sat, 12 Mar 2022 01:43:19 +0000
Message-ID: <82b678f2254b42fabe3bfbcef4b8d28c@huawei.com>
References: <SA1PR09MB8142093BE50A27A7EED132D884099@SA1PR09MB8142.namprd09.prod.outlook.com> <0db7749f-66fd-5def-a8bb-3ee316cf2ca1@foobar.org> <SA1PR09MB81421BCBA7FB59615A7638A5840B9@SA1PR09MB8142.namprd09.prod.outlook.com>
In-Reply-To: <SA1PR09MB81421BCBA7FB59615A7638A5840B9@SA1PR09MB8142.namprd09.prod.outlook.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.108.152.178]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/-8MT5CT4NN0hirgh6f9i7zufrXc>
Subject: Re: [Sidrops] [GROW] IXP Route Server question
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: Sat, 12 Mar 2022 01:43:31 -0000

Hi Sriram,

> The ASPA verification draft treats the relationship of RS to RS-client as similar
> to that of Provider to Customer. Seems reasonable? The AS of an RS client
> includes the RS's AS in its ASPA as a "Provider".
>

IMO, the ASPA verification draft regards the relationship between RS and RS-client as "peer-to-peer", maybe my understanding is wrong, I will read the ASPA verification draft again.

BR,
Shunwan

> -----Original Message-----
> From: GROW [mailto:grow-bounces@ietf.org] On Behalf Of Sriram,
> Kotikalapudi (Fed)
> Sent: Thursday, March 10, 2022 11:31 AM
> To: Nick Hilliard <nick@foobar.org>
> Cc: grow@ietf.org; sidrops@ietf.org
> Subject: Re: [GROW] IXP Route Server question
> 
> Nick and all,
> 
> Thank you. What you all shared/discussed is very useful info.
> 
> >Almost all RS's are transparent these days.  Usually IXPs go to lengths to
> ensure that the RS ASN doesn't appear in the AS path.
> 
> Good to know that. Well, that means there can be an occasional RS that is
> non-transparent. When there is a non-transparent RS, could there be big ISPs
> (Tier-1, Tier-2) present there as RS-clients?
> 
> The ASPA verification draft treats the relationship of RS to RS-client as similar
> to that of Provider to Customer. Seems reasonable? The AS of an RS client
> includes the RS's AS in its ASPA as a "Provider".
> 
> Sriram
> 
> -----Original Message-----
> From: Nick Hilliard <nick@foobar.org>
> Sent: Tuesday, March 8, 2022 4:28 PM
> To: Sriram, Kotikalapudi (Fed) <kotikalapudi.sriram@nist.gov>
> Cc: grow@ietf.org; sidrops@ietf.org
> Subject: Re: [GROW] IXP Route Server question
> 
> Sriram, Kotikalapudi (Fed) wrote on 08/03/2022 19:36:
> > This question has relevance to the ASPA method for route leak
> > detection.
> >
> > Is it possible that an ISP AS A peers with a customer AS C via a
> > non-transparent IXP AS B?
> > IOW, the AS path in routes propagated by the ISP A for customer C's
> > prefixes looks like this:  A B C.
> > I.e., can the AS of a non-transparent IXP/RS appear in an AS path in
> > the middle between an ISP and its customer?
> 
> Almost all RS's are transparent these days.  Usually IXPs go to lengths to
> ensure that the RS ASN doesn't appear in the AS path.
> 
> Some organisations provide transit over IXPs, but it's a minority thing.
> It would be very peculiar if an organisation provided transit over an IXP via
> an RS.
> 
> Some organisations provide transit to ASNs over a direct physical connection
> while maintain peering with their customer over an IXP port.
> Usually this happens by accident, but occasionally it can happen by design.
> 
> The answer to your question is that it would be technically possible, but it
> would be so peculiar and stupid that it should be considered a mistake in the
> situations where it was intentional. In all other situations, it would be a leak.
> Generally it would be safe to assume that this sort of configuration was in
> error.
> 
> Nick
> _______________________________________________
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow