From jgs@juniper.net Fri Feb 4 06:23:00 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7F343A68E9 for ; Fri, 4 Feb 2011 06:23:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.291 X-Spam-Level: X-Spam-Status: No, score=-6.291 tagged_above=-999 required=5 tests=[AWL=0.308, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GYaV8OfFOo8V for ; Fri, 4 Feb 2011 06:22:55 -0800 (PST) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by core3.amsl.com (Postfix) with ESMTP id 72C4A3A696A for ; Fri, 4 Feb 2011 06:22:34 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKTUwMdkpfJx38AKcICSPs1mowtLbqSLh+@postini.com; Fri, 04 Feb 2011 06:25:59 PST Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Fri, 4 Feb 2011 06:16:39 -0800 From: John Scudder To: "idr@ietf.org List" Date: Fri, 4 Feb 2011 06:16:37 -0800 Thread-Topic: draft-decraene-idr-reserved-extended-communities-00 adopted + working group last call Thread-Index: AcvEdiM/03uc33zYRU2KDTNLIrgtSg== Message-ID: 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 Subject: [Idr] draft-decraene-idr-reserved-extended-communities-00 adopted + working group last call X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 14:23:01 -0000 Hi, After careful consideration of the discussion regarding the adoption of dra= ft-decraene-idr-reserved-extended-communities-00, Sue and I have decided to= adopt it as a WG item. To summarize our reasoning: - The draft's goal is to consume fewer type codes from the extended communi= ty space. Given no concrete downside has been articulated, this seems like= a useful thing to do. - The draft allocates two type codes. These can be allocated FCFS in any c= ase, absent WG consent. - The draft creates two new registries. No downside has been articulated f= or doing this. In short, "doesn't hurt, might help". This message is to begin a two-week WG last call before we send the draft t= o the IESG. Please send any comments by 9 a.m. PST, Feb 18 2011. As a reminder, the draft can be found at http://tools.ietf.org/html/draft-decraene-idr-reserved-extended-communities= -00 Thanks, --John and Sue= From Internet-Drafts@ietf.org Fri Feb 11 12:30:02 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D12B33A6A3D; Fri, 11 Feb 2011 12:30:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kAvVpbxINtFW; Fri, 11 Feb 2011 12:30:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC62A3A69B9; Fri, 11 Feb 2011 12:30:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110211203001.13309.93598.idtracker@localhost> Date: Fri, 11 Feb 2011 12:30:01 -0800 Cc: idr@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-reserved-extended-communities-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 20:30:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : Reserved BGP extended communities Author(s) : B. Decraene, P. Francois Filename : draft-ietf-idr-reserved-extended-communities-00.txt Pages : 5 Date : 2011-2-11 This document assigns two BGP extended community types, one transitive and one non-transitive. It also defines two IANA registries in order to allow the allocation of reserved transitive and non-transitive extended communities. These are similar to the existing reserved (formerly Well-known) BGP communities defined in RFC 1997 but provides an easier control of inter-AS community advertisement as a community could be chosen as transitive or non- transitive across ASes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-reserved-extended-communities-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-idr-reserved-extended-communities-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-2-11122812.I-D@ietf.org> --NextPart-- From yakov@juniper.net Wed Feb 16 06:21:04 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDC163A6E49 for ; Wed, 16 Feb 2011 06:21:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.6 X-Spam-Level: X-Spam-Status: No, score=-105.6 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yo439X9HaXiQ for ; Wed, 16 Feb 2011 06:21:03 -0800 (PST) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by core3.amsl.com (Postfix) with ESMTP id 40AC73A6CA7 for ; Wed, 16 Feb 2011 06:21:03 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKTVvdaPhVWCJDmwNxWO93ee7b79YE84wn@postini.com; Wed, 16 Feb 2011 06:21:32 PST Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 16 Feb 2011 06:12:26 -0800 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id p1GECnU20072; Wed, 16 Feb 2011 06:12:49 -0800 (PST) (envelope-from yakov@juniper.net) Message-ID: <201102161412.p1GECnU20072@magenta.juniper.net> To: Ilya Varlashkin In-Reply-To: <7AB58CEC-F7F3-427C-A1EC-55B8902BAD16@nobulus.com> References: <20110110174506.3308.66220.idtracker@localhost> <7AB58CEC-F7F3-427C-A1EC-55B8902BAD16@nobulus.com> X-MH-In-Reply-To: Ilya Varlashkin message dated "Mon, 10 Jan 2011 21:09:26 +0100." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <20207.1297865569.1@juniper.net> Date: Wed, 16 Feb 2011 06:12:49 -0800 From: Yakov Rekhter Cc: IETF IDR , yakov@juniper.net Subject: Re: [Idr] I-D Action:draft-ietf-idr-rfc4760bis-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2011 14:21:04 -0000 Ilya, > As I've previously mentioned in private conversation, this draft > seem like a perfect place to address an issue of intermixing various > SAFI of the same AFI. The problem has been discussed here at IDR > ("interoperability of 6PE and native -IPv6 within same network" - > http://www.ietf.org/mail-archive/web/idr/current/m sg04364.html). > What's group view on adding something along following line to th e > draft: if a route has been learned from AFI=x SAFI=y1, then BGP > speaker MAY NOT advertise it over a SAFI=y2 session unless speaker > sets itself as NEXT_HOP? To address the above let me propose that we'll add the following: A router SHALL NOT redistribute routing information received over one particular combination of into another unless explicitly configured. The implications of doing such redistribution are numerous and serious, but outside the scope of this document. If a router is explicitly configured to redistribute routing information received over one particular combination of over another , then when redistributing the information the router MUST set NEXT_HOP to self. In the absence of any objections within the next two weeks I'll re-issue a revised version that will include the above text. Yakov. > > On Jan 10, 2011, at 18:45 , Internet-Drafts@ietf.org wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts director ies. > > This draft is a work item of the Inter-Domain Routing Working Group of the IETF. > > > > > > Title : Multiprotocol Extensions for BGP-4 > > Author(s) : R. Chandra, et al. > > Filename : draft-ietf-idr-rfc4760bis-00.txt > > Pages : 12 > > Date : 2011-01-10 > > > > This document defines extensions to BGP-4 to enable it to carry > > routing information for multiple Network Layer protocols (e.g., IPv6, > > IPX, L3VPN, etc...). The extensions are backward compatible - a > > router that supports the extensions can interoperate with a router > > that doesn't support the extensions. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc4760bis-00.txt > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > _______________________________________________ > > Idr mailing list > > Idr@ietf.org > > https://www.ietf.org/mailman/listinfo/idr > > /iLya > > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From Internet-Drafts@ietf.org Wed Feb 16 08:30:02 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC1E43A6E5B; Wed, 16 Feb 2011 08:30:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.554 X-Spam-Level: X-Spam-Status: No, score=-102.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W3Ml-H5aN2t7; Wed, 16 Feb 2011 08:30:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BE993A6AB2; Wed, 16 Feb 2011 08:30:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110216163002.21991.47225.idtracker@localhost> Date: Wed, 16 Feb 2011 08:30:02 -0800 Cc: idr@ietf.org Subject: [Idr] I-D Action:draft-ietf-idr-bgp-issues-04.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2011 16:30:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : Issues in Revising BGP-4 (RFC1771 to RFC4271) Author(s) : A. Lange Filename : draft-ietf-idr-bgp-issues-04.txt Pages : 170 Date : 2011-02-16 This document records the issues discussed and the consensus reached in the Interdomain Routing (IDR) Working Group during its efforts to revise and bring up to date the base specification for the BGP-4 protocol as documented in RFC1771. The results of these efforts are encoded in RFC4271. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-issues-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-idr-bgp-issues-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-02-16082941.I-D@ietf.org> --NextPart-- From warren@kumari.net Wed Feb 16 12:55:43 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A61AA3A6EFD for ; Wed, 16 Feb 2011 12:55:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_15=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sqm3kb0IUUd1 for ; Wed, 16 Feb 2011 12:55:42 -0800 (PST) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by core3.amsl.com (Postfix) with ESMTP id 036993A6A9D for ; Wed, 16 Feb 2011 12:55:40 -0800 (PST) Received: from [172.19.118.186] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id E3F121B401C9 for ; Wed, 16 Feb 2011 15:56:08 -0500 (EST) Message-Id: From: Warren Kumari To: idr In-Reply-To: <009201cbb64f$9da1f660$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) X-Priority: 3 Date: Wed, 16 Feb 2011 15:56:05 -0500 References: <9E95EA3A-157B-4A40-88F7-514E7FFF3477@kumari.net> <008001cb96b8$bb01d740$4001a8c0@gateway.2wire.net> <00b301cba848$3490af00$4001a8c0@gateway.2wire.net> <9AC2F61C-66C9-41B3-ACC0-DE72F0E8F83A@kumari.net> <009201cbb64f$9da1f660$4001a8c0@gateway.2wire.net> X-Mailer: Apple Mail (2.936) Subject: Re: [Idr] draft-ietf-idr-deprecate-as-sets-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2011 20:55:43 -0000 Whoops, tomorrow would be a month since I last poked this, so shame on me... Could I get others to chime in here with comments? Should I ask for this to be considered for WGLC[0]? W [0]: Yes, I *am* poking the stick in the nest and giving it a shake to see if anything flies out and bites me. :-) On Jan 17, 2011, at 8:55 AM, t.petch wrote: > Looks good to me. > > I thought briefly that the language ought to be SHOULD or MUST but > then > realised that this I-D is INFORMATIONAL so that those would not > really be appropriate. > > Tom Petch > > ----- Original Message ----- > From: "Warren Kumari" > To: "t.petch" > Cc: "Warren Kumari" ; "idr" > Sent: Sunday, January 16, 2011 4:28 PM > Subject: Re: [Idr] draft-ietf-idr-deprecate-as-sets-00 > > > > On Dec 30, 2010, at 12:37 PM, t.petch wrote: > >> Warren >> >> Top posting on deprecate since that seems the fuzzy issue. >> >> I also work in network management, and so take for granted >> statements such as >> " The value "current" means that the definition is current and valid. >> The value "obsolete" means the definition is obsolete and should not >> be implemented and/or can be removed if previously implemented. >> While the value "deprecated" also indicates an obsolete definition, >> it permits new/continued implementation in order to foster >> interoperability with older/existing implementations." >> >> from SMIv2 [RFC2578] and which is almost unchanged in YANG [RFC6020] >> >> "The "status" statement takes as an argument one of the strings >> "current", "deprecated", or "obsolete". >> >> o "current" means that the definition is current and valid. >> >> o "deprecated" indicates an obsolete definition, but it permits >> new/ >> continued implementation in order to foster interoperability with >> older/existing implementations. >> >> o "obsolete" means the definition is obsolete and SHOULD NOT be >> implemented and/or can be removed from implementations." >> >> I have always taken this to be IETF-wide so that when RFC4271 uses >> 'deprecated' without explanation, everyone knows what is meant. As >> such, I would suggest not including any definition thereof. If it >> is good > enough >> for RFC4271, ..... > > Cool, done! > >> >> But I would still include explicit sentences along the lines of 'do >> not > generate >> any new ones, and stop using existing ones as soon as you can' > > Version -01 included some strengthened text, but I've just posted -02. > Please have a look and let me know if you think this is the correct > strength -- > it's basically what you provided, but reworded slightly to be a > little more > "formal". > > W > >> >> Tom Petch >> >> ps you could include a reference to maidens praying, but that is >> probably >> too much an SNMP in-joke. >> >> ----- Original Message ----- >> From: "Warren Kumari" >> To: "t.petch" >> Cc: "Warren Kumari" ; >> Sent: Wednesday, December 29, 2010 11:08 PM >> Subject: Re: [Idr] draft-ietf-idr-deprecate-as-sets-00 >> >> On Dec 8, 2010, at 4:16 AM, t.petch wrote: >> >>> ----- Original Message ----- >>> From: "Warren Kumari" >>> To: "Warren Kumari" >>> Cc: >>> Sent: Tuesday, December 07, 2010 6:10 PM >>> Subject: Re: [Idr] draft-ietf-idr-deprecate-as-sets-00 >>> >>> >>>> From the lack of slings and arrows, I'm going to have to assume >>>> that this >>> document is just *perfect* and cannot be improved at all.... >>>> >>>> Go, prove me wrong (please?) >>> >>> Easy peasy >> >> Doh. I said that I'd get to soon, but, well, I didn't.... Sorry. >>> >>> "The reductions ... is outweighed " >> >> Good catch. Done. >>> >>> "Deprecate: To mark ... as obsolete" >>> **disagree obsolete and deprecate are quite different and I think >>> deprecate >>> correct here (but see below). >>> >> >> Yes, I agree. This is horrid, but I wasn't able to find a better >> definition of >> "deprecate" anywhere... >> I have spent a while looking at various definitions and have munged >> a few of >> them together into one :-) >> Hopefully this is a reasonable, otherwise, if you happen to be able >> to > wordsmith >> a better one I'd really appreciate it. >> >> >>> "RPKI" >>> ** not expanded, explained or referenced, nor mentioned in the >>> introduction. >> >> Bah! I didn't want to have the document held up while waiting for >> draft-ietf-sidr-arch-11 (or similar) to be published, so I tossed >> in "RPKI", >> intending to find a good reference before posting it, but then >> forgot... >> >> I have reworded things to avoid using the term RPKI, hopefully this >> is still >> specific enough. >> >>> For me, RPKI is the driving force for this I-D - I know of no >>> other reason > for >>> it to exist so more is needed here. >> >> While RPKI is the reason closest to my heart as well, it is not the >> only >> reason -- AS_SETs have caused both confusion and issues, for example: >> http://www.merit.edu/mail.archives/nanog/msg14479.html >> >> This is (IMO) both because the code is not well exercised and >> because the >> relevant bits of the RFC are, um, confusing. AS_SETs also seem to >> cause >> confusion to many operators -- if I see: >> *> 192.0.2.0/24 1 12 22 9 6 i >> I know exactly who to talk to about issues with 192.0.2.0. If I see: >> *> 192.0.2.0/24 1 12 {22 9 6} i >> who should I talk to? AS12? AS6? All of them, none of them? >> >> And what exactly does AS_PATH 3561 3356 9031 >> {35821,35821,35821,35821} i mean? >> (http://www.gossamer-threads.com/lists/cisco/nsp/137647?do=post_view_threaded_ >> >>> >>> "simplified.. " >> >> Done. >> >>> >>> Is there an exposure from systems that will refuse to process AS- >>> SET when >>> receiving one, eg a black hole? I don't know, but think it needs >>> exploring. >> >> >> If someone is announcing an aggregate containing an AS_SET, and is >> not >> announcing the more specifics as well, then yes, this could happen >> -- I have > not >> been able to find any cases of this though. I guess it is also >> possible that a >> more specific could go away, and the aggregator may have some >> backdoor route > to >> a contributor, but a: this is getting into the pathological and b: >> we are >> advising folk to stop generating these anyway :-P >> >> >>> >>> And, just what is being recommended? Deprecate is a weasel word >>> and I think >>> needs elucidating ie spell out whatever it is we are >>> recommending. I take it >> as >>> do not generate any new AS_SET and look to eliminate any that are >>> currently >>> being generated, but think that that needs saying explicitly. >> >> Yup, that is it exactly. I have attempted to demustelate it -- I >> would like to >> make it even stronger[0], but think that this is now explicit >> enough, you? >> >> W >> >> [0]: Like "Warning: AS_SETs and AS_CONFED_SETs are going away. >> Please stop >> announcing them or some chappie with a big bat will come knocking..." >> >>> Tom Petch > From ietfc@btconnect.com Fri Feb 18 03:22:49 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A79203A6C7C for ; Fri, 18 Feb 2011 03:22:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.294 X-Spam-Level: X-Spam-Status: No, score=-0.294 tagged_above=-999 required=5 tests=[AWL=-0.595, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, MANGLED_DIET=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HAmU2Zispn9v for ; Fri, 18 Feb 2011 03:22:47 -0800 (PST) Received: from mail.btconnect.com (c2bthomr10.btconnect.com [213.123.20.128]) by core3.amsl.com (Postfix) with ESMTP id B5AA53A6B59 for ; Fri, 18 Feb 2011 03:22:46 -0800 (PST) Received: from host86-141-16-12.range86-141.btcentralplus.com (HELO pc6) ([86.141.16.12]) by c2bthomr10.btconnect.com with SMTP id BUI83725; Fri, 18 Feb 2011 11:23:16 +0000 (GMT) Message-ID: <009901cbcf55$456667a0$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Warren Kumari" , "idr" References: <9E95EA3A-157B-4A40-88F7-514E7FFF3477@kumari.net><008001cb96b8$bb01d740$4001a8c0@gateway.2wire.net><00b301cba848$3490af00$4001a8c0@gateway.2wire.net><9AC2F61C-66C9-41B3-ACC0-DE72F0E8F83A@kumari.net><009201cbb64f$9da1f660$4001a8c0@gateway.2wire.net> Date: Fri, 18 Feb 2011 11:18:44 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Neutral-1, source=Queried, refid=tid=0001.0A0B0301.4D5E5695.00FC, actions=tag X-Junkmail-Status: score=10/50, host=c2bthomr10.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0202.4D5E56A4.02B7,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=single engine X-Junkmail-IWF: false Subject: Re: [Idr] draft-ietf-idr-deprecate-as-sets-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 11:22:49 -0000 ----- Original Message ----- From: "Warren Kumari" To: "idr" Sent: Wednesday, February 16, 2011 9:56 PM Subject: Re: [Idr] draft-ietf-idr-deprecate-as-sets-00 > Whoops, tomorrow would be a month since I last poked this, so shame on > me... Yes but who are you poking? I am happy with and would welcome a WG LC, but if so, direct your e-mail explicitly to the WG Chair. The issue that might be unresolved is the one of what ISPs should do when they get these deprecated attributes. For me, that is the subject for another I-D, let's get this one out pronto, but from comments on the list, I am not sure what the consensus on this is. Tom Petch > > Could I get others to chime in here with comments? Should I ask for > this to be considered for WGLC[0]? > > W > > [0]: Yes, I *am* poking the stick in the nest and giving it a shake to > see if anything flies out and bites me. :-) > > On Jan 17, 2011, at 8:55 AM, t.petch wrote: > > > Looks good to me. > > > > I thought briefly that the language ought to be SHOULD or MUST but > > then > > realised that this I-D is INFORMATIONAL so that those would not > > really be appropriate. > > > > Tom Petch > > > > ----- Original Message ----- > > From: "Warren Kumari" > > To: "t.petch" > > Cc: "Warren Kumari" ; "idr" > > Sent: Sunday, January 16, 2011 4:28 PM > > Subject: Re: [Idr] draft-ietf-idr-deprecate-as-sets-00 > > > > > > > > On Dec 30, 2010, at 12:37 PM, t.petch wrote: > > > >> Warren > >> > >> Top posting on deprecate since that seems the fuzzy issue. > >> > >> I also work in network management, and so take for granted > >> statements such as > >> " The value "current" means that the definition is current and valid. > >> The value "obsolete" means the definition is obsolete and should not > >> be implemented and/or can be removed if previously implemented. > >> While the value "deprecated" also indicates an obsolete definition, > >> it permits new/continued implementation in order to foster > >> interoperability with older/existing implementations." > >> > >> from SMIv2 [RFC2578] and which is almost unchanged in YANG [RFC6020] > >> > >> "The "status" statement takes as an argument one of the strings > >> "current", "deprecated", or "obsolete". > >> > >> o "current" means that the definition is current and valid. > >> > >> o "deprecated" indicates an obsolete definition, but it permits > >> new/ > >> continued implementation in order to foster interoperability with > >> older/existing implementations. > >> > >> o "obsolete" means the definition is obsolete and SHOULD NOT be > >> implemented and/or can be removed from implementations." > >> > >> I have always taken this to be IETF-wide so that when RFC4271 uses > >> 'deprecated' without explanation, everyone knows what is meant. As > >> such, I would suggest not including any definition thereof. If it > >> is good > > enough > >> for RFC4271, ..... > > > > Cool, done! > > > >> > >> But I would still include explicit sentences along the lines of 'do > >> not > > generate > >> any new ones, and stop using existing ones as soon as you can' > > > > Version -01 included some strengthened text, but I've just posted -02. > > Please have a look and let me know if you think this is the correct > > strength -- > > it's basically what you provided, but reworded slightly to be a > > little more > > "formal". > > > > W > > > >> > >> Tom Petch > >> > >> ps you could include a reference to maidens praying, but that is > >> probably > >> too much an SNMP in-joke. > >> > >> ----- Original Message ----- > >> From: "Warren Kumari" > >> To: "t.petch" > >> Cc: "Warren Kumari" ; > >> Sent: Wednesday, December 29, 2010 11:08 PM > >> Subject: Re: [Idr] draft-ietf-idr-deprecate-as-sets-00 > >> > >> On Dec 8, 2010, at 4:16 AM, t.petch wrote: > >> > >>> ----- Original Message ----- > >>> From: "Warren Kumari" > >>> To: "Warren Kumari" > >>> Cc: > >>> Sent: Tuesday, December 07, 2010 6:10 PM > >>> Subject: Re: [Idr] draft-ietf-idr-deprecate-as-sets-00 > >>> > >>> > >>>> From the lack of slings and arrows, I'm going to have to assume > >>>> that this > >>> document is just *perfect* and cannot be improved at all.... > >>>> > >>>> Go, prove me wrong (please?) > >>> > >>> Easy peasy > >> > >> Doh. I said that I'd get to soon, but, well, I didn't.... Sorry. > >>> > >>> "The reductions ... is outweighed " > >> > >> Good catch. Done. > >>> > >>> "Deprecate: To mark ... as obsolete" > >>> **disagree obsolete and deprecate are quite different and I think > >>> deprecate > >>> correct here (but see below). > >>> > >> > >> Yes, I agree. This is horrid, but I wasn't able to find a better > >> definition of > >> "deprecate" anywhere... > >> I have spent a while looking at various definitions and have munged > >> a few of > >> them together into one :-) > >> Hopefully this is a reasonable, otherwise, if you happen to be able > >> to > > wordsmith > >> a better one I'd really appreciate it. > >> > >> > >>> "RPKI" > >>> ** not expanded, explained or referenced, nor mentioned in the > >>> introduction. > >> > >> Bah! I didn't want to have the document held up while waiting for > >> draft-ietf-sidr-arch-11 (or similar) to be published, so I tossed > >> in "RPKI", > >> intending to find a good reference before posting it, but then > >> forgot... > >> > >> I have reworded things to avoid using the term RPKI, hopefully this > >> is still > >> specific enough. > >> > >>> For me, RPKI is the driving force for this I-D - I know of no > >>> other reason > > for > >>> it to exist so more is needed here. > >> > >> While RPKI is the reason closest to my heart as well, it is not the > >> only > >> reason -- AS_SETs have caused both confusion and issues, for example: > >> http://www.merit.edu/mail.archives/nanog/msg14479.html > >> > >> This is (IMO) both because the code is not well exercised and > >> because the > >> relevant bits of the RFC are, um, confusing. AS_SETs also seem to > >> cause > >> confusion to many operators -- if I see: > >> *> 192.0.2.0/24 1 12 22 9 6 i > >> I know exactly who to talk to about issues with 192.0.2.0. If I see: > >> *> 192.0.2.0/24 1 12 {22 9 6} i > >> who should I talk to? AS12? AS6? All of them, none of them? > >> > >> And what exactly does AS_PATH 3561 3356 9031 > >> {35821,35821,35821,35821} i mean? > >> (http://www.gossamer-threads.com/lists/cisco/nsp/137647?do=post_view_threaded_ > >> > >>> > >>> "simplified.. " > >> > >> Done. > >> > >>> > >>> Is there an exposure from systems that will refuse to process AS- > >>> SET when > >>> receiving one, eg a black hole? I don't know, but think it needs > >>> exploring. > >> > >> > >> If someone is announcing an aggregate containing an AS_SET, and is > >> not > >> announcing the more specifics as well, then yes, this could happen > >> -- I have > > not > >> been able to find any cases of this though. I guess it is also > >> possible that a > >> more specific could go away, and the aggregator may have some > >> backdoor route > > to > >> a contributor, but a: this is getting into the pathological and b: > >> we are > >> advising folk to stop generating these anyway :-P > >> > >> > >>> > >>> And, just what is being recommended? Deprecate is a weasel word > >>> and I think > >>> needs elucidating ie spell out whatever it is we are > >>> recommending. I take it > >> as > >>> do not generate any new AS_SET and look to eliminate any that are > >>> currently > >>> being generated, but think that that needs saying explicitly. > >> > >> Yup, that is it exactly. I have attempted to demustelate it -- I > >> would like to > >> make it even stronger[0], but think that this is now explicit > >> enough, you? > >> > >> W > >> > >> [0]: Like "Warning: AS_SETs and AS_CONFED_SETs are going away. > >> Please stop > >> announcing them or some chappie with a big bat will come knocking..." > >> > >>> Tom Petch > > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From ilya@nobulus.com Fri Feb 18 03:30:57 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44F693A6C8D for ; Fri, 18 Feb 2011 03:30:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.298 X-Spam-Level: X-Spam-Status: No, score=-0.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_DIET=2.3, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LXvAXN6cjNjP for ; Fri, 18 Feb 2011 03:30:56 -0800 (PST) Received: from nobulus.com (nobulus.com [IPv6:2001:6f8:892:6ff::11:152]) by core3.amsl.com (Postfix) with ESMTP id 115753A6C7C for ; Fri, 18 Feb 2011 03:30:56 -0800 (PST) Received: from nobulus.com (localhost [127.0.0.1]) by nobulus.com (Postfix) with ESMTP id A75CB170F7; Fri, 18 Feb 2011 12:31:28 +0100 (CET) X-Virus-Scanned: amavisd-new at nobulus.com Received: from nobulus.com ([127.0.0.1]) by nobulus.com (nobulus.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id uZPGf1OiA6N2; Fri, 18 Feb 2011 12:31:26 +0100 (CET) Received: from hnivarlas1 (unknown [IPv6:2001:6f8:892:6f8:b172:ac18:df83:3625]) by nobulus.com (Postfix) with ESMTPA id 98BE0170DF; Fri, 18 Feb 2011 12:31:24 +0100 (CET) Message-ID: <32289CDAB5EF4BEDB9B244BF601BD582@hnivarlas1> From: "iLya" To: "t.petch" , "Warren Kumari" , "idr" References: <9E95EA3A-157B-4A40-88F7-514E7FFF3477@kumari.net><008001cb96b8$bb01d740$4001a8c0@gateway.2wire.net><00b301cba848$3490af00$4001a8c0@gateway.2wire.net><9AC2F61C-66C9-41B3-ACC0-DE72F0E8F83A@kumari.net><009201cbb64f$9da1f660$4001a8c0@gateway.2wire.net> <009901cbcf55$456667a0$4001a8c0@gateway.2wire.net> In-Reply-To: <009901cbcf55$456667a0$4001a8c0@gateway.2wire.net> Date: Fri, 18 Feb 2011 12:31:22 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8089.726 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8089.726 Subject: Re: [Idr] draft-ietf-idr-deprecate-as-sets-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 11:30:57 -0000 -------------------------------------------------- > The issue that might be unresolved is the one of what ISPs should > do when they get these deprecated attributes. For me, that is the > subject for another I-D, let's get this one out pronto, but from comments > on the list, I am not sure what the consensus on this is. > Uhm...we had discussed what ISP's should do when such attribute is encountered, though it didn't seem like we've reached an agreement. I believe "what to do" should be part of -depricate- draft, rather then going into separate document. So let's agree on which of the suggested options to adopt and proceed to WGLC. Cheers, iLya From warren@kumari.net Fri Feb 18 09:05:09 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5547F3A6C8D for ; Fri, 18 Feb 2011 09:05:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.849 X-Spam-Level: X-Spam-Status: No, score=-100.849 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, MANGLED_DIET=2.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zmw2ake6z0Vx for ; Fri, 18 Feb 2011 09:05:07 -0800 (PST) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by core3.amsl.com (Postfix) with ESMTP id 1E18B3A6C7D for ; Fri, 18 Feb 2011 09:05:06 -0800 (PST) Received: from [172.19.118.186] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id D7D981B401C9; Fri, 18 Feb 2011 12:05:39 -0500 (EST) From: Warren Kumari To: "t.petch" In-Reply-To: <009901cbcf55$456667a0$4001a8c0@gateway.2wire.net> X-Priority: 3 References: <9E95EA3A-157B-4A40-88F7-514E7FFF3477@kumari.net><008001cb96b8$bb01d740$4001a8c0@gateway.2wire.net><00b301cba848$3490af00$4001a8c0@gateway.2wire.net><9AC2F61C-66C9-41B3-ACC0-DE72F0E8F83A@kumari.net><009201cbb64f$9da1f660$4001a8c0@gateway.2wire.net> <009901cbcf55$456667a0$4001a8c0@gateway.2wire.net> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 18 Feb 2011 12:05:37 -0500 X-Mailer: Apple Mail (2.936) Cc: idr Subject: Re: [Idr] draft-ietf-idr-deprecate-as-sets-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 17:05:09 -0000 On Feb 18, 2011, at 5:18 AM, t.petch wrote: > ----- Original Message ----- > From: "Warren Kumari" > To: "idr" > Sent: Wednesday, February 16, 2011 9:56 PM > Subject: Re: [Idr] draft-ietf-idr-deprecate-as-sets-00 > > >> Whoops, tomorrow would be a month since I last poked this, so shame >> on >> me... > > Yes but who are you poking? Actually, I wasn't poking any specific person, but rather relying in the fact that mentioning last call often entices folk to read the draft ;-) > I am happy with and would welcome > a WG LC, but if so, direct your e-mail explicitly to the WG Chair. > Fair enough - I was mainly trying to get more views / input, but Sue saw it and will be starting LC soon.... W > The issue that might be unresolved is the one of what ISPs should > do when they get these deprecated attributes. For me, that is the > subject for another I-D, let's get this one out pronto, but from > comments > on the list, I am not sure what the consensus on this is. > > Tom Petch > >> >> Could I get others to chime in here with comments? Should I ask for >> this to be considered for WGLC[0]? >> >> W >> >> [0]: Yes, I *am* poking the stick in the nest and giving it a shake >> to >> see if anything flies out and bites me. :-) >> >> On Jan 17, 2011, at 8:55 AM, t.petch wrote: >> >>> Looks good to me. >>> >>> I thought briefly that the language ought to be SHOULD or MUST but >>> then >>> realised that this I-D is INFORMATIONAL so that those would not >>> really be appropriate. >>> >>> Tom Petch >>> >>> ----- Original Message ----- >>> From: "Warren Kumari" >>> To: "t.petch" >>> Cc: "Warren Kumari" ; "idr" >>> Sent: Sunday, January 16, 2011 4:28 PM >>> Subject: Re: [Idr] draft-ietf-idr-deprecate-as-sets-00 >>> >>> >>> >>> On Dec 30, 2010, at 12:37 PM, t.petch wrote: >>> >>>> Warren >>>> >>>> Top posting on deprecate since that seems the fuzzy issue. >>>> >>>> I also work in network management, and so take for granted >>>> statements such as >>>> " The value "current" means that the definition is current and >>>> valid. >>>> The value "obsolete" means the definition is obsolete and should >>>> not >>>> be implemented and/or can be removed if previously implemented. >>>> While the value "deprecated" also indicates an obsolete definition, >>>> it permits new/continued implementation in order to foster >>>> interoperability with older/existing implementations." >>>> >>>> from SMIv2 [RFC2578] and which is almost unchanged in YANG >>>> [RFC6020] >>>> >>>> "The "status" statement takes as an argument one of the strings >>>> "current", "deprecated", or "obsolete". >>>> >>>> o "current" means that the definition is current and valid. >>>> >>>> o "deprecated" indicates an obsolete definition, but it permits >>>> new/ >>>> continued implementation in order to foster interoperability >>>> with >>>> older/existing implementations. >>>> >>>> o "obsolete" means the definition is obsolete and SHOULD NOT be >>>> implemented and/or can be removed from implementations." >>>> >>>> I have always taken this to be IETF-wide so that when RFC4271 uses >>>> 'deprecated' without explanation, everyone knows what is meant. As >>>> such, I would suggest not including any definition thereof. If it >>>> is good >>> enough >>>> for RFC4271, ..... >>> >>> Cool, done! >>> >>>> >>>> But I would still include explicit sentences along the lines of 'do >>>> not >>> generate >>>> any new ones, and stop using existing ones as soon as you can' >>> >>> Version -01 included some strengthened text, but I've just posted >>> -02. >>> Please have a look and let me know if you think this is the correct >>> strength -- >>> it's basically what you provided, but reworded slightly to be a >>> little more >>> "formal". >>> >>> W >>> >>>> >>>> Tom Petch >>>> >>>> ps you could include a reference to maidens praying, but that is >>>> probably >>>> too much an SNMP in-joke. >>>> >>>> ----- Original Message ----- >>>> From: "Warren Kumari" >>>> To: "t.petch" >>>> Cc: "Warren Kumari" ; >>>> Sent: Wednesday, December 29, 2010 11:08 PM >>>> Subject: Re: [Idr] draft-ietf-idr-deprecate-as-sets-00 >>>> >>>> On Dec 8, 2010, at 4:16 AM, t.petch wrote: >>>> >>>>> ----- Original Message ----- >>>>> From: "Warren Kumari" >>>>> To: "Warren Kumari" >>>>> Cc: >>>>> Sent: Tuesday, December 07, 2010 6:10 PM >>>>> Subject: Re: [Idr] draft-ietf-idr-deprecate-as-sets-00 >>>>> >>>>> >>>>>> From the lack of slings and arrows, I'm going to have to assume >>>>>> that this >>>>> document is just *perfect* and cannot be improved at all.... >>>>>> >>>>>> Go, prove me wrong (please?) >>>>> >>>>> Easy peasy >>>> >>>> Doh. I said that I'd get to soon, but, well, I didn't.... Sorry. >>>>> >>>>> "The reductions ... is outweighed " >>>> >>>> Good catch. Done. >>>>> >>>>> "Deprecate: To mark ... as obsolete" >>>>> **disagree obsolete and deprecate are quite different and I think >>>>> deprecate >>>>> correct here (but see below). >>>>> >>>> >>>> Yes, I agree. This is horrid, but I wasn't able to find a better >>>> definition of >>>> "deprecate" anywhere... >>>> I have spent a while looking at various definitions and have munged >>>> a few of >>>> them together into one :-) >>>> Hopefully this is a reasonable, otherwise, if you happen to be able >>>> to >>> wordsmith >>>> a better one I'd really appreciate it. >>>> >>>> >>>>> "RPKI" >>>>> ** not expanded, explained or referenced, nor mentioned in the >>>>> introduction. >>>> >>>> Bah! I didn't want to have the document held up while waiting for >>>> draft-ietf-sidr-arch-11 (or similar) to be published, so I tossed >>>> in "RPKI", >>>> intending to find a good reference before posting it, but then >>>> forgot... >>>> >>>> I have reworded things to avoid using the term RPKI, hopefully this >>>> is still >>>> specific enough. >>>> >>>>> For me, RPKI is the driving force for this I-D - I know of no >>>>> other reason >>> for >>>>> it to exist so more is needed here. >>>> >>>> While RPKI is the reason closest to my heart as well, it is not the >>>> only >>>> reason -- AS_SETs have caused both confusion and issues, for >>>> example: >>>> http://www.merit.edu/mail.archives/nanog/msg14479.html >>>> >>>> This is (IMO) both because the code is not well exercised and >>>> because the >>>> relevant bits of the RFC are, um, confusing. AS_SETs also seem to >>>> cause >>>> confusion to many operators -- if I see: >>>> *> 192.0.2.0/24 1 12 22 9 6 i >>>> I know exactly who to talk to about issues with 192.0.2.0. If I >>>> see: >>>> *> 192.0.2.0/24 1 12 {22 9 6} i >>>> who should I talk to? AS12? AS6? All of them, none of them? >>>> >>>> And what exactly does AS_PATH 3561 3356 9031 >>>> {35821,35821,35821,35821} i mean? >>>> > (http://www.gossamer-threads.com/lists/cisco/nsp/137647?do=post_view_threaded_ >>>> >>>>> >>>>> "simplified.. " >>>> >>>> Done. >>>> >>>>> >>>>> Is there an exposure from systems that will refuse to process AS- >>>>> SET when >>>>> receiving one, eg a black hole? I don't know, but think it needs >>>>> exploring. >>>> >>>> >>>> If someone is announcing an aggregate containing an AS_SET, and is >>>> not >>>> announcing the more specifics as well, then yes, this could happen >>>> -- I have >>> not >>>> been able to find any cases of this though. I guess it is also >>>> possible that a >>>> more specific could go away, and the aggregator may have some >>>> backdoor route >>> to >>>> a contributor, but a: this is getting into the pathological and b: >>>> we are >>>> advising folk to stop generating these anyway :-P >>>> >>>> >>>>> >>>>> And, just what is being recommended? Deprecate is a weasel word >>>>> and I think >>>>> needs elucidating ie spell out whatever it is we are >>>>> recommending. I take it >>>> as >>>>> do not generate any new AS_SET and look to eliminate any that are >>>>> currently >>>>> being generated, but think that that needs saying explicitly. >>>> >>>> Yup, that is it exactly. I have attempted to demustelate it -- I >>>> would like to >>>> make it even stronger[0], but think that this is now explicit >>>> enough, you? >>>> >>>> W >>>> >>>> [0]: Like "Warning: AS_SETs and AS_CONFED_SETs are going away. >>>> Please stop >>>> announcing them or some chappie with a big bat will come >>>> knocking..." >>>> >>>>> Tom Petch >>> >> >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr > From rjs@rob.sh Sun Feb 20 04:27:49 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EA193A6EE9 for ; Sun, 20 Feb 2011 04:27:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BlCqq+gZwPGR for ; Sun, 20 Feb 2011 04:27:48 -0800 (PST) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2001:b98:201:101::10:cafe]) by core3.amsl.com (Postfix) with ESMTP id 1B6DD3A6CF9 for ; Sun, 20 Feb 2011 04:27:47 -0800 (PST) Received: from [93.97.180.64] (helo=lait.config) by cappuccino.rob.sh with esmtpa (Exim 4.69) (envelope-from ) id 1Pr8MY-0007AW-Vw; Sun, 20 Feb 2011 12:26:07 +0000 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Rob Shakir In-Reply-To: <201102161412.p1GECnU20072@magenta.juniper.net> Date: Sun, 20 Feb 2011 12:28:19 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <7A8B0B42-C9FE-4ADD-8211-84075856D69B@rob.sh> References: <20110110174506.3308.66220.idtracker@localhost> <7AB58CEC-F7F3-427C-A1EC-55B8902BAD16@nobulus.com> <201102161412.p1GECnU20072@magenta.juniper.net> To: Yakov Rekhter , iLya X-Mailer: Apple Mail (2.1081) Cc: IETF IDR Subject: Re: [Idr] I-D Action:draft-ietf-idr-rfc4760bis-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Feb 2011 12:27:49 -0000 Hi, I would like to lend my support to both of the clarifications discussed = herein. In terms of the empty MP_REACH and MP_UNREACH NLRI, there are existing = implementations that do treat this as an error, therefore it is of = advantage from my perspective to confirm that this is not erroneous = behaviour. The existing texts do not appear to provide clear guidance on = this part, and I am aware of situations where this has caused = disruption. I would also like to add a +1 on the clarification of the = inter- route distribution, as Ilya has noted previously, this = leads to very unexpected consequences. Many thanks, Rob= From rjs@rob.sh Sun Feb 20 13:21:02 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7173F3A6E08; Sun, 20 Feb 2011 13:21:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qKz8LmgpgtYT; Sun, 20 Feb 2011 13:21:01 -0800 (PST) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2001:b98:201:101::10:cafe]) by core3.amsl.com (Postfix) with ESMTP id CAAFF3A6C68; Sun, 20 Feb 2011 13:21:00 -0800 (PST) Received: from [93.97.180.64] (helo=lait.config) by cappuccino.rob.sh with esmtpa (Exim 4.69) (envelope-from ) id 1PrGge-0007g8-Cn; Sun, 20 Feb 2011 21:19:24 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1081) From: Rob Shakir Date: Sun, 20 Feb 2011 21:21:37 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: To: grow@ietf.org X-Mailer: Apple Mail (2.1081) Cc: IETF IDR Subject: [Idr] Fwd: New Version Notification for draft-shakir-idr-ops-reqs-for-bgp-error-handling-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Feb 2011 21:21:02 -0000 Hi GROW/IDR [0], One of the problems faced by those operators utilising BGP at the = current time are the limited error handling mechanisms that exist within = the protocol. This continues to cause numerous issues, especially with = the evolution of BGP-4 within autonomous systems as the signalling = protocol of choice. Where existing work items do exist, in some places = they do not completely meet the requirements of modern service provider = networks. This is particularly the case where some compromise to = "protocol correctness" is required to meet the robustness requirements. To this end, the draft forwarded below intends to describe the use = cases, and requirements for enhancements to the BGP-4 protocol to meet = the robustness requirements of modern SP networks. In general, most = work items are already captured by existing drafts, but my require some = extension to meet the requirements specified. The draft has been = presented to a number of operational communities [1], and feedback = solicited as to the utility, in general, the feedback I have received is = that the approach specified captures the general operational = requirements for enhancements to error handling in BGP. To the end of producing a requirements document to which other work = items can be directed, I would very much welcome feedback on this draft = from the GROW and IDR communities. Many thanks in advance for your review. Kind regards, Rob [0]: Please excuse this mail being sent to multiple lists, whilst the = majority of the work described within the draft is within the IDR area = currently, it was pointed out to me that this draft is perhaps better = within the GROW space. If there are any comments, especially from the = relevant WG chairs, I'd be happy to take some guidance as to where this = is most suitably discussed. [1]: Particularly, this draft was presented at NANOG and UKNOF - the = slides can be found at = http://nanog.org/meetings/nanog51/presentations/Tuesday/shakir-bgp-error-h= andling_rob-shakir-FINAL2.pdf - I am hoping that I can make a video of = the presentation available within a couple of days if this is of = interest. -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] Sent: Sun 2/20/2011 9:03 PM To: Shakir, Rob Subject: New Version Notification for = draft-shakir-idr-ops-reqs-for-bgp-error-handling-01 =20 A new version of I-D, = draft-shakir-idr-ops-reqs-for-bgp-error-handling-01.txt has been = successfully submitted by Rob Shakir and posted to the IETF repository. Filename: draft-shakir-idr-ops-reqs-for-bgp-error-handling Revision: 01 Title: Operational Requirements for Enhanced Error Handling = Behaviour in BGP-4 Creation_date: 2011-02-20 WG ID: Independent Submission Number_of_pages: 22 Abstract: BGP-4 is utilised as a key intra- and inter-Autonomous System routing protocol in modern IP networks. The failure modes as defined by the original protocol standards are based on a number of assumptions around the impact of session failure. Numerous incidents both in the global Internet routing table and within Service Provider networks have been caused by strict handling of a single invalid UPDATE message causing large-scale failures in one or more Autonomous Systems. This memo describes the current use of BGP-4 within Service Provider networks, and outlines a set of requirements for further work to enhance the mechanisms available to a BGP-4 implementation when erroneous data is detected. Whilst this document does not provide specification of any standard, it is intended as an overview of a set of enhancements to BGP-4 to improve the protocol's robustness to suit its current deployment. = =20 The IETF Secretariat. From neil@domino.org Tue Feb 22 06:49:50 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53E623A68F8 for ; Tue, 22 Feb 2011 06:49:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.372 X-Spam-Level: X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A8ooohYjYQJp for ; Tue, 22 Feb 2011 06:49:49 -0800 (PST) Received: from out2b.electric.net (smtp-out-39.electric.net [72.35.23.39]) by core3.amsl.com (Postfix) with ESMTP id 1D14E3A68F6 for ; Tue, 22 Feb 2011 06:49:48 -0800 (PST) Received: from 1PrtZO-00024x-Ue by out2b.electric.net with emc1-ok (Exim 4.72) (envelope-from ) id 1PrtZP-00027d-Tp; Tue, 22 Feb 2011 06:50:31 -0800 Received: by emcmailer; Tue, 22 Feb 2011 06:50:31 -0800 Received: from [10.86.5.47] (helo=fuse247.electric.net) by out2b.electric.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1PrtZO-00024x-Ue; Tue, 22 Feb 2011 06:50:30 -0800 Received: from mailanyone.net by fuse247.electric.net with esmtpa (MailAnyone extSMTP neil@domino.org) id 1PrtZM-0005mM-S5; Tue, 22 Feb 2011 06:50:30 -0800 User-Agent: Microsoft-MacOutlook/14.2.0.101115 Date: Tue, 22 Feb 2011 14:50:26 +0000 From: "Neil J. McRae" To: Rob Shakir Message-ID: Thread-Topic: [Idr] Fwd: New Version Notification for draft-shakir-idr-ops-reqs-for-bgp-error-handling-01 In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Outbound-IP: 10.86.5.47 X-Env-From: neil@domino.org X-PolicySMART: 1340502 X-Virus-Status: Scanned by VirusSMART (c) Cc: IETF IDR Subject: Re: [Idr] Fwd: New Version Notification for draft-shakir-idr-ops-reqs-for-bgp-error-handling-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 14:49:50 -0000 Rob, This is a great document and as a network operator I think this is something that I'd like to see implemented. The downsides of a minute inconsistency are not great enough compared to a complete BGP failure with my organisations network* Regards, Neil. (* which in the last 10 years I've had way too many times). On 20/02/2011 21:21, "Rob Shakir" wrote: >Hi GROW/IDR [0], > >One of the problems faced by those operators utilising BGP at the current >time are the limited error handling mechanisms that exist within the >protocol. This continues to cause numerous issues, especially with the >evolution of BGP-4 within autonomous systems as the signalling protocol >of choice. Where existing work items do exist, in some places they do >not completely meet the requirements of modern service provider networks. > This is particularly the case where some compromise to "protocol >correctness" is required to meet the robustness requirements. > >To this end, the draft forwarded below intends to describe the use cases, >and requirements for enhancements to the BGP-4 protocol to meet the >robustness requirements of modern SP networks. In general, most work >items are already captured by existing drafts, but my require some >extension to meet the requirements specified. The draft has been >presented to a number of operational communities [1], and feedback >solicited as to the utility, in general, the feedback I have received is >that the approach specified captures the general operational requirements >for enhancements to error handling in BGP. > >To the end of producing a requirements document to which other work items >can be directed, I would very much welcome feedback on this draft from >the GROW and IDR communities. > >Many thanks in advance for your review. > >Kind regards, >Rob > >[0]: Please excuse this mail being sent to multiple lists, whilst the >majority of the work described within the draft is within the IDR area >currently, it was pointed out to me that this draft is perhaps better >within the GROW space. If there are any comments, especially from the >relevant WG chairs, I'd be happy to take some guidance as to where this >is most suitably discussed. > >[1]: Particularly, this draft was presented at NANOG and UKNOF - the >slides can be found at >http://nanog.org/meetings/nanog51/presentations/Tuesday/shakir-bgp-error-h >andling_rob-shakir-FINAL2.pdf - I am hoping that I can make a video of >the presentation available within a couple of days if this is of interest. > >-----Original Message----- >From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] >Sent: Sun 2/20/2011 9:03 PM >To: Shakir, Rob >Subject: New Version Notification for >draft-shakir-idr-ops-reqs-for-bgp-error-handling-01 > > >A new version of I-D, >draft-shakir-idr-ops-reqs-for-bgp-error-handling-01.txt has been >successfully submitted by Rob Shakir and posted to the IETF repository. > >Filename: draft-shakir-idr-ops-reqs-for-bgp-error-handling >Revision: 01 >Title: Operational Requirements for Enhanced Error Handling >Behaviour in BGP-4 >Creation_date: 2011-02-20 >WG ID: Independent Submission >Number_of_pages: 22 > >Abstract: >BGP-4 is utilised as a key intra- and inter-Autonomous System routing >protocol in modern IP networks. The failure modes as defined by the >original protocol standards are based on a number of assumptions >around the impact of session failure. Numerous incidents both in the >global Internet routing table and within Service Provider networks >have been caused by strict handling of a single invalid UPDATE >message causing large-scale failures in one or more Autonomous >Systems. > >This memo describes the current use of BGP-4 within Service Provider >networks, and outlines a set of requirements for further work to >enhance the mechanisms available to a BGP-4 implementation when >erroneous data is detected. Whilst this document does not provide >specification of any standard, it is intended as an overview of a set >of enhancements to BGP-4 to improve the protocol's robustness to suit >its current deployment. > > > > >The IETF Secretariat. > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www.ietf.org/mailman/listinfo/idr From russell@heilling.net Tue Feb 22 07:48:30 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7408E3A690B; Tue, 22 Feb 2011 07:48:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.75 X-Spam-Level: X-Spam-Status: No, score=-2.75 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5s2JqCCbZ1mU; Tue, 22 Feb 2011 07:48:29 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by core3.amsl.com (Postfix) with ESMTP id 24D3D3A68F2; Tue, 22 Feb 2011 07:48:28 -0800 (PST) Received: by pzk30 with SMTP id 30so562500pzk.31 for ; Tue, 22 Feb 2011 07:49:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heilling.net; s=google; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=SqTk89grUER4QbS8mkSogP9QvepcwhylKzmqBnYSCY8=; b=THWqor/pYKUVwV5RA9yoYpMu+hTbuCG+7XMaPCurTRxVSy30jbKENovt/jSIsrkRnv 0bSJXXgUTPcply8fCctj/zi9Lzb+6Ky6YKVzpaMy24n3NHQ+QS+PUdifq+ow9XuCw6XE EcHwKwgj1tZSxt7CZp8WNJ3zV/SsnFGSM6E98= DomainKey-Signature: a=rsa-sha1; c=nofws; d=heilling.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=CbQs4rs6iagzb68oxXiAT14wBEL5jEA9TKZBhm8ceWaLJheDEyIYhQVlaaHjIqKeSx ad4Qp/YflzOjDM4PRlz0VBuUhnbzgY9A2++SL5SmuL4fVgr/XsjkK8cCZ0I8mXaqsqNN Fmz4jNE9pEqO0XKtOcTdk8PQh8leWBFlQlEBE= MIME-Version: 1.0 Received: by 10.142.47.2 with SMTP id u2mr2286077wfu.63.1298389752317; Tue, 22 Feb 2011 07:49:12 -0800 (PST) Received: by 10.142.47.4 with HTTP; Tue, 22 Feb 2011 07:49:12 -0800 (PST) In-Reply-To: References: Date: Tue, 22 Feb 2011 15:49:12 +0000 Message-ID: From: Russell Heilling To: "Neil J. McRae" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IETF IDR , grow@ietf.org Subject: Re: [Idr] Fwd: New Version Notification for draft-shakir-idr-ops-reqs-for-bgp-error-handling-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 15:48:30 -0000 I agree 100%. As the document points out there are a lot of individual efforts to improve the situation currently within the IDR and GROW scope. Having a clear requirements document is essential to make sure that these efforts are all going in the right direction and that all concerns are addressed. Regards, Russell On 22 February 2011 14:50, Neil J. McRae wrote: > Rob, > This is a great document and as a network operator I think this is > something that I'd like to see implemented. The downsides of a minute > inconsistency are not great enough compared to a complete BGP failure wit= h > my organisations network* > > Regards, > Neil. > (* which in the last 10 years I've had way too many times). > > On 20/02/2011 21:21, "Rob Shakir" wrote: > >>Hi GROW/IDR [0], >> >>One of the problems faced by those operators utilising BGP at the current >>time are the limited error handling mechanisms that exist within the >>protocol. =A0This continues to cause numerous issues, especially with the >>evolution of BGP-4 within autonomous systems as the signalling protocol >>of choice. =A0Where existing work items do exist, in some places they do >>not completely meet the requirements of modern service provider networks. >> This is particularly the case where some compromise to "protocol >>correctness" is required to meet the robustness requirements. >> >>To this end, the draft forwarded below intends to describe the use cases, >>and requirements for enhancements to the BGP-4 protocol to meet the >>robustness requirements of modern SP networks. =A0In general, most work >>items are already captured by existing drafts, but my require some >>extension to meet the requirements specified. =A0The draft has been >>presented to a number of operational communities [1], and feedback >>solicited as to the utility, in general, the feedback I have received is >>that the approach specified captures the general operational requirements >>for enhancements to error handling in BGP. >> >>To the end of producing a requirements document to which other work items >>can be directed, I would very much welcome feedback on this draft from >>the GROW and IDR communities. >> >>Many thanks in advance for your review. >> >>Kind regards, >>Rob >> >>[0]: Please excuse this mail being sent to multiple lists, whilst the >>majority of the work described within the draft is within the IDR area >>currently, it was pointed out to me that this draft is perhaps better >>within the GROW space. =A0If there are any comments, especially from the >>relevant WG chairs, I'd be happy to take some guidance as to where this >>is most suitably discussed. >> >>[1]: Particularly, this draft was presented at NANOG and UKNOF - the >>slides can be found at >>http://nanog.org/meetings/nanog51/presentations/Tuesday/shakir-bgp-error-= h >>andling_rob-shakir-FINAL2.pdf - I am hoping that I can make a video of >>the presentation available within a couple of days if this is of interest= . >> >>-----Original Message----- >>From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] >>Sent: Sun 2/20/2011 9:03 PM >>To: Shakir, Rob >>Subject: New Version Notification for >>draft-shakir-idr-ops-reqs-for-bgp-error-handling-01 >> >> >>A new version of I-D, >>draft-shakir-idr-ops-reqs-for-bgp-error-handling-01.txt has been >>successfully submitted by Rob Shakir and posted to the IETF repository. >> >>Filename: =A0 =A0 draft-shakir-idr-ops-reqs-for-bgp-error-handling >>Revision: =A0 =A0 01 >>Title: =A0 =A0 =A0 =A0 Operational Requirements for Enhanced Error Handli= ng >>Behaviour in BGP-4 >>Creation_date: =A0 =A0 2011-02-20 >>WG ID: =A0 =A0 =A0 =A0 Independent Submission >>Number_of_pages: 22 >> >>Abstract: >>BGP-4 is utilised as a key intra- and inter-Autonomous System routing >>protocol in modern IP networks. =A0The failure modes as defined by the >>original protocol standards are based on a number of assumptions >>around the impact of session failure. =A0Numerous incidents both in the >>global Internet routing table and within Service Provider networks >>have been caused by strict handling of a single invalid UPDATE >>message causing large-scale failures in one or more Autonomous >>Systems. >> >>This memo describes the current use of BGP-4 within Service Provider >>networks, and outlines a set of requirements for further work to >>enhance the mechanisms available to a BGP-4 implementation when >>erroneous data is detected. =A0Whilst this document does not provide >>specification of any standard, it is intended as an overview of a set >>of enhancements to BGP-4 to improve the protocol's robustness to suit >>its current deployment. >> >> >> >> >>The IETF Secretariat. >> >>_______________________________________________ >>Idr mailing list >>Idr@ietf.org >>https://www.ietf.org/mailman/listinfo/idr > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --=20 Russell Heilling=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 http://perl= monkey.blogspot.com "The amazing ability of the bee to adapt herself often helps the =A0beekeeper to overcome the results of his ignorance." - Brother Adam From patrick@ianai.net Tue Feb 22 07:31:54 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A32CD3A6907; Tue, 22 Feb 2011 07:31:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.372 X-Spam-Level: X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ABKTpUvGjASL; Tue, 22 Feb 2011 07:31:51 -0800 (PST) Received: from home.priori.net (bos2.priori.net [140.186.190.105]) by core3.amsl.com (Postfix) with ESMTP id D3D8F3A690D; Tue, 22 Feb 2011 07:31:50 -0800 (PST) Received: from [IPv6:::1] (localhost [127.0.0.1]) by home.priori.net (Postfix) with ESMTP id 2DAD578C8B; Tue, 22 Feb 2011 15:32:33 +0000 (UTC) From: "Patrick W. Gilmore" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Tue, 22 Feb 2011 10:32:32 -0500 Message-Id: To: grow@ietf.org, idr@ietf.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-Mailman-Approved-At: Tue, 22 Feb 2011 09:31:58 -0800 Cc: "Patrick W. Gilmore" Subject: [Idr] New Version Notification for draft-shakir-idr-ops-reqs-for-bgp-error-handling-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 15:31:54 -0000 I would like to endorse Rob's draft. --=20 TTFN, patrick =95 To: grow at ietf.org =95 Subject: [Idr] Fwd: New Version Notification for = draft-shakir-idr-ops-reqs-for-bgp-error-handling-01 =95 From: Rob Shakir =95 Date: Sun, 20 Feb 2011 21:21:37 +0000 =95 Cc: IETF IDR =95 Delivered-to: idr at core3.amsl.com =95 List-archive: =95 List-help: =95 List-id: Inter-Domain Routing =95 List-post: =95 List-subscribe: , = =95 List-unsubscribe: = , = Hi GROW/IDR [0], One of the problems faced by those operators utilising BGP at the = current time are the limited error handling mechanisms that exist within = the protocol. This continues to cause numerous issues, especially with = the evolution of BGP-4 within autonomous systems as the signalling = protocol of choice. Where existing work items do exist, in some places = they do not completely meet the requirements of modern service provider = networks. This is particularly the case where some compromise to = "protocol correctness" is required to meet the robustness requirements. To this end, the draft forwarded below intends to describe the use = cases, and requirements for enhancements to the BGP-4 protocol to meet = the robustness requirements of modern SP networks. In general, most = work items are already captured by existing drafts, but my require some = extension to meet the requirements specified. The draft has been = presented to a number of operational communities [1], and feedback = solicited as to the utility, in general, the feedback I have received is = that the approach specified captures the general operational = requirements for enhancements to error handling in BGP. To the end of producing a requirements document to which other work = items can be directed, I would very much welcome feedback on this draft = from the GROW and IDR communities. Many thanks in advance for your review. Kind regards, Rob [0]: Please excuse this mail being sent to multiple lists, whilst the = majority of the work described within the draft is within the IDR area = currently, it was pointed out to me that this draft is perhaps better = within the GROW space. If there are any comments, especially from the = relevant WG chairs, I'd be happy to take some guidance as to where this = is most suitably discussed. [1]: Particularly, this draft was presented at NANOG and UKNOF - the = slides can be found at=20 = http://nanog.org/meetings/nanog51/presentations/Tuesday/shakir-bgp-error-h= andling_rob-shakir-FINAL2.pdf - I am hoping that I can make a video of the presentation available = within a couple of days if this is of interest. -----Original Message----- From: IETF I-D Submission Tool [ mailto:idsubmission at ietf.org] Sent: Sun 2/20/2011 9:03 PM To: Shakir, Rob Subject: New Version Notification for = draft-shakir-idr-ops-reqs-for-bgp-error-handling-01 =20 A new version of I-D, = draft-shakir-idr-ops-reqs-for-bgp-error-handling-01.txt has been = successfully submitted by Rob Shakir and posted to the IETF repository. Filename: draft-shakir-idr-ops-reqs-for-bgp-error-handling Revision: 01 Title: Operational Requirements for Enhanced Error Handling = Behaviour in BGP-4 Creation_date: 2011-02-20 WG ID: Independent Submission Number_of_pages: 22 Abstract: BGP-4 is utilised as a key intra- and inter-Autonomous System routing protocol in modern IP networks. The failure modes as defined by the original protocol standards are based on a number of assumptions around the impact of session failure. Numerous incidents both in the global Internet routing table and within Service Provider networks have been caused by strict handling of a single invalid UPDATE message causing large-scale failures in one or more Autonomous Systems. This memo describes the current use of BGP-4 within Service Provider networks, and outlines a set of requirements for further work to enhance the mechanisms available to a BGP-4 implementation when erroneous data is detected. Whilst this document does not provide specification of any standard, it is intended as an overview of a set of enhancements to BGP-4 to improve the protocol's robustness to suit its current deployment. = =20 The IETF Secretariat. From Edward.GOULD@everythingeverywhere.com Wed Feb 23 01:16:31 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C60F83A684C; Wed, 23 Feb 2011 01:16:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.38 X-Spam-Level: X-Spam-Status: No, score=-5.38 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QeH2LioU8ppj; Wed, 23 Feb 2011 01:16:30 -0800 (PST) Received: from mail140.messagelabs.com (mail140.messagelabs.com [85.158.137.83]) by core3.amsl.com (Postfix) with SMTP id 92DFB3A6809; Wed, 23 Feb 2011 01:16:29 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: Edward.GOULD@everythingeverywhere.com X-Msg-Ref: server-7.tower-140.messagelabs.com!1298452634!14026180!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [193.36.79.210] Received: (qmail 1581 invoked from network); 23 Feb 2011 09:17:14 -0000 Received: from unknown (HELO aphex) (193.36.79.210) by server-7.tower-140.messagelabs.com with SMTP; 23 Feb 2011 09:17:14 -0000 Received: from ukexodnsmtp001.uk.orangegad.com (Not Verified[172.16.132.21]) by aphex with MailMarshal (v6, 8, 2, 9371) id ; Wed, 23 Feb 2011 09:17:39 +0000 Received: from UKEXBRIMBX002.uk.orangegad.com ([172.16.131.94]) by ukexodnsmtp001.uk.orangegad.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 23 Feb 2011 09:17:14 +0000 Received: from 172.16.140.135 ([172.16.140.135]) by UKEXBRIMBX002.uk.orangegad.com ([172.16.131.97]) with Microsoft Exchange Server HTTP-DAV ; Wed, 23 Feb 2011 09:17:14 +0000 References: Thread-Topic: [Idr] New Version Notification fordraft-shakir-idr-ops-reqs-for-bgp-error-handling-01 Thread-Index: AcvTOnVfAkKqDmlIQeGSFkpkQJlD1w== Content-Transfer-Encoding: base64 From: "Gould, Edward" Content-Type: text/plain; charset="utf-8" In-Reply-To: Message-ID: Date: Tue, 22 Feb 2011 17:43:18 +0000 To: MIME-Version: 1.0 (iPhone Mail 8C148a) X-OriginalArrivalTime: 23 Feb 2011 09:17:14.0145 (UTC) FILETIME=[75672910:01CBD33A] Cc: idr@ietf.org Subject: Re: [Idr] New Version Notification fordraft-shakir-idr-ops-reqs-for-bgp-error-handling-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 09:16:31 -0000 QW5vdGhlciBlbmRvcnNlbWVudCBmcm9tIG1lLg0KDQpFZGQuDQoNClNlbnQgZnJvbSBteSBpUGhv bmUNCg0KT24gMjIgRmViIDIwMTEsIGF0IDE3OjMyLCAiUGF0cmljayBXLiBHaWxtb3JlIiA8cGF0 cmlja0BpYW5haS5uZXQ+IHdyb3RlOg0KDQo+IEkgd291bGQgbGlrZSB0byBlbmRvcnNlIFJvYidz IGRyYWZ0Lg0KPiANCj4gLS0gDQo+IFRURk4sDQo+IHBhdHJpY2sNCj4gDQo+IA0KPiAgICDigKIg VG86IGdyb3cgYXQgaWV0Zi5vcmcNCj4gICAg4oCiIFN1YmplY3Q6IFtJZHJdIEZ3ZDogTmV3IFZl cnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1zaGFraXItaWRyLW9wcy1yZXFzLWZvci1iZ3At ZXJyb3ItaGFuZGxpbmctMDENCj4gICAg4oCiIEZyb206IFJvYiBTaGFraXIgPHJqcyBhdCByb2Iu c2g+DQo+ICAgIOKAoiBEYXRlOiBTdW4sIDIwIEZlYiAyMDExIDIxOjIxOjM3ICswMDAwDQo+ICAg IOKAoiBDYzogSUVURiBJRFIgPGlkciBhdCBpZXRmLm9yZz4NCj4gICAg4oCiIERlbGl2ZXJlZC10 bzogaWRyIGF0IGNvcmUzLmFtc2wuY29tDQo+ICAgIOKAoiBMaXN0LWFyY2hpdmU6IDxodHRwOi8v d3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvaWRyPg0KPiAgICDigKIgTGlzdC1oZWxwOiA8 bWFpbHRvOmlkci1yZXF1ZXN0QGlldGYub3JnP3N1YmplY3Q9aGVscD4NCj4gICAg4oCiIExpc3Qt aWQ6IEludGVyLURvbWFpbiBSb3V0aW5nIDxpZHIuaWV0Zi5vcmc+DQo+ICAgIOKAoiBMaXN0LXBv c3Q6IDxtYWlsdG86aWRyQGlldGYub3JnPg0KPiAgICDigKIgTGlzdC1zdWJzY3JpYmU6IDxodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkcj4sIDxtYWlsdG86aWRyLXJlcXVl c3RAaWV0Zi5vcmc/c3ViamVjdD1zdWJzY3JpYmU+DQo+ICAgIOKAoiBMaXN0LXVuc3Vic2NyaWJl OiA8aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZHI+LCA8bWFpbHRvOmlk ci1yZXF1ZXN0QGlldGYub3JnP3N1YmplY3Q9dW5zdWJzY3JpYmU+DQo+IEhpIEdST1cvSURSIFsw XSwNCj4gDQo+IE9uZSBvZiB0aGUgcHJvYmxlbXMgZmFjZWQgYnkgdGhvc2Ugb3BlcmF0b3JzIHV0 aWxpc2luZyBCR1AgYXQgdGhlIGN1cnJlbnQgdGltZSBhcmUgdGhlIGxpbWl0ZWQgZXJyb3IgaGFu ZGxpbmcgbWVjaGFuaXNtcyB0aGF0IGV4aXN0IHdpdGhpbiB0aGUgcHJvdG9jb2wuICBUaGlzIGNv bnRpbnVlcyB0byBjYXVzZSBudW1lcm91cyBpc3N1ZXMsIGVzcGVjaWFsbHkgd2l0aCB0aGUgZXZv bHV0aW9uIG9mIEJHUC00IHdpdGhpbiBhdXRvbm9tb3VzIHN5c3RlbXMgYXMgdGhlIHNpZ25hbGxp bmcgcHJvdG9jb2wgb2YgY2hvaWNlLiAgV2hlcmUgZXhpc3Rpbmcgd29yayBpdGVtcyBkbyBleGlz dCwgaW4gc29tZSBwbGFjZXMgdGhleSBkbyBub3QgY29tcGxldGVseSBtZWV0IHRoZSByZXF1aXJl bWVudHMgb2YgbW9kZXJuIHNlcnZpY2UgcHJvdmlkZXIgbmV0d29ya3MuICBUaGlzIGlzIHBhcnRp Y3VsYXJseSB0aGUgY2FzZSB3aGVyZSBzb21lIGNvbXByb21pc2UgdG8gInByb3RvY29sIGNvcnJl Y3RuZXNzIiBpcyByZXF1aXJlZCB0byBtZWV0IHRoZSByb2J1c3RuZXNzIHJlcXVpcmVtZW50cy4N Cj4gDQo+IFRvIHRoaXMgZW5kLCB0aGUgZHJhZnQgZm9yd2FyZGVkIGJlbG93IGludGVuZHMgdG8g ZGVzY3JpYmUgdGhlIHVzZSBjYXNlcywgYW5kIHJlcXVpcmVtZW50cyBmb3IgZW5oYW5jZW1lbnRz IHRvIHRoZSBCR1AtNCBwcm90b2NvbCB0byBtZWV0IHRoZSByb2J1c3RuZXNzIHJlcXVpcmVtZW50 cyBvZiBtb2Rlcm4gU1AgbmV0d29ya3MuICBJbiBnZW5lcmFsLCBtb3N0IHdvcmsgaXRlbXMgYXJl IGFscmVhZHkgY2FwdHVyZWQgYnkgZXhpc3RpbmcgZHJhZnRzLCBidXQgbXkgcmVxdWlyZSBzb21l IGV4dGVuc2lvbiB0byBtZWV0IHRoZSByZXF1aXJlbWVudHMgc3BlY2lmaWVkLiAgVGhlIGRyYWZ0 IGhhcyBiZWVuIHByZXNlbnRlZCB0byBhIG51bWJlciBvZiBvcGVyYXRpb25hbCBjb21tdW5pdGll cyBbMV0sIGFuZCBmZWVkYmFjayBzb2xpY2l0ZWQgYXMgdG8gdGhlIHV0aWxpdHksIGluIGdlbmVy YWwsIHRoZSBmZWVkYmFjayBJIGhhdmUgcmVjZWl2ZWQgaXMgdGhhdCB0aGUgYXBwcm9hY2ggc3Bl Y2lmaWVkIGNhcHR1cmVzIHRoZSBnZW5lcmFsIG9wZXJhdGlvbmFsIHJlcXVpcmVtZW50cyBmb3Ig ZW5oYW5jZW1lbnRzIHRvIGVycm9yIGhhbmRsaW5nIGluIEJHUC4NCj4gDQo+IFRvIHRoZSBlbmQg b2YgcHJvZHVjaW5nIGEgcmVxdWlyZW1lbnRzIGRvY3VtZW50IHRvIHdoaWNoIG90aGVyIHdvcmsg aXRlbXMgY2FuIGJlIGRpcmVjdGVkLCBJIHdvdWxkIHZlcnkgbXVjaCB3ZWxjb21lIGZlZWRiYWNr IG9uIHRoaXMgZHJhZnQgZnJvbSB0aGUgR1JPVyBhbmQgSURSIGNvbW11bml0aWVzLg0KPiANCj4g TWFueSB0aGFua3MgaW4gYWR2YW5jZSBmb3IgeW91ciByZXZpZXcuDQo+IA0KPiBLaW5kIHJlZ2Fy ZHMsDQo+IFJvYg0KPiANCj4gWzBdOiBQbGVhc2UgZXhjdXNlIHRoaXMgbWFpbCBiZWluZyBzZW50 IHRvIG11bHRpcGxlIGxpc3RzLCB3aGlsc3QgdGhlIG1ham9yaXR5IG9mIHRoZSB3b3JrIGRlc2Ny aWJlZCB3aXRoaW4gdGhlIGRyYWZ0IGlzIHdpdGhpbiB0aGUgSURSIGFyZWEgY3VycmVudGx5LCBp dCB3YXMgcG9pbnRlZCBvdXQgdG8gbWUgdGhhdCB0aGlzIGRyYWZ0IGlzIHBlcmhhcHMgYmV0dGVy IHdpdGhpbiB0aGUgR1JPVyBzcGFjZS4gIElmIHRoZXJlIGFyZSBhbnkgY29tbWVudHMsIGVzcGVj aWFsbHkgZnJvbSB0aGUgcmVsZXZhbnQgV0cgY2hhaXJzLCBJJ2QgYmUgaGFwcHkgdG8gdGFrZSBz b21lIGd1aWRhbmNlIGFzIHRvIHdoZXJlIHRoaXMgaXMgbW9zdCBzdWl0YWJseSBkaXNjdXNzZWQu DQo+IA0KPiBbMV06IFBhcnRpY3VsYXJseSwgdGhpcyBkcmFmdCB3YXMgcHJlc2VudGVkIGF0IE5B Tk9HIGFuZCBVS05PRiAtIHRoZSBzbGlkZXMgY2FuIGJlIGZvdW5kIGF0IA0KPiBodHRwOi8vbmFu b2cub3JnL21lZXRpbmdzL25hbm9nNTEvcHJlc2VudGF0aW9ucy9UdWVzZGF5L3NoYWtpci1iZ3At ZXJyb3ItaGFuZGxpbmdfcm9iLXNoYWtpci1GSU5BTDIucGRmDQo+IC0gSSBhbSBob3BpbmcgdGhh dCBJIGNhbiBtYWtlIGEgdmlkZW8gb2YgdGhlIHByZXNlbnRhdGlvbiBhdmFpbGFibGUgd2l0aGlu IGEgY291cGxlIG9mIGRheXMgaWYgdGhpcyBpcyBvZiBpbnRlcmVzdC4NCj4gDQo+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IElFVEYgSS1EIFN1Ym1pc3Npb24gVG9vbCBbDQo+ IG1haWx0bzppZHN1Ym1pc3Npb24NCj4gYXQgaWV0Zi5vcmddDQo+IFNlbnQ6IFN1biAyLzIwLzIw MTEgOTowMyBQTQ0KPiBUbzogU2hha2lyLCBSb2INCj4gU3ViamVjdDogTmV3IFZlcnNpb24gTm90 aWZpY2F0aW9uIGZvciAgICAgICAgICBkcmFmdC1zaGFraXItaWRyLW9wcy1yZXFzLWZvci1iZ3At ZXJyb3ItaGFuZGxpbmctMDENCj4gDQo+IA0KPiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQt c2hha2lyLWlkci1vcHMtcmVxcy1mb3ItYmdwLWVycm9yLWhhbmRsaW5nLTAxLnR4dCBoYXMgYmVl biBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFJvYiBTaGFraXIgYW5kIHBvc3RlZCB0byB0aGUg SUVURiByZXBvc2l0b3J5Lg0KPiANCj4gRmlsZW5hbWU6ICAgICBkcmFmdC1zaGFraXItaWRyLW9w cy1yZXFzLWZvci1iZ3AtZXJyb3ItaGFuZGxpbmcNCj4gUmV2aXNpb246ICAgICAwMQ0KPiBUaXRs ZTogICAgICAgICBPcGVyYXRpb25hbCBSZXF1aXJlbWVudHMgZm9yIEVuaGFuY2VkIEVycm9yIEhh bmRsaW5nIEJlaGF2aW91ciBpbiBCR1AtNA0KPiBDcmVhdGlvbl9kYXRlOiAgICAgMjAxMS0wMi0y MA0KPiBXRyBJRDogICAgICAgICBJbmRlcGVuZGVudCBTdWJtaXNzaW9uDQo+IE51bWJlcl9vZl9w YWdlczogMjINCj4gDQo+IEFic3RyYWN0Og0KPiBCR1AtNCBpcyB1dGlsaXNlZCBhcyBhIGtleSBp bnRyYS0gYW5kIGludGVyLUF1dG9ub21vdXMgU3lzdGVtIHJvdXRpbmcNCj4gcHJvdG9jb2wgaW4g bW9kZXJuIElQIG5ldHdvcmtzLiAgVGhlIGZhaWx1cmUgbW9kZXMgYXMgZGVmaW5lZCBieSB0aGUN Cj4gb3JpZ2luYWwgcHJvdG9jb2wgc3RhbmRhcmRzIGFyZSBiYXNlZCBvbiBhIG51bWJlciBvZiBh c3N1bXB0aW9ucw0KPiBhcm91bmQgdGhlIGltcGFjdCBvZiBzZXNzaW9uIGZhaWx1cmUuICBOdW1l cm91cyBpbmNpZGVudHMgYm90aCBpbiB0aGUNCj4gZ2xvYmFsIEludGVybmV0IHJvdXRpbmcgdGFi bGUgYW5kIHdpdGhpbiBTZXJ2aWNlIFByb3ZpZGVyIG5ldHdvcmtzDQo+IGhhdmUgYmVlbiBjYXVz ZWQgYnkgc3RyaWN0IGhhbmRsaW5nIG9mIGEgc2luZ2xlIGludmFsaWQgVVBEQVRFDQo+IG1lc3Nh Z2UgY2F1c2luZyBsYXJnZS1zY2FsZSBmYWlsdXJlcyBpbiBvbmUgb3IgbW9yZSBBdXRvbm9tb3Vz DQo+IFN5c3RlbXMuDQo+IA0KPiBUaGlzIG1lbW8gZGVzY3JpYmVzIHRoZSBjdXJyZW50IHVzZSBv ZiBCR1AtNCB3aXRoaW4gU2VydmljZSBQcm92aWRlcg0KPiBuZXR3b3JrcywgYW5kIG91dGxpbmVz IGEgc2V0IG9mIHJlcXVpcmVtZW50cyBmb3IgZnVydGhlciB3b3JrIHRvDQo+IGVuaGFuY2UgdGhl IG1lY2hhbmlzbXMgYXZhaWxhYmxlIHRvIGEgQkdQLTQgaW1wbGVtZW50YXRpb24gd2hlbg0KPiBl cnJvbmVvdXMgZGF0YSBpcyBkZXRlY3RlZC4gIFdoaWxzdCB0aGlzIGRvY3VtZW50IGRvZXMgbm90 IHByb3ZpZGUNCj4gc3BlY2lmaWNhdGlvbiBvZiBhbnkgc3RhbmRhcmQsIGl0IGlzIGludGVuZGVk IGFzIGFuIG92ZXJ2aWV3IG9mIGEgc2V0DQo+IG9mIGVuaGFuY2VtZW50cyB0byBCR1AtNCB0byBp bXByb3ZlIHRoZSBwcm90b2NvbCdzIHJvYnVzdG5lc3MgdG8gc3VpdA0KPiBpdHMgY3VycmVudCBk ZXBsb3ltZW50Lg0KPiANCj4gDQo+IA0KPiBUaGUgSUVURiBTZWNyZXRhcmlhdC4NCj4gDQo+IA0K PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBJZHIg bWFpbGluZyBsaXN0DQo+IElkckBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2lkcg0KDQpOT1RJQ0UgQU5EIERJU0NMQUlNRVINClRoaXMgZS1tYWlsIChp bmNsdWRpbmcgYW55IGF0dGFjaG1lbnRzKSBpcyBpbnRlbmRlZCBmb3IgdGhlIGFib3ZlLW5hbWVk IHBlcnNvbihzKS4gIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIG5vdGlm eSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5LCBkZWxldGUgdGhpcyBlbWFpbCBmcm9tIHlvdXIgc3lz dGVtIGFuZCBkbyBub3QgZGlzY2xvc2Ugb3IgdXNlIGZvciBhbnkgcHVycG9zZS4gIA0KIA0KV2Ug bWF5IG1vbml0b3IgYWxsIGluY29taW5nIGFuZCBvdXRnb2luZyBlbWFpbHMgaW4gbGluZSB3aXRo IGN1cnJlbnQgbGVnaXNsYXRpb24uIFdlIGhhdmUgdGFrZW4gc3RlcHMgdG8gZW5zdXJlIHRoYXQg dGhpcyBlbWFpbCBhbmQgYXR0YWNobWVudHMgYXJlIGZyZWUgZnJvbSBhbnkgdmlydXMsIGJ1dCBp dCByZW1haW5zIHlvdXIgcmVzcG9uc2liaWxpdHkgdG8gZW5zdXJlIHRoYXQgdmlydXNlcyBkbyBu b3QgYWR2ZXJzZWx5IGFmZmVjdCB5b3UuIA0KDQpFdmVyeXRoaW5nIEV2ZXJ5d2hlcmUgTGltaXRl ZA0KUmVnaXN0ZXJlZCBpbiBFbmdsYW5kIGFuZCBXYWxlcw0KQ29tcGFueSBSZWdpc3RlcmVkIE51 bWJlcjogMDIzODIxNjENClJlZ2lzdGVyZWQgT2ZmaWNlIEFkZHJlc3M6IEhhdGZpZWxkIEJ1c2lu ZXNzIFBhcmssIEhhdGZpZWxkLCBIZXJ0Zm9yZHNoaXJlLCBBTDEwIDlCVw0K From colin@spakka.net Wed Feb 23 01:23:58 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 722E13A6816; Wed, 23 Feb 2011 01:23:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.186 X-Spam-Level: X-Spam-Status: No, score=-1.186 tagged_above=-999 required=5 tests=[AWL=1.186, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id arCWDV8uB7dl; Wed, 23 Feb 2011 01:23:57 -0800 (PST) Received: from mailhosting.spakka.net (mailhosting.spakka.net [213.229.81.134]) by core3.amsl.com (Postfix) with ESMTP id 992213A6809; Wed, 23 Feb 2011 01:23:57 -0800 (PST) Received: from loki.as29550.net ([213.229.80.68]) by mailhosting.spakka.net with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1PsAxf-00043K-P3; Wed, 23 Feb 2011 09:24:43 +0000 Message-ID: <4D64D25B.5040202@spakka.net> Date: Wed, 23 Feb 2011 09:24:43 +0000 From: Colin Petrie User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20101226 Iceowl/1.0b1 Icedove/3.0.11 MIME-Version: 1.0 To: idr@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SMTP-Authenticated-User: colin@spakka.net Cc: grow@ietf.org Subject: Re: [Idr] Fwd: New Version Notification for draft-shakir-idr-ops-reqs-for-bgp-error-handling-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 09:23:58 -0000 On 22/02/11 14:50, Neil J. McRae wrote: > Rob, > This is a great document and as a network operator I think this is > something that I'd like to see implemented. The downsides of a minute > inconsistency are not great enough compared to a complete BGP failure with > my organisations network* > I totally agree. This document is a pretty good summary of the requirements on this, and a reasonable suggested implementation to mitigate the problems we have seen before too many times. Great work, thanks Rob :) Cheers Colin From Donald.Smith@qwest.com Wed Feb 23 08:32:00 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83F733A691A; Wed, 23 Feb 2011 08:32:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.348 X-Spam-Level: X-Spam-Status: No, score=-2.348 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fIgQXpSbvfE9; Wed, 23 Feb 2011 08:31:59 -0800 (PST) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by core3.amsl.com (Postfix) with ESMTP id ADC0F3A6892; Wed, 23 Feb 2011 08:31:59 -0800 (PST) Received: from lxomavmpc030.qintra.com (lxomavmpc030.qintra.com [151.117.207.30]) by suomp64i.qwest.com (8.14.4/8.14.4) with ESMTP id p1NGWgXP023198 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Feb 2011 10:32:42 -0600 (CST) Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 8604A1E0050; Wed, 23 Feb 2011 10:32:37 -0600 (CST) Received: from suomp60i.qintra.com (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id 6CA0F1E004F; Wed, 23 Feb 2011 10:32:37 -0600 (CST) Received: from qtdenexhtm21.AD.QINTRA.COM (localhost [127.0.0.1]) by suomp60i.qintra.com (8.14.4/8.14.4) with ESMTP id p1NGWNNR021736; Wed, 23 Feb 2011 10:32:35 -0600 (CST) Received: from qtdenexmbm24.AD.QINTRA.COM ([151.119.91.226]) by qtdenexhtm21.AD.QINTRA.COM ([151.119.91.230]) with mapi; Wed, 23 Feb 2011 09:32:31 -0700 From: "Smith, Donald" To: "'Colin Petrie'" , "idr@ietf.org" Date: Wed, 23 Feb 2011 09:32:30 -0700 Thread-Topic: [GROW] [Idr] Fwd: New Version Notification for draft-shakir-idr-ops-reqs-for-bgp-error-handling-01 Thread-Index: AcvTO4X+gKWdWVawTryovH40oNA8/AAO5r/w Message-ID: References: <4D64D25B.5040202@spakka.net> In-Reply-To: <4D64D25B.5040202@spakka.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 X-CFilter-Loop: Reflected X-Mailman-Approved-At: Wed, 23 Feb 2011 09:56:45 -0800 Cc: "grow@ietf.org" Subject: Re: [Idr] [GROW] Fwd: New Version Notification for draft-shakir-idr-ops-reqs-for-bgp-error-handling-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 16:32:00 -0000 +1 reasonable bgp error handling (rather then dropping sessions and flushin= g routes) is a good idea. Ignorance is Bliss. "Bliss (Basic Language for Implementation of System Sof= tware) was a systems programming language originally for the PDP-10 and DECsystem-20 wri= tten at CMU." K-Oberman Donald.Smith@qwest.com > -----Original Message----- > From: grow-bounces@ietf.org [mailto:grow-bounces@ietf.org] On Behalf Of > Colin Petrie > Sent: Wednesday, February 23, 2011 2:25 AM > To: idr@ietf.org > Cc: grow@ietf.org > Subject: Re: [GROW] [Idr] Fwd: New Version Notification for draft- > shakir-idr-ops-reqs-for-bgp-error-handling-01 > > On 22/02/11 14:50, Neil J. McRae wrote: > > Rob, > > This is a great document and as a network operator I think this is > > something that I'd like to see implemented. The downsides of a minute > > inconsistency are not great enough compared to a complete BGP failure > with > > my organisations network* > > > > I totally agree. This document is a pretty good summary of the > requirements on this, and a reasonable suggested implementation to > mitigate the problems we have seen before too many times. > > Great work, thanks Rob :) > > Cheers > Colin > _______________________________________________ > GROW mailing list > GROW@ietf.org > https://www.ietf.org/mailman/listinfo/grow This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From chwhite@drevil.org Wed Feb 23 14:56:32 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 449DB3A68F5; Wed, 23 Feb 2011 14:56:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.372 X-Spam-Level: X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YeysXkpQgrCv; Wed, 23 Feb 2011 14:56:31 -0800 (PST) Received: from fatbastard.drevil.org (fatbastard.drevil.org [206.213.88.6]) by core3.amsl.com (Postfix) with ESMTP id 82ED33A68EE; Wed, 23 Feb 2011 14:56:31 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by fatbastard.drevil.org (Postfix) with ESMTP id 20FBE4942F08; Wed, 23 Feb 2011 14:57:19 -0800 (PST) X-Virus-Scanned: amavisd-new at drevil.org Received: from fatbastard.drevil.org ([127.0.0.1]) by localhost (fatbastard.drevil.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ux-Rq4I2IN7R; Wed, 23 Feb 2011 14:57:17 -0800 (PST) Received: from shagwell.drevil.org (shagwell.drevil.org [206.213.88.227]) by fatbastard.drevil.org (Postfix) with ESMTPSA id 966EB4942EED; Wed, 23 Feb 2011 14:57:17 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Chris White In-Reply-To: Date: Wed, 23 Feb 2011 14:57:17 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <532BEE73-B380-48FF-8C47-B10EC03A4A61@drevil.org> References: <4D64D25B.5040202@spakka.net> To: "Smith, Donald" X-Mailer: Apple Mail (2.1082) Cc: idr@ietf.org, grow@ietf.org Subject: Re: [Idr] [GROW] Fwd: New Version Notification for draft-shakir-idr-ops-reqs-for-bgp-error-handling-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 22:56:32 -0000 +1 Chris On Feb 23, 2011, at 8:32 AM, Smith, Donald wrote: > +1 reasonable bgp error handling (rather then dropping sessions and = flushing routes) is a good idea. >=20 >=20 > Ignorance is Bliss. "Bliss (Basic Language for Implementation of = System Software) was a > systems programming language originally for the PDP-10 and = DECsystem-20 written at CMU." K-Oberman > Donald.Smith@qwest.com >=20 >=20 >> -----Original Message----- >> From: grow-bounces@ietf.org [mailto:grow-bounces@ietf.org] On Behalf = Of >> Colin Petrie >> Sent: Wednesday, February 23, 2011 2:25 AM >> To: idr@ietf.org >> Cc: grow@ietf.org >> Subject: Re: [GROW] [Idr] Fwd: New Version Notification for draft- >> shakir-idr-ops-reqs-for-bgp-error-handling-01 >>=20 >> On 22/02/11 14:50, Neil J. McRae wrote: >>> Rob, >>> This is a great document and as a network operator I think this is >>> something that I'd like to see implemented. The downsides of a = minute >>> inconsistency are not great enough compared to a complete BGP = failure >> with >>> my organisations network* >>>=20 >>=20 >> I totally agree. This document is a pretty good summary of the >> requirements on this, and a reasonable suggested implementation to >> mitigate the problems we have seen before too many times. >>=20 >> Great work, thanks Rob :) >>=20 >> Cheers >> Colin >> _______________________________________________ >> GROW mailing list >> GROW@ietf.org >> https://www.ietf.org/mailman/listinfo/grow >=20 > This communication is the property of Qwest and may contain = confidential or > privileged information. Unauthorized use of this communication is = strictly > prohibited and may be unlawful. If you have received this = communication > in error, please immediately notify the sender by reply e-mail and = destroy > all copies of the communication and any attachments. > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From wim.henderickx@alcatel-lucent.com Wed Feb 23 21:57:23 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 745EC3A6822; Wed, 23 Feb 2011 21:57:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.022 X-Spam-Level: X-Spam-Status: No, score=-6.022 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KJyI-BBPoHPC; Wed, 23 Feb 2011 21:57:22 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id 177D53A6820; Wed, 23 Feb 2011 21:57:21 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p1O5un7N025997 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 24 Feb 2011 06:56:49 +0100 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.43]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Thu, 24 Feb 2011 06:56:49 +0100 From: "Henderickx, Wim (Wim)" To: Chris White , "Smith, Donald" Date: Thu, 24 Feb 2011 06:56:47 +0100 Thread-Topic: [GROW] [Idr] Fwd: New Version Notification for draft-shakir-idr-ops-reqs-for-bgp-error-handling-01 Thread-Index: AcvTrQsLnt5ukFDbQumltwx59AXe/wAOpKuQ Message-ID: <14C7F4F06DB5814AB0DE29716C4F6D6717E2D7EF@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> References: <4D64D25B.5040202@spakka.net> <532BEE73-B380-48FF-8C47-B10EC03A4A61@drevil.org> In-Reply-To: <532BEE73-B380-48FF-8C47-B10EC03A4A61@drevil.org> Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: nl-NL, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Cc: "idr@ietf.org" , "grow@ietf.org" Subject: Re: [Idr] [GROW] Fwd: New Version Notification for draft-shakir-idr-ops-reqs-for-bgp-error-handling-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2011 05:57:23 -0000 +1 -----Original Message----- From: grow-bounces@ietf.org [mailto:grow-bounces@ietf.org] On Behalf Of Chr= is White Sent: woensdag 23 februari 2011 23:57 To: Smith, Donald Cc: idr@ietf.org; grow@ietf.org Subject: Re: [GROW] [Idr] Fwd: New Version Notification for draft-shakir-id= r-ops-reqs-for-bgp-error-handling-01 +1 Chris On Feb 23, 2011, at 8:32 AM, Smith, Donald wrote: > +1 reasonable bgp error handling (rather then dropping sessions and flush= ing routes) is a good idea. >=20 >=20 > Ignorance is Bliss. "Bliss (Basic Language for Implementation of System S= oftware) was a > systems programming language originally for the PDP-10 and DECsystem-20 w= ritten at CMU." K-Oberman > Donald.Smith@qwest.com >=20 >=20 >> -----Original Message----- >> From: grow-bounces@ietf.org [mailto:grow-bounces@ietf.org] On Behalf Of >> Colin Petrie >> Sent: Wednesday, February 23, 2011 2:25 AM >> To: idr@ietf.org >> Cc: grow@ietf.org >> Subject: Re: [GROW] [Idr] Fwd: New Version Notification for draft- >> shakir-idr-ops-reqs-for-bgp-error-handling-01 >>=20 >> On 22/02/11 14:50, Neil J. McRae wrote: >>> Rob, >>> This is a great document and as a network operator I think this is >>> something that I'd like to see implemented. The downsides of a minute >>> inconsistency are not great enough compared to a complete BGP failure >> with >>> my organisations network* >>>=20 >>=20 >> I totally agree. This document is a pretty good summary of the >> requirements on this, and a reasonable suggested implementation to >> mitigate the problems we have seen before too many times. >>=20 >> Great work, thanks Rob :) >>=20 >> Cheers >> Colin >> _______________________________________________ >> GROW mailing list >> GROW@ietf.org >> https://www.ietf.org/mailman/listinfo/grow >=20 > This communication is the property of Qwest and may contain confidential = or > privileged information. Unauthorized use of this communication is strictl= y > prohibited and may be unlawful. If you have received this communication > in error, please immediately notify the sender by reply e-mail and destro= y > all copies of the communication and any attachments. > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr _______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow From jeff.tantsura@ericsson.com Wed Feb 23 22:00:23 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4131A3A6A2D; Wed, 23 Feb 2011 22:00:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YfYYzUSCHZzD; Wed, 23 Feb 2011 22:00:14 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id D6E2A3A6820; Wed, 23 Feb 2011 22:00:12 -0800 (PST) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p1O6kqU8029429; Thu, 24 Feb 2011 00:46:53 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.92]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Thu, 24 Feb 2011 00:59:32 -0500 From: Jeff Tantsura To: "Henderickx, Wim (Wim)" , Chris White , "Smith, Donald" Date: Thu, 24 Feb 2011 00:59:31 -0500 Thread-Topic: [Idr] [GROW] Fwd: New Version Notification for draft-shakir-idr-ops-reqs-for-bgp-error-handling-01 Thread-Index: AcvTrQsLnt5ukFDbQumltwx59AXe/wAOpKuQAAAXuDA= Message-ID: <0ED867EB33AB2B45AAB470D5A64CDBF60AA1F2E9CD@EUSAACMS0701.eamcs.ericsson.se> References: <4D64D25B.5040202@spakka.net> <532BEE73-B380-48FF-8C47-B10EC03A4A61@drevil.org> <14C7F4F06DB5814AB0DE29716C4F6D6717E2D7EF@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> In-Reply-To: <14C7F4F06DB5814AB0DE29716C4F6D6717E2D7EF@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> 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" , "grow@ietf.org" Subject: Re: [Idr] [GROW] Fwd: New Version Notification for draft-shakir-idr-ops-reqs-for-bgp-error-handling-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2011 06:00:23 -0000 +1 Regards, Jeff =20 -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Hende= rickx, Wim (Wim) Sent: Wednesday, February 23, 2011 21:57 To: Chris White; Smith, Donald Cc: idr@ietf.org; grow@ietf.org Subject: Re: [Idr] [GROW] Fwd: New Version Notification for draft-shakir-id= r-ops-reqs-for-bgp-error-handling-01 +1 -----Original Message----- From: grow-bounces@ietf.org [mailto:grow-bounces@ietf.org] On Behalf Of Chr= is White Sent: woensdag 23 februari 2011 23:57 To: Smith, Donald Cc: idr@ietf.org; grow@ietf.org Subject: Re: [GROW] [Idr] Fwd: New Version Notification for draft-shakir-id= r-ops-reqs-for-bgp-error-handling-01 +1 Chris On Feb 23, 2011, at 8:32 AM, Smith, Donald wrote: > +1 reasonable bgp error handling (rather then dropping sessions and flush= ing routes) is a good idea. >=20 >=20 > Ignorance is Bliss. "Bliss (Basic Language for Implementation of System S= oftware) was a > systems programming language originally for the PDP-10 and DECsystem-20 w= ritten at CMU." K-Oberman > Donald.Smith@qwest.com >=20 >=20 >> -----Original Message----- >> From: grow-bounces@ietf.org [mailto:grow-bounces@ietf.org] On Behalf Of >> Colin Petrie >> Sent: Wednesday, February 23, 2011 2:25 AM >> To: idr@ietf.org >> Cc: grow@ietf.org >> Subject: Re: [GROW] [Idr] Fwd: New Version Notification for draft- >> shakir-idr-ops-reqs-for-bgp-error-handling-01 >>=20 >> On 22/02/11 14:50, Neil J. McRae wrote: >>> Rob, >>> This is a great document and as a network operator I think this is >>> something that I'd like to see implemented. The downsides of a minute >>> inconsistency are not great enough compared to a complete BGP failure >> with >>> my organisations network* >>>=20 >>=20 >> I totally agree. This document is a pretty good summary of the >> requirements on this, and a reasonable suggested implementation to >> mitigate the problems we have seen before too many times. >>=20 >> Great work, thanks Rob :) >>=20 >> Cheers >> Colin >> _______________________________________________ >> GROW mailing list >> GROW@ietf.org >> https://www.ietf.org/mailman/listinfo/grow >=20 > This communication is the property of Qwest and may contain confidential = or > privileged information. Unauthorized use of this communication is strictl= y > prohibited and may be unlawful. If you have received this communication > in error, please immediately notify the sender by reply e-mail and destro= y > all copies of the communication and any attachments. > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr _______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From bruno.decraene@orange-ftgroup.com Fri Feb 25 09:28:26 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4270A3A6781 for ; Fri, 25 Feb 2011 09:28:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MmV1dWnGyqKn for ; Fri, 25 Feb 2011 09:28:25 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id 4360C3A65A5 for ; Fri, 25 Feb 2011 09:28:25 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id BF0D4858006; Fri, 25 Feb 2011 18:34:42 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id B65407D8001; Fri, 25 Feb 2011 18:34:42 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 25 Feb 2011 18:29:17 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 25 Feb 2011 18:29:16 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-idr-reserved-extended-communities Thread-Index: AcvVEYaySWpl3ijTR42ka2fpT+CtFw== From: To: , , , X-OriginalArrivalTime: 25 Feb 2011 17:29:17.0432 (UTC) FILETIME=[877ABF80:01CBD511] Subject: [Idr] draft-ietf-idr-reserved-extended-communities X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 17:28:26 -0000 Hi, As a reminder, draft-ietf-idr-reserved-extended-communities defines 2 IANA registries (transitive & non-transitive) to allocate an extended community from.=20 Currently, the draft proposes to assign 2 new BGP extended community types for these 2 pools. Another option would be to reuse the existing "generic four-octet AS specific" extended community sub-type defined in draft-ietf-idr-as4octet-extcomm-generic-subtype and use the reserved AS number 0x00000000 for theses 2 pools. This would be similar to the existing "well known" BGP communities pool as defined in RFC 1997, which also reuse the AS number 0x0000 space. Pro: -1- Same principle for communities and extended communities -2- a BGP implementation hard coding the extended communities types accepted by the CLI would not need to be updated twice and SP would not need to ask/wait for 2 features. Is there any comment on this proposition? In the absence of any objections within the next two weeks I'll issue a revised version which reflects the above proposition. Thanks, Regards, Bruno From david.freedman@uk.clara.net Fri Feb 25 09:49:53 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3E9A3A6781 for ; Fri, 25 Feb 2011 09:49:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.372 X-Spam-Level: X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15EHesmLUyDg for ; Fri, 25 Feb 2011 09:49:52 -0800 (PST) Received: from synchronicity.convergence.cx (synchronicity.convergence.cx [IPv6:2001:a88:0:ffff::6]) by core3.amsl.com (Postfix) with ESMTP id 5C4D03A65A5 for ; Fri, 25 Feb 2011 09:49:50 -0800 (PST) Received: from localhost ([127.0.0.1] ident=tdcdf1) by synchronicity.convergence.cx with esmtp (Exim 4.72) (envelope-from ) id 1Pt1o9-00024m-F2 for idr@ietf.org; Fri, 25 Feb 2011 17:50:25 +0000 Message-ID: <4D67EBE1.5080700@uk.clara.net> Date: Fri, 25 Feb 2011 17:50:25 +0000 From: David Freedman Organization: Claranet Limited User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.16) Gecko/20101227 Iceowl/1.0b1 Icedove/3.0.11 MIME-Version: 1.0 To: idr X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ACL-Warn: Message has been frozen because it contains sensitive words (ietf.org), please unfreeze it manually Subject: Re: [Idr] New Version Notification for draft-shakir-idr-ops-reqs-for-bgp-error-handling-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 17:49:53 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 +2 :) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1n6+EACgkQtFWeqpgEZrJ2fQCg2bUuBI+IdquqssngUJ2dhp5H ZS8AoNgtMAFcDqoTEmhAvCn/6Nhhhz1d =wJuC -----END PGP SIGNATURE----- From renwei.li@huawei.com Fri Feb 25 08:43:43 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB4FA3A6A0C; Fri, 25 Feb 2011 08:43:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.372 X-Spam-Level: X-Spam-Status: No, score=-6.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k427Zjo4R2vT; Fri, 25 Feb 2011 08:43:43 -0800 (PST) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id F08D33A63EB; Fri, 25 Feb 2011 08:43:42 -0800 (PST) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LH60064TMIAT3@usaga04-in.huawei.com>; Fri, 25 Feb 2011 10:44:35 -0600 (CST) Received: from dfweml202-edg.china.huawei.com ([172.18.9.108]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LH600L4JMI9NF@usaga04-in.huawei.com>; Fri, 25 Feb 2011 10:44:34 -0600 (CST) Received: from DFWEML401-HUB.china.huawei.com (10.193.5.101) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 25 Feb 2011 08:44:35 -0800 Received: from DFWEML503-MBX.china.huawei.com ([169.254.3.200]) by DFWEML401-HUB.china.huawei.com ([fe80::f07f:889f:78ef:8df3%13]) with mapi id 14.01.0270.001; Fri, 25 Feb 2011 08:44:33 -0800 Date: Fri, 25 Feb 2011 16:44:32 +0000 From: Renwei li In-reply-to: <14C7F4F06DB5814AB0DE29716C4F6D6717E2D7EF@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> X-Originating-IP: [10.193.34.185] To: "Henderickx, Wim (Wim)" , Chris White , "Smith, Donald" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US Thread-topic: [GROW] [Idr] Fwd: New Version Notification for draft-shakir-idr-ops-reqs-for-bgp-error-handling-01 Thread-index: AcvTrQsLnt5ukFDbQumltwx59AXe/wAOpKuQAEjn9tA= X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <4D64D25B.5040202@spakka.net> <532BEE73-B380-48FF-8C47-B10EC03A4A61@drevil.org> <14C7F4F06DB5814AB0DE29716C4F6D6717E2D7EF@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> X-Mailman-Approved-At: Fri, 25 Feb 2011 10:17:14 -0800 Cc: "idr@ietf.org" , "grow@ietf.org" Subject: Re: [Idr] [GROW] Fwd: New Version Notification for draft-shakir-idr-ops-reqs-for-bgp-error-handling-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 16:45:32 -0000 +1 Renwei -----Original Message----- From: grow-bounces@ietf.org [mailto:grow-bounces@ietf.org] On Behalf Of Henderickx, Wim (Wim) Sent: Wednesday, February 23, 2011 9:57 PM To: Chris White; Smith, Donald Cc: idr@ietf.org; grow@ietf.org Subject: Re: [GROW] [Idr] Fwd: New Version Notification for draft-shakir-idr-ops-reqs-for-bgp-error-handling-01 +1 -----Original Message----- From: grow-bounces@ietf.org [mailto:grow-bounces@ietf.org] On Behalf Of Chris White Sent: woensdag 23 februari 2011 23:57 To: Smith, Donald Cc: idr@ietf.org; grow@ietf.org Subject: Re: [GROW] [Idr] Fwd: New Version Notification for draft-shakir-idr-ops-reqs-for-bgp-error-handling-01 +1 Chris On Feb 23, 2011, at 8:32 AM, Smith, Donald wrote: > +1 reasonable bgp error handling (rather then dropping sessions and flushing routes) is a good idea. > > > Ignorance is Bliss. "Bliss (Basic Language for Implementation of System Software) was a > systems programming language originally for the PDP-10 and DECsystem-20 written at CMU." K-Oberman > Donald.Smith@qwest.com > > >> -----Original Message----- >> From: grow-bounces@ietf.org [mailto:grow-bounces@ietf.org] On Behalf Of >> Colin Petrie >> Sent: Wednesday, February 23, 2011 2:25 AM >> To: idr@ietf.org >> Cc: grow@ietf.org >> Subject: Re: [GROW] [Idr] Fwd: New Version Notification for draft- >> shakir-idr-ops-reqs-for-bgp-error-handling-01 >> >> On 22/02/11 14:50, Neil J. McRae wrote: >>> Rob, >>> This is a great document and as a network operator I think this is >>> something that I'd like to see implemented. The downsides of a minute >>> inconsistency are not great enough compared to a complete BGP failure >> with >>> my organisations network* >>> >> >> I totally agree. This document is a pretty good summary of the >> requirements on this, and a reasonable suggested implementation to >> mitigate the problems we have seen before too many times. >> >> Great work, thanks Rob :) >> >> Cheers >> Colin >> _______________________________________________ >> GROW mailing list >> GROW@ietf.org >> https://www.ietf.org/mailman/listinfo/grow > > This communication is the property of Qwest and may contain confidential or > privileged information. Unauthorized use of this communication is strictly > prohibited and may be unlawful. If you have received this communication > in error, please immediately notify the sender by reply e-mail and destroy > all copies of the communication and any attachments. > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr _______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow _______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow From jeff.tantsura@ericsson.com Fri Feb 25 11:42:16 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 732BC3A6831 for ; Fri, 25 Feb 2011 11:42:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tp13ESj-wr1m for ; Fri, 25 Feb 2011 11:42:15 -0800 (PST) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by core3.amsl.com (Postfix) with ESMTP id 73A113A681B for ; Fri, 25 Feb 2011 11:42:15 -0800 (PST) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p1PJh5SX013724 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 25 Feb 2011 13:43:07 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.92]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Fri, 25 Feb 2011 14:43:06 -0500 From: Jeff Tantsura To: "bruno.decraene@orange-ftgroup.com" , "idr@ietf.org" , "dhrao@cisco.com" , "pmohapat@cisco.com" , "jhaas@pfrc.org" Date: Fri, 25 Feb 2011 14:43:04 -0500 Thread-Topic: draft-ietf-idr-reserved-extended-communities Thread-Index: AcvVEYaySWpl3ijTR42ka2fpT+CtFwAEqaqg Message-ID: <0ED867EB33AB2B45AAB470D5A64CDBF60AA1F2F446@EUSAACMS0701.eamcs.ericsson.se> References: In-Reply-To: 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 Subject: Re: [Idr] draft-ietf-idr-reserved-extended-communities X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 19:42:16 -0000 +1 Regards, Jeff =20 -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of bruno= .decraene@orange-ftgroup.com Sent: Friday, February 25, 2011 09:29 To: idr@ietf.org; dhrao@cisco.com; pmohapat@cisco.com; jhaas@pfrc.org Subject: [Idr] draft-ietf-idr-reserved-extended-communities Hi, As a reminder, draft-ietf-idr-reserved-extended-communities defines 2 IANA registries (transitive & non-transitive) to allocate an extended community from.=20 Currently, the draft proposes to assign 2 new BGP extended community types for these 2 pools. Another option would be to reuse the existing "generic four-octet AS specific" extended community sub-type defined in draft-ietf-idr-as4octet-extcomm-generic-subtype and use the reserved AS number 0x00000000 for theses 2 pools. This would be similar to the existing "well known" BGP communities pool as defined in RFC 1997, which also reuse the AS number 0x0000 space. Pro: -1- Same principle for communities and extended communities -2- a BGP implementation hard coding the extended communities types accepted by the CLI would not need to be updated twice and SP would not need to ask/wait for 2 features. Is there any comment on this proposition? In the absence of any objections within the next two weeks I'll issue a revised version which reflects the above proposition. Thanks, Regards, Bruno _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From warren@kumari.net Fri Feb 25 14:54:10 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CD8F3A6A69; Fri, 25 Feb 2011 14:54:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.378 X-Spam-Level: X-Spam-Status: No, score=-102.378 tagged_above=-999 required=5 tests=[AWL=-0.006, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VpZeq2ENW6Ub; Fri, 25 Feb 2011 14:54:09 -0800 (PST) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by core3.amsl.com (Postfix) with ESMTP id F3C213A6A68; Fri, 25 Feb 2011 14:54:08 -0800 (PST) Received: from [172.19.118.186] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id DA1991B40ACC; Fri, 25 Feb 2011 17:55:00 -0500 (EST) Message-Id: <6DE0A851-A4E6-4A08-BCD8-9D5625DA01FB@kumari.net> From: Warren Kumari To: Renwei li In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 25 Feb 2011 17:54:57 -0500 References: <4D64D25B.5040202@spakka.net> <532BEE73-B380-48FF-8C47-B10EC03A4A61@drevil.org> <14C7F4F06DB5814AB0DE29716C4F6D6717E2D7EF@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> X-Mailer: Apple Mail (2.936) Cc: "Smith, Donald" , "idr@ietf.org" , "Henderickx, Wim \(Wim\)" , "grow@ietf.org" Subject: Re: [Idr] [GROW] Fwd: New Version Notification for draft-shakir-idr-ops-reqs-for-bgp-error-handling-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 22:54:10 -0000 Me too! On Feb 25, 2011, at 11:44 AM, Renwei li wrote: > +1 > > Renwei > > -----Original Message----- > From: grow-bounces@ietf.org [mailto:grow-bounces@ietf.org] On Behalf > Of Henderickx, Wim (Wim) > Sent: Wednesday, February 23, 2011 9:57 PM > To: Chris White; Smith, Donald > Cc: idr@ietf.org; grow@ietf.org > Subject: Re: [GROW] [Idr] Fwd: New Version Notification for draft- > shakir-idr-ops-reqs-for-bgp-error-handling-01 > > +1 > > -----Original Message----- > From: grow-bounces@ietf.org [mailto:grow-bounces@ietf.org] On Behalf > Of Chris White > Sent: woensdag 23 februari 2011 23:57 > To: Smith, Donald > Cc: idr@ietf.org; grow@ietf.org > Subject: Re: [GROW] [Idr] Fwd: New Version Notification for draft- > shakir-idr-ops-reqs-for-bgp-error-handling-01 > > +1 > > Chris > > > On Feb 23, 2011, at 8:32 AM, Smith, Donald wrote: > >> +1 reasonable bgp error handling (rather then dropping sessions and >> flushing routes) is a good idea. >> >> >> Ignorance is Bliss. "Bliss (Basic Language for Implementation of >> System Software) was a >> systems programming language originally for the PDP-10 and >> DECsystem-20 written at CMU." K-Oberman >> Donald.Smith@qwest.com >> >> >>> -----Original Message----- >>> From: grow-bounces@ietf.org [mailto:grow-bounces@ietf.org] On >>> Behalf Of >>> Colin Petrie >>> Sent: Wednesday, February 23, 2011 2:25 AM >>> To: idr@ietf.org >>> Cc: grow@ietf.org >>> Subject: Re: [GROW] [Idr] Fwd: New Version Notification for draft- >>> shakir-idr-ops-reqs-for-bgp-error-handling-01 >>> >>> On 22/02/11 14:50, Neil J. McRae wrote: >>>> Rob, >>>> This is a great document and as a network operator I think this is >>>> something that I'd like to see implemented. The downsides of a >>>> minute >>>> inconsistency are not great enough compared to a complete BGP >>>> failure >>> with >>>> my organisations network* >>>> >>> >>> I totally agree. This document is a pretty good summary of the >>> requirements on this, and a reasonable suggested implementation to >>> mitigate the problems we have seen before too many times. >>> >>> Great work, thanks Rob :) >>> >>> Cheers >>> Colin >>> _______________________________________________ >>> GROW mailing list >>> GROW@ietf.org >>> https://www.ietf.org/mailman/listinfo/grow >> >> This communication is the property of Qwest and may contain >> confidential or >> privileged information. Unauthorized use of this communication is >> strictly >> prohibited and may be unlawful. If you have received this >> communication >> in error, please immediately notify the sender by reply e-mail and >> destroy >> all copies of the communication and any attachments. >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr > > _______________________________________________ > GROW mailing list > GROW@ietf.org > https://www.ietf.org/mailman/listinfo/grow > _______________________________________________ > GROW mailing list > GROW@ietf.org > https://www.ietf.org/mailman/listinfo/grow > _______________________________________________ > GROW mailing list > GROW@ietf.org > https://www.ietf.org/mailman/listinfo/grow > From bashandy@cisco.com Mon Feb 28 12:31:53 2011 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22AD53A6C7C for ; Mon, 28 Feb 2011 12:31:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jDOxZVdTTK6L for ; Mon, 28 Feb 2011 12:31:52 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 0DA203A6A66 for ; Mon, 28 Feb 2011 12:31:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bashandy@cisco.com; l=6628; q=dns/txt; s=iport; t=1298925173; x=1300134773; h=message-id:date:from:reply-to:mime-version:to:cc:subject; bh=mSNw3QKM45DL84nVmIARYKN/B37SrXYMbM17Dgf80tQ=; b=baqOLz1d+8Om1wknoX4rO3pv2VcoGkZ8YtIru3vkM54ib8Z7Carwg/0c FOZEiWx+nh+SIOf8dEZDuwgzGvzD3HM06UWGGp1BGqyDLPYas3lgO1qva lhRo7zXeSsG4ZxsBte9obyPSFbW++rzU8OlWQl+VhJ8+sesTXETAZM3zR 8=; X-Files: signature.asc : 251 X-IronPort-AV: E=Sophos;i="4.62,242,1297036800"; d="asc'?scan'208,217";a="315970037" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-2.cisco.com with ESMTP; 28 Feb 2011 20:32:53 +0000 Received: from [10.21.75.48] ([10.21.75.48]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id p1SKWoGt027698; Mon, 28 Feb 2011 20:32:51 GMT Message-ID: <4D6C0671.6090707@cisco.com> Date: Mon, 28 Feb 2011 22:32:49 +0200 From: Ahmed Bashandy User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: idr@ietf.org X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig979DDA295ADCC2BB03032B2C" Cc: "Burjiz Pithawala \(bpithaw\)" Subject: [Idr] Fwd: New Version Notification for draft-bashandy-idr-bgp-repair-label-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: bashandy@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 20:31:53 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig979DDA295ADCC2BB03032B2C Content-Type: multipart/alternative; boundary="------------020108000806040704040303" This is a multi-part message in MIME format. --------------020108000806040704040303 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, This is a draft that proposes rerouting traffic, without waiting for BGP = to re-converge, to another PE in a BGP-free core when a PE detects that t= he NH is no longer reachable. Because traffic coming from the core is red= irected back to the core, we propose using a specially advertised label t= o make sure that the traffic does not get re-routed multiple times into t= he core, thus avoiding loops. All comments are highly appreciated Ahmed -------- Original Message -------- Subject: New Version Notification for draft-bashandy-idr-bgp-repair-labe= l-00 Date: Mon, 28 Feb 2011 08:49:59 -0800 (PST) From: IETF I-D Submission Tool To: bashandy@cisco.com CC: bpithaw@cisco.com A new version of I-D, draft-bashandy-idr-bgp-repair-label-00.txt has been= successfully submitted by Ahmed Bashandy and posted to the IETF reposito= ry. Filename: draft-bashandy-idr-bgp-repair-label Revision: 00 Title: Scalable, Loop-Free BGP FRR using Repair Label Creation_date: 2011-02-28 WG ID: Independent Submission Number_of_pages: 14 Abstract: Consider a BGP free core scenario. Suppose the provider edge BGP speaker PE1, PE2,..., PEn know about a prefix P/p via the external routers CE1, CE2,..., CEm. If the PE router PEi loses connectivity to the primary path, whether it is another PE router or a CE router, it desirable to immediately restore traffic by rerouting packets arriving to PEi and destined to the prefix P/p to one of the other PE routers that advertised P/p, say PEj, until BGP re-converges. However if the loss of connectivity of PEi to the primary path also resulted in the loss of connectivity between PEj and CEj, rerouting a packet without before the control plane converges may result in a loop. In this document, we propose using a repair label for traffic restoration while avoiding loops. We propose advertising the ''repair'' label through BGP. = =20 The IETF Secretariat. --------------020108000806040704040303 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi,

This is a draft that proposes rerouting traffic, without waiting for BGP to re-converge, to another PE in a BGP-free core when a PE detects that the NH is no longer reachable. Because traffic coming from the core is redirected back to the core, we propose using a specially advertised label to make sure that the traffic does not get re-routed multiple times into the core, thus avoiding loops.

All comments are highly appreciated

Ahmed


-------- Original Message --------
Subje= ct: New Version Notification for draft-bashandy-idr-bgp-repair-label-00
Date:= Mon, 28 Feb 2011 08:49:59 -0800 (PST)
From:= IETF I-D Submission Tool <idsubmission@ietf.org><= /td>
To: <= /th> bashandy@cisco.com
CC: <= /th> bpithaw@cisco.com 


A new version of I-D, draft-bashandy-idr-bgp-repair-label-00.txt=
 has been successfully submitted by Ahmed Bashandy and posted to the IETF=
 repository.

Filename:	 draft-bashandy-idr-bgp-repair-label
Revision:	 00
Title:		 Scalable, Loop-Free BGP FRR using Repair Label
Creation_date:	 2011-02-28
WG ID:		 Independent Submission
Number_of_pages: 14

Abstract:
Consider a BGP free core scenario. Suppose the provider edge BGP
speaker PE1, PE2,..., PEn know about a prefix P/p via the external
routers CE1, CE2,..., CEm.  If the PE router PEi loses connectivity to
the primary path, whether it is another PE router or a CE router, it
desirable to immediately restore traffic by rerouting packets arriving
to PEi and destined to the prefix P/p to one of the other PE routers
that advertised P/p, say PEj, until BGP re-converges. However if the
loss of connectivity of PEi to the primary path also resulted in the
loss of connectivity between PEj and CEj, rerouting a packet without
before the control plane converges may result in a loop. In this
document, we propose using a repair label for traffic restoration
while avoiding loops. We propose advertising the ''repair'' label
through BGP.
                                                                         =
        =20


The IETF Secretariat.
--------------020108000806040704040303-- --------------enig979DDA295ADCC2BB03032B2C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFNbAZx+G19kFA5zIYRAm5NAJ95ViwfY/BsjIPXTyUvrNKMetgmvgCdHqqD sqYHMGlgrq9ROJy0E7BKvO8= =thhr -----END PGP SIGNATURE----- --------------enig979DDA295ADCC2BB03032B2C--