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

Robert Raszuk <robert@raszuk.net> Tue, 08 March 2022 20:16 UTC

Return-Path: <robert@raszuk.net>
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 98F993A13F3 for <sidrops@ietfa.amsl.com>; Tue, 8 Mar 2022 12:16:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.108
X-Spam-Level:
X-Spam-Status: No, score=-2.108 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, HTML_MESSAGE=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
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net
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 nOOrE5-IRiNm for <sidrops@ietfa.amsl.com>; Tue, 8 Mar 2022 12:15:57 -0800 (PST)
Received: from mail-vs1-xe2d.google.com (mail-vs1-xe2d.google.com [IPv6:2607:f8b0:4864:20::e2d]) (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 DC1573A13ED for <sidrops@ietf.org>; Tue, 8 Mar 2022 12:15:56 -0800 (PST)
Received: by mail-vs1-xe2d.google.com with SMTP id u82so71557vsu.0 for <sidrops@ietf.org>; Tue, 08 Mar 2022 12:15:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Y7RGZFHfO+nov+4hnHIX69PWk5TrVGhPqGi6fHv5hWU=; b=LqIdSYZb5m0ngEkjN58/nlF496uz2wxPIvV8jvaLcYnnxhp4Nuk4vmPJkGWs1cwanj k2BD6M1JJM/CeZ/0cqWf+ur1Kxv6vgdR+idNVnCYyLkB3tSuLMrS/73Tz1rmcj+qtZE3 S3XXBESUJLWGwpyK+9jrfLL97bcIYqw8I/v1TNixLTN2VWANIL/L+80Iv6cTYMqKc97B P8O7F9rgaxHZb+bWGbPtpZesVcaj01pm4DegOEgAvJaP4vOScfEO4Dm8Kf97C9G8aExE n/crS5ysez9OWatNSEP/FXmv/RL1wMNJ/6Nk5WmLnxRkTQG17jS3xfjbgKsyoJ5J1pYv Qpzg==
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=Y7RGZFHfO+nov+4hnHIX69PWk5TrVGhPqGi6fHv5hWU=; b=X9mwQzjgo+SPSwdO9ZgxlNq36ZiwKWGyNns2TfbTtiifABfryhaxfE81dB/743fYKy M3MWlY/0zIBO2f0mGp8UGta+pbZXmqTSSh9WtRehBuk8714POpd3JrzzgBWqH7g3ZS6h u/6pSj1oKobTMk0o4NtVlA+F0fTHG5ceSq7XgCnx/3Z/tawK/Zjc8Hxj3w4dFv56+Bij 2NRDMsES4w9ZAjyKtHlMHg+FN4PX63VG5B1I+jYp87bxAbV5Dxcc7JAW6MkvuzNr/xXi VsBX4vBRl9ApX5+FiIZ/pwRiSJnzEgAdogvIBIO4wLcm4x6XA/tgYEJPyCttFXz9Sukp qKDw==
X-Gm-Message-State: AOAM532uuLPzHr95vOa7sZiYBV9hk747KMNyFXBGsKh2obi4K3FL6DLk DxjCbASzfSRqvh600wjdvCFQleCTXXvEd+HE8tYeDA==
X-Google-Smtp-Source: ABdhPJx7h/HlWhsM+qgOZSNA9vipqTz3hr0Jm+hHoKSQCkSZmeMF97MxMZmBITcMk4JpNZqgwJ5avnLqHh+/ioSTHlk=
X-Received: by 2002:a67:e893:0:b0:31c:e6c:6f69 with SMTP id x19-20020a67e893000000b0031c0e6c6f69mr7885208vsn.85.1646770555491; Tue, 08 Mar 2022 12:15:55 -0800 (PST)
MIME-Version: 1.0
References: <SA1PR09MB8142093BE50A27A7EED132D884099@SA1PR09MB8142.namprd09.prod.outlook.com> <CAL9jLaaB9k9-KjcERxM_TBqTduK1N+DaM=N8rpF9to0NdAQmzA@mail.gmail.com>
In-Reply-To: <CAL9jLaaB9k9-KjcERxM_TBqTduK1N+DaM=N8rpF9to0NdAQmzA@mail.gmail.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Tue, 8 Mar 2022 21:16:18 +0100
Message-ID: <CAOj+MMFaNDt+5siiaZBM515bD66kX-NW5jyFkv+G3XzABQXi3A@mail.gmail.com>
To: Christopher Morrow <christopher.morrow@gmail.com>
Cc: "Sriram, Kotikalapudi (Fed)" <kotikalapudi.sriram=40nist.gov@dmarc.ietf.org>, "grow@ietf.org" <grow@ietf.org>, "sidrops@ietf.org" <sidrops@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000fca96d05d9baa535"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/2u4RBkq3Cy9aozjjRSbwV_Ffv4Y>
X-Mailman-Approved-At: Tue, 08 Mar 2022 13:29:22 -0800
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: Tue, 08 Mar 2022 20:16:03 -0000

Well I think the answer is - it depends.

First IXP fabric can be used as pure L3 share LAN or can be used (and it is
often the case) as a p2p emulated VLAN over such L3 shared LAN.

Now if this is L3 shared LAN still customer and ISP may peer directly and
no third party traffic would be accepted at either end.

If we talk about emulating L2 IXP fabric becomes just an emulated circuit
and from the perspective of routing it a p2p interface.

Sure the other aspects of the IXP quality, port monitoring,
oversubscription etc... always will apply but there are ways to mitigate or
handle those in real IXPs.

Best,
R.








On Tue, Mar 8, 2022 at 9:05 PM Christopher Morrow <
christopher.morrow@gmail.com> wrote:

>
>
> 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.
>
> _______________________________________________
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow
>