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

Jeffrey Haas <jhaas@pfrc.org> Thu, 01 April 2021 13:11 UTC

Return-Path: <jhaas@slice.pfrc.org>
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 5E6433A10DC; Thu, 1 Apr 2021 06:11:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 Ij3nC_1WsgMj; Thu, 1 Apr 2021 06:11:09 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 43C413A10D8; Thu, 1 Apr 2021 06:11:04 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 2C72D1E44B; Thu, 1 Apr 2021 09:33:10 -0400 (EDT)
Date: Thu, 1 Apr 2021 09:33:10 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: Brian Dickson <brian.peter.dickson@gmail.com>
Cc: "Sriram, Kotikalapudi (Fed)" <kotikalapudi.sriram@nist.gov>, "idr@ietf.org" <idr@ietf.org>, "grow@ietf.org" <grow@ietf.org>, "draft-heitz-idr-wklc@ietf.org" <draft-heitz-idr-wklc@ietf.org>
Message-ID: <20210401133309.GN24667@pfrc.org>
References: <SA1PR09MB814269138AEE1567CEED703B847C9@SA1PR09MB8142.namprd09.prod.outlook.com> <CAH1iCip6WaQFaBM2DAjf++vW3WTm_NHmXvLTgOhpTdpRdFKigg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAH1iCip6WaQFaBM2DAjf++vW3WTm_NHmXvLTgOhpTdpRdFKigg@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/m26qK4fZkDrsRDM8Jf8EY5NemQ4>
Subject: Re: [Idr] [GROW] 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 13:11:14 -0000

[Note, commenting as an individual contributor...]

On Wed, Mar 31, 2021 at 03:10:08PM -0700, Brian Dickson wrote:
> On Wed, Mar 31, 2021 at 7:57 AM Sriram, Kotikalapudi (Fed) <
> kotikalapudi.sriram@nist.gov> wrote:
> > We (authors of the WKLC draft) can continue working on creating an IANA
> > WKLC registry for the future but I think the route leaks solution draft can
> > switch to using Transitive Extended Community. Especially, if that could
> > help expedite the route leaks draft and its deployment? I would like to
> > seek advice regarding that (I'm cc'ing GROW also here).
> 
> 
> Sorry to argue in public, but I disagree very strongly on the second part
> here.
> 
> We would like to continue proceeding with use of a LC range for
> implementation, using a single (or small number) of Global Administrator
> values.
> 
> I think we should request that a small block of GAs surrounding the initial
> assignments be tentatively marked something like Reserved for IANA
> assignment.
> That is different from actually establishing a registry or assigning them
> specifically for WKLCs, but would be compatible with subsequent WKLC work.

The issue being faced here for WKLC is a few related items:
- There needs to be some number of global admin (AS) reserved for generic use.
- Since this was not done at the time the feature was shipped, there is no
  support in anyone's code to treat subsequently allocated ranges as
  "special".

The two larger criticisms of the WKLC draft to date is that it wanted a LOT
of the AS space to be used, and that its transitivity functionality would
not fit well into an incremental deployment of the feature.  If the
transitivity requirements are removed and the space is narrowed, that at
least moves it closer to existing community operational practices.  E.g. a
single AS allocated for the purpose that leaves two unstructured fields, or
a small number of ASes.

This then would require implementations that want to treat the new
well-known fields as "special" to have code to do so.  So, we're already
looking at some level of new code.

Absent that new code, what we have is generic policy, along with the
implementation's normal propagation behavior - which is behind a knob for
some implementations.

> The move to using LC values was precipitated by the observation that the
> path for getting attributes deployed would be very long, and that operators
> (actual network operators) are looking for a solution which can be deployed
> *now*.

If the state can fit into an extended community, that similarly can be done
NOW.  A significant portion of the extended community space is available on
first-come, first-serve basis.

https://www.iana.org/assignments/bgp-extended-communities/bgp-extended-communities.xhtml

But it doesn't change the above issues.

> Nothing has changed in this regard; the WKLC draft is IMHO still the right
> path, and only the size of the initial allocation is problematic.
> 
> Having 1-4 GA values (from the 32-bit range of potential values) is not
> burdensome IMNSHO, and is a lot less of a concern than the 1/64 (or 1/16)
> of the range of 32-bit ASNs originally requested/suggested.
> 
> If we can all agree that 1-4 GA values assigned for this is acceptable, I
> suggest a revised version of the draft and assessment of consensus on the
> revised draft for adoption and last call.
> 
> LC is the ONLY viable path, given the nebulous state of implementation and
> use for EC/WC or attributes. LC is already deployed, and assigning a few
> GAs by IDR is the only roadblock to the draft in GROW getting approved.

I question your conclusion.

The desire is to have an attribute that is used for route leak mitigation
purposes.

This thread illustrates that it's very easy for such a control community in
any flavor (regular, extended, large) to be stripped because the service
provider hasn't proactively acted to permit it.

Does this really solve the problem?

-- Jeff