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

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C7F95131614 for <>; Tue, 14 Mar 2017 15:45:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.7
X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] 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 wxt4EW5DkExN for <>; Tue, 14 Mar 2017 15:45:30 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A905413161B for <>; Tue, 14 Mar 2017 15:45:29 -0700 (PDT)
Received: by with SMTP id n11so10327991wma.0 for <>; Tue, 14 Mar 2017 15:45:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=OfDxbSZ3Pr5nad2GucA7OwrS+nIfQIqv/EV9oqe1CLM=; b=ZUdg6LQP24yvg2L1PHYaZkgM6+7lpJ5g4d8csZ++xQweybInn63CPQDWvAql8zSjA0 PVVhUBsIKWxmGlRP5+R6okzy61WVXBDyXUiIJfeNcKnLOu409We6EXUNm+/xtKSO6dRD Sxn2B3oaSJcB+LxuvX2i9WLu2C0apJvNCe24iVmqoSapjQsovOz1OoyF3WNPhAX7JCWH FMX2etSoBj8GkXmreT2RGryo97wuIRqHQ621q7oE10T1m47n53D1bSKhGqrXgXuiSPaU gCmfTaiBDN0NaNw5lrsEcpIWNMgUqNU4XTNXzWg9S8vYknzFLbLzmRllDF5TmdnnRBsh yyBQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=OfDxbSZ3Pr5nad2GucA7OwrS+nIfQIqv/EV9oqe1CLM=; b=H7I877a+6ulY480ZVRioLXbDTLVRFd8mv0NCLf36zvvjmDJp4ZATtaT3I63oKeAm9S 6YdajJp/VnqpJWBOSs0IUZneUHiyrz7/2lors10Bp7+l3foFDm+Dvi/hKVV0dcNdEPJo ZcSVB0FNxAUsB7vhSh05jKh1S3P4UkLL9VVWI4gtEaTQZ1Z/FHKY2e5rNEpfv8m2Z/dn slr20EAgz8pTOGV5ZgF/up4PTtholcBW/0uC6j+wHJUOTEpNeBkCZaWMWXfjTRpK2aQX KOIHxCSHebf+Tproyv9FTN28owy/X73IXkFqqztpn9fj8KFUpsBgGmD4Nfe+zFKEDlR1 1Eyw==
X-Gm-Message-State: AFeK/H2CQfPUFLhugRJ565HE4o5iG+BEU0MqXyV7D8/+Zrom6Tf+CfeHJRlxRr53ebJCiQ==
X-Received: by with SMTP id n140mr1674200wmg.58.1489531527868; Tue, 14 Mar 2017 15:45:27 -0700 (PDT)
Received: from localhost ([2001:67c:208c:10:195a:2373:c926:335d]) by with ESMTPSA id w97sm52901wrc.20.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Mar 2017 15:45:26 -0700 (PDT)
Date: Tue, 14 Mar 2017 23:45:25 +0100
From: Job Snijders <>
To: Jeffrey Haas <>
Cc: idr wg <>
Message-ID: <20170314224525.2hjohmaf74vuxnwy@Vurt.local>
References: <03ae01d29c3e$6c5d87a0$451896e0$> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: NeoMutt/20170306 (1.8.0)
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:45:32 -0000

On Tue, Mar 14, 2017 at 06:39:16PM -0400, Jeffrey Haas wrote:
> On Tue, Mar 14, 2017 at 11:07:54PM +0100, Job Snijders wrote:
> > 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.
> This is one of those things I'd love to say "it's nice on principle" but
> usually get followed by "but the consequences are a bit ugly".
> Deprecating means largely "don't do that".  You now have to deal with all of
> the consequences of those things that still do that or expect such to be
> done.  BGP changes are all about incremental rollout headache after all.
> Implementations will still be required to understand the attribute and
> minimally to ignore it.  This means you don't really get rid of much code
> there.
> Conformance tools will still probe for what we do for things and have to be
> revised to not flag as non-conformant an implementation that doesn't pass
> the attribute along if it's been set.  Or that it's added if the as-path is
> truncated or otherwise incomplete.
> And while deaggregation isn't typically done automatically by routers, it's
> still good to signal that doing so may be a bad idea.  I'll let you dig out
> your favorite deaggregation traffic shaping tool presentation from the *NOG
> of your choice.
> So, the benefits don't really outweigh the consequence of leaving it in.
> If we'd been having this conversation as part of trying to get 1771 style AA
> semantics working right[1], I might have had a somewhat different opinion.
> > 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?
> See above.
> > 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
> > mind.
> See above. (I generally agree.)  It's also likely to get worse.
> > 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.
> You're also not the one that gets the bug reports from this sort of thing.
> :-)  
> At best, I'll acknowledge your network won't fall over from it not showing
> up the few times it actually does in the DFZ these days.
> -- Jeff
> [1] As part of Sue's crash course to how to participate in the IETF process,
> I was encouraged to try to work out issues we'd found in our implementation
> of the specification (draft-ietf-idr-bgp4-XX) on the mailing list.  As part
> of working through inconsistencies in the text regarding how AA was set, I
> tried to contact our venerable authors on BGP to get them to work through
> those inconsistencies with me.  Being busy at startups, most didn't respond.
> This left a rather inexperienced protocols implementor trying to intuit
> "what is this thing for?" and supplying various bits of text toward the
> draft to try to rectify the discrepancies.
> It turns out that if done using the intent of 1771 and earlier, AA would be
> set on *most* things, especially when policy was involved.  However,
> discovering this set of things resulted in at least 3 churns of the draft.
> Eventually that was overcome by the realization that this is an appendix, in
> the anatomy sense; a vestigial organ.  It's mostly useful to prevent
> auto-deaggregation in implementations that were transitioning from the
> classful BGP-3 to CIDR BGP-4.  Such things didn't seem to be common even
> back in the day, and the transition from -3 to -4 seemed to take very little
> time across the backbones.
> What eventually remained was "this is a good idea to signal truncation or
> loss of information from the as-path" in the event that deaggregation would
> happen. While gross, people did and still do it.  And even otherwise, having
> it as a handy note that "information was lost" during aggregation is still
> handy.[2]  Having lost most of the crazy text about the rules with which you
> set AA based on what you learned, we now have a relatively quiet feature
> that's easy to implement with some minor operational benefit.
> This exercise in archaeology was my first, and a lingering introduction to
> Internet standards.  I've almost foriven my second introduction, which
> involved SNMP.
> [2] An interesting side effect of extened UPDATES in our other thread will
> be that aggregation that results in sets from gateD family software will
> mean we have even LONGER AS_SETs today than before.  While such
> implementations support "brief" aggregation, the transitional behavior of a
> long AS_SET on a extended message speaker to a 4k speaker will make for an
> interesting edge and conformance case.

Thank you for sharing this Jeff. I treasure emails like these :)

Kind regards,