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

Job Snijders <> Tue, 14 March 2017 22:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7B57F129A76 for <>; Tue, 14 Mar 2017 15:08:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.001
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HqIopOyic0F9 for <>; Tue, 14 Mar 2017 15:07:58 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c0c::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7E254129406 for <>; Tue, 14 Mar 2017 15:07:58 -0700 (PDT)
Received: by with SMTP id l37so132971687wrc.1 for <>; Tue, 14 Mar 2017 15:07:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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 with SMTP id 32mr34436195wrq.82.1489529274895; Tue, 14 Mar 2017 15:07:54 -0700 (PDT)
MIME-Version: 1.0
Received: by 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: <>
References: <03ae01d29c3e$6c5d87a0$451896e0$> <>
From: Job Snijders <>
Date: Tue, 14 Mar 2017 23:07:54 +0100
Message-ID: <>
To: Jeffrey Haas <>, idr wg <>
Content-Type: multipart/alternative; boundary="94eb2c0d21c250257a054ab80f23"
Archived-At: <>
Subject: Re: [Idr] draft-hares-deprecate-atomic-aggregate (was Re: Request for 2 drafts)
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 14 Mar 2017 22:08:02 -0000

On Tue, 14 Mar 2017 at 20:24, Jeffrey Haas <> 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 comes to

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,