Re: [Idr] draft-hares-deprecate-atomic-aggregate (was Re: Request for 2 drafts)

Job Snijders <job@instituut.net> Tue, 14 March 2017 22:08 UTC

Return-Path: <job@instituut.net>
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 7B57F129A76 for <idr@ietfa.amsl.com>; Tue, 14 Mar 2017 15:08:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level:
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=instituut-net.20150623.gappssmtp.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 HqIopOyic0F9 for <idr@ietfa.amsl.com>; Tue, 14 Mar 2017 15:07:58 -0700 (PDT)
Received: from mail-wr0-x22f.google.com (mail-wr0-x22f.google.com [IPv6:2a00:1450:400c:c0c::22f]) (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 7E254129406 for <idr@ietf.org>; Tue, 14 Mar 2017 15:07:58 -0700 (PDT)
Received: by mail-wr0-x22f.google.com with SMTP id l37so132971687wrc.1 for <idr@ietf.org>; Tue, 14 Mar 2017 15:07:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=instituut-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=32HqNoSQCkQTBiRTUxdKMli+/FGwHmq2nU3eyKt7QVc=; b=qyJsXUlyV6sP1vqAAmGOrsrll2H3DvCROXDr4nTI3LYsj/f9FK3VMTAj20yktcRJ4u oFAA4QEPwSGBfkZ9vmeA0k8GmC8kdBt19nuduxAizYYAZmhxBkQq0zXZfeycturpk1Sb j4NnTzJQ9SS4BRmDLXXrhz+sFG+REgn0cviqVgbanWzm3EwiqRJ9nHskz8U3fiEjAly7 XXzfyDwbUSFoWQXX7whvBPeV5DHgR8axQfns6u+Om9p1/4h8ReFjHxEOgXvFvzZeloEy E5L1G/YU2uC39FSylo1bMQonvUtkchbku7nrEc77nTAPKS/oIk7e21GmnAdtsu4aKbEb bOkg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=32HqNoSQCkQTBiRTUxdKMli+/FGwHmq2nU3eyKt7QVc=; b=lr752S/xjKEwwugLE5lhQpG+1zskPqaIFQnpGUhPc2tx5YvO+zV4rtZNVzO/5af/eO ehmMDeocHUzsjAgKFYtJXVMoSX7FS6hR2XEcWN9mXlCwMiopInDeDLC19X9XY6iklma9 wcoZZqi5Q6Qs3v08zoqaPXnlHzdY7RhO+4MQOUEd8EdahTviHw5IiPKacCx7O+PV/wYR 8h14pQnBwcr4I311pab32wYBv/ULZdzAqthiriH+u2Me5oqSW6HVNlG0xUEd0I+OnYki Kn0Eg9qvytYjo7XxFLnxi67A/pxPnXIXJEiODwsSaBfJbmgFmNIFoWEBYwBkrjZyTXye 4a2A==
X-Gm-Message-State: AMke39kc4cUS55kLnfLAFdU0ACBmOX+/zmywx2KVl5lhSXEQ32/C01TUxqyY1Uyam7ng4QR25+/QwRwqjhoXTw==
X-Received: by 10.223.148.35 with SMTP id 32mr34436195wrq.82.1489529274895; Tue, 14 Mar 2017 15:07:54 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.182.162 with HTTP; Tue, 14 Mar 2017 15:07:54 -0700 (PDT)
X-Originating-IP: [2001:67c:208c:10:195a:2373:c926:335d]
In-Reply-To: <20170314193036.GC12864@pfrc.org>
References: <03ae01d29c3e$6c5d87a0$451896e0$@ndzh.com> <20170314193036.GC12864@pfrc.org>
From: Job Snijders <job@instituut.net>
Date: Tue, 14 Mar 2017 23:07:54 +0100
Message-ID: <CACWOCC-jd_02DyT3t==PbkkKpCY5_1NMWSWZt+dmLurahYFVkQ@mail.gmail.com>
To: Jeffrey Haas <jhaas@pfrc.org>, idr wg <idr@ietf.org>
Content-Type: multipart/alternative; boundary=94eb2c0d21c250257a054ab80f23
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/GsQkjLVZbYRr-PxwIqQCUOLmw-o>
Subject: Re: [Idr] draft-hares-deprecate-atomic-aggregate (was Re: Request for 2 drafts)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.22
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: Tue, 14 Mar 2017 22:08:02 -0000

On Tue, 14 Mar 2017 at 20:24, Jeffrey Haas <jhaas@pfrc.org> wrote:

> Sue,
>
> On Mon, Mar 13, 2017 at 05:11:45PM -0400, Susan Hares wrote:
> > I'd like to follow-up on our "clean up" the attribute area discussion.
> >
> > I've published:
> [...]
> >
> > draft-hares-deprecate-atomic-aggregate-00
>
> I'd actually recommend against outright deprecating AA.  Mostly it'll lead
> to confusion of compliant implementations of 1771/4271 without a lot of
> benefit.
>
> A significant amount of the controversy around the feature while
> standardizing 4271 had to do with the rules by which AA was attached to
> routes.  I suspect very few people besides Tony Li ever had a strong
> opinion
> about the behavior, especially once we got beyond the BGP-3 transition.
> (And I wasn't there at the time.  The Tony observation is driven mostly by
> him popping up a few years ago with a proposal that included AA behavior.)
>
> The current behavior of 4271 with regard to AA is pretty mild: If you're
> dropping out ASes from the path as part of aggregation, you SHOULD add this
> thing.  If you see it, don't de-aggregate.
>
> People generally don't de-aggregate magically these days and those who do
> generally expect to have to be very careful.
>
> The document that I thought was worth writing at some point, even if it
> only
> was a draft and never got published, was a short discussion about the
> origin
> of the feature, what its original intent was, what was broken about its
> original rules to be attached and why we ended up where we did.  This is
> arguably a history document intending to document a rather ugly bit of
> living history that confuses newcomers to the protocol.
>
> I'm happy to contribute to such a document.  But I don't recommend we
> proceed down the path to deprecation.


Hi Jeff,

Isn't the path to deprecate a poorly understood feature ("poorly" as in
ugly, that there is a disconnect between expectations), to just.. deprecate
it? I'd welcome historic perspective in such a deprecation document for
newcomers, it would be helpful for my edification to learn of the rise and
fall of a protocol complications.

However I don't see a compelling reason in itself to not touch 4271, for
the purpose of touching 4271. There have been a number of updates to 4271
over the years, and compliant implementations need to continue to monitor
IETF documents to remain complaint, right?

In context of internet-wide EBGP operations I'd view both aggregation
(aggregation through snipping globally unique ASNs from the as_path) as
well as de-aggregation as most unwelcome. At this point especially
de-aggregation is real threat to the DFZ, stuff like
http://bgpmon.net/bgp-optimizer-causes-thousands-of-fake-routes/ comes to
mind.

Is there a legitimate use case for keeping atomic aggregate around? if not,
we should clean up.

I'm usually in favour of deleting things that are not used.

Kind regards,

Job