Re: [sidr] [Idr] FW: New Version Notification for draft-kumari-deprecate-as-set-confed-set-00.txt
Jakob Heitz <jakob.heitz@ericsson.com> Mon, 09 July 2012 18:26 UTC
Return-Path: <jakob.heitz@ericsson.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82EC321F87E7; Mon, 9 Jul 2012 11:26:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.498
X-Spam-Level:
X-Spam-Status: No, score=-6.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dvmN8SSJkRfO; Mon, 9 Jul 2012 11:26:22 -0700 (PDT)
Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id A7CBC21F87BE; Mon, 9 Jul 2012 11:26:22 -0700 (PDT)
Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q69IQiRY015374; Mon, 9 Jul 2012 13:26:46 -0500
Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.65]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Mon, 9 Jul 2012 14:26:41 -0400
From: Jakob Heitz <jakob.heitz@ericsson.com>
To: "robert@raszuk.net" <robert@raszuk.net>, Brian Dickson <brian.peter.dickson@gmail.com>, "Sriram, Kotikalapudi" <kotikalapudi.sriram@nist.gov>
Date: Mon, 09 Jul 2012 14:26:40 -0400
Thread-Topic: [Idr] FW: New Version Notification for draft-kumari-deprecate-as-set-confed-set-00.txt
Thread-Index: Ac1d/xUDfih/roMjSr6I4xQbzhoblAAANxqA
Message-ID: <7309FCBCAE981B43ABBE69B31C8D213924985C89DB@EUSAACMS0701.eamcs.ericsson.se>
References: <D7A0423E5E193F40BE6E94126930C4930B9DC66B13@MBCLUSTER.xchange.nist.gov> <CAH1iCiq_MeyrVNZXgbv=-D41iN24S2NfQ-UWHSdRHJbY+wXG1w@mail.gmail.com> <4FFB2020.7080003@raszuk.net>
In-Reply-To: <4FFB2020.7080003@raszuk.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "idr@ietf.org" <idr@ietf.org>, "sidr@ietf.org" <sidr@ietf.org>
Subject: Re: [sidr] [Idr] FW: New Version Notification for draft-kumari-deprecate-as-set-confed-set-00.txt
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Jul 2012 18:26:23 -0000
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 >> <kotikalapudi.sriram@nist.gov <mailto: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> >> [mailto:internet-drafts@ietf.org >> <mailto: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 >> 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.