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

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 <robert@raszuk.net> wrote:

> 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.
>
>
>  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
>> <kotikalapudi.sriram@nist.gov <mailto:kotikalapudi.sriram@**nist.gov<kotikalapudi.sriram@nist.gov>>>
>> wrote:
>>
>>     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<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: internet-drafts@ietf.org <mailto:internet-drafts@ietf.**org<internet-drafts@ietf.org>
>> >
>>     [mailto:internet-drafts@ietf.**org <internet-drafts@ietf.org><mailto:
>> internet-drafts@ietf.**org <internet-drafts@ietf.org>>]
>>     Sent: Friday, July 06, 2012 7:40 PM
>>     To: sriram.ietf@gmail.com <mailto:sriram.ietf@gmail.com>
>>     Cc: warren@kumari.net <mailto:warren@kumari.net>; 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<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:
>>         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
>>     ______________________________**_________________
>>     Idr mailing list
>>     Idr@ietf.org <mailto:Idr@ietf.org>
>>     https://www.ietf.org/mailman/**listinfo/idr<https://www.ietf.org/mailman/listinfo/idr>
>>
>>
>>
>>
>>
>> ______________________________**_________________
>> Idr mailing list
>> Idr@ietf.org
>> https://www.ietf.org/mailman/**listinfo/idr<https://www.ietf.org/mailman/listinfo/idr>
>>
>>
>
>