Re: [Idr] Choice of Large vs. Extended Community for Route Leaks Solution

Brian Dickson <brian.peter.dickson@gmail.com> Thu, 01 April 2021 22:00 UTC

Return-Path: <brian.peter.dickson@gmail.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 113C93A2506; Thu, 1 Apr 2021 15:00:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 FRLjBaQIp44n; Thu, 1 Apr 2021 15:00:34 -0700 (PDT)
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 D0C6A3A262E; Thu, 1 Apr 2021 15:00:07 -0700 (PDT)
Received: by mail-vs1-xe2d.google.com with SMTP id a15so1980883vsi.0; Thu, 01 Apr 2021 15:00:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Mt8tusWLFzGXn5FxpNpNItuevrxouvxyTLytygie9nM=; b=imGXDFAnfTotPhq40UVuqGr0lzsNhMzQidLw/gcnvgCohGCyY/qA0kyLifiK3WzsxJ +1FDAcpRdAB7t1lw/4Z1H4J2trd7me5BTF1VrZLQs6YxSsEConm4BaJjycPh2UB6zvFt yY4TmXwLO8LF4kpCcOxiCk5CLrfUihZ98aAHGe5PIV7kxrZGDfJNyXHWLC/42v9PCEwJ s+691ZUBNQO84rc2CwY5xF6mdLtbsFoqkReLVCVoCl6E6X+kMiaCW4mHVZCmxB17nbLh zLlHxcQ726sM0rkIzinV6uveVlmN0Fdyd+cVGCc3mbNdxyGbfChtKd/iW+cLvLgeNpJQ /mWA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Mt8tusWLFzGXn5FxpNpNItuevrxouvxyTLytygie9nM=; b=gAF4dZO1wVW+FuMo+LZniZeOFkGAOyKnDALSHvxElUlqQGZ3KXkW18Xm+bnC0yNRrS 49Qkyz8YuiJG0l//wB/Xk3iPglFpLi1+tld4ICm0w2f2tyIKTwXJHBv6n4Mzmkt7WhZ0 508wDL0DbWn8ZSljku3RAQ96RYdtkhNaqutERp/3L9J5c60oF55BrYQP7f97NjYvYoXL GrzJiXamrqk3CoYWpXEVl5KXba6arBSuEu8BPHSiiEWOESRe3DciRTgTSDecjpuCZ7uK ETqggf1gt+8Eua8rrLdmjRUK/o3yjxzyhHvObL63Nljj7NB/iyGrK+d4S7eYpklH9ByC /4tw==
X-Gm-Message-State: AOAM531zv/6CgyePqRzM1tZAo+2bvtZyFx0DCBJoArZDzdkA8a9Iws3P 3CyLiQuCiJFIkWybSqIhuFUcdTe/iW9oJB78L30=
X-Google-Smtp-Source: ABdhPJzCgUESLLJVMqDRxZFKHBOBSNlRLBNVM3+Ey79Y0G3+26LX6PSGuytIRyNlnGm4A9GyBXfL5Qq/6hs+uA48RxQ=
X-Received: by 2002:a67:324a:: with SMTP id y71mr7070320vsy.41.1617314406209; Thu, 01 Apr 2021 15:00:06 -0700 (PDT)
MIME-Version: 1.0
References: <SA1PR09MB814269138AEE1567CEED703B847C9@SA1PR09MB8142.namprd09.prod.outlook.com> <CAH1iCip6WaQFaBM2DAjf++vW3WTm_NHmXvLTgOhpTdpRdFKigg@mail.gmail.com> <SA1PR09MB814297F9B9C36DA958E0D5D8847B9@SA1PR09MB8142.namprd09.prod.outlook.com> <SA1PR09MB8142ED974B87179E45BA7585847B9@SA1PR09MB8142.namprd09.prod.outlook.com>
In-Reply-To: <SA1PR09MB8142ED974B87179E45BA7585847B9@SA1PR09MB8142.namprd09.prod.outlook.com>
From: Brian Dickson <brian.peter.dickson@gmail.com>
Date: Thu, 01 Apr 2021 14:59:55 -0700
Message-ID: <CAH1iCio72R628XTT9y=-c0UyhZLa=5SnGxT2sw+ATMp2HZHRGA@mail.gmail.com>
To: "Sriram, Kotikalapudi (Fed)" <kotikalapudi.sriram@nist.gov>
Cc: Jeffrey Haas <jhaas@pfrc.org>, Susan Hares <shares@ndzh.com>, "idr@ietf.org" <idr@ietf.org>, "draft-heitz-idr-wklc@ietf.org" <draft-heitz-idr-wklc@ietf.org>, "grow@ietf.org" <grow@ietf.org>, "a.e.azimov@gmail.com" <a.e.azimov@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000ac1aa105bef05a7d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/cTsRDHTmB-k6TSwaTtI8X5Ia1qc>
Subject: Re: [Idr] Choice of Large vs. Extended Community for Route Leaks Solution
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Apr 2021 22:00:38 -0000

On Thu, Apr 1, 2021 at 2:06 PM Sriram, Kotikalapudi (Fed) <
kotikalapudi.sriram@nist.gov> wrote:

> There may be a knob that AS operators have for permitting transitivity,
> but we need to look at measurements to understand whether or not operators
> actually allow transitivity to EC and LC.
>
> NIST BGP measurements (thanks to my colleague Lilia Hannachi) were shared
> on the GROW list in May 2020:
> https://mailarchive.ietf.org/arch/msg/grow/JPD1-hhSvVXIZbUlNQ_1hmzD6IA/
>
> A portion is copied below. The AS path length (# unique ASes)
> distributions for BGP updates with Communities (Regular, Large, and
> Extended) are shown here. It is evident that both LC and EC propagate
> multiple AS hops. Mass stripping of LC or EC at the first hop is not
> evident.  The peak happens at AS path length 4 or 5 and that is good. That
> is the behavior that is helpful for route leak solution. The solution can
> still function even if some ASes strip. We can do some more detailed
> studies if needed.
>
> *********************************************************************
> RIPE-RIS: Community ANALYSIS (Collector : rrc03 From 2020-04-30 00:00 To
> 2020-04-30 00:55)
> *********************************************************************
> # Updates = 1075583 (Total)
> # (Regular) COMMUNITY = 859239 (79.89%)
> AS path length distribution =    1: 170 (0.02%)    2: 44803 (5.21%)    3:
> 141072 (16.42%)    4: 276271 (32.15%)    5: 238325 (27.74%)    6: 114158
> (13.29%)    7: 31365 (3.65%)    8: 9018 (1.05%)    9: 2690 (0.31%)    10:
> 811 (0.09%)    11: 358 (0.04%)    12: 169 (0.02%)    13: 22 (0%)    14: 7
> (0%)
>
> # LARGE_COMMUNITY = 152818 (14.21%)
> AS path length distribution =    2: 5655 (3.7%)    3: 17205 (11.26%)    4:
> 54372 (35.58%)    5: 45492 (29.77%)    6: 22065 (14.44%)    7: 6422 (4.2%)
>   8: 1068 (0.7%)    9: 397 (0.26%)    10: 71 (0.05%)    11: 35 (0.02%)
> 12: 26 (0.02%)    13: 6 (0%)    14: 4 (0%)
>
> # EXTENDED COMMUNITIES = 44606 (4.15%)
> AS path length distribution =    2: 2269 (5.09%)    3: 7435 (16.67%)    4:
> 17657 (39.58%)    5: 11600 (26.01%)    6: 3967 (8.89%)    7: 1221 (2.74%)
>   8: 371 (0.83%)    9: 57 (0.13%)    10: 19 (0.04%)    11: 8 (0.02%)    12:
> 1 (0%)    13: 1 (0%)
> *********************************************************************
>

One main issue will be the use of LC vs WC vs regular communities, among
the largest networks (e.g. networks nominally at the tier-1 designation).
Going from e.g. a wikipedia page with list of ASNs, that would be all or
most of these ASNs:
7018, 1299, 1239, 3320, 6453, 6461, 3356, 3549, 2914, 3257, 3491, 701,
6762, 3491.

Can you get a top-level summary of LCs with GA values from that list, and
whatever the corresponding thing would be for EC or WC?
E.g. How many unique LC values are there that match 3320:* ? Maybe a table
with ASN vs common LC count would help illustrate this.

If the majority (or vast majority) are already using LCs, and many fewer
are using WC/EC, this definitely should tilt the argument towards LCs.

Any of these networks which is using LCs extensively will very likely to be
unwilling to use anything other than a WKLC (and this use of LCs was to a
significant degree the result of requests from operators that use LCs to do
it with LCs.)

Brian