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 >> <[email protected] <mailto:[email protected]>> >> 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: [email protected] <mailto:[email protected]> >> [mailto:[email protected] >> <mailto:[email protected]>] Sent: Friday, July 06, 2012 >> 7:40 PM To: [email protected] <mailto:[email protected]> >> Cc: [email protected] <mailto:[email protected]>; 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. _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
