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

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> 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 )
> 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]
> Sent: Friday, July 06, 2012 7:40 PM
> To: sriram.ietf@gmail.com
> Cc: 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
> 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
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>