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
- [Sidrops] IXP Route Server question Sriram, Kotikalapudi (Fed)
- Re: [Sidrops] IXP Route Server question Christopher Morrow
- Re: [Sidrops] [GROW] IXP Route Server question Christopher Morrow
- Re: [Sidrops] [GROW] IXP Route Server question Nick Hilliard
- Re: [Sidrops] [GROW] IXP Route Server question Robert Raszuk
- Re: [Sidrops] [GROW] IXP Route Server question Robert Raszuk
- Re: [Sidrops] [GROW] IXP Route Server question Christopher Morrow
- Re: [Sidrops] IXP Route Server question Ben Maddison
- Re: [Sidrops] IXP Route Server question Randy Bush
- Re: [Sidrops] IXP Route Server question Randy Bush
- Re: [Sidrops] [GROW] IXP Route Server question Sriram, Kotikalapudi (Fed)
- Re: [Sidrops] IXP Route Server question Sriram, Kotikalapudi (Fed)
- Re: [Sidrops] [GROW] IXP Route Server question Nick Hilliard
- Re: [Sidrops] [GROW] IXP Route Server question Ben Maddison
- Re: [Sidrops] [GROW] IXP Route Server question Sriram, Kotikalapudi (Fed)
- Re: [Sidrops] [GROW] IXP Route Server question Zhuangshunwan
- Re: [Sidrops] [GROW] IXP Route Server question Nick Hilliard
- Re: [Sidrops] [GROW] IXP Route Server question Randy Bush
- Re: [Sidrops] [GROW] IXP Route Server question Sriram, Kotikalapudi (Fed)
- Re: [Sidrops] [GROW] IXP Route Server question Sriram, Kotikalapudi (Fed)
- Re: [Sidrops] [GROW] IXP Route Server question Nick Hilliard
- Re: [Sidrops] [GROW] IXP Route Server question Zhuangshunwan
- Re: [Sidrops] [GROW] IXP Route Server question Mosher, Rob