Re: [Sidrops] IXP Route Server question

Christopher Morrow <christopher.morrow@gmail.com> Tue, 08 March 2022 20:04 UTC

Return-Path: <christopher.morrow@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 2D1543A13ED; Tue, 8 Mar 2022 12:04:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.107
X-Spam-Level:
X-Spam-Status: No, score=-7.107 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, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=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 1XiVaK-cfoxq; Tue, 8 Mar 2022 12:04:11 -0800 (PST)
Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (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 367F23A1941; Tue, 8 Mar 2022 12:02:53 -0800 (PST)
Received: by mail-qt1-x834.google.com with SMTP id bt3so144643qtb.0; Tue, 08 Mar 2022 12:02:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JOJab311AM497SCI9UOBLSgwlbozAyhfxkcQ0Nx3m24=; b=eMxxAJGELMy4LfuNsQ0/OCSWrtGnrHCoEaEAGMpBKz6+kNXuRad8X+tp0k+/DMEtS+ hKykUXq6erjKfLXu8Ys1T9ybhu/0bHNCsurd73787kfJ5zmlQAlOlmKlHFT0ghi/EOe1 qJjDGmohDM2GaEZecVJj93oulOAh71F7/A5Q2LGpTVg5ui2sGDNH/f39h7Q2APOJ1At9 Gjtdn5XD0btrKbC1v9BXw/VrRriLCaCksUeP3FysYbT0N49Ro9L1ZpA9qJ4NgAQbZz6y UMP2PZh9acykoDZ1GVMyVr7MGvIh6KHu2iItBmU7lF0NcZTL60zYBBXtXCyLU9QWTKcj rZdg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JOJab311AM497SCI9UOBLSgwlbozAyhfxkcQ0Nx3m24=; b=N4JJhxeYbJEeVKD+DmUoVdo+F3sW4teSKp9csyQbq2gQOuC/x6i6v9MZX3iNr/hSem b2tegENgjfB2d7oYNnAqBZck8VBuykMIR+CiSzUBl+9Af2wtXAaAf0SIXSiuRaYmlqUr g4yuj0m3IlS6GfAgcIqp1PF5fsumd1ZijLovi/Je5Q08bBtNoqreuDkbwk149ePmA786 p4M72Jje4XK4EPYoHSnSfIMFgyB9efJsLdQKCbqcOMbllDvNmFsE0uLZNB6FbRipTOXX 9tythF0blOPyajPU6Ug4LtsKl5cuMp5iZmFHV0Cdbo3mpjKlD/NNCxzW3Cc5I916GXTq X1cg==
X-Gm-Message-State: AOAM532N0MSotrK9FLwqlZ5yiMJFQzMASyFmYSLUQfDq4DVLMULu4ffo EyyfRhaiDiZw0sdxD+hyEqZr/ci6KYkm/3G32QS+MhLSu9o=
X-Google-Smtp-Source: ABdhPJz26pX7z7aEzkM8f+CYq5wbURZOn6TNsu6Zde0Rc2iTlXItG2ooPIdY+cilxizJf86seOTSXXg6UiIyAg2g7XQ=
X-Received: by 2002:ac8:7dd1:0:b0:2e0:6fe1:189b with SMTP id c17-20020ac87dd1000000b002e06fe1189bmr4453863qte.629.1646769771542; Tue, 08 Mar 2022 12:02:51 -0800 (PST)
MIME-Version: 1.0
References: <SA1PR09MB8142093BE50A27A7EED132D884099@SA1PR09MB8142.namprd09.prod.outlook.com>
In-Reply-To: <SA1PR09MB8142093BE50A27A7EED132D884099@SA1PR09MB8142.namprd09.prod.outlook.com>
From: Christopher Morrow <christopher.morrow@gmail.com>
Date: Tue, 8 Mar 2022 15:02:40 -0500
Message-ID: <CAL9jLaaB9k9-KjcERxM_TBqTduK1N+DaM=N8rpF9to0NdAQmzA@mail.gmail.com>
To: "Sriram, Kotikalapudi (Fed)" <kotikalapudi.sriram=40nist.gov@dmarc.ietf.org>
Cc: "grow@ietf.org" <grow@ietf.org>, "sidrops@ietf.org" <sidrops@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000427f3205d9ba77b7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/u2dCKk81RMWk2eqNpO_ezQhjemg>
Subject: Re: [Sidrops] 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: Tue, 08 Mar 2022 20:04:14 -0000

On Tue, Mar 8, 2022 at 2:36 PM Sriram, Kotikalapudi (Fed)
<kotikalapudi.sriram=40nist.gov@dmarc.ietf.org> wrote:

> 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?
>
>
it seems unlikely to me that an ISP would pick up a 'customer' (someone
that pays them to transport packets) at an IXP fabric.
Might it happen? sure? is it messy? yes!

1) that's probably a shared port
2) there are other folk feeding routes and packets into the mix
3) how many came through the 'customer' port (which you can't really know
easily) vs other participants on the ix
4) what capacity planning could the 'customer' do here? (none, basically
with respect to the remote ISP port)

Your question might work also as:
  "ISP A has a customer C on a direct link in location Y.
   ISP A is present at IXP-Z, so is customer C, though they do not
bilaterally peer (not do they interconnect at the IXP).
  ISP A can still see Customer C's routes through the IXP-Z Route Server."

that seems plausible, but not a desired outcome for the ISP :) since they
will be unlikely to collect pesos for the traffic
which MAY pass across that interconnect.