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

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Mon, 9 Jul 2012 12:21:14 -0400

Recall that RFC6472/BCP172 is a *recommendation* for not using AS_SET and AS_CONFED_SET in BGP.
It was intended that eventually there would be a document to *proscribe*
the use of the AS_SET and AS_CONFED_SET types of the AS_PATH in BGP.  
So this document ( http://tools.ietf.org/html/draft-kumari-deprecate-as-set-confed-set-00 )
is being submitted for consideration by the WG to start work on a standards-track RFC
for deprecation of AS_SET and AS_CONFED _SET in BGPv4.
Any comments and suggestions would be welcome and much appreciated.

Sriram / Warren 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, July 06, 2012 7:40 PM
To: [email-masked]
Cc: [email-masked]; Sriram, Kotikalapudi
Subject: New Version Notification for draft-kumari-deprecate-as-set-confed-set-00.txt

A new version of I-D, draft-kumari-deprecate-as-set-confed-set-00.txt
has been successfully submitted by Kotikalapudi Sriram and posted to the IETF repository.

Filename:	 draft-kumari-deprecate-as-set-confed-set
Revision:	 00
Title:		 Deprecation of AS_SET and AS_CONFED_SET in BGP
Creation date:	 2012-07-07
WG ID:		 Individual Submission
Number of pages: 6
URL:             http://www.ietf.org/internet-drafts/draft-kumari-deprecate-as-set-confed-set-00.txt
Status:          http://datatracker.ietf.org/doc/draft-kumari-deprecate-as-set-confed-set
Htmlized:        http://tools.ietf.org/html/draft-kumari-deprecate-as-set-confed-set-00

Abstract:
   RFC 6472 (i.e., BCP 172) recommends not using AS_SET and
   AS_CONFED_SET in BGP.  This document updates RFC 4271 and proscribes
   the use of the AS_SET and AS_CONFED_SET types of the AS_PATH in
   BGPv4.  This is done to simplify the design and implementation of BGP
   and to make the semantics of the originator of a route more clear.
   This will also simplify the design, implementation, and deployment of
   ongoing work in the Secure Inter-Domain Routing Working Group.
                                                        
The IETF Secretariat

---

From: Enke Chen <[email-masked]>
Date: Mon, 09 Jul 2012 09:32:05 -0700

Hi, folks:

Is there really a need for another doc on deprecating AS_SET / 
AS_CONFED_SET?  Regardless the code in the software can not be removed.

-- Enke

On 7/9/12 9:21 AM, Sriram, Kotikalapudi wrote:
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

---

From: Brian Dickson <[email-masked]>
Date: Mon, 9 Jul 2012 13:35:23 -0400

The "analysis" (slide deck) does not itself detail the few cases where
AS_SET is not used incorrectly.

Since one of the authors was involved in that analysis, for sake of
discussing this proposal, could you please provide the following?

- route-views data on AS_SET announcements that are properly formed (per
your analysis)
- route-views data on related announcements (e.g. exact-match or
longer-prefix that form the basis for the AS_SET aggregates)

This would be the actual data, not just "counts" of the number of prefixes.
Knowing who is doing this, which prefixes are affected, and such, will help
inform us on the usage of AS_SET "in the wild".

Also, along with those prefixes, could you search the route-views data to
find out when the first announcement for each (even roughly, YYYY-MM is
good enough) occurred, with the current values?

If something has been announced in exactly the same form, for a very long
time, perhaps the configuration is just being "left alone" because none of
the techies at the organization understand what it is, what it does, or why
it is there?

And maybe someone could do out-reach to those entities to show them why &
how what they are doing is not necessary, and how to achieve whatever the
original goals were, without using AS_SET?

(If we can reduce the well-formed instances "in the wild" to as close to
zero as possible, I think it would be safe to then treat the malformed
AS_SET instances as outliers, regardless of quantity.)

It is a lot easier to deprecate something that isn't being used correctly
at all, than something that is *almost* not being used correctly at all.

And even if the latter, I am in favor of adoption of this as a WG item.

I'm just suggesting the above to move away from the "angels dancing on the
head of a pin" kind of discussion.

Brian

On Mon, Jul 9, 2012 at 12:21 PM, Sriram, Kotikalapudi <
[email-masked]> wrote:

> So this document (
> http://tools.ietf.org/html/draft-kumari-deprecate-as-set-confed-set-00 )
> Subject: New Version Notification for
> draft-kumari-deprecate-as-set-confed-set-00.txt
>
> URL:
> http://www.ietf.org/internet-drafts/draft-kumari-deprecate-as-set-confed-set-00.txt
> Status:
> http://datatracker.ietf.org/doc/draft-kumari-deprecate-as-set-confed-set
> Htmlized:
> http://tools.ietf.org/html/draft-kumari-deprecate-as-set-confed-set-00
>
> Abstract:

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 09 Jul 2012 20:17:04 +0200

Hi Brian and Sriram,

Simple question ...

Some BGP implementations use AS_SET when IBGP multipath is enabled to 
correctly advertise what is being used in data plane to a peer.

What authors of the document in question recommend to do in this case ?

And also as Enke said no matter what draft or rfc says deployed code 
will remain.

In those cases AS_SET will continue to be advertised injected by those 
BGP implementations as there is no even CLI control to stop it.

The multipath code simply calls the aspath_aggregate (latest quagga code 
http://goo.gl/ISBWj line 669) which in turn IMHO correctly inserts the 
AS_SET (http://goo.gl/oSsxE line 996).

Thx,
R.

> Knowing who is doing this, which prefixes are affected, and such, will
> help inform us on the usage of AS_SET "in the wild".
>
> Also, along with those prefixes, could you search the route-views data
> to find out when the first announcement for each (even roughly, YYYY-MM
> is good enough) occurred, with the current values?
>
> If something has been announced in exactly the same form, for a very
> long time, perhaps the configuration is just being "left alone" because
> none of the techies at the organization understand what it is, what it
> does, or why it is there?
>
> And maybe someone could do out-reach to those entities to show them why
> & how what they are doing is not necessary, and how to achieve whatever
> the original goals were, without using AS_SET?
>
> It is a lot easier to deprecate something that isn't being used
> correctly at all, than something that is *almost* not being used
> correctly at all.
>
> I'm just suggesting the above to move away from the "angels dancing on
> the head of a pin" kind of discussion.
>
> Brian
>
> On Mon, Jul 9, 2012 at 12:21 PM, Sriram, Kotikalapudi
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     From: [email-masked] <mailto:[email-masked]>
>     [mailto:[email-masked] <mailto:[email-masked]>]
>     To: [email-masked] <mailto:[email-masked]>
>     Cc: [email-masked] <mailto:[email-masked]>; Sriram, Kotikalapudi
>     [email-masked] <mailto:[email-masked]>

---

From: Jakob Heitz <[email-masked]>
Date: Mon, 9 Jul 2012 14:26:40 -0400

Better to figure out how to aggregate with sidr.

A few months ago, I wrote an email suggesting how
to build a tree of aggregated signatures.

Shall I submit it as a draft, or is there already
another way?

On Monday, July 09, 2012 11:17 AM, Robert Raszuk <> wrote:

> The multipath code simply calls the aspath_aggregate (latest quagga
> code http://goo.gl/ISBWj line 669) which in turn IMHO correctly
> inserts the AS_SET (http://goo.gl/oSsxE line 996).
> 
> Thx,
> R.
> 
> 
>> And maybe someone could do out-reach to those entities to show them
>> why & how what they are doing is not necessary, and how to achieve
>> whatever 
>>     It was intended that eventually there would be a document to
>>     *proscribe* the use of the AS_SET and AS_CONFED_SET types of the
>>     AS_PATH in BGP.     So this document (
>>    
>>    
>>    
>> ) is being submitted for consideration by the WG to start work on a 
>> standards-track RFC for deprecation of AS_SET and AS_CONFED _SET in
>> BGPv4. Any comments and suggestions would be welcome and much
>> appreciated.     
>> 
>>     Sriram / Warren
>> 
>>     [mailto:[email-masked]
>>     <mailto:[email-masked]>] Sent: Friday, July 06, 2012
>>     7:40 PM To: [email-masked] <mailto:[email-masked]>
>>     Cc: [email-masked] <mailto:[email-masked]>; Sriram,
>>     Kotikalapudi Subject: New Version Notification for
>>     A new version of I-D,
>>     draft-kumari-deprecate-as-set-confed-set-00.txt has been
>> successfully submitted by Kotikalapudi Sriram and posted to     the
>> IETF repository.  
>> 
>>     Revision:        00 Title:           Deprecation of AS_SET and
>>     AS_CONFED_SET in BGP Creation date:   2012-07-07
>>         AS_CONFED_SET in BGP.  This document updates RFC 4271 and
>>         proscribes the use of the AS_SET and AS_CONFED_SET types of
>>         the AS_PATH in BGPv4.  This is done to simplify the design
>>         and implementation     of BGP and to make the semantics of
>>         the originator of a route more clear. This will also
>>         simplify the design, implementation, and     deployment of

-- 
Jakob Heitz.

---

From: Brian Dickson <[email-masked]>
Date: Mon, 9 Jul 2012 15:21:36 -0400

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).

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.)

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 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.

And this, in turn suggests that there are actually no instances where
removing an AS_SET would break things.

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.

Anyone?

Brian

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.
P.P.S. That multipath didn't properly address its "multi-pathness" in the
withdrawal side of UPDATE messages, is not necessarily a suitable reason to
keep AS_SETs around.
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.
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.

On Mon, Jul 9, 2012 at 2:17 PM, Robert Raszuk <[email-masked]> wrote:

> And also as Enke said no matter what draft or rfc says deployed code will
> remain.
>
> In those cases AS_SET will continue to be advertised injected by those BGP
> implementations as there is no even CLI control to stop it.
>
>> <[email-masked] <mailto:kotikalapudi.sriram@**nist.gov<[email-masked]>>>
>> wrote:
>>
>> *proscribe*
>>     http://tools.ietf.org/html/**draft-kumari-deprecate-as-set-**
>> confed-set-00<http://tools.ietf.org/html/draft-kumari-deprecate-as-set-confed-set-00>)
>>     From: [email-masked] <mailto:internet-drafts@ietf.**org<[email-masked]>
>> >
>>     [mailto:internet-drafts@ietf.**org <[email-masked]><mailto:
>> internet-drafts@ietf.**org <[email-masked]>>]
>>     draft-kumari-deprecate-as-set-**confed-set-00.txt
>>
>>     A new version of I-D, draft-kumari-deprecate-as-set-**
>> confed-set-00.txt
>>     Filename:        draft-kumari-deprecate-as-set-**confed-set
>>     Revision:        00
>>     http://www.ietf.org/internet-**drafts/draft-kumari-deprecate-**
>> as-set-confed-set-00.txt<http://www.ietf.org/internet-drafts/draft-kumari-deprecate-as-set-confed-set-00.txt>
>>     Status:
>>     http://datatracker.ietf.org/**doc/draft-kumari-deprecate-as-**
>> set-confed-set<http://datatracker.ietf.org/doc/draft-kumari-deprecate-as-set-confed-set>
>>     Htmlized:
>>     http://tools.ietf.org/html/**draft-kumari-deprecate-as-set-**
>> confed-set-00<http://tools.ietf.org/html/draft-kumari-deprecate-as-set-confed-set-00>
>>
>>     Abstract:
>> proscribes
>>     ______________________________**_________________
>>     Idr mailing list
>>     https://www.ietf.org/mailman/**listinfo/idr<https://www.ietf.org/mailman/listinfo/idr>
>>
>>
>>
>>
>>
>> ______________________________**_________________
>> Idr mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/**listinfo/idr<https://www.ietf.org/mailman/listinfo/idr>
>>
>>
>
>

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 9 Jul 2012 15:52:13 -0400

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. :-)

> 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.)

> 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.

> 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.

> remove, but that in a CIDR-only world, that ATOMIC_AGGREGATE is basically

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.

> 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.

> routing-information loops.

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

> second-best path to avoid either loops, or instability, there are bigger

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

> 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