Re: [Idr] FW: New Version Notification for draft-kumari-deprecate-as-set-confed-set-00.txt

[Jeffrey Haas <[e-mail]>]

I really need to write an informational rfc on this.  My answers below are
extremely esoteric BGP-fu, some of which was reverse engineered from old
gated code and watching the evolution of RFCs and I-Ds. :-)

On Mon, Jul 09, 2012 at 03:21:36PM -0400, Brian Dickson wrote:
> I think the original intent of AS_SET, as being used when aggregating,
> should be kept separate from instances of "overloading" the attribute for
> new functionality (e.g. multipath).

The problem here is that in terms of multipath, there exist topologies where
it is not safe to provide a transparent aggregation of paths for forwarding
purposes.  I.e. if you use some vendor based multipath knobs at the wrong
place and you're someone's transit provider, there's a possibility that
forwarding loops can form.  The fact that they don't mostly attest to the
multipath knobs in question being used in sane places.

The only way in such a possibly unsafe place to prevent real forwarding
loops from being formed is to aggregate the paths into a set.  However,
existing implementations largely do not generate an AS_SET without also
resulting in a shorter prefix.

(Yes, the topology exists, but John would have to reconstruct it because my
copy of it got eaten by an overly aggressive mail server.)

> So, let's consider the "classic" AS_SET instances, which are quite possibly
> the reason we see AS_SET in the wild.
> 
> (BTW - I took a quick look at a very recent snapshot from routeviews, and
> see a grand total of 14 prefixes with non-singular, non-private AS_SET
> values, i.e. only 14 instance where the AS_SET contains more than one ASN,
> and the ASN set does not contain any private ASNs. So the deployed use
> cases in the DFZ, "in the wild", looks like only 14 total. Regardless of
> deployed code, if we get those 14 instances to fix their configs to not do
> AS_SET, we should be able to move on to depracating AS_SET, and at least,
> moving forward, can get rid of it from new code, and avoid having to
> include support for it in updates to the protocol.)

You're perhaps looking at this too politely: If the bulk of the Internet
threw away those 14 or so routes, who'd notice?  That has tended to be
bigger motivation than anything else.

> Can anyone explain why it is necessary to have an AS_SET at all, i.e. can
> anyone give an example where bad things happen without AS_SET, and those
> bad things don't happen when AS_SET is used?

The typical deployment of an AS_SET was an upstream provider servicing a set
of downstream providers from a small number of address spaces.  The
downstream providers received more specific routes from the less specific
space.  Everyone spoke BGP to each other in this group of ASes.  The
downstreams may even have direct peering sessions with each other.

The upstream would aggregate the routes together and all of the contributing
ASes would end up in the set.  The upstream would also suppress the more
specific routes.  

A side effect of this aggregation is that the downstream ASes must have
their more specific routes from each other or from the upstream.  This is
because a side effect of the AS_SET based aggregate was that no one in the
contributing set of routes could receive the less specific because it was a
loop.

Another implementation solved the problem simply by letting you
nail up the less specific route and originating that directly.  For the
topologies that were largely covered by AS_SET type aggregation above, that
was fine.  

Over a short amount of time, filtering of more specific routes became less
aggressive or the smaller providers renumbered into real space.  

Note that I can only vouch for the above as lore rather than point to the
data.  I suspect others on this list (if they're still reading) can give
more first-hand accounts.

> The text of 4271 seems to indicate that ATOMIC_AGGREGATE was needed for
> signaling that what would have required an AS_SET has had the AS_SET
> remove, but that in a CIDR-only world, that ATOMIC_AGGREGATE is basically
> informational-only.

Atomic aggregate needed its own FAQ. :-P

The feature was originally added in as a signalling mechanism mostly useful
for transitional practices between BGP-3 and BGP-4.  The meaning of the
attribute is "do not deaggregate this - loops may occur if you do".  The
thing is, most people never de-aggregate.  The Net transitioned over to
BGP-4 in pretty short order, so even that wasn't important for long.

The scenarios covered by the original text for the feature and the text
proposed across several versions of draft-ietf-idr-bgp4 covering this
feature went from incomplete to more complete to complete would be insane,
let's mostly ignore this.  The text largely as written said that if you
aggregate and path information would be lost, add the attribute.  The
trouble is this covered not only explicit aggregation by creating a shorter
prefix route but also suppressing more specific routes when you have a less
specific one.

As best I can tell, no one got the implicit aggregate feature
implemented.

There was also the problem that the specification covered the inbound
(AdjRibsIn to LocRib) case only.  You could end up with the same scenario on
an outbound basis as well.  Coding for that was impractical.

> Which leads to not only depracating the use of AS_SETs (by operators), but
> hopefully to the current I-D under discussion - making AS_SET code (and
> CONFED_AS_SET code) go away.

You can't make code for it completely go away.  There at minimum would
always be stub code to match for it and not drop peering sessions while at
the same time suppressing the routes.

> P.S. For the multipath case, what about just appending the two paths? That
> was Tony Li's suggestion in SIDR, and it avoids the routing and
> routing-information loops.

I'm behind in SIDR, but SIDR can't provide anything provable for forwarding.
That is currently true today for multipath. 

> P.P.P.S. In an ideal world, it *should* be enough to just have multipath
> send the best of the multiples to its peers. The fact that it also uses
> stuff other than its best, is just additional non-control-plane stuff, and
> shouldn't really impact peers' networks as such. If a peer's peer needs the
> second-best path to avoid either loops, or instability, there are bigger
> problems afoot.

I suspect you haven't been following add-path enough. :-)

> P.P.P.P.S. The correct solution would have been to create a new PATH
> element, which consists of fully-formed AS_PATHs themselves, which would
> have allowed loop prevention while keeping the ordering of AS_PATH
> attributes, and would allow multi-path-aware speakers to share the extra
> path info. Negotiated, of course.

FWIW, this case is similar to the multipath case above that I was discussing
would require sets.  An immediate consequence of this is "multipath routes"
with paths that churn as components are added or removed from being
multipath contributors.  If you thought BGP was noisy before, you've seen
nothing yet.

-- Jeff