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

Nick Hilliard <nick@foobar.org> Thu, 10 March 2022 23:12 UTC

Return-Path: <nick@foobar.org>
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 A46413A07B7; Thu, 10 Mar 2022 15:12:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 T0rrQjjHqvW8; Thu, 10 Mar 2022 15:11:56 -0800 (PST)
Received: from mail.netability.ie (mail.netability.ie [46.182.8.5]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DABDF3A07D4; Thu, 10 Mar 2022 15:11:53 -0800 (PST)
Received: from crumpet.local (admin.ibn.ie [46.182.8.8]) by mail.netability.ie (Postfix) with ESMTPSA id 8FBB79CC2D; Thu, 10 Mar 2022 23:11:49 +0000 (GMT)
To: "Sriram, Kotikalapudi (Fed)" <kotikalapudi.sriram@nist.gov>
Cc: "grow@ietf.org" <grow@ietf.org>, "sidrops@ietf.org" <sidrops@ietf.org>
References: <SA1PR09MB8142093BE50A27A7EED132D884099@SA1PR09MB8142.namprd09.prod.outlook.com> <0db7749f-66fd-5def-a8bb-3ee316cf2ca1@foobar.org> <SA1PR09MB81421BCBA7FB59615A7638A5840B9@SA1PR09MB8142.namprd09.prod.outlook.com>
From: Nick Hilliard <nick@foobar.org>
Message-ID: <fa0b5b32-6541-f493-e02b-fe75d44dacd5@foobar.org>
Date: Thu, 10 Mar 2022 23:11:47 +0000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:52.0) Gecko/20100101 PostboxApp/7.0.54
MIME-Version: 1.0
In-Reply-To: <SA1PR09MB81421BCBA7FB59615A7638A5840B9@SA1PR09MB8142.namprd09.prod.outlook.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/swOt_bTh1eyq2ZH78f151O5IvUQ>
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: Thu, 10 Mar 2022 23:12:01 -0000

Sriram, Kotikalapudi (Fed) wrote on 10/03/2022 03:31:
> 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?

I would seriously doubt it.  There are some "Tier 1" and "Tier 2" 
providers who peer using route servers at IXPs, but it's a bit unusual 
(and entertaining to hear them strenuously denying that this ever happens).

Non-transparent RS's were used until a couple of years ago but I'm not 
aware of any left at this point. Even when non-transparent RS's were 
more widespread, I would have expected the intersection of these two 
groups to be null, and that if there were an intersection, the 
Tier1/Tier2 providers would not be upset if those paths were dropped / 
marked as invalid.

> 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".

yes, this is reasonable.

Nick