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

[Jakob Heitz <[e-mail]>]

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:

> 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
>> <[e-mail] <mailto:[e-mail]>>
>> 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: [e-mail] <mailto:[e-mail]>
>>     [mailto:[e-mail]
>>     <mailto:[e-mail]>] Sent: Friday, July 06, 2012
>>     7:40 PM To: [e-mail] <mailto:[e-mail]>
>>     Cc: [e-mail] <mailto:[e-mail]>; 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. 
>> 

-- 
Jakob Heitz.