From iesg-secretary@ietf.org Fri Jun 1 11:54:51 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E41111E8074; Fri, 1 Jun 2012 11:54:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.489 X-Spam-Level: X-Spam-Status: No, score=-102.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EOaYmWpxJkhe; Fri, 1 Jun 2012 11:54:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B8A511E8096; Fri, 1 Jun 2012 11:54:49 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120601185444.8409.85777.idtracker@ietfa.amsl.com> Date: Fri, 01 Jun 2012 11:54:44 -0700 Cc: idr@ietf.org Subject: [Idr] Last Call: (BGP Support for Four-octet AS Number Space) to Proposed Standard X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 18:54:51 -0000 The IESG has received a request from the Inter-Domain Routing WG (idr) to consider the following document: - 'BGP Support for Four-octet AS Number Space' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-06-15. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The Autonomous System (AS) number is encoded as a two-octet entity in the base BGP specification. This document describes extensions to BGP to carry the Autonomous System numbers as four-octet entities. This document obsoletes RFC 4893. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-idr-rfc4893bis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-idr-rfc4893bis/ballot/ No IPR declarations have been submitted directly on this I-D. From cjeker@diehard.n-r-g.com Fri Jun 1 15:00:05 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 560C711E80BC for ; Fri, 1 Jun 2012 15:00:05 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sf6cN+tpuTRg for ; Fri, 1 Jun 2012 15:00:04 -0700 (PDT) Received: from diehard.n-r-g.com (diehard.n-r-g.com [62.48.3.9]) by ietfa.amsl.com (Postfix) with ESMTP id 5AF0A11E8097 for ; Fri, 1 Jun 2012 15:00:04 -0700 (PDT) Received: (qmail 17476 invoked by uid 1001); 1 Jun 2012 22:00:00 -0000 Date: Sat, 2 Jun 2012 00:00:00 +0200 From: Claudio Jeker To: idr@ietf.org Message-ID: <20120601220000.GB9448@diehard.n-r-g.com> References: <20120601185444.8409.85777.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120601185444.8409.85777.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [Idr] Last Call: (BGP Support for Four-octet AS Number Space) to Proposed Standard X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 22:00:05 -0000 On Fri, Jun 01, 2012 at 11:54:44AM -0700, The IESG wrote: > > The IESG has received a request from the Inter-Domain Routing WG (idr) to > consider the following document: > - 'BGP Support for Four-octet AS Number Space' > as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2012-06-15. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > The Autonomous System (AS) number is encoded as a two-octet entity in > the base BGP specification. This document describes extensions to BGP > to carry the Autonomous System numbers as four-octet entities. This > document obsoletes RFC 4893. > Just for the sake of clarity, OpenBGPD will not do the following: In addition, the path segment types AS_CONFED_SEQUENCE and AS_CONFED_SET [RFC5065] MUST NOT be carried in the AS4_PATH attribute of an UPDATE message. A NEW BGP speaker that receives these path segment types in the AS4_PATH attribute of an UPDATE message from an OLD BGP speaker MUST discard these path segments, adjust the relevant attribute fields accordingly, and continue processing the UPDATE message. This case SHOULD be logged locally for analysis. There is no point to do this fiddeling instead we will treat this like any other parse error of AS4_PATH. -- :wq Claudio From internet-drafts@ietf.org Mon Jun 4 06:49:54 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E8F221F8698; Mon, 4 Jun 2012 06:49:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.564 X-Spam-Level: X-Spam-Status: No, score=-102.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Au7zjpPlg4mE; Mon, 4 Jun 2012 06:49:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C46E021F85AE; Mon, 4 Jun 2012 06:49:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120604134953.1704.16230.idtracker@ietfa.amsl.com> Date: Mon, 04 Jun 2012 06:49:53 -0700 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-aigp-08.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 13:49:54 -0000 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 : The Accumulated IGP Metric Attribute for BGP Author(s) : Pradosh Mohapatra Rex Fernando Eric C. Rosen James Uttaro Filename : draft-ietf-idr-aigp-08.txt Pages : 14 Date : 2012-06-04 Routing protocols that have been designed to run within a single administrative domain ("IGPs") generally do so by assigning a metric to each link, and then choosing as the installed path between two nodes the path for which the total distance (sum of the metric of each link along the path) is minimized. BGP, designed to provide routing over a large number of independent administrative domains ("autonomous systems"), does not make its path selection decisions through the use of a metric. It is generally recognized that any attempt to do so would incur significant scalability problems, as well as inter-administration coordination problems. However, there are deployments in which a single administration runs several contiguous BGP networks. In such cases, it can be desirable, within that single administrative domain, for BGP to select paths based on a metric, just as an IGP would do. The purpose of this document is to provide a specification for doing so. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-aigp-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-idr-aigp-08.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-aigp/ From kotikalapudi.sriram@nist.gov Mon Jun 4 11:53:42 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20A6A11E80BC; Mon, 4 Jun 2012 11:53:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.854 X-Spam-Level: X-Spam-Status: No, score=-5.854 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DhHmVPP6B4nI; Mon, 4 Jun 2012 11:53:41 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 92E9F11E80B5; Mon, 4 Jun 2012 11:53:38 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 4 Jun 2012 14:53:35 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Mon, 4 Jun 2012 14:53:37 -0400 From: "Sriram, Kotikalapudi" To: "John G. Scudder" Date: Mon, 4 Jun 2012 14:51:45 -0400 Thread-Topic: [sidr] request for agenda items for interim meeting 6 Jun Thread-Index: Ac0/U5HRPlsCbHtVSUK1+tV3UsF//ADKs4sO Message-ID: References: <24B20D14B2CD29478C8D5D6E9CBB29F60F70A267@Hermes.columbia.ads.sparta.com> <24B20D14B2CD29478C8D5D6E9CBB29F625F0975D@Hermes.columbia.ads.sparta.com> <4FBBB6D1.9000008@bbn.com> <4FBC0936.7000905@bbn.com>, <5BA9D6DE-BE0E-4922-9E09-7B85BD6F9342@juniper.net> <24B20D14B2CD29478C8D5D6E9CBB29F625F12333@Hermes.columbia.ads.sparta.com> , <5F5F8CF8-061C-47C9-942C-7908963EF347@juniper.net> In-Reply-To: <5F5F8CF8-061C-47C9-942C-7908963EF347@juniper.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" MIME-Version: 1.0 Cc: "idr@ietf.org List" , "Murphy, Sandra" , "sidr@ietf.org list" Subject: Re: [Idr] [sidr] request for agenda items for interim meeting 6 Jun X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 18:53:42 -0000 Thanks for the clarification. The Secure_Path semantics in BGPSEC are the same as the *essential semantics* of BGP AS_PATH. The *essential semantics* being the sequence of ASs the prefix announcement has passed through (including AS prepending). So the Secure_Path semantics would be compatible with AS_PATH as long as said essential semantics do not change. I am curious if there is a realistic example of feature change to BGP such that the AS_PATH would no longer adhere to its essential semantics. Sriram ________________________________________ From: John G. Scudder [jgs@juniper.net] Sent: Thursday, May 31, 2012 1:31 PM To: Sriram, Kotikalapudi Cc: Murphy, Sandra; idr@ietf.org List; sidr@ietf.org list Subject: Re: [sidr] request for agenda items for interim meeting 6 Jun On May 30, 2012, at 8:02 PM, Sriram, Kotikalapudi wrote: >> >> Right, and agreed (see "formally an attack" above). But to repeat my further >> point, if the AS_PATH is present (even if not secured): "at least there's scope for a >> network operator on the receiving end to tolerate the validation failure and use >> the route anyway, if desired. In the case where there's no AS_PATH, the data are >> just gone with no chance for appeal." >> > > John, > > I do not agree that in the event of "validation failure" the route becomes unusable > in BGPSEC as currently specified. That's not what I meant. My point was that a feature may be applied that wants to change the AS_PATH in a way that can't be represented in the BGPSEC_Path_Signatures. In other words, your later statement: > the Secure_Path segment is still usable as it provides the AS path info. is not correct in all cases. Likewise, to this statement: > So validation failure in BGPSEC does not mean that "the data are just gone." My point is not that validation failure causes this. It's that absent AS_PATH, a semantically non-representable AS_PATH will be lost if forced through BGPSEC_Path_Signatures. To reiterate, the options to address the case where a feature wants to produce output that can't be represented in BGPSEC_Path_Signatures are: - Don't solve it. Effectively forbid any such feature. - Carry both AS_PATH and BGPSEC_Path_Signatures in every update. Rules for reconciliation would be required. - Downgrade BGPSEC update to BGP update. - Extend BGPSEC_Path_Signatures format to be able to represent the needed feature. (As Sandy noted, this only makes sense insofar as the feature isn't formally an attack, so this option is incomplete.) The validation failure I spoke of is a potential *consequence* of the middle two options above, and as you say, the operator can then decide what to do. --John From jgs@juniper.net Mon Jun 4 13:09:00 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59B5C21F886B; Mon, 4 Jun 2012 13:09:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.587 X-Spam-Level: X-Spam-Status: No, score=-6.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S80ZKQ1m6UnH; Mon, 4 Jun 2012 13:08:59 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id D4BD321F85FD; Mon, 4 Jun 2012 13:08:41 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKT80VySYcLeZ+wsTx2SQAqBkO0I/Segm6@postini.com; Mon, 04 Jun 2012 13:08:59 PDT Received: from [172.16.13.202] (172.16.13.202) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server id 8.3.213.0; Mon, 4 Jun 2012 13:08:33 -0700 MIME-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset="us-ascii" From: "John G. Scudder" In-Reply-To: Date: Mon, 4 Jun 2012 16:08:32 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <70E22069-12C4-435F-A7D5-109BC0B39910@juniper.net> References: <24B20D14B2CD29478C8D5D6E9CBB29F60F70A267@Hermes.columbia.ads.sparta.com> <24B20D14B2CD29478C8D5D6E9CBB29F625F0975D@Hermes.columbia.ads.sparta.com> <4FBBB6D1.9000008@bbn.com> <4FBC0936.7000905@bbn.com>, <5BA9D6DE-BE0E-4922-9E09-7B85BD6F9342@juniper.net> <24B20D14B2CD29478C8D5D6E9CBB29F625F12333@Hermes.columbia.ads.sparta.com> , <5F5F8CF8-061C-47C9-942C-7908963EF347@juniper.net> To: "Sriram, Kotikalapudi" X-Mailer: Apple Mail (2.1278) Cc: "idr@ietf.org List" , "Murphy, Sandra" , "sidr@ietf.org list" Subject: Re: [Idr] [sidr] request for agenda items for interim meeting 6 Jun X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 20:09:00 -0000 Sriram, Confederations are an example of a standardized change to BGP that = modified handling and semantics of the AS_PATH. There are various = non-standardized AS_PATH rewriting knobs as well, as previously = discussed. --John On Jun 4, 2012, at 2:51 PM, Sriram, Kotikalapudi wrote: > Thanks for the clarification. > The Secure_Path semantics in BGPSEC are the same as the *essential = semantics* of BGP AS_PATH. > The *essential semantics* being the sequence of ASs the prefix = announcement has passed through > (including AS prepending). > So the Secure_Path semantics would be compatible with AS_PATH as long = as said essential semantics do not change. > I am curious if there is a realistic example of feature change to BGP=20= > such that the AS_PATH would no longer adhere to its essential = semantics. >=20 > Sriram=20 > ________________________________________ > From: John G. Scudder [jgs@juniper.net] > Sent: Thursday, May 31, 2012 1:31 PM > To: Sriram, Kotikalapudi > Cc: Murphy, Sandra; idr@ietf.org List; sidr@ietf.org list > Subject: Re: [sidr] request for agenda items for interim meeting 6 Jun >=20 > On May 30, 2012, at 8:02 PM, Sriram, Kotikalapudi wrote: >=20 >>>=20 >>> Right, and agreed (see "formally an attack" above). But to repeat my = further >>> point, if the AS_PATH is present (even if not secured): "at least = there's scope for a >>> network operator on the receiving end to tolerate the validation = failure and use >>> the route anyway, if desired. In the case where there's no AS_PATH, = the data are >>> just gone with no chance for appeal." >>>=20 >>=20 >> John, >>=20 >> I do not agree that in the event of "validation failure" the route = becomes unusable >> in BGPSEC as currently specified. >=20 > That's not what I meant. My point was that a feature may be applied = that wants to change the AS_PATH in a way that can't be represented in = the BGPSEC_Path_Signatures. In other words, your later statement: >=20 >> the Secure_Path segment is still usable as it provides the AS path = info. >=20 > is not correct in all cases. Likewise, to this statement: >=20 >> So validation failure in BGPSEC does not mean that "the data are just = gone." >=20 > My point is not that validation failure causes this. It's that absent = AS_PATH, a semantically non-representable AS_PATH will be lost if forced = through BGPSEC_Path_Signatures. >=20 > To reiterate, the options to address the case where a feature wants to = produce output that can't be represented in BGPSEC_Path_Signatures are: >=20 > - Don't solve it. Effectively forbid any such feature. > - Carry both AS_PATH and BGPSEC_Path_Signatures in every update. Rules = for reconciliation would be required. > - Downgrade BGPSEC update to BGP update. > - Extend BGPSEC_Path_Signatures format to be able to represent the = needed feature. (As Sandy noted, this only makes sense insofar as the = feature isn't formally an attack, so this option is incomplete.) >=20 > The validation failure I spoke of is a potential *consequence* of the = middle two options above, and as you say, the operator can then decide = what to do. >=20 > --John From bruno.decraene@orange.com Wed Jun 6 02:10:50 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11F5821F86A3 for ; Wed, 6 Jun 2012 02:10:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.395 X-Spam-Level: X-Spam-Status: No, score=-2.395 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tbe+zcKxUog6 for ; Wed, 6 Jun 2012 02:10:49 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 5A51921F869D for ; Wed, 6 Jun 2012 02:10:48 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 1C65B2DC3CB; Wed, 6 Jun 2012 11:10:47 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 03F5D27C053; Wed, 6 Jun 2012 11:10:47 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Wed, 6 Jun 2012 11:10:46 +0200 From: To: "John G. Scudder" , "idr@ietf.org List" Thread-Topic: [Idr] Adoption of draft-djsmith-bgp-flowspec-oid-01 as IDR WG document Thread-Index: AQHNPcnOPMMFmZwsz0yKAJyD/9Ic05btC4vQ Date: Wed, 6 Jun 2012 09:10:46 +0000 Message-ID: <10966_1338973847_4FCF1E97_10966_7220_1_53C29892C857584299CBF5D05346208A08C9AF@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <3BBED7A5-C064-4D80-B135-CC9B678BAF4D@juniper.net> <67CB405A-6DD5-4733-8375-2272CEF0F666@juniper.net> In-Reply-To: <67CB405A-6DD5-4733-8375-2272CEF0F666@juniper.net> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.6.6.71515 Subject: Re: [Idr] Adoption of draft-djsmith-bgp-flowspec-oid-01 as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 09:10:50 -0000 Hi, I support adoption of draft-djsmith-bgp-flowspec-oid as IDR WG document Thanks, Regards, Bruno >From: John G. Scudder >Sent: Tuesday, May 29, 2012 8:34 PM > >So far I have seen replies to this from three people. This is not really s= trong >evidence of interest on the part of the WG. > >The comment period will end on Friday. > >--John > >On May 16, 2012, at 3:40 PM, John G. Scudder wrote: > >> Folks, >> >> We have received a request from the authors to adopt draft-djsmith-bgp- >flowspec-oid-01 as an IDR WG document. Please send your comments to the l= ist. >The deadline for comments is June 1, 2012 at noon EDT. >> >> Thanks, >> >> --John > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www.ietf.org/mailman/listinfo/idr ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From bruno.decraene@orange.com Wed Jun 6 02:15:30 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ECA221F8864 for ; Wed, 6 Jun 2012 02:15:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id djRnr71zVlUm for ; Wed, 6 Jun 2012 02:15:29 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 401C821F86AD for ; Wed, 6 Jun 2012 02:15:29 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 0C53722C4AA for ; Wed, 6 Jun 2012 11:15:28 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id D906E27C059 for ; Wed, 6 Jun 2012 11:15:27 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Wed, 6 Jun 2012 11:15:27 +0200 From: To: "idr@ietf.org List" Thread-Topic: draft-djsmith-bgp-flowspec-oid-0 Thread-Index: Ac1DxOjon9KduU2oR4yASthrOAf1eg== Date: Wed, 6 Jun 2012 09:15:26 +0000 Message-ID: <10966_1338974127_4FCF1FAF_10966_7275_1_53C29892C857584299CBF5D05346208A08C9E5@PEXCVZYM11.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.6.6.71515 Subject: [Idr] draft-djsmith-bgp-flowspec-oid-0 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 09:15:30 -0000 Hi, I'm fine with the current doc however please find below some comments / que= stions: 1) There may be an alternate solution which seems to fit the need and be li= ghter from a change impact: Make step (a) of the validation procedure specified in RFC 5575, section 6 = OPTIONAL for IBGP learned flow specification NLRIs _originated from (a) spe= cific Originator(s)_. (In this use case, the specific originator being the centralized BGP route = controller) 2) As we revise RFC 5575, do we need to consider the use of BGP ADD Path? I= ndeed, when checking for the originator, RFC 5575 seems to assume that the = originator advertises a single route. With ADD Path, it looks like in some = corner cases, the ingress router may select a different best path than the = egress ASBR. (and hence a neighbor AS 1 could filter traffic going to neigh= bor AS 2). 3) As we revise RFC 5575, RFC 5575 says: " BGP implementations MUST also enforce that the AS_PATH attribute of a route received via the External Border Gateway Protocol (eBGP) contains the neighboring AS in the left-most position of the AS_PATH attribute." It's not immediately clear (to me) whether it applies to all flow spec rout= es or all routes from all AFI/SAFI. 4) As there has been discussions about checking the AS_PATH (and others abo= ut removing the AS_PATH) is there a need to talk about BGPSEC? Thanks, Regards, Bruno ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From bruno.decraene@orange.com Wed Jun 6 02:18:09 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC17E21F86AD for ; Wed, 6 Jun 2012 02:18:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.463 X-Spam-Level: X-Spam-Status: No, score=-2.463 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id loFGZpqd3EMy for ; Wed, 6 Jun 2012 02:18:09 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 3271C21F86AA for ; Wed, 6 Jun 2012 02:18:09 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 5064A26441D; Wed, 6 Jun 2012 11:18:08 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 353AE238059; Wed, 6 Jun 2012 11:18:08 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Wed, 6 Jun 2012 11:18:07 +0200 From: To: John Scudder , "idr@ietf.org List" Thread-Topic: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR WG document Thread-Index: AQHNP1CvsjAP515rSkG5qJtwKCjYZJbtC2wQ Date: Wed, 6 Jun 2012 09:18:07 +0000 Message-ID: <4911_1338974288_4FCF2050_4911_12906_1_53C29892C857584299CBF5D05346208A08CA08@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.6.6.81515 Subject: Re: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 09:18:10 -0000 Hi, Support. Regards, Bruno >From: John Scudder >Sent: Thursday, May 31, 2012 7:10 PM > >Folks, > >We have received a request from the authors to adopt draft-uttaro-idr-bgp- >persistence-01 as an IDR WG document. Please send your comments to the li= st. >The deadline for comments is June 15, 2012 at noon EDT. > >Thanks, > >--John >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www.ietf.org/mailman/listinfo/idr ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From ju1738@att.com Wed Jun 6 03:30:59 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0849F21F861F for ; Wed, 6 Jun 2012 03:30:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lHiR24sOpczF for ; Wed, 6 Jun 2012 03:30:58 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id 98EA621F8638 for ; Wed, 6 Jun 2012 03:30:57 -0700 (PDT) Received: from unknown [144.160.128.153] (EHLO flpi408.enaf.ffdc.sbc.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.11.0-10) over TLS secured channel with ESMTP id 0613fcf4.0.1187668.00-265.3282610.nbfkord-smmo07.seg.att.com (envelope-from ); Wed, 06 Jun 2012 10:30:57 +0000 (UTC) X-MXL-Hash: 4fcf316142702f40-61eb1775fa0fac5b50723505407f0ab652bf7cc1 Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q56AUuaA007901; Wed, 6 Jun 2012 03:30:56 -0700 Received: from fflint03.pst.cso.att.com (fflint03.pst.cso.att.com [150.234.39.63]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q56AUh0o007747 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Jun 2012 03:30:48 -0700 Received: from MISOUT7MSGHUB9A.ITServices.sbc.com (misout7msghub9a.itservices.sbc.com [144.151.223.62]) by fflint03.pst.cso.att.com (RSA Interceptor); Wed, 6 Jun 2012 03:30:32 -0700 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9A.ITServices.sbc.com ([144.151.223.62]) with mapi id 14.01.0355.002; Wed, 6 Jun 2012 06:30:32 -0400 From: "UTTARO, JAMES" To: "'bruno.decraene@orange.com'" , John Scudder , "idr@ietf.org List" Thread-Topic: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR WG document Thread-Index: AQHNQ8VQL0KwkgADRk2TI1zM6oWkupbtFvYg Date: Wed, 6 Jun 2012 10:30:31 +0000 Message-ID: References: <4911_1338974288_4FCF2050_4911_12906_1_53C29892C857584299CBF5D05346208A08CA08@PEXCVZYM11.corporate.adroot.infra.ftgroup> In-Reply-To: <4911_1338974288_4FCF2050_4911_12906_1_53C29892C857584299CBF5D05346208A08CA08@PEXCVZYM11.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.14.14] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.128.153] X-AnalysisOut: [v=1.0 c=1 a=adihRMYR6csA:10 a=citi0Bd2UY8A:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=xwOvzTHDVLE4u4] X-AnalysisOut: [nGvK72ag==:17 a=48vgC7mUAAAA:8 a=z9tbli-vAAAA:8 a=nS9t6OmS] X-AnalysisOut: [I6UxwUx9jWgA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=oAXR_] X-AnalysisOut: [kdF8uMA:10 a=fWGYY33PfKliRyTh:21 a=WnzTfSIga9bN3c_0:21] Subject: Re: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 10:30:59 -0000 +1 Jim Uttaro -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of bruno= .decraene@orange.com Sent: Wednesday, June 06, 2012 5:18 AM To: John Scudder; idr@ietf.org List Subject: Re: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR W= G document Hi, Support. Regards, Bruno >From: John Scudder >Sent: Thursday, May 31, 2012 7:10 PM > >Folks, > >We have received a request from the authors to adopt draft-uttaro-idr-bgp- >persistence-01 as an IDR WG document. Please send your comments to the li= st. >The deadline for comments is June 15, 2012 at noon EDT. > >Thanks, > >--John >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www.ietf.org/mailman/listinfo/idr ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From ju1738@att.com Wed Jun 6 08:26:47 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B496621F8661 for ; Wed, 6 Jun 2012 08:26:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nrGSVh8dIE3d for ; Wed, 6 Jun 2012 08:26:47 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id 91AF721F85F2 for ; Wed, 6 Jun 2012 08:26:39 -0700 (PDT) Received: from unknown [144.160.128.153] (EHLO flpi408.enaf.ffdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.11.0-10) over TLS secured channel with ESMTP id ea67fcf4.0.945633.00-449.2616693.nbfkord-smmo06.seg.att.com (envelope-from ); Wed, 06 Jun 2012 15:26:39 +0000 (UTC) X-MXL-Hash: 4fcf76af79d82361-e8990ded8bc0164a1778e370cdec2234c3bef99a Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q56FQZhB015990; Wed, 6 Jun 2012 08:26:38 -0700 Received: from fflint03.pst.cso.att.com (fflint03.pst.cso.att.com [150.234.39.63]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q56FQR29015834 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Jun 2012 08:26:30 -0700 Received: from MISOUT7MSGHUB9F.ITServices.sbc.com (misout7msghub9f.itservices.sbc.com [144.151.223.71]) by fflint03.pst.cso.att.com (RSA Interceptor); Wed, 6 Jun 2012 08:26:03 -0700 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9F.ITServices.sbc.com ([144.151.223.71]) with mapi id 14.01.0355.002; Wed, 6 Jun 2012 11:26:02 -0400 From: "UTTARO, JAMES" To: "'bruno.decraene@orange.com'" , "John G. Scudder" , "idr@ietf.org List" Thread-Topic: [Idr] Adoption of draft-djsmith-bgp-flowspec-oid-01 as IDR WG document Thread-Index: AQHNQ8ROHh3Ck/aH+ECnKvbRK11TbZbtacow Date: Wed, 6 Jun 2012 15:26:01 +0000 Message-ID: References: <3BBED7A5-C064-4D80-B135-CC9B678BAF4D@juniper.net> <67CB405A-6DD5-4733-8375-2272CEF0F666@juniper.net> <10966_1338973847_4FCF1E97_10966_7220_1_53C29892C857584299CBF5D05346208A08C9AF@PEXCVZYM11.corporate.adroot.infra.ftgroup> In-Reply-To: <10966_1338973847_4FCF1E97_10966_7220_1_53C29892C857584299CBF5D05346208A08C9AF@PEXCVZYM11.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.14.14] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.128.153] X-AnalysisOut: [v=1.0 c=1 a=adihRMYR6csA:10 a=YT2uEZOwuhwA:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=xwOvzTHDVLE4u4] X-AnalysisOut: [nGvK72ag==:17 a=48vgC7mUAAAA:8 a=z9tbli-vAAAA:8 a=E06oba2Z] X-AnalysisOut: [Hp4yXXgwfkIA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=oAXR_] X-AnalysisOut: [kdF8uMA:10 a=4o0Ej3i8AG5wnTeo:21 a=B2OtGk8dEp_t3nMz:21] Subject: Re: [Idr] Adoption of draft-djsmith-bgp-flowspec-oid-01 as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 15:26:47 -0000 +1 Jim Uttaro -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of bruno= .decraene@orange.com Sent: Wednesday, June 06, 2012 5:11 AM To: John G. Scudder; idr@ietf.org List Subject: Re: [Idr] Adoption of draft-djsmith-bgp-flowspec-oid-01 as IDR WG = document Hi, I support adoption of draft-djsmith-bgp-flowspec-oid as IDR WG document Thanks, Regards, Bruno >From: John G. Scudder >Sent: Tuesday, May 29, 2012 8:34 PM > >So far I have seen replies to this from three people. This is not really s= trong >evidence of interest on the part of the WG. > >The comment period will end on Friday. > >--John > >On May 16, 2012, at 3:40 PM, John G. Scudder wrote: > >> Folks, >> >> We have received a request from the authors to adopt draft-djsmith-bgp- >flowspec-oid-01 as an IDR WG document. Please send your comments to the l= ist. >The deadline for comments is June 1, 2012 at noon EDT. >> >> Thanks, >> >> --John > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www.ietf.org/mailman/listinfo/idr ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From jmh@joelhalpern.com Wed Jun 6 09:07:07 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22EDA21F86B5 for ; Wed, 6 Jun 2012 09:07:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.955 X-Spam-Level: X-Spam-Status: No, score=-101.955 tagged_above=-999 required=5 tests=[AWL=-0.290, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YaX1Efgy5DJO for ; Wed, 6 Jun 2012 09:07:06 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 87C6921F86B6 for ; Wed, 6 Jun 2012 09:07:00 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id 35006557F98 for ; Wed, 6 Jun 2012 09:07:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 594511C07E3; Wed, 6 Jun 2012 09:06:59 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [10.10.10.110] (pool-71-161-52-13.clppva.btas.verizon.net [71.161.52.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 17AC21C07ED; Wed, 6 Jun 2012 09:06:57 -0700 (PDT) Message-ID: <4FCF800C.6070509@joelhalpern.com> Date: Wed, 06 Jun 2012 12:06:36 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: bruno.decraene@orange.com References: <4911_1338974288_4FCF2050_4911_12906_1_53C29892C857584299CBF5D05346208A08CA08@PEXCVZYM11.corporate.adroot.infra.ftgroup> In-Reply-To: <4911_1338974288_4FCF2050_4911_12906_1_53C29892C857584299CBF5D05346208A08CA08@PEXCVZYM11.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org List" Subject: Re: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 16:07:07 -0000 The question for adopting this seems to be whether the folks who have to turn it on can tell when it is safe to do so, and when it isn't. The L2VPN example in the document is an example of why it is worth considering. The L3VPN example seems to show a dangerous use case. Yours, Joel M. Halpern On 6/6/2012 5:18 AM, bruno.decraene@orange.com wrote: > Hi, > > Support. > > Regards, > Bruno > >> From: John Scudder>Sent: Thursday, May 31, 2012 7:10 PM >> >> Folks, >> >> We have received a request from the authors to adopt draft-uttaro-idr-bgp- >> persistence-01 as an IDR WG document. Please send your comments to the list. >> The deadline for comments is June 15, 2012 at noon EDT. >> >> Thanks, >> >> --John >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > From robert@raszuk.net Wed Jun 6 09:41:35 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0ADF21F8888 for ; Wed, 6 Jun 2012 09:41:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LXz+3NbCB6bO for ; Wed, 6 Jun 2012 09:41:35 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id F006F21F888A for ; Wed, 6 Jun 2012 09:41:34 -0700 (PDT) Received: (qmail 32454 invoked by uid 399); 6 Jun 2012 16:41:33 -0000 Received: from unknown (HELO ?172.16.197.148?) (pbs:robert@raszuk.net@58.80.213.53) by mail1310.opentransfer.com with ESMTPM; 6 Jun 2012 16:41:33 -0000 X-Originating-IP: 58.80.213.53 Message-ID: <4FCF883B.6050501@raszuk.net> Date: Wed, 06 Jun 2012 09:41:31 -0700 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120604 Thunderbird/13.0 MIME-Version: 1.0 To: "Joel M. Halpern" References: <4911_1338974288_4FCF2050_4911_12906_1_53C29892C857584299CBF5D05346208A08CA08@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FCF800C.6070509@joelhalpern.com> In-Reply-To: <4FCF800C.6070509@joelhalpern.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org List" Subject: Re: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 16:41:35 -0000 Hi Joel, Great comment. In fact some of the co-authors of this document target to use it in also in the SAFI 1/1 or 2/1 even so the draft softly target a bit different application space: "This document addresses new services whose requirements for persistence diverge from the Internet routing point of view." With this in mind how about either explicitly enumerating those AFI/SAFIs which can use such knob or specify those AFI/SAFIs which MUST NOT support it ? Of course this is assuming we will go with accepting this as WG doc in the first place :) Best regards, R. > The question for adopting this seems to be whether the folks who have to > turn it on can tell when it is safe to do so, and when it isn't. > The L2VPN example in the document is an example of why it is worth > considering. The L3VPN example seems to show a dangerous use case. > > Yours, > Joel M. Halpern > > On 6/6/2012 5:18 AM, bruno.decraene@orange.com wrote: >> Hi, >> >> Support. >> >> Regards, >> Bruno >> >>> From: John Scudder>Sent: Thursday, May 31, 2012 7:10 PM >>> >>> Folks, >>> >>> We have received a request from the authors to adopt >>> draft-uttaro-idr-bgp- >>> persistence-01 as an IDR WG document. Please send your comments to >>> the list. >>> The deadline for comments is June 15, 2012 at noon EDT. >>> >>> Thanks, >>> >>> --John >>> _______________________________________________ >>> Idr mailing list >>> Idr@ietf.org >>> https://www.ietf.org/mailman/listinfo/idr >> >> _________________________________________________________________________________________________________________________ >> >> >> Ce message et ses pieces jointes peuvent contenir des informations >> confidentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez >> recu ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les >> messages electroniques etant susceptibles d'alteration, >> France Telecom - Orange decline toute responsabilite si ce message a >> ete altere, deforme ou falsifie. Merci. >> >> This message and its attachments may contain confidential or >> privileged information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and >> delete this message and its attachments. >> As emails may be altered, France Telecom - Orange is not liable for >> messages that have been modified, changed or falsified. >> Thank you. >> >> _______________________________________________ >> 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 > > From randy@psg.com Wed Jun 6 10:04:12 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF6E521F8735 for ; Wed, 6 Jun 2012 10:04:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.512 X-Spam-Level: X-Spam-Status: No, score=-2.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zc9fNYdXVsbG for ; Wed, 6 Jun 2012 10:04:12 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 4C74D21F86E0 for ; Wed, 6 Jun 2012 10:04:12 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ScJeT-000CUe-JI; Wed, 06 Jun 2012 17:04:09 +0000 Date: Wed, 06 Jun 2012 10:04:09 -0700 Message-ID: From: Randy Bush To: "Joel M. Halpern" In-Reply-To: <4FCF800C.6070509@joelhalpern.com> References: <4911_1338974288_4FCF2050_4911_12906_1_53C29892C857584299CBF5D05346208A08CA08@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FCF800C.6070509@joelhalpern.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: bruno.decraene@orange.com, "idr@ietf.org List" Subject: Re: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 17:04:13 -0000 > The question for adopting this seems to be whether the folks who have > to turn it on can tell when it is safe to do so, and when it isn't. seems to me that this is a discussion for *after* it is adopted by the wg. adoption is not a process of making it perfect. it is a decision of relevance. randy From ju1738@att.com Wed Jun 6 10:13:20 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07F5021F86A2 for ; Wed, 6 Jun 2012 10:13:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id prwNGgASDlth for ; Wed, 6 Jun 2012 10:13:19 -0700 (PDT) Received: from nbfkord-smmo08.seg.att.com (nbfkord-smmo08.seg.att.com [209.65.160.95]) by ietfa.amsl.com (Postfix) with ESMTP id 6CA5B21F8685 for ; Wed, 6 Jun 2012 10:13:18 -0700 (PDT) Received: from unknown [144.160.128.153] (EHLO flpi408.enaf.ffdc.sbc.com) by nbfkord-smmo08.seg.att.com(mxl_mta-6.11.0-10) over TLS secured channel with ESMTP id daf8fcf4.0.127902.00-464.356534.nbfkord-smmo08.seg.att.com (envelope-from ); Wed, 06 Jun 2012 17:13:18 +0000 (UTC) X-MXL-Hash: 4fcf8fae6a979954-02af0a4d2b9b5dee774dd84800aa7ce07bc04d7d Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q56HDGRV026127; Wed, 6 Jun 2012 10:13:17 -0700 Received: from fflint04.pst.cso.att.com (fflint04.pst.cso.att.com [150.234.39.64]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q56HD0hW025837 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Jun 2012 10:13:09 -0700 Received: from MISOUT7MSGHUB9F.ITServices.sbc.com (misout7msghub9f.itservices.sbc.com [144.151.223.71]) by fflint04.pst.cso.att.com (RSA Interceptor); Wed, 6 Jun 2012 10:12:56 -0700 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9F.ITServices.sbc.com ([144.151.223.71]) with mapi id 14.01.0355.002; Wed, 6 Jun 2012 13:12:55 -0400 From: "UTTARO, JAMES" To: "'Joel M. Halpern'" , "bruno.decraene@orange.com" Thread-Topic: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR WG document Thread-Index: AQHNQ/6yYMHlnCICY0OfPofxid+XzJbthfbw Date: Wed, 6 Jun 2012 17:12:55 +0000 Message-ID: References: <4911_1338974288_4FCF2050_4911_12906_1_53C29892C857584299CBF5D05346208A08CA08@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FCF800C.6070509@joelhalpern.com> In-Reply-To: <4FCF800C.6070509@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.14.14] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.128.153] X-AnalysisOut: [v=1.0 c=1 a=adihRMYR6csA:10 a=lYr-YFbwilAA:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=xwOvzTHDVLE4u4] X-AnalysisOut: [nGvK72ag==:17 a=48vgC7mUAAAA:8 a=z9tbli-vAAAA:8 a=rOIzKwJy] X-AnalysisOut: [gFpxnFG8k0kA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=oAXR_] X-AnalysisOut: [kdF8uMA:10 a=RVnTcObzz00wHGcw:21 a=tBgnWCtTEaVTTcTW:21] Cc: "idr@ietf.org List" Subject: Re: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 17:13:20 -0000 Joel, I think it is a matter of the level "incorrectness" we are willing to acce= pt in the event of a catastrophic failure.. In L3VPN there is certainly the= possibility that the PE will miss a routing change that would change the V= PNs path selection and subsequent topology.. That being said we would rathe= r have some "incorrectness" instead of a catastrophic outage for customers = L3VPN...=20 There are other applications i.e using labeled BGP to provide NH reachabili= ty which are extremely static and basically never change that are excellent= candidates..=20 In the draft L2 and L3 have been enumerated, I actually have a deliverable = to write up the 3107 application ( Not done yet )... That being said I do n= ot anticipate that we will characterize every application of BGP Persistenc= e.. Jim Uttaro -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Joel = M. Halpern Sent: Wednesday, June 06, 2012 12:07 PM To: bruno.decraene@orange.com Cc: idr@ietf.org List Subject: Re: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR W= G document The question for adopting this seems to be whether the folks who have to=20 turn it on can tell when it is safe to do so, and when it isn't. The L2VPN example in the document is an example of why it is worth=20 considering. The L3VPN example seems to show a dangerous use case. Yours, Joel M. Halpern On 6/6/2012 5:18 AM, bruno.decraene@orange.com wrote: > Hi, > > Support. > > Regards, > Bruno > >> From: John Scudder>Sent: Thursday, May 31, 2012 7:10 PM >> >> Folks, >> >> We have received a request from the authors to adopt draft-uttaro-idr-bg= p- >> persistence-01 as an IDR WG document. Please send your comments to the = list. >> The deadline for comments is June 15, 2012 at noon EDT. >> >> Thanks, >> >> --John >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr > > _________________________________________________________________________= ________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > France Telecom - Orange decline toute responsabilite si ce message a ete = altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, France Telecom - Orange is not liable for messa= ges that have been modified, changed or falsified. > Thank you. > > _______________________________________________ > 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 From ju1738@att.com Wed Jun 6 10:15:39 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3E2021F86A2 for ; Wed, 6 Jun 2012 10:15:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.199 X-Spam-Level: X-Spam-Status: No, score=-106.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tr2I8l0tRu+g for ; Wed, 6 Jun 2012 10:15:38 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id 2F3F421F8608 for ; Wed, 6 Jun 2012 10:15:38 -0700 (PDT) Received: from unknown [144.160.128.153] (EHLO flpi408.enaf.ffdc.sbc.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.11.0-10) over TLS secured channel with ESMTP id 9309fcf4.0.976375.00-396.2716631.nbfkord-smmo05.seg.att.com (envelope-from ); Wed, 06 Jun 2012 17:15:38 +0000 (UTC) X-MXL-Hash: 4fcf903a7d87d8ac-4887094051f7d4c806d29961871edcc1dcfb95b5 Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q56HFaXN029221; Wed, 6 Jun 2012 10:15:37 -0700 Received: from fflint03.pst.cso.att.com (fflint03.pst.cso.att.com [150.234.39.63]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q56HFLpB028836 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Jun 2012 10:15:31 -0700 Received: from MISOUT7MSGHUB9D.ITServices.sbc.com (misout7msghub9d.itservices.sbc.com [144.151.223.93]) by fflint03.pst.cso.att.com (RSA Interceptor); Wed, 6 Jun 2012 10:15:05 -0700 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9D.ITServices.sbc.com ([144.151.223.93]) with mapi id 14.01.0355.002; Wed, 6 Jun 2012 13:15:00 -0400 From: "UTTARO, JAMES" To: "'robert@raszuk.net'" , "Joel M. Halpern" Thread-Topic: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR WG document Thread-Index: AQHNQ/6yYMHlnCICY0OfPofxid+XzJbtwYSA///F3nA= Date: Wed, 6 Jun 2012 17:14:59 +0000 Message-ID: References: <4911_1338974288_4FCF2050_4911_12906_1_53C29892C857584299CBF5D05346208A08CA08@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FCF800C.6070509@joelhalpern.com> <4FCF883B.6050501@raszuk.net> In-Reply-To: <4FCF883B.6050501@raszuk.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.14.14] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.128.153] X-AnalysisOut: [v=1.0 c=1 a=adihRMYR6csA:10 a=lYr-YFbwilAA:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=xwOvzTHDVLE4u4] X-AnalysisOut: [nGvK72ag==:17 a=48vgC7mUAAAA:8 a=z9tbli-vAAAA:8 a=3q9HExKj] X-AnalysisOut: [jk9PY2rpOcoA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=oAXR_] X-AnalysisOut: [kdF8uMA:10 a=c01Rfxp28ubGCOEv:21 a=LdWY4EC8XKFDY5Ex:21] Cc: "idr@ietf.org List" Subject: Re: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 17:15:40 -0000 Robert=20 We can add addl use cases.. I have this on my to do list.. I believe the 3= 107 use case is high on the list, BGP signaled multicast may be another, BR= AS etc... We could have a long list here and I do not want to be prescripti= ve so I will add the 3107 use case Jim Uttaro -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Rober= t Raszuk Sent: Wednesday, June 06, 2012 12:42 PM To: Joel M. Halpern Cc: idr@ietf.org List Subject: Re: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR W= G document Hi Joel, Great comment. In fact some of the co-authors of this document target to=20 use it in also in the SAFI 1/1 or 2/1 even so the draft softly target a=20 bit different application space: "This document addresses new services whose requirements for persistence diverge from the Internet routing point of view." With this in mind how about either explicitly enumerating those=20 AFI/SAFIs which can use such knob or specify those AFI/SAFIs which MUST=20 NOT support it ? Of course this is assuming we will go with accepting this as WG doc in=20 the first place :) Best regards, R. > The question for adopting this seems to be whether the folks who have to > turn it on can tell when it is safe to do so, and when it isn't. > The L2VPN example in the document is an example of why it is worth > considering. The L3VPN example seems to show a dangerous use case. > > Yours, > Joel M. Halpern > > On 6/6/2012 5:18 AM, bruno.decraene@orange.com wrote: >> Hi, >> >> Support. >> >> Regards, >> Bruno >> >>> From: John Scudder>Sent: Thursday, May 31, 2012 7:10 PM >>> >>> Folks, >>> >>> We have received a request from the authors to adopt >>> draft-uttaro-idr-bgp- >>> persistence-01 as an IDR WG document. Please send your comments to >>> the list. >>> The deadline for comments is June 15, 2012 at noon EDT. >>> >>> Thanks, >>> >>> --John >>> _______________________________________________ >>> Idr mailing list >>> Idr@ietf.org >>> https://www.ietf.org/mailman/listinfo/idr >> >> ________________________________________________________________________= _________________________________________________ >> >> >> Ce message et ses pieces jointes peuvent contenir des informations >> confidentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez >> recu ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les >> messages electroniques etant susceptibles d'alteration, >> France Telecom - Orange decline toute responsabilite si ce message a >> ete altere, deforme ou falsifie. Merci. >> >> This message and its attachments may contain confidential or >> privileged information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and >> delete this message and its attachments. >> As emails may be altered, France Telecom - Orange is not liable for >> messages that have been modified, changed or falsified. >> Thank you. >> >> _______________________________________________ >> 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 > > _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From jmh@joelhalpern.com Wed Jun 6 11:10:37 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56A1B21F8710 for ; Wed, 6 Jun 2012 11:10:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.942 X-Spam-Level: X-Spam-Status: No, score=-101.942 tagged_above=-999 required=5 tests=[AWL=-0.277, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U17k2WltMq9h for ; Wed, 6 Jun 2012 11:10:36 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 834B321F8540 for ; Wed, 6 Jun 2012 11:10:36 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 5909AA3A49 for ; Wed, 6 Jun 2012 11:10:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 3FB881BC72E5; Wed, 6 Jun 2012 11:10:35 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.10.10.110] (pool-71-161-52-13.clppva.btas.verizon.net [71.161.52.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 727631BC72D3; Wed, 6 Jun 2012 11:10:34 -0700 (PDT) Message-ID: <4FCF9D04.2080401@joelhalpern.com> Date: Wed, 06 Jun 2012 14:10:12 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "UTTARO, JAMES" References: <4911_1338974288_4FCF2050_4911_12906_1_53C29892C857584299CBF5D05346208A08CA08@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FCF800C.6070509@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org List" Subject: Re: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 18:10:37 -0000 There do seem to be significant cases where this is useful. What I am asking is that we highlight very clearly the risks, and try to be clearer about how to tell when it is a good choice. This is very different from the classical IDR policy of just providing knobs, and leaving the rest up to the vendors to guess / provide to customers / get wrong. Yours, Joel On 6/6/2012 1:12 PM, UTTARO, JAMES wrote: > Joel, > > I think it is a matter of the level "incorrectness" we are willing to accept in the event of a catastrophic failure.. In L3VPN there is certainly the possibility that the PE will miss a routing change that would change the VPNs path selection and subsequent topology.. That being said we would rather have some "incorrectness" instead of a catastrophic outage for customers L3VPN... > > There are other applications i.e using labeled BGP to provide NH reachability which are extremely static and basically never change that are excellent candidates.. > > In the draft L2 and L3 have been enumerated, I actually have a deliverable to write up the 3107 application ( Not done yet )... That being said I do not anticipate that we will characterize every application of BGP Persistence.. > > Jim Uttaro > > -----Original Message----- > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Joel M. Halpern > Sent: Wednesday, June 06, 2012 12:07 PM > To: bruno.decraene@orange.com > Cc: idr@ietf.org List > Subject: Re: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR WG document > > The question for adopting this seems to be whether the folks who have to > turn it on can tell when it is safe to do so, and when it isn't. > The L2VPN example in the document is an example of why it is worth > considering. The L3VPN example seems to show a dangerous use case. > > Yours, > Joel M. Halpern > > On 6/6/2012 5:18 AM, bruno.decraene@orange.com wrote: >> Hi, >> >> Support. >> >> Regards, >> Bruno >> >>> From: John Scudder>Sent: Thursday, May 31, 2012 7:10 PM >>> >>> Folks, >>> >>> We have received a request from the authors to adopt draft-uttaro-idr-bgp- >>> persistence-01 as an IDR WG document. Please send your comments to the list. >>> The deadline for comments is June 15, 2012 at noon EDT. >>> >>> Thanks, >>> >>> --John >>> _______________________________________________ >>> Idr mailing list >>> Idr@ietf.org >>> https://www.ietf.org/mailman/listinfo/idr >> >> _________________________________________________________________________________________________________________________ >> >> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, >> France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. >> >> This message and its attachments may contain confidential or privileged information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and delete this message and its attachments. >> As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified. >> Thank you. >> >> _______________________________________________ >> 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 > From robert@raszuk.net Wed Jun 6 16:49:30 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87F6511E8083 for ; Wed, 6 Jun 2012 16:49:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.842 X-Spam-Level: X-Spam-Status: No, score=-1.842 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R3ymzEe+f182 for ; Wed, 6 Jun 2012 16:49:29 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 9F56011E8079 for ; Wed, 6 Jun 2012 16:49:29 -0700 (PDT) Received: (qmail 13671 invoked by uid 399); 6 Jun 2012 23:49:28 -0000 Received: from unknown (HELO ?172.16.197.148?) (pbs:robert@raszuk.net@58.80.213.53) by mail1310.opentransfer.com with ESMTPM; 6 Jun 2012 23:49:28 -0000 X-Originating-IP: 58.80.213.53 Message-ID: <4FCFEC86.6050706@raszuk.net> Date: Wed, 06 Jun 2012 16:49:26 -0700 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120604 Thunderbird/13.0 MIME-Version: 1.0 To: "UTTARO, JAMES" References: <4911_1338974288_4FCF2050_4911_12906_1_53C29892C857584299CBF5D05346208A08CA08@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FCF800C.6070509@joelhalpern.com> <4FCF883B.6050501@raszuk.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org List" , "Joel M. Halpern" Subject: Re: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 23:49:30 -0000 Jim, Adding more use cases is clearly good thing. But I was in particular asking for a stronger text explicitly forbidding implementation to make IPv4 or IPv6 routes as persistent. For 1/4, 1/128 or any other "application" SAFIs I think that at the end you may do what you like :) Today Internet churn is already not low ... this draft if used incorrectly for Internet can cause additional re-advertisements based on local flaps (where GR you are keep comparing it with would not). And just as a reference point on old NPE400 I peered with the AS290 yesterday here in Tokyo interop I get 60%-70% CPU use all the time CE_c72_Internet#sh proc cpu CPU utilization for five seconds: 99%/23%; one minute: 67%; five minutes: 83% .... 103 26649044 209857 126987 62.32% 41.94% 56.76% 0 BGP Router So while any knob may look nice on the paper it does have an impact Internet wide and that's main reason I am a bit skeptical on adding more to SAFI 1/1 and 2/1. In general I think we are really missing the indirection in signalling SAFI wide parameters in BGP. Perhaps if WG thinks this would be good idea we could propose a simple new draft for defining a new signalling SAFI for all other SAFI wide events. That way in the event of use of persistent communities or shutdown on existing SAFIs single message could be send not re-advertisements of millions of routes. And that significance will only grow when you attempt to do path validation or other fancy processing inbound of each advertisement. I know you can apply persistence to subset of prefixes however I doubt that this would be practical deployment case. Clearly for shutdown it does not make much sense to only signal subset of marked routes in a given SAFI that are going down soon. Best regards, R. > Robert > > We can add addl use cases.. I have this on my to do list.. I believe > the 3107 use case is high on the list, BGP signaled multicast may be > another, BRAS etc... We could have a long list here and I do not want > to be prescriptive so I will add the 3107 use case > > Jim Uttaro > > -----Original Message----- From: idr-bounces@ietf.org > [mailto:idr-bounces@ietf.org] On Behalf Of Robert Raszuk Sent: > Wednesday, June 06, 2012 12:42 PM To: Joel M. Halpern Cc: > idr@ietf.org List Subject: Re: [Idr] Adoption of > draft-uttaro-idr-bgp-persistence-01 as IDR WG document > > Hi Joel, > > Great comment. In fact some of the co-authors of this document target > to use it in also in the SAFI 1/1 or 2/1 even so the draft softly > target a bit different application space: > > "This document addresses new services whose requirements for > persistence diverge from the Internet routing point of view." > > With this in mind how about either explicitly enumerating those > AFI/SAFIs which can use such knob or specify those AFI/SAFIs which > MUST NOT support it ? > > Of course this is assuming we will go with accepting this as WG doc > in the first place :) > > Best regards, R. > > >> The question for adopting this seems to be whether the folks who >> have to turn it on can tell when it is safe to do so, and when it >> isn't. The L2VPN example in the document is an example of why it is >> worth considering. The L3VPN example seems to show a dangerous use >> case. >> >> Yours, Joel M. Halpern >> >> On 6/6/2012 5:18 AM, bruno.decraene@orange.com wrote: >>> Hi, >>> >>> Support. >>> >>> Regards, Bruno >>> >>>> From: John Scudder>Sent: Thursday, May 31, 2012 7:10 PM >>>> >>>> Folks, >>>> >>>> We have received a request from the authors to adopt >>>> draft-uttaro-idr-bgp- persistence-01 as an IDR WG document. >>>> Please send your comments to the list. The deadline for >>>> comments is June 15, 2012 at noon EDT. >>>> >>>> Thanks, >>>> >>>> --John _______________________________________________ Idr >>>> mailing list Idr@ietf.org >>>> https://www.ietf.org/mailman/listinfo/idr >>> >>> _________________________________________________________________________________________________________________________ >>> >>> >>> >>> Ce message et ses pieces jointes peuvent contenir des informations >>> confidentielles ou privilegiees et ne doivent donc pas etre >>> diffuses, exploites ou copies sans autorisation. Si vous avez >>> recu ce message par erreur, veuillez le signaler a l'expediteur >>> et le detruire ainsi que les pieces jointes. Les messages >>> electroniques etant susceptibles d'alteration, France Telecom - >>> Orange decline toute responsabilite si ce message a ete altere, >>> deforme ou falsifie. Merci. >>> >>> This message and its attachments may contain confidential or >>> privileged information that may be protected by law; they should >>> not be distributed, used or copied without authorisation. If you >>> have received this email in error, please notify the sender and >>> delete this message and its attachments. As emails may be >>> altered, France Telecom - Orange is not liable for messages that >>> have been modified, changed or falsified. Thank you. >>> >>> _______________________________________________ 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 >> >> > > > _______________________________________________ Idr mailing list > Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr > > From stephane.litkowski@orange.com Wed Jun 6 23:46:12 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B8AB21F870B for ; Wed, 6 Jun 2012 23:46:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HLHzcEvHvsqH for ; Wed, 6 Jun 2012 23:46:12 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id B9EAE21F869D for ; Wed, 6 Jun 2012 23:46:11 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 51C3C32433E; Thu, 7 Jun 2012 08:46:10 +0200 (CEST) Received: from puexcc41.nanterre.francetelecom.fr (unknown [10.168.74.60]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 37CEA27C054; Thu, 7 Jun 2012 08:46:10 +0200 (CEST) Received: from PUEXCBL0.nanterre.francetelecom.fr ([10.168.74.47]) by puexcc41.nanterre.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 7 Jun 2012 08:46:08 +0200 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: Thu, 7 Jun 2012 08:46:09 +0200 Message-ID: <7785_1339051570_4FD04E32_7785_11757_1_4FC3556A36EE3646A09DAA60429F5335086BC954@PUEXCBL0.nanterre.francetelecom.fr> In-Reply-To: <4911_1338974288_4FCF2050_4911_12906_1_53C29892C857584299CBF5D05346208A08CA08@PEXCVZYM11.corporate.adroot.infra.ftgroup> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDRWG document Thread-Index: AQHNP1CvsjAP515rSkG5qJtwKCjYZJbtC2wQgAFoVNA= References: <4911_1338974288_4FCF2050_4911_12906_1_53C29892C857584299CBF5D05346208A08CA08@PEXCVZYM11.corporate.adroot.infra.ftgroup> From: To: "John Scudder" , X-OriginalArrivalTime: 07 Jun 2012 06:46:08.0642 (UTC) FILETIME=[3817AE20:01CD4479] X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.6.7.43337 Subject: Re: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDRWG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 06:46:12 -0000 =20 Support >From: John Scudder >Sent: Thursday, May 31, 2012 7:10 PM > >Folks, > >We have received a request from the authors to adopt=20 >draft-uttaro-idr-bgp- >persistence-01 as an IDR WG document. Please send your comments to the list. >The deadline for comments is June 15, 2012 at noon EDT. > >Thanks, > >--John >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www.ietf.org/mailman/listinfo/idr ________________________________________________________________________ _________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From pmohapat@cisco.com Thu Jun 7 00:25:14 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62F0421F85EA for ; Thu, 7 Jun 2012 00:25:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TtTE-bWGnmy1 for ; Thu, 7 Jun 2012 00:25:13 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id DCDA021F85E4 for ; Thu, 7 Jun 2012 00:25:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pmohapat@cisco.com; l=437; q=dns/txt; s=iport; t=1339053913; x=1340263513; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=cN/nt6fIbOlLTxKmZdinjWsy+T2/NTferp39eP0EorY=; b=IaxcQ3T0ktEnA17iCywDoKQUjJurD7bzBPzj36aBbQUvYhD3ZyeMJI1h /KzJUshgmIZYZgE00myLhRuJ9m7VtqFWEjvnMhzo/Yz/pZU1qXENcNKMo 5yVS1h+9rlCn03ohbPWLnoPBfiB02dzCzjRYe5iu/5yjf0Pz/sdDcSpyA o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAL5W0E+rRDoJ/2dsb2JhbABEtB2BB4IYAQEBAwESASc/BQsLRlc7h2QEmHefeI4QgjVgA4hAjF2OFIFmgwA X-IronPort-AV: E=Sophos;i="4.75,728,1330905600"; d="scan'208";a="48011182" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 07 Jun 2012 07:25:13 +0000 Received: from sjc-vpn7-643.cisco.com (sjc-vpn7-643.cisco.com [10.21.146.131]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q577PDD0001431; Thu, 7 Jun 2012 07:25:13 GMT Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Pradosh Mohapatra In-Reply-To: <4FCFEC86.6050706@raszuk.net> Date: Thu, 7 Jun 2012 00:25:12 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <507A0451-C11D-4CFB-8EE1-073220B1631E@cisco.com> References: <4911_1338974288_4FCF2050_4911_12906_1_53C29892C857584299CBF5D05346208A08CA08@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FCF800C.6070509@joelhalpern.com> <4FCF883B.6050501@raszuk.net> <4FCFEC86.6050706@raszuk.net> To: robert@raszuk.net X-Mailer: Apple Mail (2.1278) Cc: "idr@ietf.org List" , "Joel M. Halpern" , "UTTARO, JAMES" Subject: Re: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 07:25:14 -0000 Hi Robert, > Adding more use cases is clearly good thing. >=20 > But I was in particular asking for a stronger text explicitly = forbidding implementation to make IPv4 or IPv6 routes as persistent. I prefer to have a section that articulates the risks and provides = design guidelines, as per Joel's suggestion. That would be a better = technical specification than making a table of AFI/SAFI applicability. - Pradosh From rjs@rob.sh Thu Jun 7 03:06:18 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A36E121F87A9 for ; Thu, 7 Jun 2012 03:06:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.186 X-Spam-Level: X-Spam-Status: No, score=-2.186 tagged_above=-999 required=5 tests=[AWL=-0.186, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8J1WivL4qfMZ for ; Thu, 7 Jun 2012 03:06:18 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2001:b98:201:101::10:cafe]) by ietfa.amsl.com (Postfix) with ESMTP id 3AD4421F87AB for ; Thu, 7 Jun 2012 03:06:17 -0700 (PDT) Received: from [109.144.232.84] (helo=[10.10.1.158]) by cappuccino.rob.sh with esmtpa (Exim 4.72) (envelope-from ) id 1ScZaQ-0004oN-A4; Thu, 07 Jun 2012 11:05:02 +0100 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Rob Shakir In-Reply-To: <4FCF9D04.2080401@joelhalpern.com> Date: Thu, 7 Jun 2012 11:06:14 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4911_1338974288_4FCF2050_4911_12906_1_53C29892C857584299CBF5D05346208A08CA08@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FCF800C.6070509@joelhalpern.com> <4FCF9D04.2080401@joelhalpern.com> To: "Joel M. Halpern" , "idr@ietf.org List" X-Mailer: Apple Mail (2.1257) Cc: JAMES UTTARO Subject: Re: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 10:06:18 -0000 On 6 Jun 2012, at 19:10, Joel M. Halpern wrote: > There do seem to be significant cases where this is useful. > What I am asking is that we highlight very clearly the risks, and try = to be clearer about how to tell when it is a good choice. This is very = different from the classical IDR policy of just providing knobs, and = leaving the rest up to the vendors to guess / provide to customers / get = wrong. Hi Joel, All, As per Jim's previous comment, it is a case of balancing of the level of = incorrectness that is acceptable in a particular network deployment. = Having put together the L3VPN use case example, I did try to highlight = what the potential deployment concerns may be. I will look to expand = Section 5 of the draft to be much clearer on risks and the way to choose = whether a deployment of this functionality is "a good choice" as per = your recommendation. On the wider point, (and at the risk of sounding like a broken record) = my view is that we need to balance absolute protocol correctness against = the commercial and technical constraints within which protocols are = deployed. Sometimes this means that there are knobs introduced that are = potentially harmful, however, this shouldn't mean we don't have the = knobs, just that they should be clearly labelled as to their potential = issues, so that an operator can decide whether their particular = deployment requires the functionality. This does not necessarily mean = cataloguing all the possible ways a new mechanism could be deployed, and = dictating which are acceptable (particularly as what is acceptable in = some networks may not be in others), but rather (as per Joel's = suggestion) providing the necessary pointers as to how to make such a = decision. (I also support this document's adoption as a working group draft, and = encourage further discussion as to additions that should be made in the = next revision). Cheers, r. From robert@raszuk.net Thu Jun 7 06:57:20 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DCA921F888C for ; Thu, 7 Jun 2012 06:57:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.22 X-Spam-Level: X-Spam-Status: No, score=-2.22 tagged_above=-999 required=5 tests=[AWL=0.379, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GGDjtk1SL+iE for ; Thu, 7 Jun 2012 06:57:19 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 4E63621F854C for ; Thu, 7 Jun 2012 06:57:19 -0700 (PDT) Received: (qmail 25238 invoked by uid 399); 7 Jun 2012 13:57:18 -0000 Received: from unknown (HELO ?172.16.197.148?) (pbs:robert@raszuk.net@58.80.213.53) by mail1310.opentransfer.com with ESMTPM; 7 Jun 2012 13:57:18 -0000 X-Originating-IP: 58.80.213.53 Message-ID: <4FD0B33B.50603@raszuk.net> Date: Thu, 07 Jun 2012 06:57:15 -0700 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120604 Thunderbird/13.0 MIME-Version: 1.0 To: Pradosh Mohapatra , "UTTARO, JAMES" , DECRAENE Bruno RD-CORE-ISS References: <4911_1338974288_4FCF2050_4911_12906_1_53C29892C857584299CBF5D05346208A08CA08@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FCF800C.6070509@joelhalpern.com> <4FCF883B.6050501@raszuk.net> <4FCFEC86.6050706@raszuk.net> <507A0451-C11D-4CFB-8EE1-073220B1631E@cisco.com> In-Reply-To: <507A0451-C11D-4CFB-8EE1-073220B1631E@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org List" , "Joel M. Halpern" Subject: Re: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 13:57:20 -0000 Hi Pradosh, I am therefor awaiting a new section in the draft that quantitatively articulates the risk and Internet wide behaviour including BGP wave effect caused by re-advertisement of entire IPv4/IPv6 table upon the bgp session reset. As the STALE routes are not dynamically updated anymore, it's desirable that they be only used in last resort. Hence when comparing paths for a prefix, a non STALE path should be preferred over a STALE path. Btw enabling the above quoted text still suffers from the identical loop in the partially upgraded AS as shutdown draft. Shutdown solved this by enforcing no change to best path itself other then via local pref. The draft at this point only describes use of local pref in the case of all paths being STALE or says that ASBR if receiving paths over EBGP as stale "MAY" lower local pref. This is not correct. However I also have a suggestion to a bit mitigate the effect wave effect of re-advertisement. As of now the draft reads: Assuming a session failure has occurred, a BGP persistent router SHOULD retain BGP routes unless they carry the DO_NOT_PERSIST community and propagate paths to downstream speakers that indicate that a given path is now stale. How about modification to the above text with the following: Assuming a session failure has occurred, a BGP persistent router SHOULD retain BGP routes unless they carry the DO_NOT_PERSIST community and only after GR timer expiry propagate paths to downstream speakers that indicate that a given path is now stale. The above change still considers the case where basic GR is deployed and allows to avoid the BGP churn when BGP session flaps. If it does not come back you can start your re-advertisement mark stating that route is stale. As in all cases you are assuming that next hop is still reachable why the document does not recommend to upon the above BGP session failure to automatically install/activate in FIB IP or in the case of intra-domain MPLS or IP encapsulation of subject traffic to a BGP next hop ? That way you are actually assuring uninterrupted data plane delivery while local control plane recovers. Of course this would only apply to those BGP speakers which are in data plane. Rgs, R. > Hi Robert, > > >> Adding more use cases is clearly good thing. >> >> But I was in particular asking for a stronger text explicitly >> forbidding implementation to make IPv4 or IPv6 routes as >> persistent. > > > I prefer to have a section that articulates the risks and provides > design guidelines, as per Joel's suggestion. That would be a better > technical specification than making a table of AFI/SAFI > applicability. > > - Pradosh > > > From djsmith@cisco.com Thu Jun 7 07:05:55 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7E4E21F87E8 for ; Thu, 7 Jun 2012 07:05:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X7osC0vMgi1M for ; Thu, 7 Jun 2012 07:05:55 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 2876021F87E0 for ; Thu, 7 Jun 2012 07:05:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=djsmith@cisco.com; l=638; q=dns/txt; s=iport; t=1339077955; x=1340287555; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=iGmNFLC68Taf/7zxoyidlzSUGNu0xH4vlPdgvQ8/OUE=; b=MG5zxP8UeI4HanF4MPVCdFAj9FKS7DygkLMXeB34Ti7dUaZ29PPfi/Ig /PwIWVbiBsckHEUiclw777NmEKe2sPhS2VCeQoZL1XDFhqdfbzDqGPQQz Ueu/dNkSFJmSZR5y+WFxb/0qaRgnJJrfwmJhDObIyPg1xOVnPDI9mThd+ U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAOq00E+tJXG//2dsb2JhbABFtCCBB4IYAQEBBAEBAQ8BHQo0FwQCAQgRBAEBCwYXAQYBJh8JCAEBBBMIGodpC5h1oAAEix2Cc4I5YAOIQJpxgWaCfg X-IronPort-AV: E=Sophos;i="4.75,731,1330905600"; d="scan'208";a="90388042" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-5.cisco.com with ESMTP; 07 Jun 2012 14:05:54 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id q57E5sDh026232 for ; Thu, 7 Jun 2012 14:05:54 GMT Received: from xmb-rcd-202.cisco.com ([72.163.62.209]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 7 Jun 2012 09:05:53 -0500 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: Thu, 7 Jun 2012 09:05:47 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR WGdocument Thread-Index: Ac0/UK9Ojdloj2feQBiiXogqcod9rQFZa2xQ References: From: "David Smith (djsmith)" To: X-OriginalArrivalTime: 07 Jun 2012 14:05:54.0103 (UTC) FILETIME=[A70D8470:01CD44B6] Subject: Re: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR WGdocument X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 14:05:56 -0000 support -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of John Scudder Sent: Thursday, May 31, 2012 1:10 PM To: idr@ietf.org List Subject: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR WGdocument Folks, We have received a request from the authors to adopt draft-uttaro-idr-bgp-persistence-01 as an IDR WG document. Please send your comments to the list. The deadline for comments is June 15, 2012 at noon EDT. Thanks, --John _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From robert@raszuk.net Thu Jun 7 07:06:04 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 875EB21F87F5 for ; Thu, 7 Jun 2012 07:06:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.346 X-Spam-Level: X-Spam-Status: No, score=-2.346 tagged_above=-999 required=5 tests=[AWL=0.253, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qXd70Ufb9TRI for ; Thu, 7 Jun 2012 07:06:04 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id A6D5421F87F9 for ; Thu, 7 Jun 2012 07:06:03 -0700 (PDT) Received: (qmail 5978 invoked by uid 399); 7 Jun 2012 14:06:03 -0000 Received: from unknown (HELO ?172.16.197.148?) (pbs:robert@raszuk.net@58.80.213.53) by mail1310.opentransfer.com with ESMTPM; 7 Jun 2012 14:06:03 -0000 X-Originating-IP: 58.80.213.53 Message-ID: <4FD0B548.4020501@raszuk.net> Date: Thu, 07 Jun 2012 07:06:00 -0700 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120604 Thunderbird/13.0 MIME-Version: 1.0 To: Rob Shakir References: <4911_1338974288_4FCF2050_4911_12906_1_53C29892C857584299CBF5D05346208A08CA08@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FCF800C.6070509@joelhalpern.com> <4FCF9D04.2080401@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org List" , "Joel M. Halpern" , JAMES UTTARO Subject: Re: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 14:06:04 -0000 Hi Rob, > Sometimes this means that there are knobs introduced that are potentially harmful, however, this shouldn't mean we don't have the knobs, just that they should be clearly labelled as to their potential issues, so that an operator can decide whether their particular deployment requires the functionality. > As the STALE routes are not dynamically updated anymore, it's > desirable that they be only used in last resort. Hence when > comparing paths for a prefix, a non STALE path should be preferred > over a STALE path. The observation I would like to make to the above quote is that while I think we can go wild with zoo of knobs for local AFI/SAFIs (example L2VPN or L3VPN) we should be very careful to provide knobs destabilizing the Internet. And the main issue is that the ISP configuring such knob will not suffer but the entire internet will. The ISP in most cases careless about remote folks router's CPU when he decides to re-advertise with STALE, his peers will not delete this community and upon his link flap he will start to bump the version numbers of all BGP speakers within and including his upstream reach. I bet in most cases he will not even realize that ... most vendors manuals or release notes provide text what the knob does without specifying a thing about the side effects. Rgs, R. From bruno.decraene@orange.com Thu Jun 7 07:08:27 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D087921F884B for ; Thu, 7 Jun 2012 07:08:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.482 X-Spam-Level: X-Spam-Status: No, score=-2.482 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rmZvKGBUcR3n for ; Thu, 7 Jun 2012 07:08:27 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id AE53F21F885D for ; Thu, 7 Jun 2012 07:08:26 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 1C7AB18C5EB; Thu, 7 Jun 2012 16:08:26 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id DC86135C06A; Thu, 7 Jun 2012 16:08:25 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Thu, 7 Jun 2012 16:08:25 +0200 From: To: "robert@raszuk.net" Thread-Topic: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR WG document Thread-Index: AQHNRH6zoKI+KOmB1EGiK6PimNq0LZbu4CIg Date: Thu, 7 Jun 2012 14:08:25 +0000 Message-ID: <25665_1339078106_4FD0B5D9_25665_10218_11_53C29892C857584299CBF5D05346208A08D20D@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <4911_1338974288_4FCF2050_4911_12906_1_53C29892C857584299CBF5D05346208A08CA08@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FCF800C.6070509@joelhalpern.com> <4FCF883B.6050501@raszuk.net> <4FCFEC86.6050706@raszuk.net> <507A0451-C11D-4CFB-8EE1-073220B1631E@cisco.com> In-Reply-To: <507A0451-C11D-4CFB-8EE1-073220B1631E@cisco.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.6.7.120320 Cc: "idr@ietf.org List" , "Joel M. Halpern" , "UTTARO, JAMES" Subject: Re: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 14:08:27 -0000 Hi Robert,=20 >From: Pradosh Mohapatra >Sent: Thursday, June 07, 2012 9:25 AM > >Hi Robert, > > >> Adding more use cases is clearly good thing. >> >> But I was in particular asking for a stronger text explicitly forbidding >implementation to make IPv4 or IPv6 routes as persistent. > > >I prefer to have a section that articulates the risks and provides design >guidelines, as per Joel's suggestion. That would be a better technical >specification than making a table of AFI/SAFI applicability. +1 Note also that there is no strict mapping between a service and an AFI/SAFI. E.g. to come back to the Internet service you picked: - one network could carry Internet routes inside a L3 VPN.=20 - some IP unicast routes may never be advertised in the Internet routing sy= stem.=20 Bruno > >- Pradosh > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www.ietf.org/mailman/listinfo/idr ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From robert@raszuk.net Thu Jun 7 07:13:02 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 426DD21F8863 for ; Thu, 7 Jun 2012 07:13:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.41 X-Spam-Level: X-Spam-Status: No, score=-2.41 tagged_above=-999 required=5 tests=[AWL=0.189, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e1P8FOINKQ0V for ; Thu, 7 Jun 2012 07:13:01 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id B85AF21F8862 for ; Thu, 7 Jun 2012 07:13:00 -0700 (PDT) Received: (qmail 13126 invoked by uid 399); 7 Jun 2012 14:13:00 -0000 Received: from unknown (HELO ?172.16.197.148?) (pbs:robert@raszuk.net@58.80.213.53) by mail1310.opentransfer.com with ESMTPM; 7 Jun 2012 14:13:00 -0000 X-Originating-IP: 58.80.213.53 Message-ID: <4FD0B6E9.8080704@raszuk.net> Date: Thu, 07 Jun 2012 07:12:57 -0700 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120604 Thunderbird/13.0 MIME-Version: 1.0 To: bruno.decraene@orange.com References: <4911_1338974288_4FCF2050_4911_12906_1_53C29892C857584299CBF5D05346208A08CA08@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FCF800C.6070509@joelhalpern.com> <4FCF883B.6050501@raszuk.net> <4FCFEC86.6050706@raszuk.net> <507A0451-C11D-4CFB-8EE1-073220B1631E@cisco.com> <25665_1339078106_4FD0B5D9_25665_10218_11_53C29892C857584299CBF5D05346208A08D20D@PEXCVZYM11.corporate.adroot.infra.ftgroup> In-Reply-To: <25665_1339078106_4FD0B5D9_25665_10218_11_53C29892C857584299CBF5D05346208A08D20D@PEXCVZYM11.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org List" , "Joel M. Halpern" , "UTTARO, JAMES" Subject: Re: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 14:13:02 -0000 Hi Bruno, > Note also that there is no strict mapping between a service and an AFI/SAFI. > E.g. to come back to the Internet service you picked: > - one network could carry Internet routes inside a L3 VPN. That's exactly why I am not talking services, but AFI/SAFI limit. You may do what you like within 1/128. But please do not break 1/1 as I may transit via ft/orange. > - some IP unicast routes may never be advertised in the Internet routing system. not sure how this is relevant to the topic. Best, R. From pierre.francois@imdea.org Thu Jun 7 07:35:46 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C40621F868A for ; Thu, 7 Jun 2012 07:35:46 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tlkC0J0fmUrg for ; Thu, 7 Jun 2012 07:35:45 -0700 (PDT) Received: from estafeta.imdea.org (maquina46.madrimasd.org [193.145.15.46]) by ietfa.amsl.com (Postfix) with ESMTP id A0D1D21F8675 for ; Thu, 7 Jun 2012 07:35:43 -0700 (PDT) Received: from localhost (estafeta22.imdea.org [172.17.99.146]) by estafeta22.imdea.org (Postfix) with ESMTP id 11293265110; Thu, 7 Jun 2012 16:35:42 +0200 (CEST) X-Virus-Scanned: by antispam-antivirus system at imdea.org Received: from estafeta.imdea.org ([172.17.99.146]) by localhost (estafeta22.imdea.org [172.17.99.146]) (amavisd-new, port 10024) with ESMTP id jsseuVk+pAE4; Thu, 7 Jun 2012 16:35:41 +0200 (CEST) Received: from dory-2.local (52.Red-88-14-146.dynamicIP.rima-tde.net [88.14.146.52]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: pierre.francois) by estafeta22.imdea.org (Postfix) with ESMTP id CF2EC26510F; Thu, 7 Jun 2012 16:35:41 +0200 (CEST) Message-ID: <4FD0BC3E.8030707@imdea.org> Date: Thu, 07 Jun 2012 16:35:42 +0200 From: Pierre Francois User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: John Scudder References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org List" Subject: Re: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 14:35:46 -0000 Hello, Support. Pierre. On 5/31/12 7:10 PM, John Scudder wrote: > Folks, > > We have received a request from the authors to adopt draft-uttaro-idr-bgp-persistence-01 as an IDR WG document. Please send your comments to the list. The deadline for comments is June 15, 2012 at noon EDT. > > Thanks, > > --John > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From jakob.heitz@ericsson.com Thu Jun 7 08:45:47 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57B9711E80EA for ; Thu, 7 Jun 2012 08:45:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y2SVgm0zcp55 for ; Thu, 7 Jun 2012 08:45:46 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id C2BA311E80E7 for ; Thu, 7 Jun 2012 08:45:46 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q57Fjdhs002904; Thu, 7 Jun 2012 10:45:42 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.31]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Thu, 7 Jun 2012 11:45:39 -0400 From: Jakob Heitz To: "robert@raszuk.net" Date: Thu, 7 Jun 2012 11:45:53 -0400 Thread-Topic: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR WG document Thread-Index: Ac1ExJYisr39WCC0QoyqLcy2MbVJZQ== Message-ID: References: <4911_1338974288_4FCF2050_4911_12906_1_53C29892C857584299CBF5D05346208A08CA08@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FCF800C.6070509@joelhalpern.com> <4FCF883B.6050501@raszuk.net> <4FCFEC86.6050706@raszuk.net> <507A0451-C11D-4CFB-8EE1-073220B1631E@cisco.com> <4FD0B33B.50603@raszuk.net> In-Reply-To: <4FD0B33B.50603@raszuk.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: DECRAENE Bruno RD-CORE-ISS , "Joel M. Halpern" , "UTTARO, JAMES" , "idr@ietf.org List" Subject: Re: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 15:45:47 -0000 On Jun 7, 2012, at 6:57 AM, "Robert Raszuk" wrote: > As the STALE routes are not dynamically updated anymore, it's > desirable that they be only used in last resort. Hence when > comparing paths for a prefix, a non STALE path should be preferred > over a STALE path. should a path with a shorter prefix also be preferred? Say the stale path is 10.0.0.0/24 and 10.0.0.0/16 exists and is not stale. From rjs@rob.sh Thu Jun 7 10:02:44 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A11021F86CA for ; Thu, 7 Jun 2012 10:02:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.392 X-Spam-Level: X-Spam-Status: No, score=-2.392 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sP4xse9Q-bvY for ; Thu, 7 Jun 2012 10:02:44 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2001:b98:201:101::10:cafe]) by ietfa.amsl.com (Postfix) with ESMTP id DFAE021F86A8 for ; Thu, 7 Jun 2012 10:02:36 -0700 (PDT) Received: from [109.144.232.84] (helo=[10.10.1.158]) by cappuccino.rob.sh with esmtpa (Exim 4.72) (envelope-from ) id 1Scg5I-0001Oi-5X; Thu, 07 Jun 2012 18:01:20 +0100 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Rob Shakir In-Reply-To: <4FD0B548.4020501@raszuk.net> Date: Thu, 7 Jun 2012 18:02:32 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <199BAE1F-6081-4ED7-A29B-FD72F0649DB8@rob.sh> References: <4911_1338974288_4FCF2050_4911_12906_1_53C29892C857584299CBF5D05346208A08CA08@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FCF800C.6070509@joelhalpern.com> <4FCF9D04.2080401@joelhalpern.com> <4FD0B548.4020501@raszuk.net> To: robert@raszuk.net X-Mailer: Apple Mail (2.1257) Cc: "idr@ietf.org List" , "Joel M. Halpern" , JAMES UTTARO Subject: Re: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 17:02:44 -0000 On 7 Jun 2012, at 15:06, Robert Raszuk wrote: > Hi Rob, >=20 >> Sometimes this means that there are knobs introduced that are = potentially harmful, however, this shouldn't mean we don't have the = knobs, just that they should be clearly labelled as to their potential = issues, so that an operator can decide whether their particular = deployment requires the functionality. >> As the STALE routes are not dynamically updated anymore, it's >> desirable that they be only used in last resort. Hence when >> comparing paths for a prefix, a non STALE path should be preferred >> over a STALE path. >=20 > The observation I would like to make to the above quote is that while = I think we can go wild with zoo of knobs for local AFI/SAFIs (example = L2VPN or L3VPN) we should be very careful to provide knobs destabilizing = the Internet. Apologies, I should have clarified this in my earlier mail, as such, the = intention of (and discussions within) this mechanism is not to apply to = all AFIs - quoting from the abstract: "This document addresses new services whose requirements for persistence = diverge from the Internet routing point of view." The fact that (a proportion of) L[23]VPN deployments can be considered = in isolation (i.e., for a particular SP's deployments) makes them more = immediate targets for deployment of persistence; there may be = deployments of IPv4 Unicast that exist in the same isolation (i.e., are = explicitly NOT the Internet). For this reason, I do not think that = explicitly forbidding a particular AFI/SAFI is required, but that does = not mean the document should not provide strong wording that guides = against deployment for Internet routing applications. Cheers, r.= From bruno.decraene@orange.com Thu Jun 7 13:38:08 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6434A11E80E9 for ; Thu, 7 Jun 2012 13:38:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.497 X-Spam-Level: X-Spam-Status: No, score=-2.497 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k4Kr+lRkMMcs for ; Thu, 7 Jun 2012 13:38:07 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 8172D11E80AA for ; Thu, 7 Jun 2012 13:38:07 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 2C8732DC558; Thu, 7 Jun 2012 22:38:06 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 105C127C053; Thu, 7 Jun 2012 22:38:06 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Thu, 7 Jun 2012 22:38:05 +0200 From: To: "robert@raszuk.net" Thread-Topic: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR WG document Thread-Index: AQHNRLejoKI+KOmB1EGiK6PimNq0LZbvSYyg Date: Thu, 7 Jun 2012 20:38:05 +0000 Message-ID: <4424_1339101486_4FD1112E_4424_14048_1_53C29892C857584299CBF5D05346208A08D36D@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <4911_1338974288_4FCF2050_4911_12906_1_53C29892C857584299CBF5D05346208A08CA08@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FCF800C.6070509@joelhalpern.com> <4FCF883B.6050501@raszuk.net> <4FCFEC86.6050706@raszuk.net> <507A0451-C11D-4CFB-8EE1-073220B1631E@cisco.com> <25665_1339078106_4FD0B5D9_25665_10218_11_53C29892C857584299CBF5D05346208A08D20D@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FD0B6E9.8080704@raszuk.net> In-Reply-To: <4FD0B6E9.8080704@raszuk.net> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.6.7.154522 Cc: "idr@ietf.org List" , "Joel M. Halpern" , "UTTARO, JAMES" Subject: Re: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 20:38:08 -0000 Hi Robert, >From: Robert Raszuk [mailto:robert@raszuk.net] >Sent: Thursday, June 07, 2012 4:13 PM > >Hi Bruno, > >> Note also that there is no strict mapping between a service and an AFI/S= AFI. >> E.g. to come back to the Internet service you picked: >> - one network could carry Internet routes inside a L3 VPN. > >That's exactly why I am not talking services, but AFI/SAFI limit. You >may do what you like within 1/128. But please do not break 1/1 as I may >transit via ft/orange. You said that in your opinion, persistence should not be used for Internet = inter-domain routing because this would create churn in the Internet.=20 Then you deduct that therefore, persistence must not be specified for AFI/S= AFI 1/1. In short your deduction is: no persistence for internet --> no persistence = for AFI 1/1 Now what I'm saying is: 1) given that some AS may carry Internet (routing & traffic) within a L3 VP= N (1/128), then according to your deduction, persistence should also not be= used for 1/128 (because your Internet traffic may transit across an L3 VPN= AS using persistence). Hence limiting the applicability of persistence for 1/1 would not be enough= to meet your goal. >> - some IP unicast routes may never be advertised in the Internet routing >system. > >not sure how this is relevant to the topic. 2) Disallowing persistence for 1/1 would not allow using persistence for IP= v4 unicast routes which are private only and never advertised in the Intern= et. Hence "no persistence for internet --> no persistence for AFI 1/1 1" would = be too much. Conclusion [(1) + (2)]: I don't think limiting the applicability of persist= ence on a per AFI/SAFI basis is the best way to achieve your goal. Best, Bruno > >Best, >R. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From bruno.decraene@orange.com Thu Jun 7 13:50:51 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9B6A21F861E for ; Thu, 7 Jun 2012 13:50:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.05 X-Spam-Level: X-Spam-Status: No, score=-2.05 tagged_above=-999 required=5 tests=[AWL=-0.367, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, SARE_MILLIONSOF=0.315, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qyF6PTPpOv5p for ; Thu, 7 Jun 2012 13:50:51 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 00D4B21F8618 for ; Thu, 7 Jun 2012 13:50:48 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id BCC5E22C392; Thu, 7 Jun 2012 22:50:46 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 9FC28238048; Thu, 7 Jun 2012 22:50:46 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Thu, 7 Jun 2012 22:50:46 +0200 From: To: "robert@raszuk.net" Thread-Topic: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR WG document Thread-Index: AQHNRD8I+BWnMnqpf06vUjWpjqYL8JbvU36A Date: Thu, 7 Jun 2012 20:50:45 +0000 Message-ID: <8684_1339102246_4FD11426_8684_17472_1_53C29892C857584299CBF5D05346208A08D397@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <4911_1338974288_4FCF2050_4911_12906_1_53C29892C857584299CBF5D05346208A08CA08@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FCF800C.6070509@joelhalpern.com> <4FCF883B.6050501@raszuk.net> <4FCFEC86.6050706@raszuk.net> In-Reply-To: <4FCFEC86.6050706@raszuk.net> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.6.7.154522 Cc: "idr@ietf.org List" , "Joel M. Halpern" , "UTTARO, JAMES" Subject: Re: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 20:50:51 -0000 Robert, >From: Robert Raszuk >Sent: Thursday, June 07, 2012 1:49 AM > >Jim, > >Adding more use cases is clearly good thing. > >But I was in particular asking for a stronger text explicitly forbidding >implementation to make IPv4 or IPv6 routes as persistent. > >For 1/4, 1/128 or any other "application" SAFIs I think that at the end >you may do what you like :) > >Today Internet churn is already not low ... this draft if used >incorrectly for Internet can cause additional re-advertisements based on >local flaps (where GR you are keep comparing it with would not). You are assuming that persistence is meant to replace GR. But this is _not_ the case. Cf: - Slide 4 of latest IDR meeting http://tools.ietf.org/agenda/83/slides/slid= es-83-idr-7.pdf - draft section 7 http://tools.ietf.org/html/draft-uttaro-idr-bgp-persisten= ce-01#section-7 In short: persistence and GR address largely independent use cases and can = be enabled independently. Hence in your case, if GR is used (to locally recover from a short duration= failure in the control plane only), the addition of persistence does not c= hange this (the same failure will also be locally concealed by GR). Best regards, Bruno >And just as a reference point on old NPE400 I peered with the AS290 >yesterday here in Tokyo interop I get 60%-70% CPU use all the time > >CE_c72_Internet#sh proc cpu >CPU utilization for five seconds: 99%/23%; one minute: 67%; five >minutes: 83% >.... > 103 26649044 209857 126987 62.32% 41.94% 56.76% 0 BGP Router > >So while any knob may look nice on the paper it does have an impact >Internet wide and that's main reason I am a bit skeptical on adding more >to SAFI 1/1 and 2/1. > >In general I think we are really missing the indirection in signalling >SAFI wide parameters in BGP. Perhaps if WG thinks this would be good >idea we could propose a simple new draft for defining a new signalling >SAFI for all other SAFI wide events. > >That way in the event of use of persistent communities or shutdown on >existing SAFIs single message could be send not re-advertisements of >millions of routes. And that significance will only grow when you >attempt to do path validation or other fancy processing inbound of each >advertisement. > >I know you can apply persistence to subset of prefixes however I doubt >that this would be practical deployment case. Clearly for shutdown it >does not make much sense to only signal subset of marked routes in a >given SAFI that are going down soon. > >Best regards, >R. > > > >> Robert >> >> We can add addl use cases.. I have this on my to do list.. I believe >> the 3107 use case is high on the list, BGP signaled multicast may be >> another, BRAS etc... We could have a long list here and I do not want >> to be prescriptive so I will add the 3107 use case >> >> Jim Uttaro >> >> -----Original Message----- From: idr-bounces@ietf.org >> [mailto:idr-bounces@ietf.org] On Behalf Of Robert Raszuk Sent: >> Wednesday, June 06, 2012 12:42 PM To: Joel M. Halpern Cc: >> idr@ietf.org List Subject: Re: [Idr] Adoption of >> draft-uttaro-idr-bgp-persistence-01 as IDR WG document >> >> Hi Joel, >> >> Great comment. In fact some of the co-authors of this document target >> to use it in also in the SAFI 1/1 or 2/1 even so the draft softly >> target a bit different application space: >> >> "This document addresses new services whose requirements for >> persistence diverge from the Internet routing point of view." >> >> With this in mind how about either explicitly enumerating those >> AFI/SAFIs which can use such knob or specify those AFI/SAFIs which >> MUST NOT support it ? >> >> Of course this is assuming we will go with accepting this as WG doc >> in the first place :) >> >> Best regards, R. >> >> >>> The question for adopting this seems to be whether the folks who >>> have to turn it on can tell when it is safe to do so, and when it >>> isn't. The L2VPN example in the document is an example of why it is >>> worth considering. The L3VPN example seems to show a dangerous use >>> case. >>> >>> Yours, Joel M. Halpern >>> >>> On 6/6/2012 5:18 AM, bruno.decraene@orange.com wrote: >>>> Hi, >>>> >>>> Support. >>>> >>>> Regards, Bruno >>>> >>>>> From: John Scudder>Sent: Thursday, May 31, 2012 7:10 PM >>>>> >>>>> Folks, >>>>> >>>>> We have received a request from the authors to adopt >>>>> draft-uttaro-idr-bgp- persistence-01 as an IDR WG document. >>>>> Please send your comments to the list. The deadline for >>>>> comments is June 15, 2012 at noon EDT. >>>>> >>>>> Thanks, >>>>> >>>>> --John _______________________________________________ Idr >>>>> mailing list Idr@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/idr >>>> >>>> >__________________________________________________________________________= _____ >__________________________________________ >>>> >>>> >>>> >>>> >Ce message et ses pieces jointes peuvent contenir des informations >>>> confidentielles ou privilegiees et ne doivent donc pas etre >>>> diffuses, exploites ou copies sans autorisation. Si vous avez >>>> recu ce message par erreur, veuillez le signaler a l'expediteur >>>> et le detruire ainsi que les pieces jointes. Les messages >>>> electroniques etant susceptibles d'alteration, France Telecom - >>>> Orange decline toute responsabilite si ce message a ete altere, >>>> deforme ou falsifie. Merci. >>>> >>>> This message and its attachments may contain confidential or >>>> privileged information that may be protected by law; they should >>>> not be distributed, used or copied without authorisation. If you >>>> have received this email in error, please notify the sender and >>>> delete this message and its attachments. As emails may be >>>> altered, France Telecom - Orange is not liable for messages that >>>> have been modified, changed or falsified. Thank you. >>>> >>>> _______________________________________________ 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 >>> >>> >> >> >> _______________________________________________ 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 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From internet-drafts@ietf.org Thu Jun 7 14:21:46 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA74821F86D6; Thu, 7 Jun 2012 14:21:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.528 X-Spam-Level: X-Spam-Status: No, score=-102.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PmOBqo0IXTzy; Thu, 7 Jun 2012 14:21:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 290F021F8592; Thu, 7 Jun 2012 14:21:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120607212146.9568.33240.idtracker@ietfa.amsl.com> Date: Thu, 07 Jun 2012 14:21:46 -0700 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-enhanced-gr-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 21:21:46 -0000 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 : Accelerated Routing Convergence for BGP Graceful Restart Author(s) : Keyur Patel Enke Chen Rex Fernando John Scudder Filename : draft-ietf-idr-enhanced-gr-01.txt Pages : 9 Date : 2012-06-07 In this document we specify extensions to BGP graceful restart in order to avoid unnecessary transmission of the routing information preserved across a session restart, thus accelerating the routing convergence. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-enhanced-gr-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-idr-enhanced-gr-01.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-enhanced-gr/ From russw@riw.us Thu Jun 7 16:43:52 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91FE911E80F1 for ; Thu, 7 Jun 2012 16:43:52 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LjBUr0LserJw for ; Thu, 7 Jun 2012 16:43:52 -0700 (PDT) Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id 2CFAC11E809A for ; Thu, 7 Jun 2012 16:43:52 -0700 (PDT) Received: from rrcs-24-199-145-66.midsouth.biz.rr.com ([24.199.145.66] helo=[192.168.3.115]) by da31.namelessnet.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1ScmMp-00052q-GF for idr@ietf.org; Thu, 07 Jun 2012 16:43:51 -0700 Message-ID: <4FD13CBD.50709@riw.us> Date: Thu, 07 Jun 2012 19:43:57 -0400 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: idr@ietf.org References: <4911_1338974288_4FCF2050_4911_12906_1_53C29892C857584299CBF5D05346208A08CA08@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FCF800C.6070509@joelhalpern.com> <4FCF883B.6050501@raszuk.net> In-Reply-To: <4FCF883B.6050501@raszuk.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Antivirus-Scanner: Seems clean. You should still use an Antivirus Scanner Subject: Re: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 23:43:52 -0000 I support, with these two things in mind: > With this in mind how about either explicitly enumerating those > AFI/SAFIs which can use such knob or specify those AFI/SAFIs which MUST > NOT support it ? > I prefer to have a section that articulates the risks and provides design guidelines, as per Joel's suggestion. That would be a better technical specification than making a table of AFI/SAFI applicability. We should make certain these get included in the final doc before it passes to last call. Russ -- <>< riwhite@verisign.com russw@riw.us From robert@raszuk.net Fri Jun 8 04:29:10 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75F8A21F8786 for ; Fri, 8 Jun 2012 04:29:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[AWL=-0.306, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fgBSBApHHAuw for ; Fri, 8 Jun 2012 04:29:09 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 49D9521F86D0 for ; Fri, 8 Jun 2012 04:29:09 -0700 (PDT) Received: (qmail 23250 invoked by uid 399); 8 Jun 2012 11:29:08 -0000 Received: from unknown (HELO ?172.16.197.148?) (pbs:robert@raszuk.net@58.80.213.53) by mail1310.opentransfer.com with ESMTPM; 8 Jun 2012 11:29:08 -0000 X-Originating-IP: 58.80.213.53 Message-ID: <4FD1E202.6090503@raszuk.net> Date: Fri, 08 Jun 2012 04:29:06 -0700 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120604 Thunderbird/13.0 MIME-Version: 1.0 To: bruno.decraene@orange.com References: <4911_1338974288_4FCF2050_4911_12906_1_53C29892C857584299CBF5D05346208A08CA08@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FCF800C.6070509@joelhalpern.com> <4FCF883B.6050501@raszuk.net> <4FCFEC86.6050706@raszuk.net> <8684_1339102246_4FD11426_8684_17472_1_53C29892C857584299CBF5D05346208A08D397@PEXCVZYM11.corporate.adroot.infra.ftgroup> In-Reply-To: <8684_1339102246_4FD11426_8684_17472_1_53C29892C857584299CBF5D05346208A08D397@PEXCVZYM11.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org List" , "Joel M. Halpern" , "UTTARO, JAMES" Subject: Re: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 11:29:10 -0000 Bruno, I think you have misunderstood my comment. I am not assuming persistence to replace GR. I am observing that re-advertsing all routes with STALE community when GR is enabled _immediately_ when the EBGP session goes down is a bad idea. I am recommending to give GR and BGP session a chance to restart per GR spec. Then after the GR timer expires your persistence state machine could kick in. Example: t0 - session goes down t1 - you start the best path run to look for alternative valid path t2 - you start re-advertsing full table again (either new best path or for single best paths you attache STALE community) t3 - session comes up Note that session may be reestablish much sooner then you manage to propagate full table to all your peers. The way the draft is written you have just caused a completely unnecessary churn. Note also that the next hop is still valid and reachable for all the paths. So I would in fact not treat both as completely independent. I can see how they could be complementary and work together in concert. Best, R. > Robert, > >> From: Robert Raszuk >> Sent: Thursday, June 07, 2012 1:49 AM >> >> Jim, >> >> Adding more use cases is clearly good thing. >> >> But I was in particular asking for a stronger text explicitly forbidding >> implementation to make IPv4 or IPv6 routes as persistent. >> >> For 1/4, 1/128 or any other "application" SAFIs I think that at the end >> you may do what you like :) >> >> Today Internet churn is already not low ... this draft if used >> incorrectly for Internet can cause additional re-advertisements based on >> local flaps (where GR you are keep comparing it with would not). > > You are assuming that persistence is meant to replace GR. > But this is _not_ the case. > Cf: > - Slide 4 of latest IDR meeting http://tools.ietf.org/agenda/83/slides/slides-83-idr-7.pdf > - draft section 7 http://tools.ietf.org/html/draft-uttaro-idr-bgp-persistence-01#section-7 > > In short: persistence and GR address largely independent use cases and can be enabled independently. > > Hence in your case, if GR is used (to locally recover from a short duration failure in the control plane only), the addition of persistence does not change this (the same failure will also be locally concealed by GR). > > Best regards, > Bruno > >> And just as a reference point on old NPE400 I peered with the AS290 >> yesterday here in Tokyo interop I get 60%-70% CPU use all the time >> >> CE_c72_Internet#sh proc cpu >> CPU utilization for five seconds: 99%/23%; one minute: 67%; five >> minutes: 83% >> .... >> 103 26649044 209857 126987 62.32% 41.94% 56.76% 0 BGP Router >> >> So while any knob may look nice on the paper it does have an impact >> Internet wide and that's main reason I am a bit skeptical on adding more >> to SAFI 1/1 and 2/1. >> >> In general I think we are really missing the indirection in signalling >> SAFI wide parameters in BGP. Perhaps if WG thinks this would be good >> idea we could propose a simple new draft for defining a new signalling >> SAFI for all other SAFI wide events. >> >> That way in the event of use of persistent communities or shutdown on >> existing SAFIs single message could be send not re-advertisements of >> millions of routes. And that significance will only grow when you >> attempt to do path validation or other fancy processing inbound of each >> advertisement. >> >> I know you can apply persistence to subset of prefixes however I doubt >> that this would be practical deployment case. Clearly for shutdown it >> does not make much sense to only signal subset of marked routes in a >> given SAFI that are going down soon. >> >> Best regards, >> R. >> >> >> >>> Robert >>> >>> We can add addl use cases.. I have this on my to do list.. I believe >>> the 3107 use case is high on the list, BGP signaled multicast may be >>> another, BRAS etc... We could have a long list here and I do not want >>> to be prescriptive so I will add the 3107 use case >>> >>> Jim Uttaro >>> >>> -----Original Message----- From: idr-bounces@ietf.org >>> [mailto:idr-bounces@ietf.org] On Behalf Of Robert Raszuk Sent: >>> Wednesday, June 06, 2012 12:42 PM To: Joel M. Halpern Cc: >>> idr@ietf.org List Subject: Re: [Idr] Adoption of >>> draft-uttaro-idr-bgp-persistence-01 as IDR WG document >>> >>> Hi Joel, >>> >>> Great comment. In fact some of the co-authors of this document target >>> to use it in also in the SAFI 1/1 or 2/1 even so the draft softly >>> target a bit different application space: >>> >>> "This document addresses new services whose requirements for >>> persistence diverge from the Internet routing point of view." >>> >>> With this in mind how about either explicitly enumerating those >>> AFI/SAFIs which can use such knob or specify those AFI/SAFIs which >>> MUST NOT support it ? >>> >>> Of course this is assuming we will go with accepting this as WG doc >>> in the first place :) >>> >>> Best regards, R. >>> >>> >>>> The question for adopting this seems to be whether the folks who >>>> have to turn it on can tell when it is safe to do so, and when it >>>> isn't. The L2VPN example in the document is an example of why it is >>>> worth considering. The L3VPN example seems to show a dangerous use >>>> case. >>>> >>>> Yours, Joel M. Halpern >>>> >>>> On 6/6/2012 5:18 AM, bruno.decraene@orange.com wrote: >>>>> Hi, >>>>> >>>>> Support. >>>>> >>>>> Regards, Bruno >>>>> >>>>>> From: John Scudder>Sent: Thursday, May 31, 2012 7:10 PM >>>>>> >>>>>> Folks, >>>>>> >>>>>> We have received a request from the authors to adopt >>>>>> draft-uttaro-idr-bgp- persistence-01 as an IDR WG document. >>>>>> Please send your comments to the list. The deadline for >>>>>> comments is June 15, 2012 at noon EDT. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> --John _______________________________________________ Idr >>>>>> mailing list Idr@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/idr >>>>> >>>>> >> _______________________________________________________________________________ >> __________________________________________ >>>>> >>>>> >>>>> >>>>> >> Ce message et ses pieces jointes peuvent contenir des informations >>>>> confidentielles ou privilegiees et ne doivent donc pas etre >>>>> diffuses, exploites ou copies sans autorisation. Si vous avez >>>>> recu ce message par erreur, veuillez le signaler a l'expediteur >>>>> et le detruire ainsi que les pieces jointes. Les messages >>>>> electroniques etant susceptibles d'alteration, France Telecom - >>>>> Orange decline toute responsabilite si ce message a ete altere, >>>>> deforme ou falsifie. Merci. >>>>> >>>>> This message and its attachments may contain confidential or >>>>> privileged information that may be protected by law; they should >>>>> not be distributed, used or copied without authorisation. If you >>>>> have received this email in error, please notify the sender and >>>>> delete this message and its attachments. As emails may be >>>>> altered, France Telecom - Orange is not liable for messages that >>>>> have been modified, changed or falsified. Thank you. >>>>> >>>>> _______________________________________________ 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 >>>> >>>> >>> >>> >>> _______________________________________________ Idr mailing list >>> Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From bruno.decraene@orange.com Fri Jun 8 07:12:24 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59A5A21F893A for ; Fri, 8 Jun 2012 07:12:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.014 X-Spam-Level: X-Spam-Status: No, score=-2.014 tagged_above=-999 required=5 tests=[AWL=-0.331, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, SARE_MILLIONSOF=0.315, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a0RLytLJ9ao2 for ; Fri, 8 Jun 2012 07:12:23 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id DB65021F892A for ; Fri, 8 Jun 2012 07:12:22 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id A53E22DC26B; Fri, 8 Jun 2012 16:12:21 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 177774C071; Fri, 8 Jun 2012 16:12:21 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Fri, 8 Jun 2012 16:12:20 +0200 From: To: "robert@raszuk.net" Thread-Topic: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR WG document Thread-Index: AQHNRWnp+BWnMnqpf06vUjWpjqYL8JbwcwbQ Date: Fri, 8 Jun 2012 14:12:20 +0000 Message-ID: <1407_1339164741_4FD20845_1407_271_1_53C29892C857584299CBF5D05346208A08E913@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <4911_1338974288_4FCF2050_4911_12906_1_53C29892C857584299CBF5D05346208A08CA08@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FCF800C.6070509@joelhalpern.com> <4FCF883B.6050501@raszuk.net> <4FCFEC86.6050706@raszuk.net> <8684_1339102246_4FD11426_8684_17472_1_53C29892C857584299CBF5D05346208A08D397@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FD1E202.6090503@raszuk.net> In-Reply-To: <4FD1E202.6090503@raszuk.net> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.3] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.5.24.112414 Cc: "idr@ietf.org List" , "Joel M. Halpern" , "UTTARO, JAMES" Subject: Re: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 14:12:24 -0000 Um9iZXJ0LA0KDQo+QnJ1bm8sDQo+DQo+SSB0aGluayB5b3UgaGF2ZSBtaXN1bmRlcnN0b29kIG15 IGNvbW1lbnQuDQo+DQo+SSBhbSBub3QgYXNzdW1pbmcgcGVyc2lzdGVuY2UgdG8gcmVwbGFjZSBH Ui4NCj4NCj5JIGFtIG9ic2VydmluZyB0aGF0IHJlLWFkdmVydHNpbmcgYWxsIHJvdXRlcyB3aXRo IFNUQUxFIGNvbW11bml0eSB3aGVuDQo+R1IgaXMgZW5hYmxlZCBfaW1tZWRpYXRlbHlfIHdoZW4g dGhlIEVCR1Agc2Vzc2lvbiBnb2VzIGRvd24gaXMgYSBiYWQgaWRlYS4NCj4NCj5JIGFtIHJlY29t bWVuZGluZyB0byBnaXZlIEdSIGFuZCBCR1Agc2Vzc2lvbiBhIGNoYW5jZSB0byByZXN0YXJ0IHBl ciBHUg0KPnNwZWMuIFRoZW4gYWZ0ZXIgdGhlIEdSIHRpbWVyIGV4cGlyZXMgeW91ciBwZXJzaXN0 ZW5jZSBzdGF0ZSBtYWNoaW5lDQo+Y291bGQga2ljayBpbi4NCg0KSSBhZ3JlZSB3aXRoIHlvdXIg cmVjb21tZW5kYXRpb24uIEFjdHVhbGx5IHRoYXQncyB3aGF0IHRoZSBjdXJyZW50IHZlcnNpb24g b2YgdGhlIGRyYWZ0IHByb3Bvc2VzOg0KDQotIENmIMKnNy4gIkludGVyYWN0aW9ucyBiZXR3ZWVu IEdSIGFuZCBQZXJzaXN0ZW5jZSIgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC11 dHRhcm8taWRyLWJncC1wZXJzaXN0ZW5jZS0wMSNzZWN0aW9uLTcNCi0gT3IgY2Ygc2xpZGUgNSBv ZiB0aGUgc2xpZGVzIHByZXNlbnRlZCBpbiBQYXJpcyB3aGljaCBzYXlzOg0KIgktIFBlcnNpc3Rl bmNlIGFuZCBHUiBjYW4gYmUgZW5hYmxlZCBpbmRlcGVuZGVudGx5DQoJLSBJZiBib3RoIGFyZSBl bmFibGVkIG9uIGEgQkdQIHNlc3Npb24sIHRoZSBwcmluY2lwbGUgaXMgdG8gc3RhcnQgZmlyc3Qg d2l0aCBHcmFjZWZ1bCBSZXN0YXJ0DQoJCWEuIElmIEdSIHJlY292ZXJzIC0tPiBHUiBlbmRzLCBi YWNrIHRvIG5vcm1hbCBCR1AgLS0+IFBlcnNpc3RlbmNlIG5ldmVyIHVzZWQNCgkJYi4gZWxzZSAo R1IgZmFpbHMpIC0tPiBQZXJzaXN0ZW5jZSBzdGFydHMiDQoNCg0KDQo+RXhhbXBsZToNCj4NCj50 MCAtIHNlc3Npb24gZ29lcyBkb3duDQo+dDEgLSB5b3Ugc3RhcnQgdGhlIGJlc3QgcGF0aCBydW4g dG8gbG9vayBmb3IgYWx0ZXJuYXRpdmUgdmFsaWQgcGF0aA0KPnQyIC0geW91IHN0YXJ0IHJlLWFk dmVydHNpbmcgZnVsbCB0YWJsZSBhZ2FpbiAoZWl0aGVyIG5ldyBiZXN0IHBhdGggb3INCj5mb3Ig c2luZ2xlIGJlc3QgcGF0aHMgeW91IGF0dGFjaGUgU1RBTEUgY29tbXVuaXR5KQ0KPnQzIC0gc2Vz c2lvbiBjb21lcyB1cA0KPg0KPk5vdGUgdGhhdCBzZXNzaW9uIG1heSBiZSByZWVzdGFibGlzaCBt dWNoIHNvb25lciB0aGVuIHlvdSBtYW5hZ2UgdG8NCj5wcm9wYWdhdGUgZnVsbCB0YWJsZSB0byBh bGwgeW91ciBwZWVycy4NCj4NCj5UaGUgd2F5IHRoZSBkcmFmdCBpcyB3cml0dGVuIHlvdSBoYXZl IGp1c3QgY2F1c2VkIGEgY29tcGxldGVseQ0KPnVubmVjZXNzYXJ5IGNodXJuLiBOb3RlIGFsc28g dGhhdCB0aGUgbmV4dCBob3AgaXMgc3RpbGwgdmFsaWQgYW5kDQo+cmVhY2hhYmxlIGZvciBhbGwg dGhlIHBhdGhzLg0KPg0KPlNvIEkgd291bGQgaW4gZmFjdCBub3QgdHJlYXQgYm90aCBhcyBjb21w bGV0ZWx5IGluZGVwZW5kZW50LiBJIGNhbiBzZWUNCj5ob3cgdGhleSBjb3VsZCBiZSBjb21wbGVt ZW50YXJ5IGFuZCB3b3JrIHRvZ2V0aGVyIGluIGNvbmNlcnQuDQoNCkdyZWF0LiBJIGFncmVlIHdp dGggeW91OiB0aGF0J3Mgcm91Z2hseSB0aGUgdGl0bGUgb2Ygc2xpZGUgNDogIlBlcnNpc3RlbmNl ICYgR3JhY2VmdWwgUmVzdGFydDogY29tcGxlbWVudGFyeSB1c2UgY2FzZXMuIg0KDQpCZXN0IHJl Z2FyZHMsDQpCcnVubw0KPg0KPkJlc3QsDQo+Ui4NCj4NCj4NCj4+IFJvYmVydCwNCj4+DQo+Pj4g RnJvbTogUm9iZXJ0IFJhc3p1aw0KPj4+IFNlbnQ6IFRodXJzZGF5LCBKdW5lIDA3LCAyMDEyIDE6 NDkgQU0NCj4+Pg0KPj4+IEppbSwNCj4+Pg0KPj4+IEFkZGluZyBtb3JlIHVzZSBjYXNlcyBpcyBj bGVhcmx5IGdvb2QgdGhpbmcuDQo+Pj4NCj4+PiBCdXQgSSB3YXMgaW4gcGFydGljdWxhciBhc2tp bmcgZm9yIGEgc3Ryb25nZXIgdGV4dCBleHBsaWNpdGx5IGZvcmJpZGRpbmcNCj4+PiBpbXBsZW1l bnRhdGlvbiB0byBtYWtlIElQdjQgb3IgSVB2NiByb3V0ZXMgYXMgcGVyc2lzdGVudC4NCj4+Pg0K Pj4+IEZvciAxLzQsIDEvMTI4IG9yIGFueSBvdGhlciAiYXBwbGljYXRpb24iIFNBRklzIEkgdGhp bmsgdGhhdCBhdCB0aGUgZW5kDQo+Pj4geW91IG1heSBkbyB3aGF0IHlvdSBsaWtlIDopDQo+Pj4N Cj4+PiBUb2RheSBJbnRlcm5ldCBjaHVybiBpcyBhbHJlYWR5IG5vdCBsb3cgLi4uIHRoaXMgZHJh ZnQgaWYgdXNlZA0KPj4+IGluY29ycmVjdGx5IGZvciBJbnRlcm5ldCBjYW4gY2F1c2UgYWRkaXRp b25hbCByZS1hZHZlcnRpc2VtZW50cyBiYXNlZCBvbg0KPj4+IGxvY2FsIGZsYXBzICh3aGVyZSBH UiB5b3UgYXJlIGtlZXAgY29tcGFyaW5nIGl0IHdpdGggd291bGQgbm90KS4NCj4+DQo+PiBZb3Ug YXJlIGFzc3VtaW5nIHRoYXQgcGVyc2lzdGVuY2UgaXMgbWVhbnQgdG8gcmVwbGFjZSBHUi4NCj4+ IEJ1dCB0aGlzIGlzIF9ub3RfIHRoZSBjYXNlLg0KPj4gQ2Y6DQo+PiAtIFNsaWRlIDQgb2YgbGF0 ZXN0IElEUiBtZWV0aW5nDQo+aHR0cDovL3Rvb2xzLmlldGYub3JnL2FnZW5kYS84My9zbGlkZXMv c2xpZGVzLTgzLWlkci03LnBkZg0KPj4gLSBkcmFmdCBzZWN0aW9uIDcgaHR0cDovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtdXR0YXJvLWlkci1iZ3AtDQo+cGVyc2lzdGVuY2UtMDEjc2VjdGlv bi03DQo+Pg0KPj4gSW4gc2hvcnQ6IHBlcnNpc3RlbmNlIGFuZCBHUiBhZGRyZXNzIGxhcmdlbHkg aW5kZXBlbmRlbnQgdXNlIGNhc2VzIGFuZCBjYW4gYmUNCj5lbmFibGVkIGluZGVwZW5kZW50bHku DQo+Pg0KPj4gSGVuY2UgaW4geW91ciBjYXNlLCBpZiBHUiBpcyB1c2VkICh0byBsb2NhbGx5IHJl Y292ZXIgZnJvbSBhIHNob3J0IGR1cmF0aW9uDQo+ZmFpbHVyZSBpbiB0aGUgY29udHJvbCBwbGFu ZSBvbmx5KSwgdGhlIGFkZGl0aW9uIG9mIHBlcnNpc3RlbmNlIGRvZXMgbm90IGNoYW5nZQ0KPnRo aXMgKHRoZSBzYW1lIGZhaWx1cmUgd2lsbCBhbHNvIGJlIGxvY2FsbHkgY29uY2VhbGVkIGJ5IEdS KS4NCj4+DQo+PiBCZXN0IHJlZ2FyZHMsDQo+PiBCcnVubw0KPj4NCj4+PiBBbmQganVzdCBhcyBh IHJlZmVyZW5jZSBwb2ludCBvbiBvbGQgTlBFNDAwIEkgcGVlcmVkIHdpdGggdGhlIEFTMjkwDQo+ Pj4geWVzdGVyZGF5IGhlcmUgaW4gVG9reW8gaW50ZXJvcCBJIGdldCA2MCUtNzAlIENQVSB1c2Ug YWxsIHRoZSB0aW1lDQo+Pj4NCj4+PiBDRV9jNzJfSW50ZXJuZXQjc2ggcHJvYyBjcHUNCj4+PiBD UFUgdXRpbGl6YXRpb24gZm9yIGZpdmUgc2Vjb25kczogOTklLzIzJTsgb25lIG1pbnV0ZTogNjcl OyBmaXZlDQo+Pj4gbWludXRlczogODMlDQo+Pj4gLi4uLg0KPj4+ICAgMTAzICAgIDI2NjQ5MDQ0 ICAgIDIwOTg1NyAgICAgMTI2OTg3IDYyLjMyJSA0MS45NCUgNTYuNzYlICAgMCBCR1AgUm91dGVy DQo+Pj4NCj4+PiBTbyB3aGlsZSBhbnkga25vYiBtYXkgbG9vayBuaWNlIG9uIHRoZSBwYXBlciBp dCBkb2VzIGhhdmUgYW4gaW1wYWN0DQo+Pj4gSW50ZXJuZXQgd2lkZSBhbmQgdGhhdCdzIG1haW4g cmVhc29uIEkgYW0gYSBiaXQgc2tlcHRpY2FsIG9uIGFkZGluZyBtb3JlDQo+Pj4gdG8gU0FGSSAx LzEgYW5kIDIvMS4NCj4+Pg0KPj4+IEluIGdlbmVyYWwgSSB0aGluayB3ZSBhcmUgcmVhbGx5IG1p c3NpbmcgdGhlIGluZGlyZWN0aW9uIGluIHNpZ25hbGxpbmcNCj4+PiBTQUZJIHdpZGUgcGFyYW1l dGVycyBpbiBCR1AuIFBlcmhhcHMgaWYgV0cgdGhpbmtzIHRoaXMgd291bGQgYmUgZ29vZA0KPj4+ IGlkZWEgd2UgY291bGQgcHJvcG9zZSBhIHNpbXBsZSBuZXcgZHJhZnQgZm9yIGRlZmluaW5nIGEg bmV3IHNpZ25hbGxpbmcNCj4+PiBTQUZJIGZvciBhbGwgb3RoZXIgU0FGSSB3aWRlIGV2ZW50cy4N Cj4+Pg0KPj4+IFRoYXQgd2F5IGluIHRoZSBldmVudCBvZiB1c2Ugb2YgcGVyc2lzdGVudCBjb21t dW5pdGllcyBvciBzaHV0ZG93biBvbg0KPj4+IGV4aXN0aW5nIFNBRklzIHNpbmdsZSBtZXNzYWdl IGNvdWxkIGJlIHNlbmQgbm90IHJlLWFkdmVydGlzZW1lbnRzIG9mDQo+Pj4gbWlsbGlvbnMgb2Yg cm91dGVzLiBBbmQgdGhhdCBzaWduaWZpY2FuY2Ugd2lsbCBvbmx5IGdyb3cgd2hlbiB5b3UNCj4+ PiBhdHRlbXB0IHRvIGRvIHBhdGggdmFsaWRhdGlvbiBvciBvdGhlciBmYW5jeSBwcm9jZXNzaW5n IGluYm91bmQgb2YgZWFjaA0KPj4+IGFkdmVydGlzZW1lbnQuDQo+Pj4NCj4+PiBJIGtub3cgeW91 IGNhbiBhcHBseSBwZXJzaXN0ZW5jZSB0byBzdWJzZXQgb2YgcHJlZml4ZXMgaG93ZXZlciBJIGRv dWJ0DQo+Pj4gdGhhdCB0aGlzIHdvdWxkIGJlIHByYWN0aWNhbCBkZXBsb3ltZW50IGNhc2UuIENs ZWFybHkgZm9yIHNodXRkb3duIGl0DQo+Pj4gZG9lcyBub3QgbWFrZSBtdWNoIHNlbnNlIHRvIG9u bHkgc2lnbmFsIHN1YnNldCBvZiBtYXJrZWQgcm91dGVzIGluIGENCj4+PiBnaXZlbiBTQUZJIHRo YXQgYXJlIGdvaW5nIGRvd24gc29vbi4NCj4+Pg0KPj4+IEJlc3QgcmVnYXJkcywNCj4+PiBSLg0K Pj4+DQo+Pj4NCj4+Pg0KPj4+PiBSb2JlcnQNCj4+Pj4NCj4+Pj4gV2UgY2FuIGFkZCBhZGRsIHVz ZSBjYXNlcy4uIEkgaGF2ZSB0aGlzIG9uIG15IHRvIGRvIGxpc3QuLiBJIGJlbGlldmUNCj4+Pj4g dGhlIDMxMDcgdXNlIGNhc2UgaXMgaGlnaCBvbiB0aGUgbGlzdCwgQkdQIHNpZ25hbGVkIG11bHRp Y2FzdCBtYXkgYmUNCj4+Pj4gYW5vdGhlciwgQlJBUyBldGMuLi4gV2UgY291bGQgaGF2ZSBhIGxv bmcgbGlzdCBoZXJlIGFuZCBJIGRvIG5vdCB3YW50DQo+Pj4+IHRvIGJlIHByZXNjcmlwdGl2ZSBz byBJIHdpbGwgYWRkIHRoZSAzMTA3IHVzZSBjYXNlDQo+Pj4+DQo+Pj4+IEppbSBVdHRhcm8NCj4+ Pj4NCj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0gRnJvbTogaWRyLWJvdW5jZXNAaWV0 Zi5vcmcNCj4+Pj4gW21haWx0bzppZHItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFJv YmVydCBSYXN6dWsgU2VudDoNCj4+Pj4gV2VkbmVzZGF5LCBKdW5lIDA2LCAyMDEyIDEyOjQyIFBN IFRvOiBKb2VsIE0uIEhhbHBlcm4gQ2M6DQo+Pj4+IGlkckBpZXRmLm9yZyBMaXN0IFN1YmplY3Q6 IFJlOiBbSWRyXSBBZG9wdGlvbiBvZg0KPj4+PiBkcmFmdC11dHRhcm8taWRyLWJncC1wZXJzaXN0 ZW5jZS0wMSBhcyBJRFIgV0cgZG9jdW1lbnQNCj4+Pj4NCj4+Pj4gSGkgSm9lbCwNCj4+Pj4NCj4+ Pj4gR3JlYXQgY29tbWVudC4gSW4gZmFjdCBzb21lIG9mIHRoZSBjby1hdXRob3JzIG9mIHRoaXMg ZG9jdW1lbnQgdGFyZ2V0DQo+Pj4+IHRvIHVzZSBpdCBpbiBhbHNvIGluIHRoZSBTQUZJIDEvMSBv ciAyLzEgZXZlbiBzbyB0aGUgZHJhZnQgc29mdGx5DQo+Pj4+IHRhcmdldCBhIGJpdCBkaWZmZXJl bnQgYXBwbGljYXRpb24gc3BhY2U6DQo+Pj4+DQo+Pj4+ICJUaGlzIGRvY3VtZW50IGFkZHJlc3Nl cyBuZXcgc2VydmljZXMgd2hvc2UgcmVxdWlyZW1lbnRzIGZvcg0KPj4+PiBwZXJzaXN0ZW5jZSBk aXZlcmdlIGZyb20gdGhlIEludGVybmV0IHJvdXRpbmcgcG9pbnQgb2Ygdmlldy4iDQo+Pj4+DQo+ Pj4+IFdpdGggdGhpcyBpbiBtaW5kIGhvdyBhYm91dCBlaXRoZXIgZXhwbGljaXRseSBlbnVtZXJh dGluZyB0aG9zZQ0KPj4+PiBBRkkvU0FGSXMgd2hpY2ggY2FuIHVzZSBzdWNoIGtub2Igb3Igc3Bl Y2lmeSB0aG9zZSBBRkkvU0FGSXMgd2hpY2gNCj4+Pj4gTVVTVCBOT1Qgc3VwcG9ydCBpdCA/DQo+ Pj4+DQo+Pj4+IE9mIGNvdXJzZSB0aGlzIGlzIGFzc3VtaW5nIHdlIHdpbGwgZ28gd2l0aCBhY2Nl cHRpbmcgdGhpcyBhcyBXRyBkb2MNCj4+Pj4gaW4gdGhlIGZpcnN0IHBsYWNlIDopDQo+Pj4+DQo+ Pj4+IEJlc3QgcmVnYXJkcywgUi4NCj4+Pj4NCj4+Pj4NCj4+Pj4+IFRoZSBxdWVzdGlvbiBmb3Ig YWRvcHRpbmcgdGhpcyBzZWVtcyB0byBiZSB3aGV0aGVyIHRoZSBmb2xrcyB3aG8NCj4+Pj4+IGhh dmUgdG8gdHVybiBpdCBvbiBjYW4gdGVsbCB3aGVuIGl0IGlzIHNhZmUgdG8gZG8gc28sIGFuZCB3 aGVuIGl0DQo+Pj4+PiBpc24ndC4gVGhlIEwyVlBOIGV4YW1wbGUgaW4gdGhlIGRvY3VtZW50IGlz IGFuIGV4YW1wbGUgb2Ygd2h5IGl0IGlzDQo+Pj4+PiB3b3J0aCBjb25zaWRlcmluZy4gIFRoZSBM M1ZQTiBleGFtcGxlIHNlZW1zIHRvIHNob3cgYSBkYW5nZXJvdXMgdXNlDQo+Pj4+PiBjYXNlLg0K Pj4+Pj4NCj4+Pj4+IFlvdXJzLCBKb2VsIE0uIEhhbHBlcm4NCj4+Pj4+DQo+Pj4+PiBPbiA2LzYv MjAxMiA1OjE4IEFNLCBicnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tIHdyb3RlOg0KPj4+Pj4+IEhp LA0KPj4+Pj4+DQo+Pj4+Pj4gU3VwcG9ydC4NCj4+Pj4+Pg0KPj4+Pj4+IFJlZ2FyZHMsIEJydW5v DQo+Pj4+Pj4NCj4+Pj4+Pj4gRnJvbTogSm9obiBTY3VkZGVyPlNlbnQ6IFRodXJzZGF5LCBNYXkg MzEsIDIwMTIgNzoxMCBQTQ0KPj4+Pj4+Pg0KPj4+Pj4+PiBGb2xrcywNCj4+Pj4+Pj4NCj4+Pj4+ Pj4gV2UgaGF2ZSByZWNlaXZlZCBhIHJlcXVlc3QgZnJvbSB0aGUgYXV0aG9ycyB0byBhZG9wdA0K Pj4+Pj4+PiBkcmFmdC11dHRhcm8taWRyLWJncC0gcGVyc2lzdGVuY2UtMDEgYXMgYW4gSURSIFdH IGRvY3VtZW50Lg0KPj4+Pj4+PiBQbGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIHRvIHRoZSBsaXN0 LiBUaGUgZGVhZGxpbmUgZm9yDQo+Pj4+Pj4+IGNvbW1lbnRzIGlzIEp1bmUgMTUsIDIwMTIgYXQg bm9vbiBFRFQuDQo+Pj4+Pj4+DQo+Pj4+Pj4+IFRoYW5rcywNCj4+Pj4+Pj4NCj4+Pj4+Pj4gLS1K b2huIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIElkcg0K Pj4+Pj4+PiBtYWlsaW5nIGxpc3QgSWRyQGlldGYub3JnDQo+Pj4+Pj4+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vaWRyDQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+DQo+X19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4gQ2UgbWVzc2FnZSBl dCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zDQo+ Pj4+Pj4gY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMg cGFzIGV0cmUNCj4+Pj4+PiBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9y aXNhdGlvbi4gU2kgdm91cyBhdmV6DQo+Pj4+Pj4gcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIs IHZldWlsbGV6IGxlIHNpZ25hbGVyIGEgbCdleHBlZGl0ZXVyDQo+Pj4+Pj4gZXQgbGUgZGV0cnVp cmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzDQo+Pj4+Pj4gZWxl Y3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLCBGcmFuY2UgVGVsZWNv bSAtDQo+Pj4+Pj4gT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVz c2FnZSBhIGV0ZSBhbHRlcmUsDQo+Pj4+Pj4gZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQo+ Pj4+Pj4NCj4+Pj4+PiBUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFp biBjb25maWRlbnRpYWwgb3INCj4+Pj4+PiBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5 IGJlIHByb3RlY3RlZCBieSBsYXc7IHRoZXkgc2hvdWxkDQo+Pj4+Pj4gbm90IGJlIGRpc3RyaWJ1 dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uIElmIHlvdQ0KPj4+Pj4+ IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2Vu ZGVyIGFuZA0KPj4+Pj4+IGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4g QXMgZW1haWxzIG1heSBiZQ0KPj4+Pj4+IGFsdGVyZWQsIEZyYW5jZSBUZWxlY29tIC0gT3Jhbmdl IGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQNCj4+Pj4+PiBoYXZlIGJlZW4gbW9kaWZp ZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLiBUaGFuayB5b3UuDQo+Pj4+Pj4NCj4+Pj4+PiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyBJZHIgbWFpbGluZyBs aXN0DQo+Pj4+Pj4gSWRyQGlldGYub3JnIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vaWRyDQo+Pj4+Pj4NCj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fIElkciBtYWlsaW5nIGxpc3QNCj4+Pj4+IElkckBpZXRmLm9yZyBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkcg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+ DQo+Pj4+DQo+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fIElkciBtYWlsaW5nIGxpc3QNCj4+Pj4gSWRyQGlldGYub3JnIGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vaWRyDQo+DQo+DQoNCgpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0 IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29u ZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUg ZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMg YXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBs J2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4g TGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlv biwKRnJhbmNlIFRlbGVjb20gLSBPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBz aSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpU aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwg b3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0 aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0 aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxl YXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0 YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgRnJhbmNlIFRlbGVjb20gLSBPcmFu Z2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNo YW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5b3UuCgo= From robert@raszuk.net Fri Jun 8 07:35:13 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2DB821F8638 for ; Fri, 8 Jun 2012 07:35:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.397 X-Spam-Level: X-Spam-Status: No, score=-2.397 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S2OikzbZ9bqo for ; Fri, 8 Jun 2012 07:35:13 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id DFFD121F85F2 for ; Fri, 8 Jun 2012 07:35:12 -0700 (PDT) Received: (qmail 3012 invoked by uid 399); 8 Jun 2012 14:35:12 -0000 Received: from unknown (HELO ?172.16.197.148?) (pbs:robert@raszuk.net@58.80.213.53) by mail1310.opentransfer.com with ESMTPM; 8 Jun 2012 14:35:12 -0000 X-Originating-IP: 58.80.213.53 Message-ID: <4FD20D9E.2010505@raszuk.net> Date: Fri, 08 Jun 2012 07:35:10 -0700 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120604 Thunderbird/13.0 MIME-Version: 1.0 To: bruno.decraene@orange.com References: <4911_1338974288_4FCF2050_4911_12906_1_53C29892C857584299CBF5D05346208A08CA08@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FCF800C.6070509@joelhalpern.com> <4FCF883B.6050501@raszuk.net> <4FCFEC86.6050706@raszuk.net> <8684_1339102246_4FD11426_8684_17472_1_53C29892C857584299CBF5D05346208A08D397@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FD1E202.6090503@raszuk.net> <1407_1339164741_4FD20845_1407_271_1_53C29892C857584299CBF5D05346208A08E913@PEXCVZYM11.corporate.adroot.infra.ftgroup> In-Reply-To: <1407_1339164741_4FD20845_1407_271_1_53C29892C857584299CBF5D05346208A08E913@PEXCVZYM11.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org List" , "Joel M. Halpern" , "UTTARO, JAMES" Subject: Re: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 14:35:13 -0000 Hi Bruno, > I agree with your recommendation. Actually that's what the current > version of the draft proposes: Actually the current version of the draft says much earlier: "4. Operation 4.1. BGP session failure Assuming a session failure has occurred, a BGP persistent router SHOULD retain BGP routes unless they carry the DO_NOT_PERSIST community and propagate paths to downstream speakers that indicate that a given path is now stale." That is wrong to say the above as below sections contradict with it. > Great. I agree with you: that's roughly the title of slide 4: > "Persistence & Graceful Restart: complementary use cases." I am glad we are converging ;) How about _mandating_ GR to be used with persistence ? At least for some global AFI/SAFIs ? If so that may to some extend address my concern with unnecessary BGP churn while in the same time allow you to accomplish 100% of your goal? ----- However for the record I am still not supportive of this idea in general. I clearly see that this idea is the tool to increase wrong designs of BGP networks. It's in fact a patch to a very bad network design. We should highly avoid such patches. In network designs where you have native path redundancy as well as you do not relay on single vendor/source BGP implementation for any BGP control plane element this idea does not bring any value. Yes I am aware that popular vendors do not support seamless multi-bgp implementation control planes today. But this can be/is being easily addressed. Best regards, R. From ju1738@att.com Fri Jun 8 07:43:19 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48B8821F8582 for ; Fri, 8 Jun 2012 07:43:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.967 X-Spam-Level: X-Spam-Status: No, score=-105.967 tagged_above=-999 required=5 tests=[AWL=0.632, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7cWKk9fgfv6y for ; Fri, 8 Jun 2012 07:43:18 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id 1DDA921F857F for ; Fri, 8 Jun 2012 07:43:18 -0700 (PDT) Received: from unknown [144.160.128.153] (EHLO flpi408.enaf.ffdc.sbc.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.11.0-10) over TLS secured channel with ESMTP id 58f02df4.0.1865321.00-453.5164237.nbfkord-smmo07.seg.att.com (envelope-from ); Fri, 08 Jun 2012 14:43:18 +0000 (UTC) X-MXL-Hash: 4fd20f8613926f8a-e24cdd514d3311b0bde3f8aeab68bf461a45c54e Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q58EhEHL003241; Fri, 8 Jun 2012 07:43:17 -0700 Received: from fflint04.pst.cso.att.com (fflint04.pst.cso.att.com [150.234.39.64]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q58Eh2l0003030 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Jun 2012 07:43:09 -0700 Received: from MISOUT7MSGHUB9E.ITServices.sbc.com (misout7msghub9e.itservices.sbc.com [144.151.223.61]) by fflint04.pst.cso.att.com (RSA Interceptor); Fri, 8 Jun 2012 07:42:43 -0700 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9E.ITServices.sbc.com ([144.151.223.61]) with mapi id 14.01.0355.002; Fri, 8 Jun 2012 10:42:41 -0400 From: "UTTARO, JAMES" To: "'robert@raszuk.net'" , "bruno.decraene@orange.com" Thread-Topic: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR WG document Thread-Index: AQHNRYT1iN4+L+vTcUqPVnyFIlVabA== Date: Fri, 8 Jun 2012 14:42:41 +0000 Message-ID: References: <4911_1338974288_4FCF2050_4911_12906_1_53C29892C857584299CBF5D05346208A08CA08@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FCF800C.6070509@joelhalpern.com> <4FCF883B.6050501@raszuk.net> <4FCFEC86.6050706@raszuk.net> <8684_1339102246_4FD11426_8684_17472_1_53C29892C857584299CBF5D05346208A08D397@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FD1E202.6090503@raszuk.net> <1407_1339164741_4FD20845_1407_271_1_53C29892C857584299CBF5D05346208A08E913@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FD20D9E.2010505@raszuk.net> In-Reply-To: <4FD20D9E.2010505@raszuk.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.141.253] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.128.153] X-AnalysisOut: [v=1.0 c=1 a=ugEe1kqlDI0A:10 a=lYr-YFbwilAA:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=IkcTkHD0fZMA:10 a=xwOvzTHDVLE4u4] X-AnalysisOut: [nGvK72ag==:17 a=2clOPd4PAAAA:8 a=z9tbli-vAAAA:8 a=48vgC7mU] X-AnalysisOut: [AAAA:8 a=uK1Fm5MZgVKgFVfDQ2cA:9 a=QEXdDO2ut3YA:10 a=bDUki_] X-AnalysisOut: [mJ7DgA:10 a=oAXR_kdF8uMA:10 a=lZB815dzVvQA:10] Cc: "idr@ietf.org List" , "Joel M. Halpern" Subject: Re: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 14:43:19 -0000 Q29tbWVudHMgSW4tTGluZS4uDQoNCkppbSBVdHRhcm8NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCkZyb206IFJvYmVydCBSYXN6dWsgW21haWx0bzpyb2JlcnRAcmFzenVrLm5ldF0gDQpT ZW50OiBGcmlkYXksIEp1bmUgMDgsIDIwMTIgMTA6MzUgQU0NClRvOiBicnVuby5kZWNyYWVuZUBv cmFuZ2UuY29tDQpDYzogaWRyQGlldGYub3JnIExpc3Q7IEpvZWwgTS4gSGFscGVybjsgVVRUQVJP LCBKQU1FUw0KU3ViamVjdDogUmU6IFtJZHJdIEFkb3B0aW9uIG9mIGRyYWZ0LXV0dGFyby1pZHIt YmdwLXBlcnNpc3RlbmNlLTAxIGFzIElEUiBXRyBkb2N1bWVudA0KDQpIaSBCcnVubywNCg0KPiBJ IGFncmVlIHdpdGggeW91ciByZWNvbW1lbmRhdGlvbi4gQWN0dWFsbHkgdGhhdCdzIHdoYXQgdGhl IGN1cnJlbnQNCj4gdmVyc2lvbiBvZiB0aGUgZHJhZnQgcHJvcG9zZXM6DQoNCkFjdHVhbGx5IHRo ZSBjdXJyZW50IHZlcnNpb24gb2YgdGhlIGRyYWZ0IHNheXMgbXVjaCBlYXJsaWVyOg0KDQoiNC4g IE9wZXJhdGlvbg0KDQo0LjEuICBCR1Agc2Vzc2lvbiBmYWlsdXJlDQoNCiAgICBBc3N1bWluZyBh IHNlc3Npb24gZmFpbHVyZSBoYXMgb2NjdXJyZWQsIGEgQkdQIHBlcnNpc3RlbnQgcm91dGVyDQog ICAgU0hPVUxEIHJldGFpbiBCR1Agcm91dGVzIHVubGVzcyB0aGV5IGNhcnJ5IHRoZSBET19OT1Rf UEVSU0lTVA0KICAgIGNvbW11bml0eSBhbmQgcHJvcGFnYXRlIHBhdGhzIHRvIGRvd25zdHJlYW0g c3BlYWtlcnMgdGhhdCBpbmRpY2F0ZQ0KICAgIHRoYXQgYSBnaXZlbiBwYXRoIGlzIG5vdyBzdGFs ZS4iDQoNClRoYXQgaXMgd3JvbmcgdG8gc2F5IHRoZSBhYm92ZSBhcyBiZWxvdyBzZWN0aW9ucyBj b250cmFkaWN0IHdpdGggaXQuDQpbSmltIFU+XSBXaHkgaXMgdGhhdC4uIElmIHRoZSB0d28gYXJl IHVzZWQgaW4gY29uanVuY3Rpb24gdGhhZW4gYWZ0ZXIgR1IgYmVoYXZpb3IgaXMgY29tcGxldGUg YW5kIFBlcnNpc3RlbmNlIGlzIGFjdGl2YXRlZCB0aGVuIHRoaXMgY291bGQgYmUgYSBiZWhhdmlv ciBiYXNlZCB1cG9uIHdoYXQgdGhlIFNQIHdhbnRzIHRvIGRvIGluIHRlcm1zIG9mIHRoZWlyIHVu aXF1ZSByZXF1aXJlbWVudHMuLg0KDQo+IEdyZWF0LiBJIGFncmVlIHdpdGggeW91OiB0aGF0J3Mg cm91Z2hseSB0aGUgdGl0bGUgb2Ygc2xpZGUgNDoNCj4gIlBlcnNpc3RlbmNlICYgR3JhY2VmdWwg UmVzdGFydDogY29tcGxlbWVudGFyeSB1c2UgY2FzZXMuIg0KDQpJIGFtIGdsYWQgd2UgYXJlIGNv bnZlcmdpbmcgOykNCg0KSG93IGFib3V0IF9tYW5kYXRpbmdfIEdSIHRvIGJlIHVzZWQgd2l0aCBw ZXJzaXN0ZW5jZSA/IEF0IGxlYXN0IGZvciBzb21lIA0KZ2xvYmFsIEFGSS9TQUZJcyA/DQpbSmlt IFU+XSBJcyB0aGF0IGxpa2UgYSBwYXBhbCBtYW5kYXRlIDspIEkgdGhpbmsgdGhhdCBmb2xrcyBh cmUgY2FwYWJsZSBvZiB1bmRlcnN0YW5kaW5nIHRoZSBiZWhhdmlvciBhcyBtdWNoIGFzIGFueSBv dGhlciB0ZWNobm9sb2d5Li4NCg0KSWYgc28gdGhhdCBtYXkgdG8gc29tZSBleHRlbmQgYWRkcmVz cyBteSBjb25jZXJuIHdpdGggdW5uZWNlc3NhcnkgQkdQIA0KY2h1cm4gd2hpbGUgaW4gdGhlIHNh bWUgdGltZSBhbGxvdyB5b3UgdG8gYWNjb21wbGlzaCAxMDAlIG9mIHlvdXIgZ29hbD8NCg0KLS0t LS0NCg0KSG93ZXZlciBmb3IgdGhlIHJlY29yZCBJIGFtIHN0aWxsIG5vdCBzdXBwb3J0aXZlIG9m IHRoaXMgaWRlYSBpbiANCmdlbmVyYWwuIEkgY2xlYXJseSBzZWUgdGhhdCB0aGlzIGlkZWEgaXMg dGhlIHRvb2wgdG8gaW5jcmVhc2Ugd3JvbmcgDQpkZXNpZ25zIG9mIEJHUCBuZXR3b3Jrcy4gSXQn cyBpbiBmYWN0IGEgcGF0Y2ggdG8gYSB2ZXJ5IGJhZCBuZXR3b3JrIA0KZGVzaWduLiBXZSBzaG91 bGQgaGlnaGx5IGF2b2lkIHN1Y2ggcGF0Y2hlcy4NCg0KSW4gbmV0d29yayBkZXNpZ25zIHdoZXJl IHlvdSBoYXZlIG5hdGl2ZSBwYXRoIHJlZHVuZGFuY3kgYXMgd2VsbCBhcyB5b3UgDQpkbyBub3Qg cmVsYXkgb24gc2luZ2xlIHZlbmRvci9zb3VyY2UgQkdQIGltcGxlbWVudGF0aW9uIGZvciBhbnkg QkdQIA0KY29udHJvbCBwbGFuZSBlbGVtZW50IHRoaXMgaWRlYSBkb2VzIG5vdCBicmluZyBhbnkg dmFsdWUuDQpbSmltIFU+XSBUaGUgbm90aW9uIG9mIEJHUCBwZXJzaXN0ZW5jZSBhcyB5b3UgcG9p bnQgb3V0IHdvdWxkIG5vdCBiZSBuZWVkZWQgaWYgYWZ0ZXIgdGhlIHRoaW5ncyB5b3UgbWVudGlv biAoIFBsdXMgb3RoZXJzICkgd291bGQgaGF2ZSBiZWVuIHN1ZmZpY2llbnQgc2FmZWd1YXJkZWQg b3VyIG5ldHdvcmsgZnJvbSB0aGlzIHR5cGUgb2YgZmFpbHVyZSBtb2RlLg0KDQpZZXMgSSBhbSBh d2FyZSB0aGF0IHBvcHVsYXIgdmVuZG9ycyBkbyBub3Qgc3VwcG9ydCBzZWFtbGVzcyBtdWx0aS1i Z3AgDQppbXBsZW1lbnRhdGlvbiBjb250cm9sIHBsYW5lcyB0b2RheS4gQnV0IHRoaXMgY2FuIGJl L2lzIGJlaW5nIGVhc2lseSANCmFkZHJlc3NlZC4NCg0KQmVzdCByZWdhcmRzLA0KUi4NCg== From robert@raszuk.net Fri Jun 8 08:08:54 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EEA521F873A for ; Fri, 8 Jun 2012 08:08:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.425 X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HG6HAwKi9cZm for ; Fri, 8 Jun 2012 08:08:53 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 4EF8A21F86C8 for ; Fri, 8 Jun 2012 08:08:42 -0700 (PDT) Received: (qmail 18448 invoked by uid 399); 8 Jun 2012 15:08:41 -0000 Received: from unknown (HELO ?172.16.197.148?) (pbs:robert@raszuk.net@58.80.213.53) by mail1310.opentransfer.com with ESMTPM; 8 Jun 2012 15:08:41 -0000 X-Originating-IP: 58.80.213.53 Message-ID: <4FD21577.2030103@raszuk.net> Date: Fri, 08 Jun 2012 08:08:39 -0700 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120604 Thunderbird/13.0 MIME-Version: 1.0 To: "UTTARO, JAMES" References: <4911_1338974288_4FCF2050_4911_12906_1_53C29892C857584299CBF5D05346208A08CA08@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FCF800C.6070509@joelhalpern.com> <4FCF883B.6050501@raszuk.net> <4FCFEC86.6050706@raszuk.net> <8684_1339102246_4FD11426_8684_17472_1_53C29892C857584299CBF5D05346208A08D397@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FD1E202.6090503@raszuk.net> <1407_1339164741_4FD20845_1407_271_1_53C29892C857584299CBF5D05346208A08E913@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FD20D9E.2010505@raszuk.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "bruno.decraene@orange.com" , "Joel M. Halpern" , "idr@ietf.org List" Subject: Re: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 15:08:54 -0000 Hi Jim, > Assuming a session failure has occurred, a BGP persistent router > SHOULD retain BGP routes unless they carry the DO_NOT_PERSIST > community and propagate paths to downstream speakers that indicate > that a given path is now stale." > > That is wrong to say the above as below sections contradict with it. > > [Jim U>] Why is that.. If the two are used in conjunction thaen after > GR behavior is complete and Persistence is activated then this could > be a behavior based upon what the SP wants to do in terms of their > unique requirements.. The above quote does not mention GR. > However for the record I am still not supportive of this idea in > general. I clearly see that this idea is the tool to increase wrong > designs of BGP networks. It's in fact a patch to a very bad network > design. We should highly avoid such patches. > > In network designs where you have native path redundancy as well as > you do not relay on single vendor/source BGP implementation for any > BGP control plane element this idea does not bring any value. [Jim > U>] The notion of BGP persistence as you point out would not be > needed if after the things you mention ( Plus others ) would have > been sufficient safeguarded our network from this type of failure > mode. Exactly. IMHO we should shoot for right design not for patching badly made holes. Keep on mind that when we die (sooner or later) new folks will see persistent draft as an IDR/IETF recommendation. I really do not see this an advantage of any sort. Also Jakob's question still stays open .. Should STALE /16 be more preferred then STALE /24 which is covered by /16 ? While I have no idea how is he going to run best path across different prefixes it would be great to have community agreement on this question. In general I am not sure if you realize, but this is difficult space you are entering from different perspective as the draft does not limit itself to only control plane BGP speaker action. In data plane some BGP implementations advertise only active (RIB/FIB) inserted routes while some do not care. Especially for the latter case where RIB has a route via different protocol and next hop self is set withdrawing it from BGP is not the best idea when original session the prefix was learned goes down. But I am not sure how much of real practical cases you would plan to include in the draft. Thx, R. From ju1738@att.com Fri Jun 8 08:29:01 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B17FF21F8934 for ; Fri, 8 Jun 2012 08:29:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.046 X-Spam-Level: X-Spam-Status: No, score=-106.046 tagged_above=-999 required=5 tests=[AWL=0.553, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ko3UToDy+wKO for ; Fri, 8 Jun 2012 08:29:01 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id AEF3F21F891B for ; Fri, 8 Jun 2012 08:29:00 -0700 (PDT) Received: from unknown [144.160.128.153] (EHLO flpi408.enaf.ffdc.sbc.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.11.0-10) over TLS secured channel with ESMTP id c3a12df4.0.1881305.00-402.5209663.nbfkord-smmo07.seg.att.com (envelope-from ); Fri, 08 Jun 2012 15:29:00 +0000 (UTC) X-MXL-Hash: 4fd21a3c13857504-dfeff63f38098948554f226df1501373672f078e Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q58FSwSn025052; Fri, 8 Jun 2012 08:28:59 -0700 Received: from fflint04.pst.cso.att.com (fflint04.pst.cso.att.com [150.234.39.64]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q58FSp64024836 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Jun 2012 08:28:52 -0700 Received: from MISOUT7MSGHUB9E.ITServices.sbc.com (misout7msghub9e.itservices.sbc.com [144.151.223.61]) by fflint04.pst.cso.att.com (RSA Interceptor); Fri, 8 Jun 2012 08:28:18 -0700 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9E.ITServices.sbc.com ([144.151.223.61]) with mapi id 14.01.0355.002; Fri, 8 Jun 2012 11:28:18 -0400 From: "UTTARO, JAMES" To: "'robert@raszuk.net'" Thread-Topic: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR WG document Thread-Index: AQHNRYT1iN4+L+vTcUqPVnyFIlVabJbwyS+A///AYlA= Date: Fri, 8 Jun 2012 15:28:17 +0000 Message-ID: References: <4911_1338974288_4FCF2050_4911_12906_1_53C29892C857584299CBF5D05346208A08CA08@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FCF800C.6070509@joelhalpern.com> <4FCF883B.6050501@raszuk.net> <4FCFEC86.6050706@raszuk.net> <8684_1339102246_4FD11426_8684_17472_1_53C29892C857584299CBF5D05346208A08D397@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FD1E202.6090503@raszuk.net> <1407_1339164741_4FD20845_1407_271_1_53C29892C857584299CBF5D05346208A08E913@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FD20D9E.2010505@raszuk.net> <4FD21577.2030103@raszuk.net> In-Reply-To: <4FD21577.2030103@raszuk.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.141.253] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.128.153] X-AnalysisOut: [v=1.0 c=1 a=ugEe1kqlDI0A:10 a=lYr-YFbwilAA:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=xwOvzTHDVLE4u4] X-AnalysisOut: [nGvK72ag==:17 a=2clOPd4PAAAA:8 a=z9tbli-vAAAA:8 a=48vgC7mU] X-AnalysisOut: [AAAA:8 a=pZd7kVOcUMjFaqJRnMgA:9 a=CjuIK1q_8ugA:10 a=bDUki_] X-AnalysisOut: [mJ7DgA:10 a=oAXR_kdF8uMA:10 a=lZB815dzVvQA:10] Cc: "bruno.decraene@orange.com" , "Joel M. Halpern" , "idr@ietf.org List" Subject: Re: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 15:29:01 -0000 Comments In-Line=20 Jim Uttaro -----Original Message----- From: Robert Raszuk [mailto:robert@raszuk.net]=20 Sent: Friday, June 08, 2012 11:09 AM To: UTTARO, JAMES Cc: bruno.decraene@orange.com; idr@ietf.org List; Joel M. Halpern Subject: Re: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR W= G document Hi Jim, > Assuming a session failure has occurred, a BGP persistent router > SHOULD retain BGP routes unless they carry the DO_NOT_PERSIST > community and propagate paths to downstream speakers that indicate > that a given path is now stale." > > That is wrong to say the above as below sections contradict with it. > > [Jim U>] Why is that.. If the two are used in conjunction thaen after > GR behavior is complete and Persistence is activated then this could > be a behavior based upon what the SP wants to do in terms of their > unique requirements.. The above quote does not mention GR. > However for the record I am still not supportive of this idea in > general. I clearly see that this idea is the tool to increase wrong > designs of BGP networks. It's in fact a patch to a very bad network > design. We should highly avoid such patches. > > In network designs where you have native path redundancy as well as > you do not relay on single vendor/source BGP implementation for any > BGP control plane element this idea does not bring any value. [Jim > U>] The notion of BGP persistence as you point out would not be > needed if after the things you mention ( Plus others ) would have > been sufficient safeguarded our network from this type of failure > mode. Exactly. IMHO we should shoot for right design not for patching badly made holes. [Jim U>] Yes Robert.. I endeavor to create $hitty designs so that the netwo= rk can fail and then I can spend my time explaining why we need some superf= luous solutions to problems we created ourselves.. I mean as you point out = the obvious design safeguards should be in place and gee whiz us dopey SP d= esigners are just too plain stupid to figure out the basics of a robust sca= lable design.. What insight.. Hold on I am going to make some new holes in = the network, going to get my shovel right now ;) =20 Keep on mind that when we die (sooner or later) new folks will see=20 persistent draft as an IDR/IETF recommendation. I really do not see this an advantage of any sort. [Jim U>] Yes I think I have gotten that point Also Jakob's question still stays open .. Should STALE /16 be more=20 preferred then STALE /24 which is covered by /16 ? While I have no idea=20 how is he going to run best path across different prefixes it would be=20 great to have community agreement on this question. In general I am not sure if you realize, but this is difficult space you=20 are entering from different perspective as the draft does not limit=20 itself to only control plane BGP speaker action.=20 [Jim U>] I think you have to realize that BGP is being used in lots of new = applications in 2k+ In data plane some BGP=20 implementations advertise only active (RIB/FIB) inserted routes while=20 some do not care. Especially for the latter case where RIB has a route=20 via different protocol and next hop self is set withdrawing it from BGP=20 is not the best idea when original session the prefix was learned goes=20 down. But I am not sure how much of real practical cases you would plan=20 to include in the draft. Thx, R. From robert@raszuk.net Fri Jun 8 08:40:10 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 723EA21F85FD for ; Fri, 8 Jun 2012 08:40:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hGoEyVkC9Iw6 for ; Fri, 8 Jun 2012 08:40:09 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 4FDC321F85D8 for ; Fri, 8 Jun 2012 08:40:09 -0700 (PDT) Received: (qmail 29095 invoked by uid 399); 8 Jun 2012 15:40:08 -0000 Received: from unknown (HELO ?172.16.197.148?) (pbs:robert@raszuk.net@58.80.213.53) by mail1310.opentransfer.com with ESMTPM; 8 Jun 2012 15:40:08 -0000 X-Originating-IP: 58.80.213.53 Message-ID: <4FD21CD7.30806@raszuk.net> Date: Fri, 08 Jun 2012 08:40:07 -0700 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120604 Thunderbird/13.0 MIME-Version: 1.0 To: "UTTARO, JAMES" References: <4911_1338974288_4FCF2050_4911_12906_1_53C29892C857584299CBF5D05346208A08CA08@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FCF800C.6070509@joelhalpern.com> <4FCF883B.6050501@raszuk.net> <4FCFEC86.6050706@raszuk.net> <8684_1339102246_4FD11426_8684_17472_1_53C29892C857584299CBF5D05346208A08D397@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FD1E202.6090503@raszuk.net> <1407_1339164741_4FD20845_1407_271_1_53C29892C857584299CBF5D05346208A08E913@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FD20D9E.2010505@raszuk.net> <4FD21577.2030103@raszuk.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "bruno.decraene@orange.com" , "Joel M. Halpern" , "idr@ietf.org List" Subject: Re: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 15:40:10 -0000 Jim, > whiz us dopey SP designers are just too plain stupid to figure out > the basics of a robust scalable design.. What insight.. My comment is not about that "SP designers are just too plain stupid". My comment is about that industry for it's commercial reasons does not offer today a hybrid BGP control plane solutions. Even when some vendors have multiple independent BGP implementation today and could offer it with minimal effort they are not. That one is just an amazing miss. So you still want to patch holes rather then avoid them as you go by what is shipping rather then what should be shipping. I disagree with such approach. Best, R. From internet-drafts@ietf.org Tue Jun 12 00:56:13 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D311D21F860F; Tue, 12 Jun 2012 00:56:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lOMSEfswAwuy; Tue, 12 Jun 2012 00:56:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CE0F21F85C6; Tue, 12 Jun 2012 00:56:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.20 Message-ID: <20120612075613.2710.86390.idtracker@ietfa.amsl.com> Date: Tue, 12 Jun 2012 00:56:13 -0700 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-bgp-ipv6-rt-constrain-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 07:56:14 -0000 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 : IPv6 Extensions for Route Target Distribution Author(s) : Keyur Patel Robert Raszuk Martin Djernaes Jie Dong Mach(Guoyi) Chen Filename : draft-ietf-idr-bgp-ipv6-rt-constrain-02.txt Pages : 7 Date : 2012-06-12 Abstract: The current route target distribution specification described in RFC4684 defines Route Target NLRIs of maximum length of 12 bytes. The IPv6 specific Route Target extended community is defined in [RFC5701] as length of 20 bytes. Since the current specification only supports prefixes of maximum length of 12 bytes, the lack of an IPv6 specific Route Target reachability information may be a problem when an operator wants to use this application in a pure IPv6 environment. This document defines an extension that allows BGP to exchange longer length IPv6 Route Target prefixes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ipv6-rt-constrain There's also a htmlized version available at: http://tools.ietf.org/html/submission.filename }}-02 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-bgp-ipv6-rt-constrain-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From stbryant@cisco.com Tue Jun 12 03:30:14 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB6E121F8645 for ; Tue, 12 Jun 2012 03:30:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xHgdmVwTSvFv for ; Tue, 12 Jun 2012 03:30:14 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 05E7E21F8613 for ; Tue, 12 Jun 2012 03:30:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=1859; q=dns/txt; s=iport; t=1339497014; x=1340706614; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=nmJhvr+PaMqdRZlnKVklQYnOAjEkX/RMYOuh6GkbgtU=; b=BX/V5jbw2NUcUy3ZcZVjAJozajMHsJt0twKYPkt9BvHVmkf1Sl/2XgT/ jKacO33oRqTzY6iquKaPPS/+E7zmdM0/xwtakzaI5rMOi9UFHSFVwQGH/ WU2clPmApfiEebuPgdiBhxcsFVr2j0HA2o4B6n1lG5g6w606InxO/7ehB Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAOEY10+Q/khR/2dsb2JhbABFtT6BB4IYAQEBBBIBAiMvBwoBEAsOCgkWBAsJAwIBAgFFBg0BBQIBAR6HaZkjg0cQnBKLI4YRA5UfjhWBBGKCYQ X-IronPort-AV: E=Sophos;i="4.75,757,1330905600"; d="scan'208";a="5681419" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-4.cisco.com with ESMTP; 12 Jun 2012 10:30:12 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q5CAUCvG019045 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Jun 2012 10:30:12 GMT Received: from dhcp-bdlk10-data-vlan300-64-103-106-111.cisco.com (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id q5CAUBJT004518; Tue, 12 Jun 2012 11:30:12 +0100 (BST) Message-ID: <4FD71A33.8040901@cisco.com> Date: Tue, 12 Jun 2012 11:30:11 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20120601 Thunderbird/13.0 MIME-Version: 1.0 To: Claudio Jeker References: <20120601185444.8409.85777.idtracker@ietfa.amsl.com> <20120601220000.GB9448@diehard.n-r-g.com> In-Reply-To: <20120601220000.GB9448@diehard.n-r-g.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr@ietf.org Subject: Re: [Idr] Last Call: (BGP Support for Four-octet AS Number Space) to Proposed Standard X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 10:30:15 -0000 On 01/06/2012 23:00, Claudio Jeker wrote: > On Fri, Jun 01, 2012 at 11:54:44AM -0700, The IESG wrote: >> The IESG has received a request from the Inter-Domain Routing WG (idr) to >> consider the following document: >> - 'BGP Support for Four-octet AS Number Space' >> as Proposed Standard >> >> The IESG plans to make a decision in the next few weeks, and solicits >> final comments on this action. Please send substantive comments to the >> ietf@ietf.org mailing lists by 2012-06-15. Exceptionally, comments may be >> sent to iesg@ietf.org instead. In either case, please retain the >> beginning of the Subject line to allow automated sorting. >> >> Abstract >> >> >> The Autonomous System (AS) number is encoded as a two-octet entity in >> the base BGP specification. This document describes extensions to BGP >> to carry the Autonomous System numbers as four-octet entities. This >> document obsoletes RFC 4893. >> > Just for the sake of clarity, OpenBGPD will not do the following: > > In addition, the path segment types AS_CONFED_SEQUENCE and > AS_CONFED_SET [RFC5065] MUST NOT be carried in the AS4_PATH attribute > of an UPDATE message. A NEW BGP speaker that receives these path > segment types in the AS4_PATH attribute of an UPDATE message from an > OLD BGP speaker MUST discard these path segments, adjust the relevant > attribute fields accordingly, and continue processing the UPDATE > message. This case SHOULD be logged locally for analysis. > > There is no point to do this fiddeling instead we will treat this like any > other parse error of AS4_PATH. > Claudio Since this is in last call, I have to ask whether you have objection to the publication of the above text, or have any proposed text changes? Stewart From rjs@rob.sh Tue Jun 12 04:04:24 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C36621F8619 for ; Tue, 12 Jun 2012 04:04:24 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DH-ZSfjGOVt7 for ; Tue, 12 Jun 2012 04:04:23 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2001:b98:201:101::10:cafe]) by ietfa.amsl.com (Postfix) with ESMTP id 80FD921F84C8 for ; Tue, 12 Jun 2012 04:04:22 -0700 (PDT) Received: from [109.144.233.5] (helo=[10.96.1.186]) by cappuccino.rob.sh with esmtpa (Exim 4.72) (envelope-from ) id 1SeOsL-0008Th-42; Tue, 12 Jun 2012 12:03:05 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: Rob Shakir Date: Tue, 12 Jun 2012 12:04:20 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <29BED4EE-34F3-4F48-B0ED-95D3E0240544@rob.sh> References: To: "idr@ietf.org List" X-Mailer: Apple Mail (2.1257) Subject: [Idr] Fwd: [GROW] WGLC: draft-ietf-grow-ops-reqs-for-bgp-error-handling-04 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 11:04:24 -0000 Hi IDR, As there has been discussion of this draft previously in IDR, as well as = GROW. Please accept this as a heads-up for the WGLC in GROW being = initiated. As per usual, comments and/or feedback are very welcome. Many thanks, r. Begin forwarded message: > From: Christopher Morrow > Subject: [GROW] WGLC: = draft-ietf-grow-ops-reqs-for-bgp-error-handling-04 > Date: 11 June 2012 21:21:49 GMT+01:00 > To: grow-chairs@tools.ietf.org, "grow@ietf.org grow@ietf.org" = >=20 > Hello GROW-WG folk, > Please take this message as the start of a 2 week, ending 6/25/2012 > (June 25, 2012) WGLC for the subject draft, link to current version: > = >=20 > 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. >=20 > 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 > -Chris > co-chair > _______________________________________________ > GROW mailing list > GROW@ietf.org > https://www.ietf.org/mailman/listinfo/grow From cjeker@diehard.n-r-g.com Tue Jun 12 06:54:58 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E443B21F85AC for ; Tue, 12 Jun 2012 06:54:58 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1hECH0ztXm1K for ; Tue, 12 Jun 2012 06:54:58 -0700 (PDT) Received: from diehard.n-r-g.com (diehard.n-r-g.com [62.48.3.9]) by ietfa.amsl.com (Postfix) with ESMTP id DD9FE21F859A for ; Tue, 12 Jun 2012 06:54:57 -0700 (PDT) Received: (qmail 2896 invoked by uid 1001); 12 Jun 2012 13:54:55 -0000 Date: Tue, 12 Jun 2012 15:54:55 +0200 From: Claudio Jeker To: Stewart Bryant Message-ID: <20120612135455.GC18025@diehard.n-r-g.com> References: <20120601185444.8409.85777.idtracker@ietfa.amsl.com> <20120601220000.GB9448@diehard.n-r-g.com> <4FD71A33.8040901@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4FD71A33.8040901@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: idr@ietf.org Subject: Re: [Idr] Last Call: (BGP Support for Four-octet AS Number Space) to Proposed Standard X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 13:54:59 -0000 On Tue, Jun 12, 2012 at 11:30:11AM +0100, Stewart Bryant wrote: > On 01/06/2012 23:00, Claudio Jeker wrote: > >On Fri, Jun 01, 2012 at 11:54:44AM -0700, The IESG wrote: > >>The IESG has received a request from the Inter-Domain Routing WG (idr) to > >>consider the following document: > >>- 'BGP Support for Four-octet AS Number Space' > >> as Proposed Standard > >> > >>The IESG plans to make a decision in the next few weeks, and solicits > >>final comments on this action. Please send substantive comments to the > >>ietf@ietf.org mailing lists by 2012-06-15. Exceptionally, comments may be > >>sent to iesg@ietf.org instead. In either case, please retain the > >>beginning of the Subject line to allow automated sorting. > >> > >>Abstract > >> > >> > >> The Autonomous System (AS) number is encoded as a two-octet entity in > >> the base BGP specification. This document describes extensions to BGP > >> to carry the Autonomous System numbers as four-octet entities. This > >> document obsoletes RFC 4893. > >> > >Just for the sake of clarity, OpenBGPD will not do the following: > > > > In addition, the path segment types AS_CONFED_SEQUENCE and > > AS_CONFED_SET [RFC5065] MUST NOT be carried in the AS4_PATH attribute > > of an UPDATE message. A NEW BGP speaker that receives these path > > segment types in the AS4_PATH attribute of an UPDATE message from an > > OLD BGP speaker MUST discard these path segments, adjust the relevant > > attribute fields accordingly, and continue processing the UPDATE > > message. This case SHOULD be logged locally for analysis. > > > >There is no point to do this fiddeling instead we will treat this like any > >other parse error of AS4_PATH. > > > Claudio > > Since this is in last call, I have to ask whether you have objection > to the publication > of the above text, or have any proposed text changes? I see no reason to enforce AS_CONFED_SEQUENCE and AS_CONFED_SET stripping on all AS4 implementations. It forces bgp implementations that don't have confederation support to strip out something that will cause an error in the regular path and for those systems ignoring the AS4_PATH attribute is perfectly fine. I do not understand how a workaround needs to be a MUST for something that is a MUST NOT at the same time? Why MUST we workaround something that MUST NOT appear? Why do we need to add extra code that is hard to test and maybe cause for further errors because it modifies attributes in very uncommon way? I propose to remove that paragraph entierly since it does only add complexity to the protocol for no reason and therefor is only a source of errors without any benefit. -- :wq Claudio From stbryant@cisco.com Tue Jun 12 07:25:38 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C331F21F85C7; Tue, 12 Jun 2012 07:25:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Sc7O9l0O+Am; Tue, 12 Jun 2012 07:25:36 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 0BEFC21F85AE; Tue, 12 Jun 2012 07:25:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=3140; q=dns/txt; s=iport; t=1339511136; x=1340720736; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=WOGT0lESNND4R+zquSAfl5kfhD9AHxG7YiFg/doMqKU=; b=Tzn8RXdQqdCc6RTjtN03PfVft/t/CKHxKwUjkJ+YiHUbazMgmcl+ZqAu lZa+zr4iFU75QxtFtf0BueSpvvItmNLd/SXKVHT+Hmk+iw4za2XOk1mqQ gH6PkbqWx8aHIXe9oaVaTmgg2iFb5i80nhS5M88l4KJx94cXSVebCpaVr U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EACxQ10+Q/khM/2dsb2JhbABFtTiBB4IYAQEBBBIBAiMvBwoBDAQcAwECAQkWBAsJAwIBAgE7AggGDQEFAgEBHodpmTKDRxCcGIsnhhEDlR+OFYEEYoJh X-IronPort-AV: E=Sophos;i="4.75,758,1330905600"; d="scan'208";a="5694672" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-4.cisco.com with ESMTP; 12 Jun 2012 14:25:34 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q5CEPYZw026352 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Jun 2012 14:25:34 GMT Received: from dhcp-bdlk10-data-vlan300-64-103-106-111.cisco.com (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id q5CEPYkH020306; Tue, 12 Jun 2012 15:25:34 +0100 (BST) Message-ID: <4FD7515E.3000101@cisco.com> Date: Tue, 12 Jun 2012 15:25:34 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20120601 Thunderbird/13.0 MIME-Version: 1.0 To: "Ietf@ietf.org" References: <20120612135455.GC18025@diehard.n-r-g.com> In-Reply-To: <20120612135455.GC18025@diehard.n-r-g.com> X-Forwarded-Message-Id: <20120612135455.GC18025@diehard.n-r-g.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr mailing list , "idr-chairs@tools.ietf.org" Subject: [Idr] Fwd: Re: Last Call: (BGP Support for Four-octet AS Number Space) to Proposed Standard X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 14:25:38 -0000 FYI Copying to IETF list as this is an IETF LC Stewart -------- Original Message -------- Subject: Re: [Idr] Last Call: (BGP Support for Four-octet AS Number Space) to Proposed Standard Date: Tue, 12 Jun 2012 15:54:55 +0200 From: Claudio Jeker To: Stewart Bryant CC: On Tue, Jun 12, 2012 at 11:30:11AM +0100, Stewart Bryant wrote: > On 01/06/2012 23:00, Claudio Jeker wrote: > >On Fri, Jun 01, 2012 at 11:54:44AM -0700, The IESG wrote: > >>The IESG has received a request from the Inter-Domain Routing WG (idr) to > >>consider the following document: > >>- 'BGP Support for Four-octet AS Number Space' > >> as Proposed Standard > >> > >>The IESG plans to make a decision in the next few weeks, and solicits > >>final comments on this action. Please send substantive comments to the > >>ietf@ietf.org mailing lists by 2012-06-15. Exceptionally, comments may be > >>sent to iesg@ietf.org instead. In either case, please retain the > >>beginning of the Subject line to allow automated sorting. > >> > >>Abstract > >> > >> > >> The Autonomous System (AS) number is encoded as a two-octet entity in > >> the base BGP specification. This document describes extensions to BGP > >> to carry the Autonomous System numbers as four-octet entities. This > >> document obsoletes RFC 4893. > >> > >Just for the sake of clarity, OpenBGPD will not do the following: > > > > In addition, the path segment types AS_CONFED_SEQUENCE and > > AS_CONFED_SET [RFC5065] MUST NOT be carried in the AS4_PATH attribute > > of an UPDATE message. A NEW BGP speaker that receives these path > > segment types in the AS4_PATH attribute of an UPDATE message from an > > OLD BGP speaker MUST discard these path segments, adjust the relevant > > attribute fields accordingly, and continue processing the UPDATE > > message. This case SHOULD be logged locally for analysis. > > > >There is no point to do this fiddeling instead we will treat this like any > >other parse error of AS4_PATH. > > > Claudio > > Since this is in last call, I have to ask whether you have objection > to the publication > of the above text, or have any proposed text changes? I see no reason to enforce AS_CONFED_SEQUENCE and AS_CONFED_SET stripping on all AS4 implementations. It forces bgp implementations that don't have confederation support to strip out something that will cause an error in the regular path and for those systems ignoring the AS4_PATH attribute is perfectly fine. I do not understand how a workaround needs to be a MUST for something that is a MUST NOT at the same time? Why MUST we workaround something that MUST NOT appear? Why do we need to add extra code that is hard to test and maybe cause for further errors because it modifies attributes in very uncommon way? I propose to remove that paragraph entierly since it does only add complexity to the protocol for no reason and therefor is only a source of errors without any benefit. -- :wq Claudio From robert@raszuk.net Tue Jun 12 08:38:33 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F013821F869A for ; Tue, 12 Jun 2012 08:38:32 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id je69hSb-KPCV for ; Tue, 12 Jun 2012 08:38:32 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id B8FB621F8693 for ; Tue, 12 Jun 2012 08:38:31 -0700 (PDT) Received: (qmail 18042 invoked by uid 399); 12 Jun 2012 15:38:30 -0000 Received: from unknown (HELO ?172.16.197.148?) (pbs:robert@raszuk.net@58.80.213.53) by mail1310.opentransfer.com with ESMTPM; 12 Jun 2012 15:38:30 -0000 X-Originating-IP: 58.80.213.53 Message-ID: <4FD76275.5040205@raszuk.net> Date: Tue, 12 Jun 2012 08:38:29 -0700 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120604 Thunderbird/13.0 MIME-Version: 1.0 To: Claudio Jeker References: <20120601185444.8409.85777.idtracker@ietfa.amsl.com> <20120601220000.GB9448@diehard.n-r-g.com> <4FD71A33.8040901@cisco.com> <20120612135455.GC18025@diehard.n-r-g.com> In-Reply-To: <20120612135455.GC18025@diehard.n-r-g.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr@ietf.org Subject: Re: [Idr] Last Call: (BGP Support for Four-octet AS Number Space) to Proposed Standard X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 15:38:33 -0000 Hi Claudio, One clarification question to your comment ... > It forces bgp implementations that don't have > confederation support to strip out something that will cause an error in > the regular path and for those systems ignoring the AS4_PATH attribute > is perfectly fine. Why are you saying that there will be an error in the regular AS_PATH ? As far as I can see the above quote refers only to AS4_PATH. The motivation is that instead of dropping the session or treating as withdraw robust BGP speaker can just remove the unexpected bad elements from AS4_PATH. In that respect this paragraph seems to add value and should be kept. Rgs, R. From cjeker@diehard.n-r-g.com Tue Jun 12 10:14:06 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59B9D21F8627 for ; Tue, 12 Jun 2012 10:14:06 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bZBMdb7LtsQF for ; Tue, 12 Jun 2012 10:14:05 -0700 (PDT) Received: from diehard.n-r-g.com (diehard.n-r-g.com [62.48.3.9]) by ietfa.amsl.com (Postfix) with ESMTP id A003721F858F for ; Tue, 12 Jun 2012 10:14:04 -0700 (PDT) Received: (qmail 10805 invoked by uid 1001); 12 Jun 2012 17:14:01 -0000 Date: Tue, 12 Jun 2012 19:14:01 +0200 From: Claudio Jeker To: Robert Raszuk Message-ID: <20120612171401.GH9448@diehard.n-r-g.com> References: <20120601185444.8409.85777.idtracker@ietfa.amsl.com> <20120601220000.GB9448@diehard.n-r-g.com> <4FD71A33.8040901@cisco.com> <20120612135455.GC18025@diehard.n-r-g.com> <4FD76275.5040205@raszuk.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4FD76275.5040205@raszuk.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: idr@ietf.org Subject: Re: [Idr] Last Call: (BGP Support for Four-octet AS Number Space) to Proposed Standard X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 17:14:06 -0000 On Tue, Jun 12, 2012 at 08:38:29AM -0700, Robert Raszuk wrote: > Hi Claudio, > > One clarification question to your comment ... > > >It forces bgp implementations that don't have > >confederation support to strip out something that will cause an error in > >the regular path and for those systems ignoring the AS4_PATH attribute > >is perfectly fine. > > Why are you saying that there will be an error in the regular > AS_PATH ? As far as I can see the above quote refers only to > AS4_PATH. If an implementation does not support confederations then an AS_PATH with confederation elements will cause an error. Sure an invalid AS4_PATH as that does not imply that the AS_PATH will have the same structure. > The motivation is that instead of dropping the session or treating > as withdraw robust BGP speaker can just remove the unexpected bad > elements from AS4_PATH. In that respect this paragraph seems to add > value and should be kept. It seems you did not finish reading the draft: The AS4_PATH attribute in an UPDATE message SHALL be considered malformed under the following conditions: ... - the path segment type in the attribute is not one of the types defined: AS_SEQUENCE, AS_SET. A NEW BGP speaker that receives a malformed AS4_PATH attribute in an UPDATE message from an OLD BGP speaker MUST discard the attribute, and continue processing the UPDATE message. The error SHOULD be logged locally for analysis. So there is no dropping of the session and also no treat as withdraw. It will just remove a malformed AS4_PATH from the received attributes. Since an AS4_PATH attribute MUST NOT include AS_CONFED_SEQUENCE and AS_CONFED_SET (or anything else but AS_SEQUENCE and AS_SET) it can be considered malformed. What will we gain from having to add complex code for something that should not happen in the first place instead of using the default of reverting back to the regular 2-byte AS_PATH attribute because the AS4_PATH attribute was considered malformed? -- :wq Claudio From enkechen@cisco.com Tue Jun 12 10:37:05 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E9C621F8643 for ; Tue, 12 Jun 2012 10:37:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NrhqN5N5ZJWl for ; Tue, 12 Jun 2012 10:37:04 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 632B721F8655 for ; Tue, 12 Jun 2012 10:37:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=enkechen@cisco.com; l=2804; q=dns/txt; s=iport; t=1339522624; x=1340732224; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=WwVSJOELQcCd93Twe4t2Dl8QXSWtq3i5jJ1xjgaWzdU=; b=FqcInlvl9KvFVtvYA4duEF7IFbKfRIxmsS5DPhKk1pFinENkADggdit+ Do+CrhsbZmqpaRXUmROR3b5/BNIUEbAyiYqZqimud2AfH8264irZUbhPT Ee9DOGnzqI44AabG7hpgyqV0vyjlnXjR0e5bT3sIouiqdJpbcRiPpBwzP c=; X-IronPort-AV: E=Sophos;i="4.75,759,1330905600"; d="scan'208";a="48560356" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 12 Jun 2012 17:37:04 +0000 Received: from sjc-vpn2-1460.cisco.com (sjc-vpn2-1460.cisco.com [10.21.117.180]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q5CHb4eB015263; Tue, 12 Jun 2012 17:37:04 GMT Message-ID: <4FD77E8A.8000103@cisco.com> Date: Tue, 12 Jun 2012 10:38:18 -0700 From: Enke Chen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Claudio Jeker References: <20120601185444.8409.85777.idtracker@ietfa.amsl.com> <20120601220000.GB9448@diehard.n-r-g.com> <4FD71A33.8040901@cisco.com> <20120612135455.GC18025@diehard.n-r-g.com> <4FD76275.5040205@raszuk.net> <20120612171401.GH9448@diehard.n-r-g.com> In-Reply-To: <20120612171401.GH9448@diehard.n-r-g.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr@ietf.org, Robert Raszuk Subject: Re: [Idr] Last Call: (BGP Support for Four-octet AS Number Space) to Proposed Standard X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 17:37:05 -0000 Hi, Claudio: Not sure if you are aware of the large scale outage that occurred a few years ago from the leak of the confed related segments by one implementation. At the time quite a few implementations were resetting the sessions when receiving such updates. While discarding the whole AS4_PATH would be simpler and less disruptive (than session resetting), it would still lose the vital as-path info contained in the AS4_PATH which can otherwise be recovered by "repairing" the attribute. That is why the approach specified in the rfc4893bis is adopted, and it has been implemented widely. -- Enke On 6/12/12 10:14 AM, Claudio Jeker wrote: > On Tue, Jun 12, 2012 at 08:38:29AM -0700, Robert Raszuk wrote: >> Hi Claudio, >> >> One clarification question to your comment ... >> >>> It forces bgp implementations that don't have >>> confederation support to strip out something that will cause an error in >>> the regular path and for those systems ignoring the AS4_PATH attribute >>> is perfectly fine. >> Why are you saying that there will be an error in the regular >> AS_PATH ? As far as I can see the above quote refers only to >> AS4_PATH. > If an implementation does not support confederations then an AS_PATH with > confederation elements will cause an error. Sure an invalid AS4_PATH as > that does not imply that the AS_PATH will have the same structure. > >> The motivation is that instead of dropping the session or treating >> as withdraw robust BGP speaker can just remove the unexpected bad >> elements from AS4_PATH. In that respect this paragraph seems to add >> value and should be kept. > It seems you did not finish reading the draft: > > The AS4_PATH attribute in an UPDATE message SHALL be considered > malformed under the following conditions: > > ... > > - the path segment type in the attribute is not one of the > types defined: AS_SEQUENCE, AS_SET. > > A NEW BGP speaker that receives a malformed AS4_PATH attribute in an > UPDATE message from an OLD BGP speaker MUST discard the attribute, > and continue processing the UPDATE message. The error SHOULD be > logged locally for analysis. > > So there is no dropping of the session and also no treat as withdraw. > It will just remove a malformed AS4_PATH from the received attributes. > Since an AS4_PATH attribute MUST NOT include AS_CONFED_SEQUENCE and > AS_CONFED_SET (or anything else but AS_SEQUENCE and AS_SET) it can be > considered malformed. > > What will we gain from having to add complex code for something that > should not happen in the first place instead of using the default of > reverting back to the regular 2-byte AS_PATH attribute because the > AS4_PATH attribute was considered malformed? > From jgs@juniper.net Tue Jun 12 10:39:02 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7D3D21F8473 for ; Tue, 12 Jun 2012 10:39:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zZEaY9bSy8Zy for ; Tue, 12 Jun 2012 10:39:02 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id EEDB921F8472 for ; Tue, 12 Jun 2012 10:39:01 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKT9d+si1muxU1tRSKbNMkplwVfUKt0OLc@postini.com; Tue, 12 Jun 2012 10:39:01 PDT Received: from [172.16.13.202] (172.16.13.202) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server id 8.3.213.0; Tue, 12 Jun 2012 10:38:25 -0700 MIME-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset="us-ascii" From: "John G. Scudder" In-Reply-To: <3BBED7A5-C064-4D80-B135-CC9B678BAF4D@juniper.net> Date: Tue, 12 Jun 2012 13:38:24 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <3BBED7A5-C064-4D80-B135-CC9B678BAF4D@juniper.net> To: "idr@ietf.org List" X-Mailer: Apple Mail (2.1278) Cc: draft-djsmith-bgp-flowspec-oid@tools.ietf.org Subject: Re: [Idr] Adoption of draft-djsmith-bgp-flowspec-oid-01 as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 17:39:02 -0000 The draft is accepted as an IDR working group document. Authors, please = resubmit as draft-ietf-idr-bgp-flowspec-oid. Thanks, --John=20 On May 16, 2012, at 3:40 PM, John Scudder wrote: > Folks, >=20 > We have received a request from the authors to adopt = draft-djsmith-bgp-flowspec-oid-01 as an IDR WG document. Please send = your comments to the list. The deadline for comments is June 1, 2012 at = noon EDT. >=20 > Thanks, >=20 > --John From enkechen@cisco.com Tue Jun 12 11:19:17 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CEC421F84A6; Tue, 12 Jun 2012 11:19:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 44mTvJOKbgBt; Tue, 12 Jun 2012 11:19:16 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 86A7521F84A0; Tue, 12 Jun 2012 11:19:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=enkechen@cisco.com; l=4069; q=dns/txt; s=iport; t=1339525156; x=1340734756; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=Lw1sIdHAZPtBu0WJOGAVELpx4paMKByDJbGPpOwoqKE=; b=jvV6cTJAlsi5i4A988NlbLRCjGc2V1zfXeS1I8bTTzq4NohjLKLa5dHP DjEJJlvHgvP4MdgyrPzI7rYBaoorMeUJf2iQystvTuAGt+I3kBY/z3n4j xYZZxVjT4oPYdolosSRh8551SmvoZ1B1OZdQrqH38K2RFzhF2NUA7oYYW U=; X-IronPort-AV: E=Sophos;i="4.75,759,1330905600"; d="scan'208";a="48566393" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 12 Jun 2012 18:19:16 +0000 Received: from dhcp-171-71-139-24.cisco.com (dhcp-171-71-139-24.cisco.com [171.71.139.24]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q5CIJGi4021678; Tue, 12 Jun 2012 18:19:16 GMT Message-ID: <4FD7886F.5090508@cisco.com> Date: Tue, 12 Jun 2012 11:20:31 -0700 From: Enke Chen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: stbryant@cisco.com References: <20120612135455.GC18025@diehard.n-r-g.com> <4FD7515E.3000101@cisco.com> In-Reply-To: <4FD7515E.3000101@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr mailing list , "idr-chairs@tools.ietf.org" , "Ietf@ietf.org" Subject: Re: [Idr] Fwd: Re: Last Call: (BGP Support for Four-octet AS Number Space) to Proposed Standard X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 18:19:17 -0000 Here is my reply to Claudio on the IDR list. Copying the IETF list. ------------------------------------------------------ Hi, Claudio: Not sure if you are aware of the large scale outage that occurred a few years ago from the leak of the confed related segments by one implementation. At the time quite a few implementations were resetting the sessions when receiving such updates. While discarding the whole AS4_PATH would be simpler and less disruptive (than session resetting), it would still lose the vital as-path info contained in the AS4_PATH which can otherwise be recovered by "repairing" the attribute. That is why the approach specified in the rfc4893bis is adopted, and it has been implemented widely. -- Enke On 6/12/12 7:25 AM, Stewart Bryant wrote: > FYI > > Copying to IETF list as this is an IETF LC > > Stewart > > -------- Original Message -------- > Subject: Re: [Idr] Last Call: (BGP Support for Four-octet AS > Number Space) to Proposed Standard > Date: Tue, 12 Jun 2012 15:54:55 +0200 > From: Claudio Jeker > To: Stewart Bryant > CC: > > > > On Tue, Jun 12, 2012 at 11:30:11AM +0100, Stewart Bryant wrote: >> On 01/06/2012 23:00, Claudio Jeker wrote: >> >On Fri, Jun 01, 2012 at 11:54:44AM -0700, The IESG wrote: >> >>The IESG has received a request from the Inter-Domain Routing WG >> (idr) to >> >>consider the following document: >> >>- 'BGP Support for Four-octet AS Number Space' >> >> as Proposed Standard >> >> >> >>The IESG plans to make a decision in the next few weeks, and solicits >> >>final comments on this action. Please send substantive comments to the >> >>ietf@ietf.org mailing lists by 2012-06-15. Exceptionally, comments >> may be >> >>sent to iesg@ietf.org instead. In either case, please retain the >> >>beginning of the Subject line to allow automated sorting. >> >> >> >>Abstract >> >> >> >> >> >> The Autonomous System (AS) number is encoded as a two-octet >> entity in >> >> the base BGP specification. This document describes extensions >> to BGP >> >> to carry the Autonomous System numbers as four-octet entities. >> This >> >> document obsoletes RFC 4893. >> >> >> >Just for the sake of clarity, OpenBGPD will not do the following: >> > >> > In addition, the path segment types AS_CONFED_SEQUENCE and >> > AS_CONFED_SET [RFC5065] MUST NOT be carried in the AS4_PATH >> attribute >> > of an UPDATE message. A NEW BGP speaker that receives these path >> > segment types in the AS4_PATH attribute of an UPDATE message >> from an >> > OLD BGP speaker MUST discard these path segments, adjust the >> relevant >> > attribute fields accordingly, and continue processing the UPDATE >> > message. This case SHOULD be logged locally for analysis. >> > >> >There is no point to do this fiddeling instead we will treat this >> like any >> >other parse error of AS4_PATH. >> > >> Claudio >> >> Since this is in last call, I have to ask whether you have objection >> to the publication >> of the above text, or have any proposed text changes? > > I see no reason to enforce AS_CONFED_SEQUENCE and AS_CONFED_SET stripping > on all AS4 implementations. It forces bgp implementations that don't have > confederation support to strip out something that will cause an error in > the regular path and for those systems ignoring the AS4_PATH attribute > is perfectly fine. I do not understand how a workaround needs to be a > MUST for something that is a MUST NOT at the same time? Why MUST we > workaround something that MUST NOT appear? Why do we need to add extra > code that is hard to test and maybe cause for further errors because it > modifies attributes in very uncommon way? > > I propose to remove that paragraph entierly since it does only add > complexity to the protocol for no reason and therefor is only a source of > errors without any benefit. From jgs@juniper.net Wed Jun 13 12:25:36 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAB1C11E80AD for ; Wed, 13 Jun 2012 12:25:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KIRkGDPRl1Lt for ; Wed, 13 Jun 2012 12:25:36 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by ietfa.amsl.com (Postfix) with ESMTP id B80A911E809C for ; Wed, 13 Jun 2012 12:25:32 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKT9jpKZyzMUeBqd379aYrXVlHuXKzxRLJ@postini.com; Wed, 13 Jun 2012 12:25:35 PDT Received: from [172.16.13.202] (172.16.13.202) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server id 8.3.213.0; Wed, 13 Jun 2012 12:24:45 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Apple Message framework v1278) From: "John G. Scudder" In-Reply-To: Date: Wed, 13 Jun 2012 15:24:44 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: To: "idr@ietf.org List" X-Mailer: Apple Mail (2.1278) Subject: Re: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 19:25:37 -0000 Folks, Although there has been a lively discussion about the merits of the = draft, I have seen only four replies from people other than co-authors = that clearly stated a preference for adoption. If you have not yet = stated a preference, and have one, I encourage you to do so. The comment period will end on Friday. --John P.S.: If you replied but changed the subject line it is possible I = didn't include your message in my tally. On May 31, 2012, at 1:10 PM, John Scudder wrote: > Folks, >=20 > We have received a request from the authors to adopt = draft-uttaro-idr-bgp-persistence-01 as an IDR WG document. Please send = your comments to the list. The deadline for comments is June 15, 2012 = at noon EDT. >=20 > Thanks, >=20 > --John From randy@psg.com Wed Jun 13 14:06:29 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEC8121F8597 for ; Wed, 13 Jun 2012 14:06:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5qdrm+dZHXJL for ; Wed, 13 Jun 2012 14:06:28 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 2B5B521F8596 for ; Wed, 13 Jun 2012 14:06:26 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Seull-000Ayw-Ez; Wed, 13 Jun 2012 21:06:25 +0000 Date: Thu, 14 Jun 2012 06:06:24 +0900 Message-ID: From: Randy Bush To: "John G. Scudder" In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: idr wg Subject: Re: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 21:06:29 -0000 i guess i support adoption, but wonder if there is a walter scott idr sub-wg o fix the grammar o 4.1.1 needs a capitalized MUST and has yucchy semantic issues, e.g. it mandates propagating a stale path whose pref has been lowered when that may not have been or may no longer be the best path. it mandates generating a withdraw when the route may not have been propagated, ... o 4.1.2 needs to make clear that all routers should use the same value for knocking down local-pref o 8 there are other attacks. e.g. a wire grab no longer needs to keep ip state up at all. i am sure i could think of more if i had coffee. randy From robert@raszuk.net Wed Jun 13 16:26:02 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8651011E80C0 for ; Wed, 13 Jun 2012 16:26:02 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sag8-TdUr-Fe for ; Wed, 13 Jun 2012 16:26:02 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id AA75C11E80B0 for ; Wed, 13 Jun 2012 16:26:01 -0700 (PDT) Received: (qmail 2450 invoked by uid 399); 13 Jun 2012 23:26:00 -0000 Received: from unknown (HELO ?172.16.197.148?) (pbs:robert@raszuk.net@58.80.213.53) by mail1310.opentransfer.com with ESMTPM; 13 Jun 2012 23:26:00 -0000 X-Originating-IP: 58.80.213.53 Message-ID: <4FD92187.8080403@raszuk.net> Date: Wed, 13 Jun 2012 16:25:59 -0700 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120604 Thunderbird/13.0 MIME-Version: 1.0 To: "John G. Scudder" References: <4911_1338974288_4FCF2050_4911_12906_1_53C29892C857584299CBF5D05346208A08CA08@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FCF800C.6070509@joelhalpern.com> <4FCF883B.6050501@raszuk.net> <4FCFEC86.6050706@raszuk.net> <8684_1339102246_4FD11426_8684_17472_1_53C29892C857584299CBF5D05346208A08D397@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FD1E202.6090503@raszuk.net> <1407_1339164741_4FD20845_1407_271_1_53C29892C857584299CBF5D05346208A08E913@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FD20D9E.2010505@raszuk.net> <4FD21577.2030103@raszuk.net> <4FD21CD7.30806@raszuk.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org List" Subject: Re: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 23:26:02 -0000 Hi John, #1 question which Jakob stated is still not answered. Should STALE path be less or more preferred then non stale less specific one. The question makes a lot of sense and if the answer is yes then I am afraid BGP implementations will become really complicated. There is one way to avoid such complication by adding a trick to simple-va which would conditionally suppress stale path regardless of next hope if less specific covering it is present without STALE flag. This could be much simpler then messing with best path to compare different nets. That would also mean that persistence MUST be always used with simple-va. #2 In all cases where persistence draft may apply (VPLS) you may as well configure the service without BGP. We are just propagating static config in BGP here essentially. #3 For most other cases right network design removes the need for persistence draft. For transient BGP session flaps basic GR with perhaps longer timer works fine to maintain data plane connectivity. #4 The proposal does not mandate new capability in BGP. In networks with mixed persistence support and no support especially on EBGP links this seems extremely dangerous feature. Draft discusses the sender cases where bgp speaker is persistence capable. But the draft neglects to mention the handling on the receiver where the receiver is not capable of recognizing the STALE community and still selects the STALE path as best even if there is non STALE path present for the given net. As community is an opaque value for it the re-advertisement of STALE will happen and good valid path even if longer will be not promoted as best. As mentioned in the other comment the way the draft is worded today has a potential to introduce significant churn in the Internet when any single BGP speaker experiences BGP session flap and starts the re-advertise full table with and without STALE color. To mitigate that persistence was suggested to use _only_ with GR (and do nothing before the GR timer expires .. Bruno agreed with that - but the draft does not mandate GR which IMHO it should). To clearly conclude looking at cost/benefit equation I am not supporting adoption of this proposal the way the draft is fundamentally written today. It is not that we could work on bits and pieces after adoption. It is that there are fundamental issues with it today. Also I am not agreeing in principle with basic pre-assumption for this work Jim mentioned in the reply that flaky and "maybe reachable" route is better then no route. I prefer the latter. The reason being is that if we declare no reachability in BGP other (upper/application) layers could converge around it. If we "pretend" in BGP the reachability is there while it is not, application few hops away has no way of knowing it. Best regards, R. > Robert, > > The general tone of your comments leads me to think you may be > against WG adoption of the document, but I haven't seen any clear > statement from you so thus far I am not counting you either way. If > you want to clarify a position feel free to either ucast me or reply > to the list. > > By the way, thank you for your contribution to the discussion. > > --John > From robert@raszuk.net Wed Jun 13 17:05:17 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EE4911E808F for ; Wed, 13 Jun 2012 17:05:17 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WOCkZyD7uxId for ; Wed, 13 Jun 2012 17:05:17 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 2A71711E80DC for ; Wed, 13 Jun 2012 17:05:16 -0700 (PDT) Received: (qmail 16223 invoked by uid 399); 14 Jun 2012 00:05:15 -0000 Received: from unknown (HELO ?172.16.197.148?) (pbs:robert@raszuk.net@58.80.213.53) by mail1310.opentransfer.com with ESMTPM; 14 Jun 2012 00:05:15 -0000 X-Originating-IP: 58.80.213.53 Message-ID: <4FD92ABA.6080100@raszuk.net> Date: Wed, 13 Jun 2012 17:05:14 -0700 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120604 Thunderbird/13.0 MIME-Version: 1.0 To: "John G. Scudder" References: <4911_1338974288_4FCF2050_4911_12906_1_53C29892C857584299CBF5D05346208A08CA08@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FCF800C.6070509@joelhalpern.com> <4FCF883B.6050501@raszuk.net> <4FCFEC86.6050706@raszuk.net> <8684_1339102246_4FD11426_8684_17472_1_53C29892C857584299CBF5D05346208A08D397@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FD1E202.6090503@raszuk.net> <1407_1339164741_4FD20845_1407_271_1_53C29892C857584299CBF5D05346208A08E913@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FD20D9E.2010505@raszuk.net> <4FD21577.2030103@raszuk.net> <4FD21CD7.30806@raszuk.net> <4FD92187.8080403@raszuk.net> In-Reply-To: <4FD92187.8080403@raszuk.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org List" Subject: Re: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 00:05:17 -0000 > Also I am not agreeing in principle with basic pre-assumption for this > work Jim mentioned in the reply that flaky and "maybe reachable" route > is better then no route. I prefer the latter. The reason being is that > if we declare no reachability in BGP other (upper/application) layers > could converge around it. If we "pretend" in BGP the reachability is > there while it is not, application few hops away has no way of knowing it. Let me expand a bit on this point as I think this is important. Imagine an ASBR with BGP connection to peering AS as well as with wireless connection as backup to the other AS. The protocol running over wireless connection is ROLL. By default ROLL will have higher admin distance (will be less preferred) when competing against the same prefix at the RIB insertion. If we do not remove the flaky and "perhaps reachable" prefix from BGP the other backup path has no chance to be installed in RIB. That effectively means that we have broken any backup/redundancy options which may be coming to a router outside of BGP. /* The same story also applies to ALTO or similar tools where sources for information may be coming from other then BGP protocols. */ Best regards, R. From enkechen@cisco.com Wed Jun 13 17:31:02 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C9DC11E80AF for ; Wed, 13 Jun 2012 17:31:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0UIb11S9j7Z4 for ; Wed, 13 Jun 2012 17:31:01 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 5D7B321F852D for ; Wed, 13 Jun 2012 17:31:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=enkechen@cisco.com; l=1860; q=dns/txt; s=iport; t=1339633861; x=1340843461; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=tGdP+SLBHKPy6CJgAOiCOZYXtujdh9Ur5hCQ/gFBLzU=; b=HHM+mZoZFPIx762L5pyeH+gYe1C5as+baM3Gh/VO0MORvr1kdUL3IRNw xtc5bS0JIEDpG5U58yX7GYKMGq5IMwAR9IFBzzO/Sgnl8rqSfKtInbQeM Xh8DvXZv7dVEKng1hV0OZx8nOFn9uy/AO9GCZ0ajwIu6K7QF3iZwzBfpa 0=; X-IronPort-AV: E=Sophos;i="4.75,768,1330905600"; d="scan'208";a="46295444" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 14 Jun 2012 00:31:01 +0000 Received: from dhcp-171-71-139-24.cisco.com (dhcp-171-71-139-24.cisco.com [171.71.139.24]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q5E0V0OT004569; Thu, 14 Jun 2012 00:31:01 GMT Message-ID: <4FD93110.9090505@cisco.com> Date: Wed, 13 Jun 2012 17:32:16 -0700 From: Enke Chen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: "John G. Scudder" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org List" Subject: Re: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 00:31:02 -0000 Hi, folks: As I stated on this mailing list before, I believe that most of the key requirements specified in the "persistence draft" can be easily addressed by a couple knobs with GR: o introduce the concept of the "minimal stale timer" in GR: This will allow the stale routes to be kept for a much longer time if so configured locally. o use a stale path first, and then switch to an alternate path after a certain amount of time: This would be locally configurable. They can be easily covered by adding some text in the GR re-spin which is in progress. It seems logical also for GR to cover these points. Then GR would not be limited to just "shorter timers". As the concept of GR is well established, and it already provides "persistence", I do not see much value for IDR to have another spec that conceptually and operationally overlaps with it. -- Enke On 6/13/12 12:24 PM, John G. Scudder wrote: > Folks, > > Although there has been a lively discussion about the merits of the draft, I have seen only four replies from people other than co-authors that clearly stated a preference for adoption. If you have not yet stated a preference, and have one, I encourage you to do so. > > The comment period will end on Friday. > > --John > > P.S.: If you replied but changed the subject line it is possible I didn't include your message in my tally. > > On May 31, 2012, at 1:10 PM, John Scudder wrote: > >> Folks, >> >> We have received a request from the authors to adopt draft-uttaro-idr-bgp-persistence-01 as an IDR WG document. Please send your comments to the list. The deadline for comments is June 15, 2012 at noon EDT. >> >> Thanks, >> >> --John > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From jgs@juniper.net Wed Jun 13 17:50:57 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71CB911E80E3 for ; Wed, 13 Jun 2012 17:50:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lB9N8jT3itoB for ; Wed, 13 Jun 2012 17:50:56 -0700 (PDT) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by ietfa.amsl.com (Postfix) with ESMTP id 3C65911E80E9 for ; Wed, 13 Jun 2012 17:50:55 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKT9k1ZcdH3Mx4k0irjAZA4vOIqYOfjSGA@postini.com; Wed, 13 Jun 2012 17:50:56 PDT Received: from [172.16.13.202] (172.16.13.202) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server id 8.3.213.0; Wed, 13 Jun 2012 17:48:48 -0700 MIME-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset="iso-8859-1" From: "John G. Scudder" In-Reply-To: <4FD92187.8080403@raszuk.net> Date: Wed, 13 Jun 2012 20:48:47 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <2B37563C-F3E2-4113-A5A2-35BA83F64FC3@juniper.net> References: <4911_1338974288_4FCF2050_4911_12906_1_53C29892C857584299CBF5D05346208A08CA08@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FCF800C.6070509@joelhalpern.com> <4FCF883B.6050501@raszuk.net> <4FCFEC86.6050706@raszuk.net> <8684_1339102246_4FD11426_8684_17472_1_53C29892C857584299CBF5D05346208A08D397@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FD1E202.6090503@raszuk.net> <1407_1339164741_4FD20845_1407_271_1_53C29892C857584299CBF5D05346208A08E913@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FD20D9E.2010505@raszuk.net> <4FD21577.2030103@raszuk.net> <4FD21CD7.30806@raszuk.net> <4FD92187.8080403@raszuk.net> To: "robert@raszuk.net" X-Mailer: Apple Mail (2.1278) Cc: "idr@ietf.org List" Subject: Re: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 00:50:57 -0000 Robert, To this point: On Jun 13, 2012, at 7:25 PM, Robert Raszuk wrote: > In networks with=20 > mixed persistence support and no support especially on EBGP links this=20= > seems extremely dangerous feature. Your concern for "mixed persistence support" would actually seem to = support the opposite point of view, that this *should* be standardized. = As you know, one key reason to standardize things is to facilitate = deployment of such features in mixed networks. I expect this will not be persuasive to you given your other objections, = but I thought I should point it out. Regards, --John= From john@jlc.net Wed Jun 13 17:52:55 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C68911E80AC for ; Wed, 13 Jun 2012 17:52:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gpGAPQktOyj8 for ; Wed, 13 Jun 2012 17:52:55 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 0819311E80E8 for ; Wed, 13 Jun 2012 17:52:55 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 3E79433C22; Wed, 13 Jun 2012 20:52:55 -0400 (EDT) Date: Wed, 13 Jun 2012 20:52:55 -0400 From: John Leslie To: "John G. Scudder" Message-ID: <20120614005255.GQ21341@verdi> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Cc: "idr@ietf.org List" Subject: Re: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 00:52:55 -0000 John G. Scudder wrote: > > Although there has been a lively discussion about the merits of the draft, > I have seen only four replies from people other than co-authors that > clearly stated a preference for adoption. If you have not yet stated a > preference, and have one, I encourage you to do so. Despite the impressive author list, I'd really rather not adopt it. Most of my particular dislikes _could_ be addressed: but this sort of thing should be between consenting adults, with warning labels; and I don't see a practical way to ensure reasonably quick propagation of unreachability. In no way do I mean to say that an individual AS can't continue to _use_ stale routes -- but we don't need an RFC for them to do so. I'm very nervous about _advertising_ stale routes; and I fear that with idr-bgp-persistence, we'd have legacy routers advertising them as if they were good. (You asked...) -- John Leslie From robert@raszuk.net Wed Jun 13 19:52:54 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B30811E80F0 for ; Wed, 13 Jun 2012 19:52:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=0.930, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nGQlwBR2b1RN for ; Wed, 13 Jun 2012 19:52:54 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id CAD2E11E80F1 for ; Wed, 13 Jun 2012 19:52:53 -0700 (PDT) Received: (qmail 8619 invoked by uid 399); 14 Jun 2012 02:52:53 -0000 Received: from unknown (HELO ?10.30.3.58?) (pbs:robert@raszuk.net@45.0.224.238) by mail1310.opentransfer.com with ESMTPM; 14 Jun 2012 02:52:53 -0000 X-Originating-IP: 45.0.224.238 Message-ID: <4FD95202.2010205@raszuk.net> Date: Wed, 13 Jun 2012 19:52:50 -0700 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120604 Thunderbird/13.0 MIME-Version: 1.0 To: "John G. Scudder" References: <4911_1338974288_4FCF2050_4911_12906_1_53C29892C857584299CBF5D05346208A08CA08@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FCF800C.6070509@joelhalpern.com> <4FCF883B.6050501@raszuk.net> <4FCFEC86.6050706@raszuk.net> <8684_1339102246_4FD11426_8684_17472_1_53C29892C857584299CBF5D05346208A08D397@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FD1E202.6090503@raszuk.net> <1407_1339164741_4FD20845_1407_271_1_53C29892C857584299CBF5D05346208A08E913@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FD20D9E.2010505@raszuk.net> <4FD21577.2030103@raszuk.net> <4FD21CD7.30806@raszuk.net> <4FD92187.8080403@raszuk.net> <2B37563C-F3E2-4113-A5A2-35BA83F64FC3@junipe r.net> In-Reply-To: <2B37563C-F3E2-4113-A5A2-35BA83F64FC3@juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org List" Subject: Re: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 02:52:54 -0000 Hi John, Actually not. Standardization does not equal that a feature will be enabled or router image automatically upgraded after RFC is issued :). As long as EBGP speaker I do not control will not support this extension I will still signal a STALE path with the community which he will consider as good as not STALE one. To your point the case today between any two adjacent ASes (and within the AS) you can achieve persistence by just agreeing on some community value internally. Best regards, R. > Robert, > > To this point: > > On Jun 13, 2012, at 7:25 PM, Robert Raszuk wrote: > >> In networks with >> mixed persistence support and no support especially on EBGP links this >> seems extremely dangerous feature. > > Your concern for "mixed persistence support" would actually seem to support the opposite point of view, that this *should* be standardized. As you know, one key reason to standardize things is to facilitate deployment of such features in mixed networks. > > I expect this will not be persuasive to you given your other objections, but I thought I should point it out. > > Regards, > > --John > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > From enkechen@cisco.com Wed Jun 13 20:08:02 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB7E511E80EE for ; Wed, 13 Jun 2012 20:08:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IW4cNYKgw+KU for ; Wed, 13 Jun 2012 20:08:02 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id E72CD11E80CE for ; Wed, 13 Jun 2012 20:07:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=enkechen@cisco.com; l=1930; q=dns/txt; s=iport; t=1339643269; x=1340852869; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=U+stsYX5Bre05BE5Dh/5LEADxyl3TuIrPgRgzY0WUUw=; b=HMYSPRZUI4HeoSByx5jQ7TY25Sw5ngVTr6LRX8zOq4BeEJN8Se11jb1P 2fq7nOoxqLExCPZ63XYCSCb8npjtJaEDY718VpPqrrXPp7XvnRvmN+2mF 9TMRUoRTURg3dXvBJbUwgfDaW0We68SE0Qzxnd2BUFaZNL6bYFtExwn6l 4=; X-IronPort-AV: E=Sophos;i="4.75,768,1330905600"; d="scan'208";a="45768183" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 14 Jun 2012 03:07:49 +0000 Received: from enkechen-mac.local ([10.21.72.252]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q5E37nqn015538; Thu, 14 Jun 2012 03:07:49 GMT Message-ID: <4FD955D1.8090807@cisco.com> Date: Wed, 13 Jun 2012 20:09:05 -0700 From: Enke Chen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: robert@raszuk.net References: <4FCF800C.6070509@joelhalpern.com> <4FCF883B.6050501@raszuk.net> <4FCFEC86.6050706@raszuk.net> <8684_1339102246_4FD11426_8684_17472_1_53C29892C857584299CBF5D05346208A08D397@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FD1E202.6090503@raszuk.net> <1407_1339164741_4FD20845_1407_271_1_53C29892C857584299CBF5D05346208A08E913@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FD20D9E.2010505@raszuk.net> <4FD21577.2030103@raszuk.net> <4FD21CD7.30806@raszuk.net> <4FD92187.8080403@raszuk.net> <2B37563C-F3E2-4113-A5A2-35BA83F64FC3@junipe r.net> <4FD95202.2010205@raszuk.net> In-Reply-To: <4FD95202.2010205@raszuk.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org List" Subject: Re: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 03:08:03 -0000 Just try to point out the obvious: in general a new global community is difficult to roll out. The lack of scoping creates many operationally issues such as who can set it, who can override it, and where to accept and where to filter. It can be a burden for all involved, e.g., it has to be filtered out everywhere in a network if one does not want to use it. -- Enke On 6/13/12 7:52 PM, Robert Raszuk wrote: > Hi John, > > Actually not. Standardization does not equal that a feature will be > enabled or router image automatically upgraded after RFC is issued :). > > As long as EBGP speaker I do not control will not support this > extension I will still signal a STALE path with the community which he > will consider as good as not STALE one. > > To your point the case today between any two adjacent ASes (and within > the AS) you can achieve persistence by just agreeing on some community > value internally. > > Best regards, > R. > >> Robert, >> >> To this point: >> >> On Jun 13, 2012, at 7:25 PM, Robert Raszuk wrote: >> >>> In networks with >>> mixed persistence support and no support especially on EBGP links this >>> seems extremely dangerous feature. >> >> Your concern for "mixed persistence support" would actually seem to >> support the opposite point of view, that this *should* be >> standardized. As you know, one key reason to standardize things is to >> facilitate deployment of such features in mixed networks. >> >> I expect this will not be persuasive to you given your other >> objections, but I thought I should point it out. >> >> Regards, >> >> --John >> _______________________________________________ >> 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 From john@jlc.net Wed Jun 13 23:26:12 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99D3811E8088; Wed, 13 Jun 2012 23:26:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gN3GIrbP+aXK; Wed, 13 Jun 2012 23:26:12 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id A904611E8087; Wed, 13 Jun 2012 23:26:11 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id CE9D933C22; Thu, 14 Jun 2012 02:26:10 -0400 (EDT) Date: Thu, 14 Jun 2012 02:26:10 -0400 From: John Leslie To: Claudio Jeker , idr@ietf.org, ietf@ietf.org Message-ID: <20120614062610.GR21341@verdi> References: <20120612135455.GC18025@diehard.n-r-g.com> <4FD7515E.3000101@cisco.com> <4FD7886F.5090508@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4FD7886F.5090508@cisco.com> User-Agent: Mutt/1.4.1i Subject: Re: [Idr] Last Call: (BGP Support for Four-octet AS Number Space) to Proposed Standard X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 06:26:12 -0000 Enke Chen wrote: > On 6/12/12 7:25 AM, Stewart Bryant wrote: > From: Claudio Jeker >> On Tue, Jun 12, 2012 at 11:30:11AM +0100, Stewart Bryant wrote: >>> On 01/06/2012 23:00, Claudio Jeker wrote: >>>> On Fri, Jun 01, 2012 at 11:54:44AM -0700, The IESG wrote: >>>>> >>>>> The IESG has received a request from the Inter-Domain Routing WG >>>>> (idr) to consider the following document: >>>>> - 'BGP Support for Four-octet AS Number Space' >>>>> as Proposed Standard >>>>> >>>>> Abstract >>>>> >>>>> The Autonomous System (AS) number is encoded as a two-octet >>>>> entity in the base BGP specification. This document describes >>>>> extensions to BGP to carry the Autonomous System numbers as >>>>> four-octet entities. This document obsoletes RFC 4893. >>>> >>>> Just for the sake of clarity, OpenBGPD will not do the following: >>>> >>>> In addition, the path segment types AS_CONFED_SEQUENCE and >>>> AS_CONFED_SET [RFC5065] MUST NOT be carried in the AS4_PATH >>>> attribute of an UPDATE message. A NEW BGP speaker that receives >>>> these path segment types in the AS4_PATH attribute of an UPDATE >>>> message from an OLD BGP speaker MUST discard these path segments, >>>> adjust the relevant attribute fields accordingly, and continue >>>> processing the UPDATE message. This case SHOULD be logged locally >>>> for analysis. >>>> >>>> There is no point to do this fiddeling instead we will treat this >>>> like any other parse error of AS4_PATH. >>>> >>>> Claudio That would make the OpenBSD implementation non-compliant with 4893bis. >>> Since this is in last call, I have to ask whether you have objection >>> to the publication of the above text, or have any proposed text >>> changes? >> >> I see no reason to enforce AS_CONFED_SEQUENCE and AS_CONFED_SET stripping >> on all AS4 implementations. It forces bgp implementations that don't have >> confederation support to strip out something that will cause an error in >> the regular path and for those systems ignoring the AS4_PATH attribute >> is perfectly fine. I do not understand how a workaround needs to be a >> MUST for something that is a MUST NOT at the same time? Why MUST we >> workaround something that MUST NOT appear? Why do we need to add extra >> code that is hard to test and maybe cause for further errors because it >> modifies attributes in very uncommon way? Enke explains why this is called for in 4893bis. It may help to recall the IETF mantra: "We believe in rough consensus and running code." At the time 4893 was designed, it was a strict requirement in IDR that nothing could get to Proposed Standard without demonstrating multiple implementations. In practice, this meant we only documented something after multiple vendors had it deployed. Thus, 4893 went out with bugs (though I was in the rough, explaining in general terms some weaknesses). One bug in particular turned out to be _very_ serious. Patching in the AS4_PATH produced some AS_CONFED stuff very much out of context. A fix was desperately needed, and several vendors quickly patched it. 4893bis, as I understood it, documented this fix. I'm still in the rough, but I saw no point in objecting to documenting actual practice. If in fact, OpenBSD has no intention of patching for this bug, _they_ need to be considered "in the rough" (as well as non-compliant). If, OTOH, they wish to propose a different fix, it's possible the IESG might ask IDR to consider it. (I can certainly imagine better ways to resolve the problem.) But any fix (IMHO) _must_ dispose of out-of-context AS_CONFED stuff that still may be in the wild. >> I propose to remove that paragraph entierly since it does only add >> complexity to the protocol for no reason and therefor is only a source >> of errors without any benefit. (I cannot endorse that proposal. It's too likely there's legacy equipment that allows AS_CONFED stuff to be placed in AS4_PATH.) > Hi, Claudio: > > Not sure if you are aware of the large scale outage that occurred a few > years ago from the leak of the confed related segments by one > implementation. At the time quite a few implementations were resetting > the sessions when receiving such updates. > > While discarding the whole AS4_PATH would be simpler and less disruptive > (than session resetting), it would still lose the vital as-path info > contained in the AS4_PATH which can otherwise be recovered by > "repairing" the attribute. That is why the approach specified in the > rfc4893bis is adopted, and it has been implemented widely. > > -- Enke -- John Leslie From jie.dong@huawei.com Thu Jun 14 01:10:29 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE3F021F866D for ; Thu, 14 Jun 2012 01:10:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.684 X-Spam-Level: X-Spam-Status: No, score=-5.684 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fwpqB4xSRwKY for ; Thu, 14 Jun 2012 01:10:24 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 6ABCF21F866B for ; Thu, 14 Jun 2012 01:10:24 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHE14190; Thu, 14 Jun 2012 04:10:23 -0400 (EDT) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 14 Jun 2012 01:09:33 -0700 Received: from SZXEML416-HUB.china.huawei.com (10.82.67.155) by dfweml406-hub.china.huawei.com (10.193.5.131) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 14 Jun 2012 01:09:38 -0700 Received: from SZXEML504-MBX.china.huawei.com ([169.254.4.129]) by szxeml416-hub.china.huawei.com ([10.82.67.155]) with mapi id 14.01.0323.003; Thu, 14 Jun 2012 16:09:31 +0800 From: Jie Dong To: "robert@raszuk.net" , "UTTARO, JAMES" Thread-Topic: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR WG document Thread-Index: AQHNRD8LwNJmTzWfMUuT2X6qQWRzSJb5gB1A Date: Thu, 14 Jun 2012 08:09:31 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C927324FF999@szxeml504-mbx.china.huawei.com> References: <4911_1338974288_4FCF2050_4911_12906_1_53C29892C857584299CBF5D05346208A08CA08@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FCF800C.6070509@joelhalpern.com> <4FCF883B.6050501@raszuk.net> <4FCFEC86.6050706@raszuk.net> In-Reply-To: <4FCFEC86.6050706@raszuk.net> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.97.57] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "idr@ietf.org List" , "Joel M. Halpern" Subject: Re: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 08:10:29 -0000 > That way in the event of use of persistent communities or shutdown on > existing SAFIs single message could be send not re-advertisements of > millions of routes. And that significance will only grow when you > attempt to do path validation or other fancy processing inbound of each > advertisement. Agreed that using a single message instead of re-advertising millions of ro= utes in such cases would be better.=20 Best regards, Jie > -----Original Message----- > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Rob= ert > Raszuk > Sent: Thursday, June 07, 2012 7:49 AM > To: UTTARO, JAMES > Cc: idr@ietf.org List; Joel M. Halpern > Subject: Re: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR= WG > document >=20 > Jim, >=20 > Adding more use cases is clearly good thing. >=20 > But I was in particular asking for a stronger text explicitly forbidding > implementation to make IPv4 or IPv6 routes as persistent. >=20 > For 1/4, 1/128 or any other "application" SAFIs I think that at the end > you may do what you like :) >=20 > Today Internet churn is already not low ... this draft if used > incorrectly for Internet can cause additional re-advertisements based on > local flaps (where GR you are keep comparing it with would not). >=20 > And just as a reference point on old NPE400 I peered with the AS290 > yesterday here in Tokyo interop I get 60%-70% CPU use all the time >=20 > CE_c72_Internet#sh proc cpu > CPU utilization for five seconds: 99%/23%; one minute: 67%; five > minutes: 83% > .... > 103 26649044 209857 126987 62.32% 41.94% 56.76% 0 > BGP Router >=20 > So while any knob may look nice on the paper it does have an impact > Internet wide and that's main reason I am a bit skeptical on adding more > to SAFI 1/1 and 2/1. >=20 > In general I think we are really missing the indirection in signalling > SAFI wide parameters in BGP. Perhaps if WG thinks this would be good > idea we could propose a simple new draft for defining a new signalling > SAFI for all other SAFI wide events. >=20 > That way in the event of use of persistent communities or shutdown on > existing SAFIs single message could be send not re-advertisements of > millions of routes. And that significance will only grow when you > attempt to do path validation or other fancy processing inbound of each > advertisement. >=20 > I know you can apply persistence to subset of prefixes however I doubt > that this would be practical deployment case. Clearly for shutdown it > does not make much sense to only signal subset of marked routes in a > given SAFI that are going down soon. >=20 > Best regards, > R. >=20 >=20 >=20 > > Robert > > > > We can add addl use cases.. I have this on my to do list.. I believe > > the 3107 use case is high on the list, BGP signaled multicast may be > > another, BRAS etc... We could have a long list here and I do not want > > to be prescriptive so I will add the 3107 use case > > > > Jim Uttaro > > > > -----Original Message----- From: idr-bounces@ietf.org > > [mailto:idr-bounces@ietf.org] On Behalf Of Robert Raszuk Sent: > > Wednesday, June 06, 2012 12:42 PM To: Joel M. Halpern Cc: > > idr@ietf.org List Subject: Re: [Idr] Adoption of > > draft-uttaro-idr-bgp-persistence-01 as IDR WG document > > > > Hi Joel, > > > > Great comment. In fact some of the co-authors of this document target > > to use it in also in the SAFI 1/1 or 2/1 even so the draft softly > > target a bit different application space: > > > > "This document addresses new services whose requirements for > > persistence diverge from the Internet routing point of view." > > > > With this in mind how about either explicitly enumerating those > > AFI/SAFIs which can use such knob or specify those AFI/SAFIs which > > MUST NOT support it ? > > > > Of course this is assuming we will go with accepting this as WG doc > > in the first place :) > > > > Best regards, R. > > > > > >> The question for adopting this seems to be whether the folks who > >> have to turn it on can tell when it is safe to do so, and when it > >> isn't. The L2VPN example in the document is an example of why it is > >> worth considering. The L3VPN example seems to show a dangerous use > >> case. > >> > >> Yours, Joel M. Halpern > >> > >> On 6/6/2012 5:18 AM, bruno.decraene@orange.com wrote: > >>> Hi, > >>> > >>> Support. > >>> > >>> Regards, Bruno > >>> > >>>> From: John Scudder>Sent: Thursday, May 31, 2012 7:10 PM > >>>> > >>>> Folks, > >>>> > >>>> We have received a request from the authors to adopt > >>>> draft-uttaro-idr-bgp- persistence-01 as an IDR WG document. > >>>> Please send your comments to the list. The deadline for > >>>> comments is June 15, 2012 at noon EDT. > >>>> > >>>> Thanks, > >>>> > >>>> --John _______________________________________________ Idr > >>>> mailing list Idr@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/idr > >>> > >>> > ________________________________________________________________ > _________________________________________________________ > >>> > >>> > >>> > >>> > Ce message et ses pieces jointes peuvent contenir des informations > >>> confidentielles ou privilegiees et ne doivent donc pas etre > >>> diffuses, exploites ou copies sans autorisation. Si vous avez > >>> recu ce message par erreur, veuillez le signaler a l'expediteur > >>> et le detruire ainsi que les pieces jointes. Les messages > >>> electroniques etant susceptibles d'alteration, France Telecom - > >>> Orange decline toute responsabilite si ce message a ete altere, > >>> deforme ou falsifie. Merci. > >>> > >>> This message and its attachments may contain confidential or > >>> privileged information that may be protected by law; they should > >>> not be distributed, used or copied without authorisation. If you > >>> have received this email in error, please notify the sender and > >>> delete this message and its attachments. As emails may be > >>> altered, France Telecom - Orange is not liable for messages that > >>> have been modified, changed or falsified. Thank you. > >>> > >>> _______________________________________________ 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 > >> > >> > > > > > > _______________________________________________ Idr mailing list > > Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr > > > > >=20 >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From bruno.decraene@orange.com Thu Jun 14 03:26:50 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12CD621F8557 for ; Thu, 14 Jun 2012 03:26:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 61sw3yyvezr3 for ; Thu, 14 Jun 2012 03:26:49 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id CC9FE21F8555 for ; Thu, 14 Jun 2012 03:26:48 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 1AD2418C13B; Thu, 14 Jun 2012 12:26:47 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id EF18927C053; Thu, 14 Jun 2012 12:26:46 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Thu, 14 Jun 2012 12:26:46 +0200 From: To: Jakob Heitz , "robert@raszuk.net" Thread-Topic: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR WG document Thread-Index: AQHNRLV1Krxik7qjvku42V+dyzAtsJbu3kuAgAq8kWA= Date: Thu, 14 Jun 2012 10:26:46 +0000 Message-ID: <3185_1339669607_4FD9BC66_3185_4099_6_53C29892C857584299CBF5D05346208A08FC9B@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <4911_1338974288_4FCF2050_4911_12906_1_53C29892C857584299CBF5D05346208A08CA08@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FCF800C.6070509@joelhalpern.com> <4FCF883B.6050501@raszuk.net> <4FCFEC86.6050706@raszuk.net> <507A0451-C11D-4CFB-8EE1-073220B1631E@cisco.com> <4FD0B33B.50603@raszuk.net> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.6.14.93315 Cc: "idr@ietf.org List" , "Joel M. Halpern" , "UTTARO, JAMES" Subject: Re: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 10:26:50 -0000 Hi Jakob, >From: Jakob Heitz [mailto:jakob.heitz@ericsson.com] >Sent: Thursday, June = 07, 2012 5:46 PM > >On Jun 7, 2012, at 6:57 AM, "Robert Raszuk" wrote: >> As the STALE routes are not dynamically updated anymore, it's >> desirable that they be only used in last resort. Hence when >> comparing paths for a prefix, a non STALE path should be preferred >> over a STALE path. > >should a path with a shorter prefix also be preferred? >Say the stale path is 10.0.0.0/24 and 10.0.0.0/16 exists and is not stale. You are raising a good point. While preferring non stale more specific prefix over stale prefix could pro= bably make sense, IMHO I would not push persistence in this direction: - too much change in BGP - to some extend, the point of more specific prefixes being preferred in th= e forwarding plane independently of the BGP preferences is a different subj= ect. E.g. draft-francois-limited-scope-specifics-01 is another aspect. Regards, Bruno ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From bruno.decraene@orange.com Thu Jun 14 03:32:12 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 489A721F8664 for ; Thu, 14 Jun 2012 03:32:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AiGgbu9WMZIt for ; Thu, 14 Jun 2012 03:32:11 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 10EE221F8659 for ; Thu, 14 Jun 2012 03:32:11 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 723E922C42C; Thu, 14 Jun 2012 12:32:10 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 58A0623804B; Thu, 14 Jun 2012 12:32:10 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Thu, 14 Jun 2012 12:32:10 +0200 From: To: "robert@raszuk.net" Thread-Topic: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR WG document Thread-Index: AQHNSbvqKrxik7qjvku42V+dyzAtsJb5kExA Date: Thu, 14 Jun 2012 10:32:09 +0000 Message-ID: <13306_1339669930_4FD9BDAA_13306_6206_1_53C29892C857584299CBF5D05346208A08FCCA@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <4911_1338974288_4FCF2050_4911_12906_1_53C29892C857584299CBF5D05346208A08CA08@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FCF800C.6070509@joelhalpern.com> <4FCF883B.6050501@raszuk.net> <4FCFEC86.6050706@raszuk.net> <8684_1339102246_4FD11426_8684_17472_1_53C29892C857584299CBF5D05346208A08D397@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FD1E202.6090503@raszuk.net> <1407_1339164741_4FD20845_1407_271_1_53C29892C857584299CBF5D05346208A08E913@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FD20D9E.2010505@raszuk.net> <4FD21577.2030103@raszuk.net> <4FD21CD7.30806@raszuk.net> <4FD92187.8080403@raszuk.net> In-Reply-To: <4FD92187.8080403@raszuk.net> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.6.14.93315 Cc: "idr@ietf.org List" Subject: Re: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 10:32:12 -0000 Robert, >From: Robert Raszuk >Sent: Thursday, June 14, 2012 1:26 AM > >Hi John, > >#1 question which Jakob stated is still not answered.=20 Done. >Should STALE path >be less or more preferred then non stale less specific one. The question >makes a lot of sense and if the answer is yes then I am afraid BGP >implementations will become really complicated. > >There is one way to avoid such complication by adding a trick to >simple-va which would conditionally suppress stale path regardless of >next hope if less specific covering it is present without STALE flag. >This could be much simpler then messing with best path to compare >different nets. That would also mean that persistence MUST be always >used with simple-va. > >#2 In all cases where persistence draft may apply (VPLS) you may as well >configure the service without BGP. We are just propagating static config >in BGP here essentially. I'm missing your point. In this cases, are you calling for persistence or a= re you calling for not using BGP? >#3 For most other cases right network design removes the need for >persistence draft. For transient BGP session flaps basic GR with perhaps >longer timer works fine to maintain data plane connectivity. GR hides the issue. Persistence let's application know about the issue while allowing applicati= on to still use the route. IMO, proving information and choice to applications seems a least an option= to consider. >#4 The proposal does not mandate new capability in BGP. In networks with >mixed persistence support and no support especially on EBGP links this >seems extremely dangerous feature. Draft discusses the sender cases >where bgp speaker is persistence capable. But the draft neglects to >mention the handling on the receiver where the receiver is not capable >of recognizing the STALE community and still selects the STALE path as >best even if there is non STALE path present for the given net. As >community is an opaque value for it the re-advertisement of STALE will >happen and good valid path even if longer will be not promoted as best. Within the AS, I don't recall that the draft "neglects" anything. Between ASes, the issues is indeed more complexes and probably still need t= o be worked on. Yet, some simple solutions addressing the deployment uses c= ases seem a priori doable (e.g. withdraw stale path on eBGP except on speci= fically agreed BGP sessions). Possibly, the advertisement of a BGP capabili= ty could possibly be useful over eBGP sessions. >As mentioned in the other comment the way the draft is worded today has >a potential to introduce significant churn in the Internet when any >single BGP speaker experiences BGP session flap and starts the >re-advertise full table with and without STALE color. No. That's not an accurate summary of your other comment. You were comparin= g GR versus persistence. I replied that persistence is not intended to repl= ace GR. Hence you should compare GR vs GR + persistence. Then you replied t= hat "that may to some extend address my concern with unnecessary BGP churn"= . IMHO this is a understatement, but I called it quit. > To mitigate that >persistence was suggested to use _only_ with GR (and do nothing before >the GR timer expires .. Bruno agreed with that - but the draft does not >mandate GR which IMHO it should). No, I did not agreed with that. Cf the above for a summary of what I said. So far, I don't see a reason to mandate GR when persistence is used. Also, your point seems rather to mandate GR in all cases, independently of = persistence. This point is out of scope of the persistence draft. Write ano= ther draft if you want to mandate GR. >To clearly conclude looking at cost/benefit equation I am not supporting >adoption of this proposal the way the draft is fundamentally written >today. It is not that we could work on bits and pieces after adoption. >It is that there are fundamental issues with it today. You would need to detail the "fundamental issues" that you are seeing. If t= hese are the points 1 to 4 in this email, I have not being convinced. >Also I am not agreeing in principle with basic pre-assumption for this >work Jim mentioned in the reply that flaky and "maybe reachable" route >is better then no route. I prefer the latter. The reason being is that >if we declare no reachability in BGP other (upper/application) layers >could converge around it. If we "pretend" in BGP the reachability is >there while it is not, application few hops away has no way of knowing it. Again, that's exactly why persistence is richer than the "just use GR" prop= osal that you are pushing as an alternate.=20 I'm not sure what kind of "applications" you are referring to. If they don'= t have access to BGP routes, they probably don't care about BGP routes. If = they do, persistence does provide the information regarding the states of t= hose routes. Contrary to GR, it does not "pretend" that the BGP reachabilit= y has not changed. Best regards, Bruno >Best regards, >R. > >> Robert, >> >> The general tone of your comments leads me to think you may be >> against WG adoption of the document, but I haven't seen any clear >> statement from you so thus far I am not counting you either way. If >> you want to clarify a position feel free to either ucast me or reply >> to the list. >> >> By the way, thank you for your contribution to the discussion. >> >> --John >> > > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www.ietf.org/mailman/listinfo/idr ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From bruno.decraene@orange.com Thu Jun 14 03:32:23 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AEF221F8665 for ; Thu, 14 Jun 2012 03:32:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0db3nk5Wv1sv for ; Thu, 14 Jun 2012 03:32:22 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 74EDB21F86B9 for ; Thu, 14 Jun 2012 03:32:21 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 9D6F032443A; Thu, 14 Jun 2012 12:32:20 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 819D135C045; Thu, 14 Jun 2012 12:32:20 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Thu, 14 Jun 2012 12:32:20 +0200 From: To: "robert@raszuk.net" , "John G. Scudder" Thread-Topic: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR WG document Thread-Index: AQHNSbvqKrxik7qjvku42V+dyzAtsJb4zb8AgADAdBA= Date: Thu, 14 Jun 2012 10:32:20 +0000 Message-ID: <6212_1339669940_4FD9BDB4_6212_4377_1_53C29892C857584299CBF5D05346208A08FCE1@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <4911_1338974288_4FCF2050_4911_12906_1_53C29892C857584299CBF5D05346208A08CA08@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FCF800C.6070509@joelhalpern.com> <4FCF883B.6050501@raszuk.net> <4FCFEC86.6050706@raszuk.net> <8684_1339102246_4FD11426_8684_17472_1_53C29892C857584299CBF5D05346208A08D397@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FD1E202.6090503@raszuk.net> <1407_1339164741_4FD20845_1407_271_1_53C29892C857584299CBF5D05346208A08E913@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FD20D9E.2010505@raszuk.net> <4FD21577.2030103@raszuk.net> <4FD21CD7.30806@raszuk.net> <4FD92187.8080403@raszuk.net> <4FD92ABA.6080100@raszuk.net> In-Reply-To: <4FD92ABA.6080100@raszuk.net> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.6.14.93315 Cc: "idr@ietf.org List" Subject: Re: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 10:32:23 -0000 Robert, >From: Robert Raszuk >Sent: Thursday, June 14, 2012 2:05 AM > >> Also I am not agreeing in principle with basic pre-assumption for this >> work Jim mentioned in the reply that flaky and "maybe reachable" route >> is better then no route. I prefer the latter. The reason being is that >> if we declare no reachability in BGP other (upper/application) layers >> could converge around it. If we "pretend" in BGP the reachability is >> there while it is not, application few hops away has no way of knowing i= t. That's exactly why the persistence approach is richer than the GR approach = that you are pushing instead. Indeed, the key difference is that persistenc= e do advertise the error condition and does not "pretend" nothing happened = (like GR does). > >Let me expand a bit on this point as I think this is important. > >Imagine an ASBR with BGP connection to peering AS as well as with >wireless connection as backup to the other AS. The protocol running over >wireless connection is ROLL. > >By default ROLL will have higher admin distance (will be less preferred) >when competing against the same prefix at the RIB insertion. IMHO the interaction between BGP and ROLL is probably not the key concern f= or the community (or the key reason the disregard the persistence proposal) As you mentioned, the point you raised is the default configuration. Persis= tence could probably address this by changing the admin distance of the rou= tes marked as stale. OTOH, I'm a bit curious on how your preferred alternat= ive (GR) would handle your imaginary case. Best regards, Bruno >If we do not remove the flaky and "perhaps reachable" prefix from BGP >the other backup path has no chance to be installed in RIB. > >That effectively means that we have broken any backup/redundancy options >which may be coming to a router outside of BGP. > >/* The same story also applies to ALTO or similar tools where sources >for information may be coming from other then BGP protocols. */ > >Best regards, >R. > > > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www.ietf.org/mailman/listinfo/idr ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From ju1738@att.com Thu Jun 14 05:59:46 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D44C021F85A1 for ; Thu, 14 Jun 2012 05:59:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SegJuqCIfhWH for ; Thu, 14 Jun 2012 05:59:46 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id 983BB21F859E for ; Thu, 14 Jun 2012 05:59:45 -0700 (PDT) Received: from unknown [144.160.128.153] (EHLO flpi408.enaf.ffdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.11.0-10) over TLS secured channel with ESMTP id 040e9df4.0.1118437.00-419.3078159.nbfkord-smmo06.seg.att.com (envelope-from ); Thu, 14 Jun 2012 12:59:45 +0000 (UTC) X-MXL-Hash: 4fd9e04131e40a37-6446fc5961e82f6d709c539a1f1205730a275e3b Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q5ECxhpE031338; Thu, 14 Jun 2012 05:59:44 -0700 Received: from fflint04.pst.cso.att.com (fflint04.pst.cso.att.com [150.234.39.64]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q5ECxb7I031266 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 Jun 2012 05:59:41 -0700 Received: from MISOUT7MSGHUB9D.ITServices.sbc.com (misout7msghub9d.itservices.sbc.com [144.151.223.93]) by fflint04.pst.cso.att.com (RSA Interceptor); Thu, 14 Jun 2012 05:59:12 -0700 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9D.ITServices.sbc.com ([144.151.223.93]) with mapi id 14.01.0355.002; Thu, 14 Jun 2012 08:59:12 -0400 From: "UTTARO, JAMES" To: "'robert@raszuk.net'" , "John G. Scudder" Thread-Topic: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR WG document Thread-Index: AQHNSbvsv3otEWMwak+BXlh0P/oBKJb5v2FQ Date: Thu, 14 Jun 2012 12:59:11 +0000 Message-ID: References: <4911_1338974288_4FCF2050_4911_12906_1_53C29892C857584299CBF5D05346208A08CA08@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FCF800C.6070509@joelhalpern.com> <4FCF883B.6050501@raszuk.net> <4FCFEC86.6050706@raszuk.net> <8684_1339102246_4FD11426_8684_17472_1_53C29892C857584299CBF5D05346208A08D397@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FD1E202.6090503@raszuk.net> <1407_1339164741_4FD20845_1407_271_1_53C29892C857584299CBF5D05346208A08E913@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FD20D9E.2010505@raszuk.net> <4FD21577.2030103@raszuk.net> <4FD21CD7.30806@raszuk.net> <4FD92187.8080403@raszuk.net> In-Reply-To: <4FD92187.8080403@raszuk.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.91.76.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.128.153] X-AnalysisOut: [v=1.0 c=1 a=g8Qva45Ca7EA:10 a=lYr-YFbwilAA:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=xwOvzTHDVLE4u4] X-AnalysisOut: [nGvK72ag==:17 a=48vgC7mUAAAA:8 a=bGRABurAssN1xHeYQKYA:9 a=] X-AnalysisOut: [CjuIK1q_8ugA:10 a=lZB815dzVvQA:10] Cc: "idr@ietf.org List" Subject: Re: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 12:59:46 -0000 Ah the morning mail has arrived ;) Comments In-Line.. Jim Uttaro -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Rober= t Raszuk Sent: Wednesday, June 13, 2012 7:26 PM To: John G. Scudder Cc: idr@ietf.org List Subject: Re: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR W= G document Hi John, #1 question which Jakob stated is still not answered. Should STALE path=20 be less or more preferred then non stale less specific one. The question=20 makes a lot of sense and if the answer is yes then I am afraid BGP=20 implementations will become really complicated. [Jim U>] I do not see this in scope of BGP Persistence.. This was never the= intent and I see no reason to change that for the applications of interest There is one way to avoid such complication by adding a trick to=20 simple-va which would conditionally suppress stale path regardless of=20 next hope if less specific covering it is present without STALE flag.=20 This could be much simpler then messing with best path to compare=20 different nets. That would also mean that persistence MUST be always=20 used with simple-va. #2 In all cases where persistence draft may apply (VPLS) you may as well=20 configure the service without BGP. We are just propagating static config=20 in BGP here essentially. [Jim U>] BGP is a powerful tool for discovery and signaling..I guess we cou= ld also build GRE tunnels to create L3 VPNs too.. But these approaches are = simply not practical.. #3 For most other cases right network design removes the need for=20 persistence draft. For transient BGP session flaps basic GR with perhaps=20 longer timer works fine to maintain data plane connectivity. [Jim U>] I think I have addressed the Persistence vs GR ad nauseaum.. So I = guess here goes high level yet again... GR is done at a per session lacks path granularity GR does not survive through failure modes that I require i.e Timer Expiry, = Malformed Update etc... GR is better suited where the session is assumed to be coming back in a sho= rt timeframe GR semantic ties the session to the forwarding as is appropriate GR does not survive through multiple restarts GR upon coming back floods all of the paths relearned.. I think I saw a dra= ft to "fix" this but have not read it yet..It is good that the GR authors a= re coming around to the "make before break" approach as detailed in the BGP= Persistence draft as it makes sense for the GR application also. GR assumes that paths that are "suspect" are still considered best, there i= s no informing the topology that paths over this session should be de-preff= ed.. Essentially GR is deciding for the SP. I want the control. Do we really need to have this conversation again, and again, and again.. T= he religious aspect is becoming annoying..=20 #4 The proposal does not mandate new capability in BGP. In networks with=20 mixed persistence support and no support especially on EBGP links this=20 seems extremely dangerous feature. Draft discusses the sender cases=20 where bgp speaker is persistence capable. But the draft neglects to=20 mention the handling on the receiver where the receiver is not capable=20 of recognizing the STALE community and still selects the STALE path as=20 best even if there is non STALE path present for the given net. As=20 community is an opaque value for it the re-advertisement of STALE will=20 happen and good valid path even if longer will be not promoted as best. [Jim U>] Addressed in Paris.=20 As mentioned in the other comment the way the draft is worded today has=20 a potential to introduce significant churn in the Internet when any=20 single BGP speaker experiences BGP session flap and starts the=20 re-advertise full table with and without STALE color. To mitigate that=20 persistence was suggested to use _only_ with GR (and do nothing before=20 the GR timer expires .. Bruno agreed with that - but the draft does not=20 mandate GR which IMHO it should). [Jim U>] Internet is not the intended use case.=20 To clearly conclude looking at cost/benefit equation I am not supporting=20 adoption of this proposal the way the draft is fundamentally written=20 today. It is not that we could work on bits and pieces after adoption.=20 It is that there are fundamental issues with it today. Also I am not agreeing in principle with basic pre-assumption for this=20 work Jim mentioned in the reply that flaky and "maybe reachable" route=20 is better then no route. I prefer the latter. The reason being is that=20 if we declare no reachability in BGP other (upper/application) layers=20 could converge around it. If we "pretend" in BGP the reachability is=20 there while it is not, application few hops away has no way of knowing it. [Jim U>] Incorrect.. I never said the path was flaky, only the mechanism by= which it was learned may be suspect.. I think folks need to get a perspect= ive on other applications that use BGP.. Best regards, R. > Robert, > > The general tone of your comments leads me to think you may be > against WG adoption of the document, but I haven't seen any clear > statement from you so thus far I am not counting you either way. If > you want to clarify a position feel free to either ucast me or reply > to the list. > > By the way, thank you for your contribution to the discussion. > > --John > _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From ju1738@att.com Thu Jun 14 06:03:05 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C38DF21F8671 for ; Thu, 14 Jun 2012 06:03:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B6IJbaGcsxvt for ; Thu, 14 Jun 2012 06:02:53 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id D911D21F85CC for ; Thu, 14 Jun 2012 06:02:52 -0700 (PDT) Received: from unknown [144.160.128.153] (EHLO nbfkord-smmo07.seg.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.11.0-10) with ESMTP id cf0e9df4.2aaae422c940.589640.00-593.1638714.nbfkord-smmo07.seg.att.com (envelope-from ); Thu, 14 Jun 2012 13:02:52 +0000 (UTC) X-MXL-Hash: 4fd9e0fc3bf856f5-d8a641d6c686d5b0c973bcfc5f8f7baf0b9b568a Received: from unknown [144.160.128.153] (EHLO flpi408.enaf.ffdc.sbc.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.11.0-10) over TLS secured channel with ESMTP id af0e9df4.0.589630.00-385.1638688.nbfkord-smmo07.seg.att.com (envelope-from ); Thu, 14 Jun 2012 13:02:50 +0000 (UTC) X-MXL-Hash: 4fd9e0fa58655370-70c017369e77f144f698e724252408ee25086726 Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q5ED2mxU003163; Thu, 14 Jun 2012 06:02:49 -0700 Received: from fflint03.pst.cso.att.com (fflint03.pst.cso.att.com [150.234.39.63]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q5ED2hGf003020 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 Jun 2012 06:02:44 -0700 Received: from MISOUT7MSGHUB9A.ITServices.sbc.com (misout7msghub9a.itservices.sbc.com [144.151.223.62]) by fflint03.pst.cso.att.com (RSA Interceptor); Thu, 14 Jun 2012 06:02:20 -0700 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9A.ITServices.sbc.com ([144.151.223.62]) with mapi id 14.01.0355.002; Thu, 14 Jun 2012 09:02:08 -0400 From: "UTTARO, JAMES" To: "'Enke Chen'" , "John G. Scudder" Thread-Topic: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR WG document Thread-Index: AQHNScUE0di1p3SdRkOfv6uPo4eOtZb5x5CQ Date: Thu, 14 Jun 2012 13:02:08 +0000 Message-ID: References: <4FD93110.9090505@cisco.com> In-Reply-To: <4FD93110.9090505@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.91.76.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.128.153] X-AnalysisOut: [v=1.0 c=1 a=g8Qva45Ca7EA:10 a=lYr-YFbwilAA:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=xwOvzTHDVLE4u4] X-AnalysisOut: [nGvK72ag==:17 a=48vgC7mUAAAA:8 a=aoKvsRqIHjpPpX20hG0A:9 a=] X-AnalysisOut: [CjuIK1q_8ugA:10 a=lZB815dzVvQA:10] Cc: "idr@ietf.org List" Subject: Re: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 13:03:05 -0000 Enke, Here is the text from my note to Robert..=20 [Jim U>] I think I have addressed the Persistence vs GR ad nauseaum.. So I = guess here goes high level yet again... GR is done at a per session lacks path granularity GR does not survive through failure modes that I require i.e Timer Expiry, = Malformed Update etc... GR is better suited where the session is assumed to be coming back in a sho= rt timeframe GR semantic ties the session to the forwarding as is appropriate GR does not survive through multiple restarts GR upon coming back floods all of the paths relearned.. I think I saw a dra= ft to "fix" this but have not read it yet..It is good that the GR authors a= re coming around to the "make before break" approach as detailed in the BGP= Persistence draft as it makes sense for the GR application also. GR assumes that paths that are "suspect" are still considered best, there i= s no informing the topology that paths over this session should be de-preff= ed.. Essentially GR is deciding for the SP. I want the control. Did not get a chance to look back at the other e-mails on this so this list= may be incomplete.. If we are going to re-spin GR to become Persistence then maybe we should si= mply add the subset of functionality provided by GR to the Persistence draf= t.. Jim Uttaro -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Enke = Chen Sent: Wednesday, June 13, 2012 8:32 PM To: John G. Scudder Cc: idr@ietf.org List Subject: Re: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR W= G document Hi, folks: As I stated on this mailing list before, I believe that most of the key=20 requirements specified in the "persistence draft" can be easily=20 addressed by a couple knobs with GR: o introduce the concept of the "minimal stale timer" in GR: This=20 will allow the stale routes to be kept for a much longer time if so=20 configured locally. o use a stale path first, and then switch to an alternate path after=20 a certain amount of time: This would be locally configurable. They can be easily covered by adding some text in the GR re-spin which=20 is in progress. It seems logical also for GR to cover these points. =20 Then GR would not be limited to just "shorter timers". As the concept of GR is well established, and it already provides=20 "persistence", I do not see much value for IDR to have another spec that=20 conceptually and operationally overlaps with it. -- Enke On 6/13/12 12:24 PM, John G. Scudder wrote: > Folks, > > Although there has been a lively discussion about the merits of the draft= , I have seen only four replies from people other than co-authors that clea= rly stated a preference for adoption. If you have not yet stated a preferen= ce, and have one, I encourage you to do so. > > The comment period will end on Friday. > > --John > > P.S.: If you replied but changed the subject line it is possible I didn't= include your message in my tally. > > On May 31, 2012, at 1:10 PM, John Scudder wrote: > >> Folks, >> >> We have received a request from the authors to adopt draft-uttaro-idr-bg= p-persistence-01 as an IDR WG document. Please send your comments to the l= ist. The deadline for comments is June 15, 2012 at noon EDT. >> >> Thanks, >> >> --John > > _______________________________________________ > 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 From robert@raszuk.net Thu Jun 14 06:07:46 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 768E021F86B1 for ; Thu, 14 Jun 2012 06:07:46 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nW-jsBUhfdK0 for ; Thu, 14 Jun 2012 06:07:46 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id B37C721F8658 for ; Thu, 14 Jun 2012 06:07:45 -0700 (PDT) Received: (qmail 10794 invoked by uid 399); 14 Jun 2012 13:07:44 -0000 Received: from unknown (HELO ?172.16.197.148?) (pbs:robert@raszuk.net@58.80.213.53) by mail1310.opentransfer.com with ESMTPM; 14 Jun 2012 13:07:44 -0000 X-Originating-IP: 58.80.213.53 Message-ID: <4FD9E21F.40503@raszuk.net> Date: Thu, 14 Jun 2012 06:07:43 -0700 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120604 Thunderbird/13.0 MIME-Version: 1.0 To: bruno.decraene@orange.com References: <4911_1338974288_4FCF2050_4911_12906_1_53C29892C857584299CBF5D05346208A08CA08@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FCF800C.6070509@joelhalpern.com> <4FCF883B.6050501@raszuk.net> <4FCFEC86.6050706@raszuk.net> <507A0451-C11D-4CFB-8EE1-073220B1631E@cisco.com> <4FD0B33B.50603@raszuk.net> <3185_1339669607_4FD9BC66_3185_4099_6_53C29892C857584299CBF5D05346208A08FC9B@PEXCVZYM11.corporate.adroot.infra.ftgroup> In-Reply-To: <3185_1339669607_4FD9BC66_3185_4099_6_53C29892C857584299CBF5D05346208A08FC9B@PEXCVZYM11.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org List" , "Joel M. Halpern" , "UTTARO, JAMES" Subject: Re: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 13:07:46 -0000 Bruno, > While preferring non stale more specific prefix over stale prefix > could probably You have completely reversed the question. More specific will be preferred today by default no need to discuss it. The question was about preferring less specific non stale vs more specific stale. I gave example how it could be solved with simple-va easy extension. Best, R. > Hi Jakob, > >> From: Jakob Heitz [mailto:jakob.heitz@ericsson.com] >Sent: Thursday, June 07, 2012 5:46 PM >> >> On Jun 7, 2012, at 6:57 AM, "Robert Raszuk" wrote: >>> As the STALE routes are not dynamically updated anymore, it's >>> desirable that they be only used in last resort. Hence when >>> comparing paths for a prefix, a non STALE path should be preferred >>> over a STALE path. >> >> should a path with a shorter prefix also be preferred? >> Say the stale path is 10.0.0.0/24 and 10.0.0.0/16 exists and is not stale. > > You are raising a good point. > While preferring non stale more specific prefix over stale prefix could probably make sense, IMHO I would not push persistence in this direction: > - too much change in BGP > - to some extend, the point of more specific prefixes being preferred in the forwarding plane independently of the BGP preferences is a different subject. E.g. draft-francois-limited-scope-specifics-01 is another aspect. > > Regards, > Bruno > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > > > From ju1738@att.com Thu Jun 14 06:10:43 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4530021F865E for ; Thu, 14 Jun 2012 06:10:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S0PQq1IekHxS for ; Thu, 14 Jun 2012 06:10:42 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id 776F021F85D7 for ; Thu, 14 Jun 2012 06:10:42 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO nbfkord-smmo06.seg.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.11.0-10) with ESMTP id 2d2e9df4.5a77e940.1121842.00-528.3087755.nbfkord-smmo06.seg.att.com (envelope-from ); Thu, 14 Jun 2012 13:10:42 +0000 (UTC) X-MXL-Hash: 4fd9e2d203958d81-8b37eaeb13f6111a93e0a05cd6b45d2c5681b30b Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.11.0-10) over TLS secured channel with ESMTP id fc2e9df4.0.1121822.00-452.3087695.nbfkord-smmo06.seg.att.com (envelope-from ); Thu, 14 Jun 2012 13:10:40 +0000 (UTC) X-MXL-Hash: 4fd9e2d0108ecb72-660a8b94bae2585bc23f63d3d17c3dfc11af3e92 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q5EDAdoO010856; Thu, 14 Jun 2012 09:10:39 -0400 Received: from sflint02.pst.cso.att.com (sflint02.pst.cso.att.com [144.154.234.229]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q5EDAZWv010797 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 Jun 2012 09:10:38 -0400 Received: from MISOUT7MSGHUB9C.ITServices.sbc.com (misout7msghub9c.itservices.sbc.com [144.151.223.82]) by sflint02.pst.cso.att.com (RSA Interceptor); Thu, 14 Jun 2012 09:10:27 -0400 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9C.ITServices.sbc.com ([144.151.223.82]) with mapi id 14.01.0355.002; Thu, 14 Jun 2012 09:10:27 -0400 From: "UTTARO, JAMES" To: "'Enke Chen'" , "John G. Scudder" Thread-Topic: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR WG document Thread-Index: AQHNScUE0di1p3SdRkOfv6uPo4eOtZb5ycEg Date: Thu, 14 Jun 2012 13:10:27 +0000 Message-ID: References: <4FD93110.9090505@cisco.com> In-Reply-To: <4FD93110.9090505@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.91.76.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=1.0 c=1 a=g8Qva45Ca7EA:10 a=lYr-YFbwilAA:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=ZRNLZ4dFUbCvG8] X-AnalysisOut: [UMqPvVAA==:17 a=48vgC7mUAAAA:8 a=YLhe9WNXZqUBWDaffgsA:9 a=] X-AnalysisOut: [CjuIK1q_8ugA:10 a=lZB815dzVvQA:10] Cc: "idr@ietf.org List" Subject: Re: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 13:10:43 -0000 Enke, One other note here.. =20 The notion of "can easily be addressed by a couple of knobs with GR:" is e= xactly the problem with using GR.. Should I have to go ahead and modify the= behavior on thousands of endpoints by changing different knobs, oh crap I = better make sure they all realize the same behavior.. This is impractical f= rom a consistent network architecture/design viewpoint..=20 Jim Uttaro -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Enke = Chen Sent: Wednesday, June 13, 2012 8:32 PM To: John G. Scudder Cc: idr@ietf.org List Subject: Re: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR W= G document Hi, folks: As I stated on this mailing list before, I believe that most of the key=20 requirements specified in the "persistence draft" can be easily=20 addressed by a couple knobs with GR: o introduce the concept of the "minimal stale timer" in GR: This=20 will allow the stale routes to be kept for a much longer time if so=20 configured locally. o use a stale path first, and then switch to an alternate path after=20 a certain amount of time: This would be locally configurable. They can be easily covered by adding some text in the GR re-spin which=20 is in progress. It seems logical also for GR to cover these points. =20 Then GR would not be limited to just "shorter timers". As the concept of GR is well established, and it already provides=20 "persistence", I do not see much value for IDR to have another spec that=20 conceptually and operationally overlaps with it. -- Enke On 6/13/12 12:24 PM, John G. Scudder wrote: > Folks, > > Although there has been a lively discussion about the merits of the draft= , I have seen only four replies from people other than co-authors that clea= rly stated a preference for adoption. If you have not yet stated a preferen= ce, and have one, I encourage you to do so. > > The comment period will end on Friday. > > --John > > P.S.: If you replied but changed the subject line it is possible I didn't= include your message in my tally. > > On May 31, 2012, at 1:10 PM, John Scudder wrote: > >> Folks, >> >> We have received a request from the authors to adopt draft-uttaro-idr-bg= p-persistence-01 as an IDR WG document. Please send your comments to the l= ist. The deadline for comments is June 15, 2012 at noon EDT. >> >> Thanks, >> >> --John > > _______________________________________________ > 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 From ju1738@att.com Thu Jun 14 06:14:22 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DE7621F8665 for ; Thu, 14 Jun 2012 06:14:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6lbuAFdF3sO3 for ; Thu, 14 Jun 2012 06:14:22 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id AF2A521F8663 for ; Thu, 14 Jun 2012 06:14:21 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO nbfkord-smmo06.seg.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.11.0-10) with ESMTP id da3e9df4.741a7940.1122839.00-551.3090547.nbfkord-smmo06.seg.att.com (envelope-from ); Thu, 14 Jun 2012 13:14:21 +0000 (UTC) X-MXL-Hash: 4fd9e3ad69be5846-0c497c6cb17bdf67165e15052b06ab1330828eb2 Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.11.0-10) over TLS secured channel with ESMTP id 8a3e9df4.0.1122817.00-448.3090484.nbfkord-smmo06.seg.att.com (envelope-from ); Thu, 14 Jun 2012 13:14:16 +0000 (UTC) X-MXL-Hash: 4fd9e3a8637c08d4-1c161c13361c992c2597b15222bee98f0dde294b Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q5EDEF8k012453; Thu, 14 Jun 2012 09:14:16 -0400 Received: from sflint01.pst.cso.att.com (sflint01.pst.cso.att.com [144.154.234.228]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q5EDEEia012450 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 Jun 2012 09:14:14 -0400 Received: from MISOUT7MSGHUB9F.ITServices.sbc.com (misout7msghub9f.itservices.sbc.com [144.151.223.71]) by sflint01.pst.cso.att.com (RSA Interceptor); Thu, 14 Jun 2012 09:14:03 -0400 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9F.ITServices.sbc.com ([144.151.223.71]) with mapi id 14.01.0355.002; Thu, 14 Jun 2012 09:14:03 -0400 From: "UTTARO, JAMES" To: "'Enke Chen'" , "robert@raszuk.net" Thread-Topic: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR WG document Thread-Index: AQHNSdjWLXi2MBtrREqehs60QxJP75b5ZXmAgABlE8A= Date: Thu, 14 Jun 2012 13:14:02 +0000 Message-ID: References: <4FCF800C.6070509@joelhalpern.com> <4FCF883B.6050501@raszuk.net> <4FCFEC86.6050706@raszuk.net> <8684_1339102246_4FD11426_8684_17472_1_53C29892C857584299CBF5D05346208A08D397@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FD1E202.6090503@raszuk.net> <1407_1339164741_4FD20845_1407_271_1_53C29892C857584299CBF5D05346208A08E913@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FD20D9E.2010505@raszuk.net> <4FD21577.2030103@raszuk.net> <4FD21CD7.30806@raszuk.net> <4FD92187.8080403@raszuk.net> <2B37563C-F3E2-4113-A5A2-35BA83F64FC3@junipe r.net> <4FD95202.2010205@raszuk.net> <4FD955D1.8090807@cisco.com> In-Reply-To: <4FD955D1.8090807@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.91.76.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=1.0 c=1 a=g8Qva45Ca7EA:10 a=lYr-YFbwilAA:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=ZRNLZ4dFUbCvG8] X-AnalysisOut: [UMqPvVAA==:17 a=48vgC7mUAAAA:8 a=2clOPd4PAAAA:8 a=5lDujw4h] X-AnalysisOut: [n4j2fBaw-lcA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=bDUki] X-AnalysisOut: [_mJ7DgA:10 a=la1YspKwmuUw0L62:21 a=--dNvr2KVux59-or:21] Cc: "idr@ietf.org List" Subject: Re: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 13:14:22 -0000 Without divulging too much internal AT&T plans, we are embarking on rolling= out a number of communities to accomplish our network design goals. These = communities have recently been defined and are the process of standardizati= on. I think we can figure out the operational end.. What we really need is = for folks to understand the reqs we have for BGP today in the post internet= BGP signaled era..=20 Jim Uttaro -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Enke = Chen Sent: Wednesday, June 13, 2012 11:09 PM To: robert@raszuk.net Cc: idr@ietf.org List Subject: Re: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR W= G document Just try to point out the obvious: in general a new global community is=20 difficult to roll out. The lack of scoping creates many operationally=20 issues such as who can set it, who can override it, and where to accept=20 and where to filter. It can be a burden for all involved, e.g., it has to be filtered out=20 everywhere in a network if one does not want to use it. -- Enke On 6/13/12 7:52 PM, Robert Raszuk wrote: > Hi John, > > Actually not. Standardization does not equal that a feature will be=20 > enabled or router image automatically upgraded after RFC is issued :). > > As long as EBGP speaker I do not control will not support this=20 > extension I will still signal a STALE path with the community which he=20 > will consider as good as not STALE one. > > To your point the case today between any two adjacent ASes (and within=20 > the AS) you can achieve persistence by just agreeing on some community=20 > value internally. > > Best regards, > R. > >> Robert, >> >> To this point: >> >> On Jun 13, 2012, at 7:25 PM, Robert Raszuk wrote: >> >>> In networks with >>> mixed persistence support and no support especially on EBGP links this >>> seems extremely dangerous feature. >> >> Your concern for "mixed persistence support" would actually seem to=20 >> support the opposite point of view, that this *should* be=20 >> standardized. As you know, one key reason to standardize things is to=20 >> facilitate deployment of such features in mixed networks. >> >> I expect this will not be persuasive to you given your other=20 >> objections, but I thought I should point it out. >> >> Regards, >> >> --John >> _______________________________________________ >> 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 _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From robert@raszuk.net Thu Jun 14 06:20:12 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4E8621F8688 for ; Thu, 14 Jun 2012 06:20:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2uxByJV6eOL5 for ; Thu, 14 Jun 2012 06:20:12 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 0EE2821F866A for ; Thu, 14 Jun 2012 06:20:12 -0700 (PDT) Received: (qmail 26622 invoked by uid 399); 14 Jun 2012 13:20:11 -0000 Received: from unknown (HELO ?172.16.197.148?) (pbs:robert@raszuk.net@58.80.213.53) by mail1310.opentransfer.com with ESMTPM; 14 Jun 2012 13:20:11 -0000 X-Originating-IP: 58.80.213.53 Message-ID: <4FD9E50A.7000703@raszuk.net> Date: Thu, 14 Jun 2012 06:20:10 -0700 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120604 Thunderbird/13.0 MIME-Version: 1.0 To: "UTTARO, JAMES" References: <4FCF800C.6070509@joelhalpern.com> <4FCF883B.6050501@raszuk.net> <4FCFEC86.6050706@raszuk.net> <8684_1339102246_4FD11426_8684_17472_1_53C29892C857584299CBF5D05346208A08D397@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FD1E202.6090503@raszuk.net> <1407_1339164741_4FD20845_1407_271_1_53C29892C857584299CBF5D05346208A08E913@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FD20D9E.2010505@raszuk.net> <4FD21577.2030103@raszuk.net> <4FD21CD7.30806@raszuk.net> <4FD92187.8080403@raszuk.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org List" Subject: Re: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 13:20:12 -0000 Jim, > [Jim U>] BGP is a powerful tool for discovery and signaling..I guess > we could also build GRE tunnels to create L3 VPNs too.. But these > approaches are simply not practical.. For your reference BGP next hop is used today to automatically encapsulate L3VPN packets from src to remote PE. mGRE is a very practical approach .. much more practical and much more scalable then running LDP or RSVP-TE for providing service transport encapsulation in number of cases .. from large service provider WANs with 10,000s PEs to modern data centers with 100,000s+ hypervisors. I am amazed by your lack of practical information. Best, R. From randy@psg.com Thu Jun 14 07:00:02 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCFEC21F86BA for ; Thu, 14 Jun 2012 07:00:02 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jh6CFKIHL-3i for ; Thu, 14 Jun 2012 07:00:02 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id DEFED21F86B1 for ; Thu, 14 Jun 2012 07:00:01 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SfAac-000DUc-Qr; Thu, 14 Jun 2012 13:59:59 +0000 Date: Thu, 14 Jun 2012 22:59:57 +0900 Message-ID: From: Randy Bush To: "UTTARO, JAMES" In-Reply-To: References: <4FD93110.9090505@cisco.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: "idr@ietf.org List" Subject: Re: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 14:00:02 -0000 > The notion of "can easily be addressed by a couple of knobs with GR:" > is exactly the problem with using GR.. Should I have to go ahead and > modify the behavior on thousands of endpoints by changing different > knobs, oh crap I better make sure they all realize the same > behavior.. This is impractical from a consistent network > architecture/design viewpoint.. won't all bgp speakers in your network will have to be configured to deal with persistence? same kinky deal. death by complexity. randy From ju1738@att.com Thu Jun 14 07:10:19 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C268521F8448 for ; Thu, 14 Jun 2012 07:10:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vf-IyAMANOvh for ; Thu, 14 Jun 2012 07:10:15 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id 1A66221F846A for ; Thu, 14 Jun 2012 07:10:15 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO nbfkord-smmo07.seg.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.11.0-10) with ESMTP id 7c0f9df4.2aaace409940.609784.00-557.1695969.nbfkord-smmo07.seg.att.com (envelope-from ); Thu, 14 Jun 2012 14:10:15 +0000 (UTC) X-MXL-Hash: 4fd9f0c726a5ead4-59c890aa3edd9f1d9ae10e5c5ef4603692088e41 Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.11.0-10) over TLS secured channel with ESMTP id 4c0f9df4.0.609771.00-323.1695924.nbfkord-smmo07.seg.att.com (envelope-from ); Thu, 14 Jun 2012 14:10:12 +0000 (UTC) X-MXL-Hash: 4fd9f0c468654ea0-0137931bce8c8cbb5243517b60a692c3a044c77a Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q5EEABOF007837; Thu, 14 Jun 2012 10:10:11 -0400 Received: from sflint02.pst.cso.att.com (sflint02.pst.cso.att.com [144.154.234.229]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q5EEA7dU007740 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 Jun 2012 10:10:08 -0400 Received: from MISOUT7MSGHUB9C.ITServices.sbc.com (misout7msghub9c.itservices.sbc.com [144.151.223.82]) by sflint02.pst.cso.att.com (RSA Interceptor); Thu, 14 Jun 2012 10:10:00 -0400 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9C.ITServices.sbc.com ([144.151.223.82]) with mapi id 14.01.0355.002; Thu, 14 Jun 2012 10:10:00 -0400 From: "UTTARO, JAMES" To: "'Randy Bush'" Thread-Topic: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR WG document Thread-Index: AQHNScUE0di1p3SdRkOfv6uPo4eOtZb5ycEggABRuYD//784YA== Date: Thu, 14 Jun 2012 14:09:59 +0000 Message-ID: References: <4FD93110.9090505@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.91.76.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=1.0 c=1 a=g8Qva45Ca7EA:10 a=lYr-YFbwilAA:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=ZRNLZ4dFUbCvG8] X-AnalysisOut: [UMqPvVAA==:17 a=No5EcEP4AAAA:8 a=48vgC7mUAAAA:8 a=JNHOtBW1] X-AnalysisOut: [KNTw6EHdc9oA:9 a=CjuIK1q_8ugA:10 a=PKgchsl1YdkA:10 a=lZB81] X-AnalysisOut: [5dzVvQA:10] Cc: "idr@ietf.org List" Subject: Re: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 14:10:20 -0000 Yes.. But there is no variation in the config it is applied the same way on= all supported endpoints regardless of vendor, OS release, platform.. Knobs= by various vendors on different releases generally mean inconsistency.. I = do think that some AFI/SAFI should be configured with Persistence as a defa= ult but that is not in scope of this discussion... Jim Uttaro -----Original Message----- From: Randy Bush [mailto:randy@psg.com]=20 Sent: Thursday, June 14, 2012 10:00 AM To: UTTARO, JAMES Cc: 'Enke Chen'; John G. Scudder; idr@ietf.org List Subject: Re: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR W= G document > The notion of "can easily be addressed by a couple of knobs with GR:" > is exactly the problem with using GR.. Should I have to go ahead and > modify the behavior on thousands of endpoints by changing different > knobs, oh crap I better make sure they all realize the same > behavior.. This is impractical from a consistent network > architecture/design viewpoint.. won't all bgp speakers in your network will have to be configured to deal with persistence? same kinky deal. death by complexity. randy From randy@psg.com Thu Jun 14 07:13:59 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EDED21F8649 for ; Thu, 14 Jun 2012 07:13:59 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4TTOTxj3d+vc for ; Thu, 14 Jun 2012 07:13:59 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 2B98621F846A for ; Thu, 14 Jun 2012 07:13:59 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SfAo7-000DWp-MS; Thu, 14 Jun 2012 14:13:56 +0000 Date: Thu, 14 Jun 2012 23:13:54 +0900 Message-ID: From: Randy Bush To: "UTTARO, JAMES" In-Reply-To: References: <4FD93110.9090505@cisco.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: "idr@ietf.org List" Subject: Re: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 14:13:59 -0000 > Yes.. But there is no variation in the config it is applied the same > way on all supported endpoints regardless of vendor, OS release, > platform.. Knobs by various vendors on different releases generally > mean inconsistency. for those who still configure networks at the keyboard while talking of a post-bgp internet. :) randy From robert@raszuk.net Thu Jun 14 07:16:56 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4089A21F8547 for ; Thu, 14 Jun 2012 07:16:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6LewvLe4Nd0J for ; Thu, 14 Jun 2012 07:16:55 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 7D4BE21F8546 for ; Thu, 14 Jun 2012 07:16:53 -0700 (PDT) Received: (qmail 4936 invoked by uid 399); 14 Jun 2012 14:16:53 -0000 Received: from unknown (HELO ?172.16.197.148?) (pbs:robert@raszuk.net@58.80.213.53) by mail1310.opentransfer.com with ESMTPM; 14 Jun 2012 14:16:53 -0000 X-Originating-IP: 58.80.213.53 Message-ID: <4FD9F254.9040300@raszuk.net> Date: Thu, 14 Jun 2012 07:16:52 -0700 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120604 Thunderbird/13.0 MIME-Version: 1.0 To: "UTTARO, JAMES" References: <4FD93110.9090505@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org List" Subject: Re: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 14:16:56 -0000 > I do think that some AFI/SAFI should be configured with Persistence as a default Let me point our that you are apparently confusing NETCONF with BGP. The former is persistent by design the latter is not (and it is a feature for the latter not a bug). Best, R. From bruno.decraene@orange.com Thu Jun 14 07:59:29 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EECC21F86D4 for ; Thu, 14 Jun 2012 07:59:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A1BYVeXnSPQw for ; Thu, 14 Jun 2012 07:59:28 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 72F6F21F86D3 for ; Thu, 14 Jun 2012 07:59:28 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 6141418C580; Thu, 14 Jun 2012 16:59:27 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 2329F27C058; Thu, 14 Jun 2012 16:59:27 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Thu, 14 Jun 2012 16:59:26 +0200 From: To: "robert@raszuk.net" Thread-Topic: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR WG document Thread-Index: AQHNSi6vKrxik7qjvku42V+dyzAtsJb55b6g Date: Thu, 14 Jun 2012 14:59:26 +0000 Message-ID: <12684_1339685967_4FD9FC4F_12684_2820_4_53C29892C857584299CBF5D05346208A090FEF@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <4911_1338974288_4FCF2050_4911_12906_1_53C29892C857584299CBF5D05346208A08CA08@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FCF800C.6070509@joelhalpern.com> <4FCF883B.6050501@raszuk.net> <4FCFEC86.6050706@raszuk.net> <507A0451-C11D-4CFB-8EE1-073220B1631E@cisco.com> <4FD0B33B.50603@raszuk.net> <3185_1339669607_4FD9BC66_3185_4099_6_53C29892C857584299CBF5D05346208A08FC9B@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FD9E21F.40503@raszuk.net> In-Reply-To: <4FD9E21F.40503@raszuk.net> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.3] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.6.14.124529 Cc: "idr@ietf.org List" , "UTTARO, JAMES" Subject: Re: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 14:59:29 -0000 Robert, >Bruno, > > > While preferring non stale more specific prefix over stale prefix > > could probably > >You have completely reversed the question.=20 You are right. My mistake in rephrasing. Please read :s/more/less (i.e.: While preferring non stale less specific prefix over stale prefix co= uld probably make sense...) Sorry for the spam. However, hopefully, there should not be typo in other part of the email. >More specific will be >preferred today by default no need to discuss it. > >The question was about preferring less specific non stale vs more >specific stale. > >I gave example how it could be solved with simple-va easy extension. > >Best, >R. > >> Hi Jakob, >> >>> From: Jakob Heitz [mailto:jakob.heitz@ericsson.com] >Sent: Thursday, Ju= ne >07, 2012 5:46 PM >>> >>> On Jun 7, 2012, at 6:57 AM, "Robert Raszuk" wrote: >>>> As the STALE routes are not dynamically updated anymore, it's >>>> desirable that they be only used in last resort. Hence when >>>> comparing paths for a prefix, a non STALE path should be preferred >>>> over a STALE path. >>> >>> should a path with a shorter prefix also be preferred? >>> Say the stale path is 10.0.0.0/24 and 10.0.0.0/16 exists and is not sta= le. >> >> You are raising a good point. >> While preferring non stale more specific prefix over stale prefix could >probably make sense, IMHO I would not push persistence in this direction: >> - too much change in BGP >> - to some extend, the point of more specific prefixes being preferred in= the >forwarding plane independently of the BGP preferences is a different subje= ct. >E.g. draft-francois-limited-scope-specifics-01 is another aspect. >> >> Regards, >> Bruno >> >> >__________________________________________________________________________= _____ >__________________________________________ >> >> Ce message et ses pieces jointes peuvent contenir des informations >confidentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez r= ecu >ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages >electroniques etant susceptibles d'alteration, >> France Telecom - Orange decline toute responsabilite si ce message a ete >altere, deforme ou falsifie. Merci. >> >> This message and its attachments may contain confidential or privileged >information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and d= elete >this message and its attachments. >> As emails may be altered, France Telecom - Orange is not liable for mess= ages >that have been modified, changed or falsified. >> Thank you. >> >> >> > ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From enkechen@cisco.com Thu Jun 14 08:53:21 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 169B121F85E7 for ; Thu, 14 Jun 2012 08:53:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g6pnDn1OJPxC for ; Thu, 14 Jun 2012 08:53:20 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 932E821F86D7 for ; Thu, 14 Jun 2012 08:53:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=enkechen@cisco.com; l=3106; q=dns/txt; s=iport; t=1339689198; x=1340898798; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=1LiVgWXOYSmplmLGE3Uu7MhDzPkfLSVwRVK5cpCQ6XY=; b=KrplGIt67gB68BUOIIObnZr/FfuNd7TGAdE6omDMqvxlSKYHyyC2bjrQ bjeFDrpBUt0g42f6BS9bZo0TfrAMdabbkPpFFH0dWSqLjPRZK3zGulubi yXp0eVz4hfBH261rXgp0bsciveBTlrPPNoN4fZC+NO/Sv2JXIBDB2R4vO I=; X-IronPort-AV: E=Sophos;i="4.75,770,1330905600"; d="scan'208";a="45837020" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 14 Jun 2012 15:53:18 +0000 Received: from enkechen-mac.local ([10.21.71.148]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q5EFrIBO022539; Thu, 14 Jun 2012 15:53:18 GMT Message-ID: <4FDA093B.6030209@cisco.com> Date: Thu, 14 Jun 2012 08:54:35 -0700 From: Enke Chen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: "UTTARO, JAMES" References: <4FCF883B.6050501@raszuk.net> <4FCFEC86.6050706@raszuk.net> <8684_1339102246_4FD11426_8684_17472_1_53C29892C857584299CBF5D05346208A08D397@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FD1E202.6090503@raszuk.net> <1407_1339164741_4FD20845_1407_271_1_53C29892C857584299CBF5D05346208A08E913@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FD20D9E.2010505@raszuk.net> <4FD21577.2030103@raszuk.net> <4FD21CD7.30806@raszuk.net> <4FD92187.8080403@raszuk.net> <2B37563C-F3E2-4113-A5A2-35BA83F64FC3@junipe r.net> <4FD95202.2010205@raszuk.net> <4FD955D1.8090807@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org List" , "robert@raszuk.net" Subject: Re: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 15:53:21 -0000 Jim, It may be true that "you can figure out the operational end", but can the whole world figure out? With a global community, the whole world will need to deal with it. I do not think that is necessary, nor fair. -- Enke On 6/14/12 6:14 AM, UTTARO, JAMES wrote: > Without divulging too much internal AT&T plans, we are embarking on rolling out a number of communities to accomplish our network design goals. These communities have recently been defined and are the process of standardization. I think we can figure out the operational end.. What we really need is for folks to understand the reqs we have for BGP today in the post internet BGP signaled era.. > > Jim Uttaro > > -----Original Message----- > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Enke Chen > Sent: Wednesday, June 13, 2012 11:09 PM > To: robert@raszuk.net > Cc: idr@ietf.org List > Subject: Re: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR WG document > > Just try to point out the obvious: in general a new global community is > difficult to roll out. The lack of scoping creates many operationally > issues such as who can set it, who can override it, and where to accept > and where to filter. > > It can be a burden for all involved, e.g., it has to be filtered out > everywhere in a network if one does not want to use it. > > -- Enke > > On 6/13/12 7:52 PM, Robert Raszuk wrote: >> Hi John, >> >> Actually not. Standardization does not equal that a feature will be >> enabled or router image automatically upgraded after RFC is issued :). >> >> As long as EBGP speaker I do not control will not support this >> extension I will still signal a STALE path with the community which he >> will consider as good as not STALE one. >> >> To your point the case today between any two adjacent ASes (and within >> the AS) you can achieve persistence by just agreeing on some community >> value internally. >> >> Best regards, >> R. >> >>> Robert, >>> >>> To this point: >>> >>> On Jun 13, 2012, at 7:25 PM, Robert Raszuk wrote: >>> >>>> In networks with >>>> mixed persistence support and no support especially on EBGP links this >>>> seems extremely dangerous feature. >>> Your concern for "mixed persistence support" would actually seem to >>> support the opposite point of view, that this *should* be >>> standardized. As you know, one key reason to standardize things is to >>> facilitate deployment of such features in mixed networks. >>> >>> I expect this will not be persuasive to you given your other >>> objections, but I thought I should point it out. >>> >>> Regards, >>> >>> --John >>> _______________________________________________ >>> 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 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From ju1738@att.com Thu Jun 14 11:24:13 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E791221F864E for ; Thu, 14 Jun 2012 11:24:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.999 X-Spam-Level: X-Spam-Status: No, score=-105.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ILu+K17YpOWv for ; Thu, 14 Jun 2012 11:24:12 -0700 (PDT) Received: from nbfkord-smmo08.seg.att.com (nbfkord-smmo08.seg.att.com [209.65.160.95]) by ietfa.amsl.com (Postfix) with ESMTP id 1971021F8646 for ; Thu, 14 Jun 2012 11:24:12 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO nbfkord-smmo08.seg.att.com) by nbfkord-smmo08.seg.att.com(mxl_mta-6.11.0-10) with ESMTP id c4c2adf4.2aaad581b940.1292353.00-588.3554289.nbfkord-smmo08.seg.att.com (envelope-from ); Thu, 14 Jun 2012 18:24:12 +0000 (UTC) X-MXL-Hash: 4fda2c4c2e54fc6f-251ac9b943179ce540f795da1bb74340296a8112 Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo08.seg.att.com(mxl_mta-6.11.0-10) over TLS secured channel with ESMTP id 74c2adf4.0.1292336.00-330.3554241.nbfkord-smmo08.seg.att.com (envelope-from ); Thu, 14 Jun 2012 18:24:07 +0000 (UTC) X-MXL-Hash: 4fda2c4713db24ae-badc7c57a6580a68731784089724261491bb134c Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q5EIO6aE009833; Thu, 14 Jun 2012 14:24:07 -0400 Received: from sflint02.pst.cso.att.com (sflint02.pst.cso.att.com [144.154.234.229]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q5EIO0gV009823 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 Jun 2012 14:24:03 -0400 Received: from MISOUT7MSGHUB9F.ITServices.sbc.com (misout7msghub9f.itservices.sbc.com [144.151.223.71]) by sflint02.pst.cso.att.com (RSA Interceptor); Thu, 14 Jun 2012 14:23:43 -0400 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9F.ITServices.sbc.com ([144.151.223.71]) with mapi id 14.01.0355.002; Thu, 14 Jun 2012 14:23:43 -0400 From: "UTTARO, JAMES" To: "'Enke Chen'" Thread-Topic: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR WG document Thread-Index: AQHNSdjWLXi2MBtrREqehs60QxJP75b5ZXmAgABlE8CAAHDNgP//5Ttg Date: Thu, 14 Jun 2012 18:23:43 +0000 Message-ID: References: <4FCF883B.6050501@raszuk.net> <4FCFEC86.6050706@raszuk.net> <8684_1339102246_4FD11426_8684_17472_1_53C29892C857584299CBF5D05346208A08D397@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FD1E202.6090503@raszuk.net> <1407_1339164741_4FD20845_1407_271_1_53C29892C857584299CBF5D05346208A08E913@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FD20D9E.2010505@raszuk.net> <4FD21577.2030103@raszuk.net> <4FD21CD7.30806@raszuk.net> <4FD92187.8080403@raszuk.net> <2B37563C-F3E2-4113-A5A2-35BA83F64FC3@junipe r.net> <4FD95202.2010205@raszuk.net> <4FD955D1.8090807@cisco.com> <4FDA093B.6030209@cisco.com> In-Reply-To: <4FDA093B.6030209@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.133.82] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=1.0 c=1 a=-hb8KOZl30UA:10 a=lYr-YFbwilAA:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=ZRNLZ4dFUbCvG8] X-AnalysisOut: [UMqPvVAA==:17 a=AUd_NHdVAAAA:8 a=2clOPd4PAAAA:8 a=48vgC7mU] X-AnalysisOut: [AAAA:8 a=dBW16Mfb2MdzBieFcfUA:9 a=CjuIK1q_8ugA:10 a=JfD0Fc] X-AnalysisOut: [h1gWkA:10 a=bDUki_mJ7DgA:10 a=lZB815dzVvQA:10 a=fbVbGajnew] X-AnalysisOut: [ORY__5:21 a=tHv1KnB-0F9LmLrE:21] Cc: "idr@ietf.org List" , "robert@raszuk.net" Subject: Re: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 18:24:13 -0000 Enke, Not sure I understand. Referring to the slides Bruno presented is your con= cern that the STALE CV is used to provide the semantic across AS boundaries= ?? For the iBGP case the use of Cost Community, Local Pref have been identi= fied as mechanisms to de-pref the STALE path. Is this what you are speaking= too?.. Across AS boundaries the STALE CD would only need to be interpreted= once and the desired iBGP mechanism set.. Pls Clarify.. The technology is necessary and we need to be fair to our customers who exp= ect that a failure in our control plane that simply advertises paths should= not tear down their VPLS,VPN,3107 MultiCast etc...network. Jim Uttaro -----Original Message----- From: Enke Chen [mailto:enkechen@cisco.com]=20 Sent: Thursday, June 14, 2012 11:55 AM To: UTTARO, JAMES Cc: robert@raszuk.net; idr@ietf.org List; Enke Chen Subject: Re: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR W= G document Jim, It may be true that "you can figure out the operational end", but can=20 the whole world figure out? With a global community, the whole world=20 will need to deal with it. I do not think that is necessary, nor fair. -- Enke On 6/14/12 6:14 AM, UTTARO, JAMES wrote: > Without divulging too much internal AT&T plans, we are embarking on rolli= ng out a number of communities to accomplish our network design goals. Thes= e communities have recently been defined and are the process of standardiza= tion. I think we can figure out the operational end.. What we really need i= s for folks to understand the reqs we have for BGP today in the post intern= et BGP signaled era.. > > Jim Uttaro > > -----Original Message----- > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Enk= e Chen > Sent: Wednesday, June 13, 2012 11:09 PM > To: robert@raszuk.net > Cc: idr@ietf.org List > Subject: Re: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR= WG document > > Just try to point out the obvious: in general a new global community is > difficult to roll out. The lack of scoping creates many operationally > issues such as who can set it, who can override it, and where to accept > and where to filter. > > It can be a burden for all involved, e.g., it has to be filtered out > everywhere in a network if one does not want to use it. > > -- Enke > > On 6/13/12 7:52 PM, Robert Raszuk wrote: >> Hi John, >> >> Actually not. Standardization does not equal that a feature will be >> enabled or router image automatically upgraded after RFC is issued :). >> >> As long as EBGP speaker I do not control will not support this >> extension I will still signal a STALE path with the community which he >> will consider as good as not STALE one. >> >> To your point the case today between any two adjacent ASes (and within >> the AS) you can achieve persistence by just agreeing on some community >> value internally. >> >> Best regards, >> R. >> >>> Robert, >>> >>> To this point: >>> >>> On Jun 13, 2012, at 7:25 PM, Robert Raszuk wrote: >>> >>>> In networks with >>>> mixed persistence support and no support especially on EBGP links this >>>> seems extremely dangerous feature. >>> Your concern for "mixed persistence support" would actually seem to >>> support the opposite point of view, that this *should* be >>> standardized. As you know, one key reason to standardize things is to >>> facilitate deployment of such features in mixed networks. >>> >>> I expect this will not be persuasive to you given your other >>> objections, but I thought I should point it out. >>> >>> Regards, >>> >>> --John >>> _______________________________________________ >>> 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 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From enkechen@cisco.com Thu Jun 14 11:34:57 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 772E921F8668 for ; Thu, 14 Jun 2012 11:34:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j78Kz3j6dTe5 for ; Thu, 14 Jun 2012 11:34:56 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 8C1D521F8720 for ; Thu, 14 Jun 2012 11:34:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=enkechen@cisco.com; l=4421; q=dns/txt; s=iport; t=1339698896; x=1340908496; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=JB6F1KsNI/I+Ip3EevarPcK2E4AKq4Ltoz1oQZDmOd8=; b=HI/qoscKkCBijE/9SctEh+LKeyatXS0rYqkdsEKM8F0zgt/Vm4bRk8ZD jUS6TG9HABIShzx8cxh9gGnT025iaEL1gODlb2YQeYyF+WJtL+cMIooC5 2SbXu3InUKQvsY785ip1pl8gpd5Y/nnY7Fvrzx+G0iXqd8SQbrLOU2H+d c=; X-IronPort-AV: E=Sophos;i="4.75,772,1330905600"; d="scan'208";a="48888197" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 14 Jun 2012 18:34:56 +0000 Received: from dhcp-171-71-139-24.cisco.com (dhcp-171-71-139-24.cisco.com [171.71.139.24]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q5EIYu0E019584; Thu, 14 Jun 2012 18:34:56 GMT Message-ID: <4FDA2F1D.6070706@cisco.com> Date: Thu, 14 Jun 2012 11:36:13 -0700 From: Enke Chen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: "UTTARO, JAMES" References: <4FCFEC86.6050706@raszuk.net> <8684_1339102246_4FD11426_8684_17472_1_53C29892C857584299CBF5D05346208A08D397@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FD1E202.6090503@raszuk.net> <1407_1339164741_4FD20845_1407_271_1_53C29892C857584299CBF5D05346208A08E913@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FD20D9E.2010505@raszuk.net> <4FD21577.2030103@raszuk.net> <4FD21CD7.30806@raszuk.net> <4FD92187.8080403@raszuk.net> <2B37563C-F3E2-4113-A5A2-35BA83F64FC3@junipe r.net> <4FD95202.2010205@raszuk.net> <4FD955D1.8090807@cisco.com> <4FDA093B.6030209@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org List" , "robert@raszuk.net" Subject: Re: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 18:34:57 -0000 Jim, What happens if an EBGP peer does not recognize this global STALE community? Isn't true that It may end up using the path that has been stale for days even in the presence of an alternate path. -- Enke On 6/14/12 11:23 AM, UTTARO, JAMES wrote: > Enke, > > Not sure I understand. Referring to the slides Bruno presented is your concern that the STALE CV is used to provide the semantic across AS boundaries?? For the iBGP case the use of Cost Community, Local Pref have been identified as mechanisms to de-pref the STALE path. Is this what you are speaking too?.. Across AS boundaries the STALE CD would only need to be interpreted once and the desired iBGP mechanism set.. Pls Clarify.. > > The technology is necessary and we need to be fair to our customers who expect that a failure in our control plane that simply advertises paths should not tear down their VPLS,VPN,3107 MultiCast etc...network. > > Jim Uttaro > > -----Original Message----- > From: Enke Chen [mailto:enkechen@cisco.com] > Sent: Thursday, June 14, 2012 11:55 AM > To: UTTARO, JAMES > Cc: robert@raszuk.net; idr@ietf.org List; Enke Chen > Subject: Re: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR WG document > > Jim, > > It may be true that "you can figure out the operational end", but can > the whole world figure out? With a global community, the whole world > will need to deal with it. I do not think that is necessary, nor fair. > > -- Enke > > On 6/14/12 6:14 AM, UTTARO, JAMES wrote: >> Without divulging too much internal AT&T plans, we are embarking on rolling out a number of communities to accomplish our network design goals. These communities have recently been defined and are the process of standardization. I think we can figure out the operational end.. What we really need is for folks to understand the reqs we have for BGP today in the post internet BGP signaled era.. >> >> Jim Uttaro >> >> -----Original Message----- >> From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Enke Chen >> Sent: Wednesday, June 13, 2012 11:09 PM >> To: robert@raszuk.net >> Cc: idr@ietf.org List >> Subject: Re: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR WG document >> >> Just try to point out the obvious: in general a new global community is >> difficult to roll out. The lack of scoping creates many operationally >> issues such as who can set it, who can override it, and where to accept >> and where to filter. >> >> It can be a burden for all involved, e.g., it has to be filtered out >> everywhere in a network if one does not want to use it. >> >> -- Enke >> >> On 6/13/12 7:52 PM, Robert Raszuk wrote: >>> Hi John, >>> >>> Actually not. Standardization does not equal that a feature will be >>> enabled or router image automatically upgraded after RFC is issued :). >>> >>> As long as EBGP speaker I do not control will not support this >>> extension I will still signal a STALE path with the community which he >>> will consider as good as not STALE one. >>> >>> To your point the case today between any two adjacent ASes (and within >>> the AS) you can achieve persistence by just agreeing on some community >>> value internally. >>> >>> Best regards, >>> R. >>> >>>> Robert, >>>> >>>> To this point: >>>> >>>> On Jun 13, 2012, at 7:25 PM, Robert Raszuk wrote: >>>> >>>>> In networks with >>>>> mixed persistence support and no support especially on EBGP links this >>>>> seems extremely dangerous feature. >>>> Your concern for "mixed persistence support" would actually seem to >>>> support the opposite point of view, that this *should* be >>>> standardized. As you know, one key reason to standardize things is to >>>> facilitate deployment of such features in mixed networks. >>>> >>>> I expect this will not be persuasive to you given your other >>>> objections, but I thought I should point it out. >>>> >>>> Regards, >>>> >>>> --John >>>> _______________________________________________ >>>> 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 >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr From ju1738@att.com Thu Jun 14 12:05:47 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C6EE21F876F for ; Thu, 14 Jun 2012 12:05:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.999 X-Spam-Level: X-Spam-Status: No, score=-105.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1pNl0E87y3ND for ; Thu, 14 Jun 2012 12:05:46 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id 0EB5021F876E for ; Thu, 14 Jun 2012 12:05:45 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO nbfkord-smmo07.seg.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.11.0-10) with ESMTP id a063adf4.2aaae9234940.707779.00-555.1975942.nbfkord-smmo07.seg.att.com (envelope-from ); Thu, 14 Jun 2012 19:05:46 +0000 (UTC) X-MXL-Hash: 4fda360a40451861-dcaa4ee59ba262467d9b0e2f187b9bbc4c15964d Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.11.0-10) over TLS secured channel with ESMTP id 7063adf4.0.707767.00-445.1975901.nbfkord-smmo07.seg.att.com (envelope-from ); Thu, 14 Jun 2012 19:05:44 +0000 (UTC) X-MXL-Hash: 4fda3608309df2b9-4b0e81c93a9a6d4689003207d51d81288dc63df4 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q5EJ5hEo032746; Thu, 14 Jun 2012 15:05:43 -0400 Received: from sflint01.pst.cso.att.com (sflint01.pst.cso.att.com [144.154.234.228]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q5EJ5Xt7032638 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 Jun 2012 15:05:37 -0400 Received: from MISOUT7MSGHUB9A.ITServices.sbc.com (misout7msghub9a.itservices.sbc.com [144.151.223.62]) by sflint01.pst.cso.att.com (RSA Interceptor); Thu, 14 Jun 2012 15:05:19 -0400 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9A.ITServices.sbc.com ([144.151.223.62]) with mapi id 14.01.0355.002; Thu, 14 Jun 2012 15:05:19 -0400 From: "UTTARO, JAMES" To: "'Enke Chen'" Thread-Topic: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR WG document Thread-Index: AQHNSdjWLXi2MBtrREqehs60QxJP75b5ZXmAgABlE8CAAHDNgP//5TtggABH7oD//8F2sA== Date: Thu, 14 Jun 2012 19:05:18 +0000 Message-ID: References: <4FCFEC86.6050706@raszuk.net> <8684_1339102246_4FD11426_8684_17472_1_53C29892C857584299CBF5D05346208A08D397@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FD1E202.6090503@raszuk.net> <1407_1339164741_4FD20845_1407_271_1_53C29892C857584299CBF5D05346208A08E913@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FD20D9E.2010505@raszuk.net> <4FD21577.2030103@raszuk.net> <4FD21CD7.30806@raszuk.net> <4FD92187.8080403@raszuk.net> <2B37563C-F3E2-4113-A5A2-35BA83F64FC3@junipe r.net> <4FD95202.2010205@raszuk.net> <4FD955D1.8090807@cisco.com> <4FDA093B.6030209@cisco.com> <4FDA2F1D.6070706@cisco.com> In-Reply-To: <4FDA2F1D.6070706@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.133.82] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=1.0 c=1 a=-hb8KOZl30UA:10 a=lYr-YFbwilAA:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=ZRNLZ4dFUbCvG8] X-AnalysisOut: [UMqPvVAA==:17 a=AUd_NHdVAAAA:8 a=2clOPd4PAAAA:8 a=48vgC7mU] X-AnalysisOut: [AAAA:8 a=BqQF1tpSpKZ6dSFxHCcA:9 a=CjuIK1q_8ugA:10 a=JfD0Fc] X-AnalysisOut: [h1gWkA:10 a=bDUki_mJ7DgA:10 a=lZB815dzVvQA:10 a=NO8aD1Dmb9] X-AnalysisOut: [x0rwLq:21 a=1bJYBd43xDr_3PN6:21] Cc: "idr@ietf.org List" , "robert@raszuk.net" Subject: Re: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 19:05:47 -0000 Enke, You are essentially echoing my concern for using GR and how it does not in= form an iBGP topology about path learned over a GR Active session.. I can s= upport this if GR is used as originally intended as a short duration hit wi= th control plane expected back quickly, but too be clear if there was an al= ternate path within the iBGP topology it would not be used while GR is acti= ve and not informing that paths learned there are suspect within or between= AS domains true??. We cannot have it both ways. To address your concern directly. In the models I am considering we control= or have cooperative arrangements with other partners that would ensure tha= t the behavior you describe would not occur. For a generic eBGP peer with a= customer the first thing that must happen is that the de-preffed path is t= he "only" path. For a VPN customer the majority of Hub sites i.e DCs are mu= lti-homed, in the internet model I am not that close too but I believe we h= ave multiple peering points, that being said we must clearly identify the u= se case and the risk/benefit analysis. Jim Uttaro -----Original Message----- From: Enke Chen [mailto:enkechen@cisco.com]=20 Sent: Thursday, June 14, 2012 2:36 PM To: UTTARO, JAMES Cc: robert@raszuk.net; idr@ietf.org List; Enke Chen Subject: Re: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR W= G document Jim, What happens if an EBGP peer does not recognize this global STALE=20 community? Isn't true that It may end up using the path that has been=20 stale for days even in the presence of an alternate path. -- Enke On 6/14/12 11:23 AM, UTTARO, JAMES wrote: > Enke, > > Not sure I understand. Referring to the slides Bruno presented is your c= oncern that the STALE CV is used to provide the semantic across AS boundari= es?? For the iBGP case the use of Cost Community, Local Pref have been iden= tified as mechanisms to de-pref the STALE path. Is this what you are speaki= ng too?.. Across AS boundaries the STALE CD would only need to be interpret= ed once and the desired iBGP mechanism set.. Pls Clarify.. > > The technology is necessary and we need to be fair to our customers who e= xpect that a failure in our control plane that simply advertises paths shou= ld not tear down their VPLS,VPN,3107 MultiCast etc...network. > > Jim Uttaro > > -----Original Message----- > From: Enke Chen [mailto:enkechen@cisco.com] > Sent: Thursday, June 14, 2012 11:55 AM > To: UTTARO, JAMES > Cc: robert@raszuk.net; idr@ietf.org List; Enke Chen > Subject: Re: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR= WG document > > Jim, > > It may be true that "you can figure out the operational end", but can > the whole world figure out? With a global community, the whole world > will need to deal with it. I do not think that is necessary, nor fair. > > -- Enke > > On 6/14/12 6:14 AM, UTTARO, JAMES wrote: >> Without divulging too much internal AT&T plans, we are embarking on roll= ing out a number of communities to accomplish our network design goals. The= se communities have recently been defined and are the process of standardiz= ation. I think we can figure out the operational end.. What we really need = is for folks to understand the reqs we have for BGP today in the post inter= net BGP signaled era.. >> >> Jim Uttaro >> >> -----Original Message----- >> From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of En= ke Chen >> Sent: Wednesday, June 13, 2012 11:09 PM >> To: robert@raszuk.net >> Cc: idr@ietf.org List >> Subject: Re: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as ID= R WG document >> >> Just try to point out the obvious: in general a new global community is >> difficult to roll out. The lack of scoping creates many operationally >> issues such as who can set it, who can override it, and where to accept >> and where to filter. >> >> It can be a burden for all involved, e.g., it has to be filtered out >> everywhere in a network if one does not want to use it. >> >> -- Enke >> >> On 6/13/12 7:52 PM, Robert Raszuk wrote: >>> Hi John, >>> >>> Actually not. Standardization does not equal that a feature will be >>> enabled or router image automatically upgraded after RFC is issued :). >>> >>> As long as EBGP speaker I do not control will not support this >>> extension I will still signal a STALE path with the community which he >>> will consider as good as not STALE one. >>> >>> To your point the case today between any two adjacent ASes (and within >>> the AS) you can achieve persistence by just agreeing on some community >>> value internally. >>> >>> Best regards, >>> R. >>> >>>> Robert, >>>> >>>> To this point: >>>> >>>> On Jun 13, 2012, at 7:25 PM, Robert Raszuk wrote: >>>> >>>>> In networks with >>>>> mixed persistence support and no support especially on EBGP links thi= s >>>>> seems extremely dangerous feature. >>>> Your concern for "mixed persistence support" would actually seem to >>>> support the opposite point of view, that this *should* be >>>> standardized. As you know, one key reason to standardize things is to >>>> facilitate deployment of such features in mixed networks. >>>> >>>> I expect this will not be persuasive to you given your other >>>> objections, but I thought I should point it out. >>>> >>>> Regards, >>>> >>>> --John >>>> _______________________________________________ >>>> 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 >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr From jakob.heitz@ericsson.com Thu Jun 14 13:08:51 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87BB621F873A for ; Thu, 14 Jun 2012 13:08:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.359 X-Spam-Level: X-Spam-Status: No, score=-5.359 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6-+KfZUKno7F for ; Thu, 14 Jun 2012 13:08:50 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 8E23821F865F for ; Thu, 14 Jun 2012 13:08:50 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q5EK7TGe005982; Thu, 14 Jun 2012 15:08:48 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.64]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Thu, 14 Jun 2012 16:08:40 -0400 From: Jakob Heitz To: "bruno.decraene@orange.com" , "robert@raszuk.net" Date: Thu, 14 Jun 2012 16:08:39 -0400 Thread-Topic: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR WG document Thread-Index: AQHNRLV1Krxik7qjvku42V+dyzAtsJbu3kuAgAq8kWCAAKxoQA== Message-ID: <7309FCBCAE981B43ABBE69B31C8D213921C21D06B5@EUSAACMS0701.eamcs.ericsson.se> References: <4911_1338974288_4FCF2050_4911_12906_1_53C29892C857584299CBF5D05346208A08CA08@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FCF800C.6070509@joelhalpern.com> <4FCF883B.6050501@raszuk.net> <4FCFEC86.6050706@raszuk.net> <507A0451-C11D-4CFB-8EE1-073220B1631E@cisco.com> <4FD0B33B.50603@raszuk.net> <3185_1339669607_4FD9BC66_3185_4099_6_53C29892C857584299CBF5D05346208A08FC9B@PEXCVZYM11.corporate.adroot.infra.ftgroup> In-Reply-To: <3185_1339669607_4FD9BC66_3185_4099_6_53C29892C857584299CBF5D05346208A08FC9B@PEXCVZYM11.corporate.adroot.infra.ftgroup> 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 List" , "Joel M. Halpern" , "UTTARO, JAMES" Subject: Re: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 20:08:51 -0000 I asked whether it was necessary, not whether it was too hard. There is (in my mind) an essential difference between a stale path and a low preference path: A low preference path exists. A stale path may not exist. In GR, we consider a short term existence doubt acceptable. You are proposing a long term existence doubt. This is the possibility of long term continuous traffic drop, not just traffic taking a longer path. On Thursday, June 14, 2012 3:27 AM, bruno.decraene@orange.com wrote: > Hi Jakob, >=20 >> From: Jakob Heitz [mailto:jakob.heitz@ericsson.com] >Sent: Thursday, >> June 07, 2012 5:46 PM=20 >>=20 >> On Jun 7, 2012, at 6:57 AM, "Robert Raszuk" >> wrote:=20 >>> As the STALE routes are not dynamically updated anymore, it's >>> desirable that they be only used in last resort. Hence when >>> comparing paths for a prefix, a non STALE path should be >>> preferred over a STALE path. >>=20 >> should a path with a shorter prefix also be preferred? >> Say the stale path is 10.0.0.0/24 and 10.0.0.0/16 exists and is not >> stale.=20 >=20 > You are raising a good point. > While preferring non stale more specific prefix over stale prefix > could probably make sense, IMHO I would not push persistence in this > direction: =20 > - too much change in BGP > - to some extend, the point of more specific prefixes being preferred > in the forwarding plane independently of the BGP preferences is a > different subject. E.g. draft-francois-limited-scope-specifics-01 is > another aspect. =20 >=20 > Regards, > Bruno >=20 --=20 Jakob Heitz.= From ju1738@att.com Thu Jun 14 13:20:42 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FEF521F85BD for ; Thu, 14 Jun 2012 13:20:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.679 X-Spam-Level: X-Spam-Status: No, score=-105.679 tagged_above=-999 required=5 tests=[AWL=-0.320, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KvwcKiZcOZBX for ; Thu, 14 Jun 2012 13:20:42 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id BAA6721F85A5 for ; Thu, 14 Jun 2012 13:20:41 -0700 (PDT) Received: from unknown [144.160.128.153] (EHLO nbfkord-smmo05.seg.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.11.0-10) with ESMTP id 9974adf4.6326a940.1286617.00-517.3526237.nbfkord-smmo05.seg.att.com (envelope-from ); Thu, 14 Jun 2012 20:20:41 +0000 (UTC) X-MXL-Hash: 4fda47997992a17e-44dee11647ce3d531603c5213483747f39bfe8b1 Received: from unknown [144.160.128.153] (EHLO flpi408.enaf.ffdc.sbc.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.11.0-10) over TLS secured channel with ESMTP id e874adf4.0.1286567.00-418.3525983.nbfkord-smmo05.seg.att.com (envelope-from ); Thu, 14 Jun 2012 20:20:30 +0000 (UTC) X-MXL-Hash: 4fda478e2bd9702c-60a089537fdcc3ef40e1a48b59f163b78a9de3bc Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q5EKKSGw014083; Thu, 14 Jun 2012 13:20:29 -0700 Received: from fflint04.pst.cso.att.com (fflint04.pst.cso.att.com [150.234.39.64]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q5EKKID5013924 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 Jun 2012 13:20:21 -0700 Received: from MISOUT7MSGHUB9B.ITServices.sbc.com (misout7msghub9b.itservices.sbc.com [144.151.223.72]) by fflint04.pst.cso.att.com (RSA Interceptor); Thu, 14 Jun 2012 13:19:57 -0700 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9B.ITServices.sbc.com ([144.151.223.72]) with mapi id 14.01.0355.002; Thu, 14 Jun 2012 16:19:57 -0400 From: "UTTARO, JAMES" To: "'Jakob Heitz'" , "bruno.decraene@orange.com" , "robert@raszuk.net" Thread-Topic: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR WG document Thread-Index: AQHNSmqdUZA/lNcAoUCmRt6Y2yCigQ== Date: Thu, 14 Jun 2012 20:19:56 +0000 Message-ID: References: <4911_1338974288_4FCF2050_4911_12906_1_53C29892C857584299CBF5D05346208A08CA08@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FCF800C.6070509@joelhalpern.com> <4FCF883B.6050501@raszuk.net> <4FCFEC86.6050706@raszuk.net> <507A0451-C11D-4CFB-8EE1-073220B1631E@cisco.com> <4FD0B33B.50603@raszuk.net> <3185_1339669607_4FD9BC66_3185_4099_6_53C29892C857584299CBF5D05346208A08FC9B@PEXCVZYM11.corporate.adroot.infra.ftgroup> <7309FCBCAE981B43ABBE69B31C8D213921C21D06B5@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D213921C21D06B5@EUSAACMS0701.eamcs.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.133.82] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.128.153] X-AnalysisOut: [v=1.0 c=1 a=-hb8KOZl30UA:10 a=lYr-YFbwilAA:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=xwOvzTHDVLE4u4] X-AnalysisOut: [nGvK72ag==:17 a=0FD05c-RAAAA:8 a=z9tbli-vAAAA:8 a=2clOPd4P] X-AnalysisOut: [AAAA:8 a=48vgC7mUAAAA:8 a=NARlE3IJKiWtmu-Blc8A:9 a=CjuIK1q] X-AnalysisOut: [_8ugA:10 a=f7GxY0FH8QIA:10 a=oAXR_kdF8uMA:10 a=bDUki_mJ7Dg] X-AnalysisOut: [A:10 a=lZB815dzVvQA:10] Cc: "idr@ietf.org List" , "Joel M. Halpern" Subject: Re: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 20:20:42 -0000 Jakob, Comments In-Line.. Jim Uttaro -----Original Message----- From: Jakob Heitz [mailto:jakob.heitz@ericsson.com]=20 Sent: Thursday, June 14, 2012 4:09 PM To: bruno.decraene@orange.com; robert@raszuk.net Cc: Pradosh Mohapatra; UTTARO, JAMES; idr@ietf.org List; Joel M. Halpern Subject: RE: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR W= G document I asked whether it was necessary, not whether it was too hard. There is (in my mind) an essential difference between a stale path and a low preference path: A low preference path exists. [Jim U>] Agreed A stale path may not exist. [Jim U>] Based on the service this is certainly true. Thus the reasoning is= that Persistence is applicable to use cases where the "risk" of inconsiste= ncy is out-weighed by a total outage.. as an ex, a 3107 BGP solution that c= reates an IGP is one which is very stable and should never change unless a = NH is added/deleted, a BGP Signaled VPLS is another ex.. Let me be very cle= ar we are not advocating that Persistence be used in an environment where t= here is a lot of normal churn that changes paths and associated NHs.. In GR, we consider a short term existence doubt acceptable. [Jim U>] Agreed. That is exactly the philosophical reason that changing kno= bs and timers does not turn it into Persistence.. The fundamental assumptio= n is that it is a short duration hit. To increase the timers turns it into = a medium/long existence and is not useful if there are other alternative pa= ths available and GR is not capable of informing the topology of suspect pa= ths.. You are proposing a long term existence doubt. [Jim U>] Yes. This is the possibility of long term continuous traffic drop, not just traffic taking a longer path. [Jim U>] First select appropriate AF/SAFI, service.. Then make a determinat= ion of catastrophic vs incremental outage... On Thursday, June 14, 2012 3:27 AM, bruno.decraene@orange.com wrote: > Hi Jakob, >=20 >> From: Jakob Heitz [mailto:jakob.heitz@ericsson.com] >Sent: Thursday, >> June 07, 2012 5:46 PM=20 >>=20 >> On Jun 7, 2012, at 6:57 AM, "Robert Raszuk" >> wrote:=20 >>> As the STALE routes are not dynamically updated anymore, it's >>> desirable that they be only used in last resort. Hence when >>> comparing paths for a prefix, a non STALE path should be >>> preferred over a STALE path. >>=20 >> should a path with a shorter prefix also be preferred? >> Say the stale path is 10.0.0.0/24 and 10.0.0.0/16 exists and is not >> stale.=20 >=20 > You are raising a good point. > While preferring non stale more specific prefix over stale prefix > could probably make sense, IMHO I would not push persistence in this > direction: =20 > - too much change in BGP > - to some extend, the point of more specific prefixes being preferred > in the forwarding plane independently of the BGP preferences is a > different subject. E.g. draft-francois-limited-scope-specifics-01 is > another aspect. =20 >=20 > Regards, > Bruno >=20 --=20 Jakob Heitz. From randy@psg.com Thu Jun 14 16:15:38 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03FFF11E807F for ; Thu, 14 Jun 2012 16:15:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IF3qGsMXqGhr for ; Thu, 14 Jun 2012 16:15:37 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id A8A0811E8072 for ; Thu, 14 Jun 2012 16:15:37 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SfJGI-000Ekv-Hk; Thu, 14 Jun 2012 23:15:34 +0000 Date: Fri, 15 Jun 2012 08:15:33 +0900 Message-ID: From: Randy Bush To: "UTTARO, JAMES" In-Reply-To: References: <4FCF883B.6050501@raszuk.net> <4FCFEC86.6050706@raszuk.net> <8684_1339102246_4FD11426_8684_17472_1_53C29892C857584299CBF5D05346208A08D397@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FD1E202.6090503@raszuk.net> <1407_1339164741_4FD20845_1407_271_1_53C29892C857584299CBF5D05346208A08E913@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FD20D9E.2010505@raszuk.net> <4FD21577.2030103@raszuk.net> <4FD21CD7.30806@raszuk.net> <4FD92187.8080403@raszuk.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: "idr@ietf.org List" , "robert@raszuk.net" Subject: Re: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 23:15:38 -0000 > The technology is necessary and we need to be fair to our customers > who expect that a failure in our control plane that simply advertises > paths should not tear down their VPLS,VPN,3107 MultiCast > etc...network. so you are expecting catastrophic failures of your control plane and yet you expect this ever more complex mechanism to bail you out. and you require that your ebgp peers play along? randy From robert@raszuk.net Thu Jun 14 17:31:13 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 357F811E809A for ; Thu, 14 Jun 2012 17:31:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fSFLeF8DCimN for ; Thu, 14 Jun 2012 17:31:12 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 86ADD11E8098 for ; Thu, 14 Jun 2012 17:31:08 -0700 (PDT) Received: (qmail 31940 invoked by uid 399); 15 Jun 2012 00:31:07 -0000 Received: from unknown (HELO ?172.16.197.148?) (pbs:robert@raszuk.net@58.80.213.53) by mail1310.opentransfer.com with ESMTPM; 15 Jun 2012 00:31:07 -0000 X-Originating-IP: 58.80.213.53 Message-ID: <4FDA824A.8070103@raszuk.net> Date: Thu, 14 Jun 2012 17:31:06 -0700 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120604 Thunderbird/13.0 MIME-Version: 1.0 To: "idr@ietf.org List" References: <4FCF800C.6070509@joelhalpern.com> <4FCF883B.6050501@raszuk.net> <4FCFEC86.6050706@raszuk.net> <8684_1339102246_4FD11426_8684_17472_1_53C29892C857584299CBF5D05346208A08D397@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FD1E202.6090503@raszuk.net> <1407_1339164741_4FD20845_1407_271_1_53C29892C857584299CBF5D05346208A08E913@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FD20D9E.2010505@raszuk.net> <4FD21577.2030103@raszuk.net> <4FD21CD7.30806@raszuk.net> <4FD92187.8080403@raszuk.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Idr] Adoption of draft-uttaro-idr-bgp-persistence-01 as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 00:31:13 -0000 > GR is done at a per session lacks path granularity That's another characteristic of the proposal which requires serious consideration. In my previous 4 points I have focused on effects of re-advertisement of paths marked as STALE. But the proposal introduces upon BGP session failure per path decision to keep and use the path (+re-advertise as STALE) or not. That effectively means that all BGP implementation optimizations which went into the shipping code basis to delete as soon as possible _all_ paths which came from particular BGP session upon it's failure are now to be modified to consider only those which carry DO_NOT_PERSIST community. Having GR per session and Persistance per path is also an interesting complication. The current draft seems to be saying (unlike some authors) that it is ok to keep GR in place and during GR timer do not resignal them as STALE. However we have heard already that it is wrong to keep the path in GR mode for the GR timer without telling about it to customers. Quote: "GR assumes that paths that are "suspect" are still considered best, there is no informing the topology that paths over this session should be de-preffed.. Essentially GR is deciding for the SP. I want the control." I am quite not clear what the behaviour of GR+Persistance is really expected to be. While all can be developed it does cost cpu, memory and stability. Regards, R. From shares@ndzh.com Fri Jun 15 12:03:57 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E9D311E80C8 for ; Fri, 15 Jun 2012 12:03:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.106 X-Spam-Level: ** X-Spam-Status: No, score=2.106 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VT8Rtix-owCV for ; Fri, 15 Jun 2012 12:03:56 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [63.208.161.194]) by ietfa.amsl.com (Postfix) with ESMTP id 1DDF811E80B5 for ; Fri, 15 Jun 2012 12:03:55 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.124.192.200; Received: from SKH2012HPLT (unverified [174.124.192.200]) by hickoryhill-consulting.com (SurgeMail 5.2a) with ESMTP id 3389294-1945496 for multiple; Fri, 15 Jun 2012 15:03:48 -0400 From: "Susan Hares" To: Date: Fri, 15 Jun 2012 15:03:47 -0400 Message-ID: <003c01cd4b29$97d7b150$c78713f0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003D_01CD4B08.10C61150" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac1LKKslUprHg2opQAqhsJ0zGwTtpQ== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Cc: "'John G. Scudder'" Subject: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 19:03:57 -0000 This is a multipart message in MIME format. ------=_NextPart_000_003D_01CD4B08.10C61150 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit IDR WG and BGPers: While there is a strong debate on draft-uttaro-idr-bgp-persistence-01 as IDR WG document, I do not see a clear consensus. We also did not get an overwhelming number of you to hum either way (11 total). Since some of those who voted "no" have suggested alternate text to the author, I would like to extend the time to consider this draft for 3 more weeks. To accept the draft we need a few more of you to "hum" yes or "hum" no. Sue Hares ------=_NextPart_000_003D_01CD4B08.10C61150 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

IDR WG and BGPers: =

 

While there is a = strong debate on draft-uttaro-idr-bgp-persistence-01 as IDR WG document, = I do not see a clear consensus.  We also did not get an = overwhelming number of you to hum either way (11 total). =

 

Since some of those = who voted “no” have suggested alternate text to the author, = I would like to extend the time to consider this draft for 3 more weeks. =

 

To accept the draft = we need a few more of you to “hum” yes or “hum” = no.

 

Sue = Hares

 

 

------=_NextPart_000_003D_01CD4B08.10C61150-- From Donald.Smith@CenturyLink.com Fri Jun 15 12:48:48 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8209511E80F9 for ; Fri, 15 Jun 2012 12:48:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r1bijvajh024 for ; Fri, 15 Jun 2012 12:48:47 -0700 (PDT) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by ietfa.amsl.com (Postfix) with ESMTP id 8748911E808E for ; Fri, 15 Jun 2012 12:48:47 -0700 (PDT) Received: from lxdenvmpc030.qintra.com (lxdenvmpc030.qintra.com [10.1.51.30]) by sudnp799.qwest.com (8.14.4/8.14.4) with ESMTP id q5FJmiKG007107 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 Jun 2012 13:48:45 -0600 (MDT) Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id A45091E005F; Fri, 15 Jun 2012 13:48:39 -0600 (MDT) Received: from suomp61i.qintra.com (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id 802D31E005B; Fri, 15 Jun 2012 13:48:39 -0600 (MDT) Received: from suomp61i.qintra.com (localhost [127.0.0.1]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id q5FJmdoL010621; Fri, 15 Jun 2012 14:48:39 -0500 (CDT) Received: from qtdenexhtm22.AD.QINTRA.COM (qtdenexhtm22.ad.qintra.com [151.119.91.231]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id q5FJmcKh010616 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Fri, 15 Jun 2012 14:48:38 -0500 (CDT) Received: from qtdenexmbm24.AD.QINTRA.COM ([151.119.91.226]) by qtdenexhtm22.AD.QINTRA.COM ([151.119.91.231]) with mapi; Fri, 15 Jun 2012 13:48:38 -0600 From: "Smith, Donald" To: "'Susan Hares'" , "'idr@ietf.org'" Date: Fri, 15 Jun 2012 13:48:37 -0600 Thread-Topic: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks Thread-Index: Ac1LKKslUprHg2opQAqhsJ0zGwTtpQABwNAw Message-ID: References: <003c01cd4b29$97d7b150$c78713f0$@ndzh.com> In-Reply-To: <003c01cd4b29$97d7b150$c78713f0$@ndzh.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 X-CFilter-Loop: Reflected Cc: "'John G. Scudder'" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 19:48:48 -0000 Yes. I failed to review this during the last run but would like to. When packets collide the controllers cease transmission AND wait a random t= ime before retransmission (mostly)! Donald.Smith@CenturyLink.com > -----Original Message----- > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of > Susan Hares > Sent: Friday, June 15, 2012 1:04 PM > To: idr@ietf.org > Cc: 'John G. Scudder' > Subject: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - > 3 more weeks > > IDR WG and BGPers: > > > > While there is a strong debate on draft-uttaro-idr-bgp-persistence-01 > as IDR WG document, I do not see a clear consensus. We also did not > get an overwhelming number of you to hum either way (11 total). > > > > Since some of those who voted "no" have suggested alternate text to the > author, I would like to extend the time to consider this draft for 3 > more weeks. > > > > To accept the draft we need a few more of you to "hum" yes or "hum" no. > > > > Sue Hares > > > > This communication is the property of CenturyLink and may contain confident= ial or privileged information. Unauthorized use of this communication is st= rictly 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 randy@psg.com Fri Jun 15 14:56:59 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37DAD21F8483 for ; Fri, 15 Jun 2012 14:56:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pgCHZgTPgFcw for ; Fri, 15 Jun 2012 14:56:58 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id B9C0521F846A for ; Fri, 15 Jun 2012 14:56:58 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SfeVm-000IPG-2t; Fri, 15 Jun 2012 21:56:58 +0000 Date: Sat, 16 Jun 2012 06:56:57 +0900 Message-ID: From: Randy Bush To: Susan Hares In-Reply-To: <003c01cd4b29$97d7b150$c78713f0$@ndzh.com> References: <003c01cd4b29$97d7b150$c78713f0$@ndzh.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: idr wg Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 21:56:59 -0000 > While there is a strong debate on draft-uttaro-idr-bgp-persistence-01 > as IDR WG document which is procedurally strange to me. i said yes to making it a wg document so we could discuss it. since we seem to be discussing it anyway, i guess the hum is really about whether one thinks it should be a ps, kinda what i thought wglc was, which i don't. so i guess, no, i do not support this being a wg document. randy From internet-drafts@ietf.org Sun Jun 17 13:28:27 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3A3521F8608; Sun, 17 Jun 2012 13:28:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.432 X-Spam-Level: X-Spam-Status: No, score=-102.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TKFhQpVopo5G; Sun, 17 Jun 2012 13:28:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 704DC21F85AC; Sun, 17 Jun 2012 13:28:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.20 Message-ID: <20120617202827.13689.83125.idtracker@ietfa.amsl.com> Date: Sun, 17 Jun 2012 13:28:27 -0700 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-add-paths-07.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jun 2012 20:28:28 -0000 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 : Advertisement of Multiple Paths in BGP Author(s) : Daniel Walton Enke Chen Alvaro Retana John Scudder Filename : draft-ietf-idr-add-paths-07.txt Pages : 8 Date : 2012-06-17 Abstract: In this document we propose a BGP extension that allows the advertisement of multiple paths for the same address prefix without the new paths implicitly replacing any previous ones. The essence of the extension is that each path is identified by a path identifier in addition to the address prefix. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-add-paths There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-add-paths-07 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-add-paths-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Sun Jun 17 13:35:12 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A624A21F8622; Sun, 17 Jun 2012 13:35:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.442 X-Spam-Level: X-Spam-Status: No, score=-102.442 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CeoZSwyfGjXE; Sun, 17 Jun 2012 13:35:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DA3A21F85FD; Sun, 17 Jun 2012 13:35:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.20 Message-ID: <20120617203512.20483.48784.idtracker@ietfa.amsl.com> Date: Sun, 17 Jun 2012 13:35:12 -0700 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-bgp-enhanced-route-refresh-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jun 2012 20:35:12 -0000 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 : Enhanced Route Refresh Capability for BGP-4 Author(s) : Keyur Patel Enke Chen Balaji Venkatachalapathy Filename : draft-ietf-idr-bgp-enhanced-route-refresh-02.txt Pages : 6 Date : 2012-06-17 Abstract: In this document we enhance the existing BGP route refresh mechanisms to provide for the demarcation of the beginning and the ending of a route refresh. The enhancement can be used to facilitate on-line, non-disruptive consistency validations of BGP routing updates. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-enhanced-route-refresh There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-bgp-enhanced-route-refresh-02 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-bgp-enhanced-route-refr= esh-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Sun Jun 17 13:44:52 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 069F621F865A; Sun, 17 Jun 2012 13:44:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.452 X-Spam-Level: X-Spam-Status: No, score=-102.452 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fCAvGqS5mj5H; Sun, 17 Jun 2012 13:44:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2213721F8608; Sun, 17 Jun 2012 13:44:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.20 Message-ID: <20120617204451.26844.76025.idtracker@ietfa.amsl.com> Date: Sun, 17 Jun 2012 13:44:51 -0700 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-error-handling-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jun 2012 20:44:52 -0000 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 : Revised Error Handling for BGP UPDATE Messages Author(s) : John G. Scudder Enke Chen Pradosh Mohapatra Keyur Patel Filename : draft-ietf-idr-error-handling-02.txt Pages : 10 Date : 2012-06-17 Abstract: According to the base BGP specification, a BGP speaker that receives an UPDATE message containing a malformed attribute is required to reset the session over which the offending attribute was received. This behavior is undesirable as a session reset would impact not only routes with the offending attribute, but also other valid routes exchanged over the session. This document partially revises the error handling for UPDATE messages, and provides guidelines for the authors of documents defining new attributes. Finally, it revises the error handling procedures for several existing attributes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-error-handling There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-error-handling-02 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-error-handling-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ju1738@att.com Sun Jun 17 17:29:44 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B294921F854A; Sun, 17 Jun 2012 17:29:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.192 X-Spam-Level: X-Spam-Status: No, score=-106.192 tagged_above=-999 required=5 tests=[AWL=0.407, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IQcoYMSZNAtV; Sun, 17 Jun 2012 17:29:44 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id A7B4321F8547; Sun, 17 Jun 2012 17:29:43 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.11.0-10) over TLS secured channel with ESMTP id 7767edf4.0.79424.00-470.204487.nbfkord-smmo05.seg.att.com (envelope-from ); Mon, 18 Jun 2012 00:29:43 +0000 (UTC) X-MXL-Hash: 4fde76774912034f-2e7b489bfab7e0657a7ac3b405547e209b346f88 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q5I0Tgwe007344; Sun, 17 Jun 2012 20:29:42 -0400 Received: from sflint01.pst.cso.att.com (sflint01.pst.cso.att.com [144.154.234.228]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q5I0TZBK007316 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 17 Jun 2012 20:29:41 -0400 Received: from MISOUT7MSGHUB9E.ITServices.sbc.com (misout7msghub9e.itservices.sbc.com [144.151.223.61]) by sflint01.pst.cso.att.com (RSA Interceptor); Sun, 17 Jun 2012 20:29:18 -0400 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9E.ITServices.sbc.com ([144.151.223.61]) with mapi id 14.01.0355.002; Sun, 17 Jun 2012 20:29:16 -0400 From: "UTTARO, JAMES" To: "'internet-drafts@ietf.org'" , "i-d-announce@ietf.org" Thread-Topic: [Idr] I-D Action: draft-ietf-idr-error-handling-02.txt Thread-Index: AQHNTMoO3AC4WgUFwEeXslewDoqMZpb/MenA Date: Mon, 18 Jun 2012 00:29:16 +0000 Message-ID: References: <20120617204451.26844.76025.idtracker@ietfa.amsl.com> In-Reply-To: <20120617204451.26844.76025.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.57.220] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=1.0 c=1 a=BuzhNiqCtxIA:10 a=Crak0S_X7RUA:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=ZRNLZ4dFUbCvG8] X-AnalysisOut: [UMqPvVAA==:17 a=48vgC7mUAAAA:8 a=0XoN3xWwTxSwhkm8rGEA:9 a=] X-AnalysisOut: [CjuIK1q_8ugA:10 a=lZB815dzVvQA:10] Cc: "idr@ietf.org" Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2012 00:29:44 -0000 I took a read on this ( I will read more thoroughly) but one section jumped= out at me. "Operational Considerations". Although the "treat-as-withdraw" error-handling behavior defined in Section 2 makes every effort to preserve BGP's correctness, we note that if an UPDATE received on an IBGP session is subjected to this treatment, inconsistent routing within the affected Autonomous System may result. The consequences of inconsistent routing can include long-lived forwarding loops and black holes. While lamentable, this issue is expected to be rare in practice, and more importantly is seen as less problematic than the session-reset behavior it replaces. " When a malformed attribute is indeed detected over an IBGP session, we RECOMMEND that routes with the malformed attribute be identified and traced back to the ingress router in the network where the routes were sourced or received externally, and then a filter be applied on the ingress router to prevent the routes from being sourced or received. This will help maintain routing consistency in the network." I don't think the terminology "lamentable" to describe Long lived forwardin= g loops and black holes is appropriate as it would probably be more than re= grettable. Could you expand on the conditions and how BGP would eventually = recover. That would be a good addition. I am a bit confused, how does this = type of error handling which restarts GR ( As of my last read ) and which B= GP persistence lives through change the paradigm of these solutions? There = is a notion of treat as withdraw for some attrs, but don't tear down sessio= n?? How many malformed updates before the session is torn down? Ever?=20 According to the next paragraph ( See below ) there is an expectation that = the offending ingress router should be identified, and then a filter should= be applied for those paths in a given updated with the malformed attrs :) = What is the recommendation for doing this? Will there be a draft whereby th= e detecting router somehow figures out the offending ingress router, builds= routing policy and then sends it there to dynamically create the filter. T= his seems non-trivial, I guess Flowspec like technology may be used not sur= e.. Is the ingress router assumed to be in the same AS domain as the detect= ing router? Administrative domain may span multiple AS domains.. Jim Uttaro -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of inter= net-drafts@ietf.org Sent: Sunday, June 17, 2012 4:45 PM To: i-d-announce@ietf.org Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-error-handling-02.txt 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 : Revised Error Handling for BGP UPDATE Messages Author(s) : John G. Scudder Enke Chen Pradosh Mohapatra Keyur Patel Filename : draft-ietf-idr-error-handling-02.txt Pages : 10 Date : 2012-06-17 Abstract: According to the base BGP specification, a BGP speaker that receives an UPDATE message containing a malformed attribute is required to reset the session over which the offending attribute was received. This behavior is undesirable as a session reset would impact not only routes with the offending attribute, but also other valid routes exchanged over the session. This document partially revises the error handling for UPDATE messages, and provides guidelines for the authors of documents defining new attributes. Finally, it revises the error handling procedures for several existing attributes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-error-handling There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-error-handling-02 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-error-handling-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From gvandeve@cisco.com Sun Jun 17 19:14:37 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F08DF21F85D1 for ; Sun, 17 Jun 2012 19:14:36 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZzmilTyhdgGp for ; Sun, 17 Jun 2012 19:14:35 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 1CA0E21F85CE for ; Sun, 17 Jun 2012 19:14:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=gvandeve@cisco.com; l=5987; q=dns/txt; s=iport; t=1339985675; x=1341195275; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=mLsk0neHb/yzUyH2IJYk2qC/fHT1p+E10yIe8fJjY5U=; b=ZTy0Gds//Q7IPfYl0n/IO8KZRdJEIovmZVGkR3DiQFL2yHVlsOAF74v5 EIWgOPDGCQa8zMlD/kPa24rV5E8MfKin1LKC2nY399q8XVbaRC0gBVmrO Ie6kq3+CMzf71sM2iQtv9g7W0ls/1zvQIP5yEZPVw1nqL3jFV6IPs/0VT w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAOSN3k+Q/khR/2dsb2JhbABFgkWzEYEHghgBAQEEEgEJEQNJEAIBCA4DBAEBCwYNCgEGAUUJCAEBBAESCBqHaZhhnmqLN4VbYAOjO4FmgmI X-IronPort-AV: E=Sophos;i="4.75,789,1330905600"; d="scan'208,217";a="5887153" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-4.cisco.com with ESMTP; 18 Jun 2012 02:14:33 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q5I2EXQS023036; Mon, 18 Jun 2012 02:14:33 GMT Received: from xmb-ams-102.cisco.com ([144.254.74.77]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 18 Jun 2012 04:14:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD4CF8.19C26732" Date: Mon, 18 Jun 2012 04:14:31 +0200 Message-ID: <5C99EC8C99D9BB45AC51D20DC2AD2DC507D5E3CF@XMB-AMS-102.cisco.com> In-Reply-To: <003c01cd4b29$97d7b150$c78713f0$@ndzh.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3more weeks Thread-Index: Ac1LKKslUprHg2opQAqhsJ0zGwTtpQBz1/Cg References: <003c01cd4b29$97d7b150$c78713f0$@ndzh.com> From: "Gunter Van de Velde (gvandeve)" To: "Susan Hares" , X-OriginalArrivalTime: 18 Jun 2012 02:14:33.0416 (UTC) FILETIME=[19ECC480:01CD4CF8] Cc: "John G. Scudder" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2012 02:14:38 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD4CF8.19C26732 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 'hum' ... yes... =20 G/ =20 From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: vrijdag 15 juni 2012 21:04 To: idr@ietf.org Cc: 'John G. Scudder' Subject: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3more weeks =20 IDR WG and BGPers:=20 =20 While there is a strong debate on draft-uttaro-idr-bgp-persistence-01 as IDR WG document, I do not see a clear consensus. We also did not get an overwhelming number of you to hum either way (11 total).=20 =20 Since some of those who voted "no" have suggested alternate text to the author, I would like to extend the time to consider this draft for 3 more weeks.=20 =20 To accept the draft we need a few more of you to "hum" yes or "hum" no.=20 =20 Sue Hares =20 =20 ------_=_NextPart_001_01CD4CF8.19C26732 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

‘hum’ ... = yes...

 

G/

 

From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares
Sent: vrijdag 15 juni 2012 21:04
To: idr@ietf.org
Cc: 'John G. Scudder'
Subject: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG = document - 3more weeks

 

IDR WG and BGPers:

 

While there is a strong debate on draft-uttaro-idr-bgp-persistence-01 as IDR = WG document, I do not see a clear consensus.  We also did not get an overwhelming number of you to hum either way (11 total). =

 

Since some of those who voted “no” have suggested alternate text = to the author, I would like to extend the time to consider this draft for 3 more weeks. =

 

To accept the draft we need a few more of you to “hum” yes or = “hum” no.

 

Sue Hares

 

 

------_=_NextPart_001_01CD4CF8.19C26732-- From roberto.fragassi@alcatel-lucent.com Mon Jun 18 05:49:22 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBED121F858D for ; Mon, 18 Jun 2012 05:49:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y47q4oW95hTF for ; Mon, 18 Jun 2012 05:49:21 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id B2A3821F84DE for ; Mon, 18 Jun 2012 05:49:21 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id q5ICnI84027282 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 18 Jun 2012 07:49:18 -0500 (CDT) Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q5ICnIrH023418 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 18 Jun 2012 07:49:18 -0500 Received: from USNAVSXCHMBSC2.ndc.alcatel-lucent.com ([135.3.39.145]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Mon, 18 Jun 2012 07:49:18 -0500 From: "Fragassi, Roberto (Roberto)" To: Susan Hares , "idr@ietf.org" Date: Mon, 18 Jun 2012 07:49:22 -0500 Thread-Topic: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks Thread-Index: Ac1LKKslUprHg2opQAqhsJ0zGwTtpQCJx/sQ Message-ID: <73F3CA62A57C6148B6ECEB8DB8E40A290B97818F2F@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> References: <003c01cd4b29$97d7b150$c78713f0$@ndzh.com> In-Reply-To: <003c01cd4b29$97d7b150$c78713f0$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_73F3CA62A57C6148B6ECEB8DB8E40A290B97818F2FUSNAVSXCHMBSC_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Cc: "'John G. Scudder'" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2012 12:49:23 -0000 --_000_73F3CA62A57C6148B6ECEB8DB8E40A290B97818F2FUSNAVSXCHMBSC_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 Support. With the continued growth of spoke topologies in mobility backhaul, the con= tinued work on this draft as WG has its value for dealing with catastrophic= failures. From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Susan= Hares Sent: Friday, June 15, 2012 3:04 PM To: idr@ietf.org Cc: 'John G. Scudder' Subject: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 m= ore weeks IDR WG and BGPers: While there is a strong debate on draft-uttaro-idr-bgp-persistence-01 as ID= R WG document, I do not see a clear consensus. We also did not get an over= whelming number of you to hum either way (11 total). Since some of those who voted "no" have suggested alternate text to the aut= hor, I would like to extend the time to consider this draft for 3 more week= s. To accept the draft we need a few more of you to "hum" yes or "hum" no. Sue Hares --_000_73F3CA62A57C6148B6ECEB8DB8E40A290B97818F2FUSNAVSXCHMBSC_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1 Support.

 

With the continued growth of spoke topologies in= mobility backhaul, the continued work on this draft as WG has its value fo= r dealing with catastrophic failures.

 

From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.or= g] On Behalf Of Susan Hares
Sent: Friday, June 15, 2012 3:= 04 PM
To: idr@ietf.org
Cc: 'John G. Scudder'
Subj= ect: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 m= ore weeks

 =

IDR WG and BGPers:

 

While there is a strong debate on draft-uttaro-idr-bgp-p= ersistence-01 as IDR WG document, I do not see a clear consensus.  We = also did not get an overwhelming number of you to hum either way (11 total)= .

 

Since some of= those who voted “no” have suggested alternate text to the auth= or, I would like to extend the time to consider this draft for 3 more weeks= .

 

To accept the= draft we need a few more of you to “hum” yes or “humR= 21; no.

 

Sue Har= es

 

 

= --_000_73F3CA62A57C6148B6ECEB8DB8E40A290B97818F2FUSNAVSXCHMBSC_-- From paul@unbehagen.net Mon Jun 18 07:38:56 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4505121F86B4 for ; Mon, 18 Jun 2012 07:38:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7kw8QLofREb3 for ; Mon, 18 Jun 2012 07:38:55 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 084BA21F86B3 for ; Mon, 18 Jun 2012 07:38:54 -0700 (PDT) Received: by yhq56 with SMTP id 56so4234164yhq.31 for ; Mon, 18 Jun 2012 07:38:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=/MxcBaV/ItVKdeMa3rRBzElKdEpym0Mk9h6hZop5lEY=; b=P17Sv+JPKy9IKbhYl5d0nb4M8RcO1+Lt9RBpYFOtQdrfFVi1axypwJtB/rX/epiIYX ZNbXgFXZ+5Naazec++osmhtln7aNI0JUkba70NmZtKceLgbB0ypvDZSiH9CWPLCbxkNQ xNhAWuB8CrHGIK7ZjCAa4J+bmejIWw8KS6aqTseShjE57K6GQYHYX32SCfFYPUyJdmax y7ZxqSNtJxddKOTWdxisDhJeZy72ti5AuK8DU8TvTYgumPaM/daUhtsNOSNoaE0MeQZX qrIrWOzbV8zCYLbs/ZpY3Cu4XBsFM+JJLRKkxjh78i7DW9ClRj4urpuTOl+NRkmVExzF /gqA== Received: by 10.50.181.232 with SMTP id dz8mr8754461igc.72.1340030334086; Mon, 18 Jun 2012 07:38:54 -0700 (PDT) Received: from [10.0.1.6] (c-67-161-144-217.hsd1.co.comcast.net. [67.161.144.217]) by mx.google.com with ESMTPS id bo7sm15940541igb.2.2012.06.18.07.38.51 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 18 Jun 2012 07:38:52 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_6C48D3F9-95A5-4B7B-8DB4-51A26DE992FE" From: Paul Unbehagen In-Reply-To: <73F3CA62A57C6148B6ECEB8DB8E40A290B97818F2F@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> Date: Mon, 18 Jun 2012 08:38:51 -0600 Message-Id: References: <003c01cd4b29$97d7b150$c78713f0$@ndzh.com> <73F3CA62A57C6148B6ECEB8DB8E40A290B97818F2F@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> To: "Fragassi, Roberto (Roberto)" X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQkzFt7V6i5LMhNe/nSjLPY7zEYSj62EC26TbvIeMU3c3mRibpZJ/3OFUZ/mISw6jg1YXvCQ Cc: "idr@ietf.org" , "'John G. Scudder'" , Susan Hares Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2012 14:38:56 -0000 --Apple-Mail=_6C48D3F9-95A5-4B7B-8DB4-51A26DE992FE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 +1 -- Paul On Jun 18, 2012, at 6:49 AM, Fragassi, Roberto (Roberto) wrote: > +1 Support. > =20 > With the continued growth of spoke topologies in mobility backhaul, = the continued work on this draft as WG has its value for dealing with = catastrophic failures. > =20 > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of = Susan Hares > Sent: Friday, June 15, 2012 3:04 PM > To: idr@ietf.org > Cc: 'John G. Scudder' > Subject: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document = - 3 more weeks > =20 > IDR WG and BGPers: > =20 > While there is a strong debate on draft-uttaro-idr-bgp-persistence-01 = as IDR WG document, I do not see a clear consensus. We also did not get = an overwhelming number of you to hum either way (11 total). > =20 > Since some of those who voted =93no=94 have suggested alternate text = to the author, I would like to extend the time to consider this draft = for 3 more weeks. > =20 > To accept the draft we need a few more of you to =93hum=94 yes or = =93hum=94 no. > =20 > Sue Hares > =20 > =20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr --Apple-Mail=_6C48D3F9-95A5-4B7B-8DB4-51A26DE992FE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 +1



On Jun 18, 2012, at 6:49 AM, Fragassi, Roberto (Roberto) = wrote:

+1 Support.
 
With the = continued growth of spoke topologies in mobility backhaul, the continued = work on this draft as WG has its value for dealing with catastrophic = failures.
 
From: idr-bounces@ietf.org = [mailto:idr-bounces@ietf.org] On Behalf Of Susan = Hares
Sent: Friday, June 15, 2012 3:04 = PM
To: idr@ietf.org
Cc: 'John G. = Scudder'
Subject: [Idr] = draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more = weeks
 
IDR WG and BGPers:
 
While there is a strong debate on = draft-uttaro-idr-bgp-persistence-01 as IDR WG document, I do not see a = clear consensus.  We also did not get an overwhelming number of you = to hum either way (11 total).
 
Since some of those who voted =93no=94= have suggested alternate text to the author, I would like to extend the = time to consider this draft for 3 more = weeks.
 
To accept the draft we need a few more of you to =93hum=94 yes = or =93hum=94 no.
 
Sue Hares
 
 
____________________________________= ___________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mail= man/listinfo/idr

= --Apple-Mail=_6C48D3F9-95A5-4B7B-8DB4-51A26DE992FE-- From jgs@juniper.net Mon Jun 18 08:30:59 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A284F21F86FA for ; Mon, 18 Jun 2012 08:30:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7d0lVyJ4vIUf for ; Mon, 18 Jun 2012 08:30:59 -0700 (PDT) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by ietfa.amsl.com (Postfix) with ESMTP id D47DD21F86F9 for ; Mon, 18 Jun 2012 08:30:58 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKT99Jreh5GG95XMriSIMUksQ+SOXwD0nd@postini.com; Mon, 18 Jun 2012 08:30:58 PDT Received: from [172.16.13.205] (172.16.13.205) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server id 8.3.213.0; Mon, 18 Jun 2012 08:29:45 -0700 From: "John G. Scudder" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 18 Jun 2012 11:29:46 -0400 Message-ID: <8AE0D84F-7E85-44DC-BE6B-754615ACD207@juniper.net> To: "idr@ietf.org List" MIME-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Cc: draft-ymbk-rfd-usable@tools.ietf.org Subject: [Idr] IDR WG adoption of draft-ymbk-rfd-usable X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2012 15:30:59 -0000 Folks, draft-ymbk-rfd-usable is adopted as an IDR WG item. Sorry for not = announcing this earlier. Authors, please resubmit as draft-ietf-idr. Thanks, --John= From robert@raszuk.net Mon Jun 18 09:00:20 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B6EB21F86F3 for ; Mon, 18 Jun 2012 09:00:20 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hu36-1PQrrjH for ; Mon, 18 Jun 2012 09:00:19 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id B04F421F86F1 for ; Mon, 18 Jun 2012 09:00:18 -0700 (PDT) Received: (qmail 29687 invoked by uid 399); 18 Jun 2012 16:00:17 -0000 Received: from unknown (HELO ?192.168.1.91?) (pbs:robert@raszuk.net@83.31.223.50) by mail1310.opentransfer.com with ESMTPM; 18 Jun 2012 16:00:17 -0000 X-Originating-IP: 83.31.223.50 Message-ID: <4FDF508F.2040400@raszuk.net> Date: Mon, 18 Jun 2012 18:00:15 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: "UTTARO, JAMES" References: <20120617204451.26844.76025.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org" , "'internet-drafts@ietf.org'" , "i-d-announce@ietf.org" Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2012 16:00:20 -0000 Jim, > I am a bit confused, how does this type of error handling which > restarts GR ( As of my last read ) and which BGP persistence lives > through change the paradigm of these solutions? Can you please expand on what do you mean that "BGP persistence lives through"? Are you expecting that in the case of malformed update message where treat-as-withdraw would be applicable BGP speaker MUST NOT withdraw prefixes under the described error condition because neighbor is marked as "persistent" ? Thx, R. From jgs@juniper.net Mon Jun 18 09:08:40 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BD5621F86EE for ; Mon, 18 Jun 2012 09:08:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 76RaNsRp+AZe for ; Mon, 18 Jun 2012 09:08:39 -0700 (PDT) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by ietfa.amsl.com (Postfix) with ESMTP id 3B24E21F86DA for ; Mon, 18 Jun 2012 09:08:27 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKT99SejeRyg/FnIywSVCBYENemkGlWm44@postini.com; Mon, 18 Jun 2012 09:08:39 PDT Received: from [172.16.13.205] (172.16.13.205) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server id 8.3.213.0; Mon, 18 Jun 2012 09:07:34 -0700 MIME-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset="us-ascii" From: "John G. Scudder" In-Reply-To: Date: Mon, 18 Jun 2012 12:07:33 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <888345AD-04F2-4A64-A801-FC9928632C91@juniper.net> References: <003c01cd4b29$97d7b150$c78713f0$@ndzh.com> To: Randy Bush X-Mailer: Apple Mail (2.1278) Cc: idr wg , Susan Hares Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2012 16:08:40 -0000 On Jun 15, 2012, at 5:56 PM, Randy Bush wrote: >> While there is a strong debate on draft-uttaro-idr-bgp-persistence-01 >> as IDR WG document >=20 > which is procedurally strange to me. i said yes to making it a wg > document so we could discuss it. =20 We can discuss anything related to BGP on the IDR list, within reason. A = document doesn't need to be chartered to be discussed. WG adoption means there is consensus for the WG to work on the problem = the draft addresses, and to generally start with the approach proposed = in the draft, although the latter is subject to discussion. Or that's how I see it. > since we seem to be discussing it > anyway, i guess the hum is really about whether one thinks it should = be > a ps, kinda what i thought wglc was, which i don't. so i guess, no, i > do not support this being a wg document. Duly noted. --John= From internet-drafts@ietf.org Mon Jun 18 09:18:03 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 958FB21F8715; Mon, 18 Jun 2012 09:18:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.391 X-Spam-Level: X-Spam-Status: No, score=-102.391 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xrwqb4sNa0go; Mon, 18 Jun 2012 09:18:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1477221F86CB; Mon, 18 Jun 2012 09:18:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.20 Message-ID: <20120618161803.11671.64167.idtracker@ietfa.amsl.com> Date: Mon, 18 Jun 2012 09:18:03 -0700 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-rfd-usable-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2012 16:18:03 -0000 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 : Making Route Flap Damping Usable Author(s) : Cristel Pelsser Randy Bush Keyur Patel Pradosh Mohapatra Loughborough University Filename : draft-ietf-idr-rfd-usable-00.txt Pages : 9 Date : 2012-06-18 Abstract: Route Flap Damping (RFD) was first proposed to reduce BGP churn in routers. Unfortunately, RFD was found to severely penalize sites for being well-connected because topological richness amplifies the number of update messages exchanged. Many operators have turned RFD off. Based on experimental measurement, this document recommends adjusting a few RFD algorithmic constants and limits, to reduce the high risks with RFD, with the result being damping a non-trivial amount of long term churn without penalizing well-behaved prefixes' normal convergence process. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-rfd-usable There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-rfd-usable-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Faisal.Hashmi@alcatel-lucent.com Mon Jun 18 09:25:31 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62A3921F86FA for ; Mon, 18 Jun 2012 09:25:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.598 X-Spam-Level: X-Spam-Status: No, score=-7.598 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FiR-820AV1Wk for ; Mon, 18 Jun 2012 09:25:30 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 4D1C521F873E for ; Mon, 18 Jun 2012 09:25:30 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id q5IGPMoL025965 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 18 Jun 2012 11:25:27 -0500 (CDT) Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q5IGPMYe004010 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 18 Jun 2012 11:25:22 -0500 Received: from USNAVSXCHMBSC3.ndc.alcatel-lucent.com ([135.3.39.144]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Mon, 18 Jun 2012 11:25:22 -0500 From: "Hashmi, Faisal (Faisal)" To: "'idr@ietf.org'" Date: Mon, 18 Jun 2012 11:24:34 -0500 Thread-Topic: draft-uttaro-idr-bgp-persistence-01 Thread-Index: Ac1Nbtis5YKjVxdZTOqd5RXxohYeww== Message-ID: <8E9515536A871047BDE6B631B17A425E02B8F75764@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_8E9515536A871047BDE6B631B17A425E02B8F75764USNAVSXCHMBSC_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 X-Mailman-Approved-At: Mon, 18 Jun 2012 09:28:37 -0700 Subject: [Idr] draft-uttaro-idr-bgp-persistence-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2012 16:25:31 -0000 --_000_8E9515536A871047BDE6B631B17A425E02B8F75764USNAVSXCHMBSC_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document I support this draft. Thanks Faisal Hashmi Senior Systems Engineer Alcatel-Lucent 832 520 4052 CCIE Service Provider. CCIE#19248 Project Management Professional (PMP) --_000_8E9515536A871047BDE6B631B17A425E02B8F75764USNAVSXCHMBSC_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
[Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document
 
I support this draft.
 
 
Thanks
 
Faisal Hashmi
Senior Systems Engineer
Alcatel-Lucent
832 520 4052
CCIE Service Provider. CCIE#19248
Project Management Professional (PMP)
 
 --_000_8E9515536A871047BDE6B631B17A425E02B8F75764USNAVSXCHMBSC_-- From saku@ytti.fi Mon Jun 18 10:47:31 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50E4A21F86C7 for ; Mon, 18 Jun 2012 10:47:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nNuCqlt4g+ao for ; Mon, 18 Jun 2012 10:47:30 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4D05221F84A0 for ; Mon, 18 Jun 2012 10:47:30 -0700 (PDT) Received: by ggnc4 with SMTP id c4so4319442ggn.31 for ; Mon, 18 Jun 2012 10:47:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding:x-gm-message-state; bh=qBxPj+KnMYqg7kixJZLOUFonTyXlz296UPo6+Mz7EzA=; b=NnvvX35RbPxniC2xkbrc2h8kg7KWgVBXjyE1dcn+i8uDc2rqN/4Vd5MZFAolfQR8J2 97OvIUGEcQy9NoSkTex12D9KXBmnVUPTjg71Jk9AiQ2v08W5dWtp6sydA4rUtzczabqf eLw2mc2g2BWC90JFiwl6tTQrAfz0lCy5/jl+p5jUlHsfaHo02MQa8FLdlwLWRF5vdnlR aiDlXpsNVoxfByxl9yHh74+XJvZDDmbD2cYhtf4nRT7nG/DB4iWl2uVdCMBpjIkepeKB qYlcLtjh1tvgGLVxC97Lsp8sSqxj4Ocs3TPUEUTOMPOm152cNytGt2pg6sVjh7qw7lde kyRw== MIME-Version: 1.0 Received: by 10.50.161.198 with SMTP id xu6mr4867255igb.40.1340041649354; Mon, 18 Jun 2012 10:47:29 -0700 (PDT) Received: by 10.64.14.136 with HTTP; Mon, 18 Jun 2012 10:47:29 -0700 (PDT) In-Reply-To: <20120618161803.11671.64167.idtracker@ietfa.amsl.com> References: <20120618161803.11671.64167.idtracker@ietfa.amsl.com> Date: Mon, 18 Jun 2012 20:47:29 +0300 Message-ID: From: Saku Ytti To: idr@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmR6fNv8YzZahjEPHK15FOwDE8fYuNIChI+rzC1i/qcC9K0gIB8DNf7k2yZre1zG/hFh3/I Subject: Re: [Idr] I-D Action: draft-ietf-idr-rfd-usable-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2012 17:47:31 -0000 I would love to see optional local-pref based penalty instead of suppressio= n. As an operator I'm less concerned of RE usage than I am pulling connectivity when competitor still offers connectivity. But when there are multiple options, penalizing unstable route would be nice. On 18 June 2012 19:18, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > =C2=A0This draft is a work item of the Inter-Domain Routing Working Group= of the IETF. > > =C2=A0 =C2=A0 =C2=A0 =C2=A0Title =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Mak= ing Route Flap Damping Usable > =C2=A0 =C2=A0 =C2=A0 =C2=A0Author(s) =C2=A0 =C2=A0 =C2=A0 : Cristel Pelss= er > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0Randy Bush > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0Keyur Patel > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0Pradosh Mohapatra > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0Loughborough University > =C2=A0 =C2=A0 =C2=A0 =C2=A0Filename =C2=A0 =C2=A0 =C2=A0 =C2=A0: draft-ie= tf-idr-rfd-usable-00.txt > =C2=A0 =C2=A0 =C2=A0 =C2=A0Pages =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 9 > =C2=A0 =C2=A0 =C2=A0 =C2=A0Date =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= : 2012-06-18 > > Abstract: > =C2=A0 Route Flap Damping (RFD) was first proposed to reduce BGP churn in > =C2=A0 routers. =C2=A0Unfortunately, RFD was found to severely penalize s= ites for > =C2=A0 being well-connected because topological richness amplifies the > =C2=A0 number of update messages exchanged. =C2=A0Many operators have tur= ned RFD > =C2=A0 off. =C2=A0Based on experimental measurement, this document recomm= ends > =C2=A0 adjusting a few RFD algorithmic constants and limits, to reduce th= e > =C2=A0 high risks with RFD, with the result being damping a non-trivial > =C2=A0 amount of long term churn without penalizing well-behaved prefixes= ' > =C2=A0 normal convergence process. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-idr-rfd-usable > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-idr-rfd-usable-00 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --=20 =C2=A0 ++ytti From wim.henderickx@alcatel-lucent.com Mon Jun 18 11:15:35 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F80721F86DD for ; Mon, 18 Jun 2012 11:15:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.248 X-Spam-Level: X-Spam-Status: No, score=-10.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tsw5UHtYJh7w for ; Mon, 18 Jun 2012 11:15:33 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 7A02B21F86D5 for ; Mon, 18 Jun 2012 11:15:33 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q5IIF5CI030537 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 18 Jun 2012 20:15:27 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.43]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Mon, 18 Jun 2012 20:15:08 +0200 From: "Henderickx, Wim (Wim)" To: Paul Unbehagen , "Fragassi, Roberto (Roberto)" Date: Mon, 18 Jun 2012 20:15:07 +0200 Thread-Topic: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks Thread-Index: Ac1NYCjamw4/mxMIT1O4r5aHaehmcAAHh7Jg Message-ID: <14C7F4F06DB5814AB0DE29716C4F6D6702DF7129F6@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> References: <003c01cd4b29$97d7b150$c78713f0$@ndzh.com> <73F3CA62A57C6148B6ECEB8DB8E40A290B97818F2F@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> In-Reply-To: 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: multipart/alternative; boundary="_000_14C7F4F06DB5814AB0DE29716C4F6D6702DF7129F6FRMRSSXCHMBSB_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Cc: "idr@ietf.org" , Susan Hares , "'John G. Scudder'" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2012 18:15:35 -0000 --_000_14C7F4F06DB5814AB0DE29716C4F6D6702DF7129F6FRMRSSXCHMBSB_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Paul = Unbehagen Sent: maandag 18 juni 2012 16:39 To: Fragassi, Roberto (Roberto) Cc: idr@ietf.org; 'John G. Scudder'; Susan Hares Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document -= 3 more weeks +1 -- Paul On Jun 18, 2012, at 6:49 AM, Fragassi, Roberto (Roberto) wrote: +1 Support. With the continued growth of spoke topologies in mobility backhaul, the con= tinued work on this draft as WG has its value for dealing with catastrophic= failures. From: idr-bounces@ietf.org [mailto:idr-bounces= @ietf.org] On Behalf Of Susan Hares Sent: Friday, June 15, 2012 3:04 PM To: idr@ietf.org Cc: 'John G. Scudder' Subject: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 m= ore weeks IDR WG and BGPers: While there is a strong debate on draft-uttaro-idr-bgp-persistence-01 as ID= R WG document, I do not see a clear consensus. We also did not get an over= whelming number of you to hum either way (11 total). Since some of those who voted "no" have suggested alternate text to the aut= hor, I would like to extend the time to consider this draft for 3 more week= s. To accept the draft we need a few more of you to "hum" yes or "hum" no. Sue Hares _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr --_000_14C7F4F06DB5814AB0DE29716C4F6D6702DF7129F6FRMRSSXCHMBSB_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1

 <= /o:p>

From: idr-bounces@ietf.o= rg [mailto:idr-bounces@ietf.org] On Behalf Of Paul Unbehagen
S= ent: maandag 18 juni 2012 16:39
To: Fragassi, Roberto (Robert= o)
Cc: idr@ietf.org; 'John G. Scudder'; Susan Hares
Subject= : Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 = more weeks

 = ;

+1

=  

 

<= div>

--

Paul

 

=  

 

<= p class=3DMsoNormal>On Jun 18, 2012, at 6:49 AM, Fragassi, Roberto (Roberto= ) wrote:



+1 Support.

=

 

With the continued growth of spoke topologies in m= obility backhaul, the continued work on this draft as WG has its value for = dealing with catastrophic failures.

 

From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Friday, June 15, 2012 3:04 PM
To: i= dr@ietf.org
Cc: 'John G. Scudder'
Subject:=  [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document -= 3 more weeks

&nb= sp;

IDR WG and BGPers:

 

While the= re is a strong debate on draft-uttaro-idr-bgp-persistence-01 as IDR WG docu= ment, I do not see a clear consensus.  We also did not get an overwhel= ming number of you to hum either way (11 total).

 

Since some of those = who voted “no” have suggested alternate text to the author, I w= ould like to extend the time to consider this draft for 3 more weeks.<= /o:p>

 

To accept the draft we need a few more of you to “hum” yes or = “hum” no.

=  

Sue Hares

=  

 

_______________________________________________
Idr m= ailing list
Idr@ietf.org
https://= www.ietf.org/mailman/listinfo/idr

 

= --_000_14C7F4F06DB5814AB0DE29716C4F6D6702DF7129F6FRMRSSXCHMBSB_-- From ss2539@att.com Mon Jun 18 10:04:00 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14C1021F86F3 for ; Mon, 18 Jun 2012 10:04:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S8j+WQzgNatJ for ; Mon, 18 Jun 2012 10:03:59 -0700 (PDT) Received: from nbfkord-smmo04.seg.att.com (nbfkord-smmo04.seg.att.com [209.65.160.86]) by ietfa.amsl.com (Postfix) with ESMTP id 3F37021F86EA for ; Mon, 18 Jun 2012 10:03:59 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo04.seg.att.com(mxl_mta-6.11.0-10) over TLS secured channel with ESMTP id e7f5fdf4.0.233339.00-418.627676.nbfkord-smmo04.seg.att.com (envelope-from ); Mon, 18 Jun 2012 17:03:59 +0000 (UTC) X-MXL-Hash: 4fdf5f7f173d7f6d-ee209f7625a83cde9ece0e8ab7cd2148b0b35992 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q5IH3wEb006223 for ; Mon, 18 Jun 2012 13:03:58 -0400 Received: from sflint01.pst.cso.att.com (sflint01.pst.cso.att.com [144.154.234.228]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q5IH3nPx006167 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 18 Jun 2012 13:03:50 -0400 Received: from MISOUT7MSGHUB9C.ITServices.sbc.com (misout7msghub9c.itservices.sbc.com [144.151.223.82]) by sflint01.pst.cso.att.com (RSA Interceptor) for ; Mon, 18 Jun 2012 13:03:38 -0400 Received: from MISOUT7MSGUSR9N.ITServices.sbc.com ([144.151.223.65]) by MISOUT7MSGHUB9C.ITServices.sbc.com ([144.151.223.82]) with mapi id 14.01.0355.002; Mon, 18 Jun 2012 13:03:38 -0400 From: "SAAD, SAMIR S" To: "'idr@ietf.org'" Thread-Topic: [Idr] draft-uttaro-idr-bgp-persistence-01 Thread-Index: Ac1NdEx7mt9FHkJeQeKGJnTBB63iqg== Date: Mon, 18 Jun 2012 17:03:37 +0000 Message-ID: <438B11A5EC21D347A63ACB77E58C78BA1519F0@MISOUT7MSGUSR9N.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.16.32.55] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=1.0 c=1 a=ll1CIi-hfRQA:10 a=vy2uH0WJBaMA:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=ZRNLZ4dFUbCvG8] X-AnalysisOut: [UMqPvVAA==:17 a=2YCzzi453IZrIstbR6QA:9 a=CjuIK1q_8ugA:10] X-Mailman-Approved-At: Mon, 18 Jun 2012 12:07:50 -0700 Subject: [Idr] draft-uttaro-idr-bgp-persistence-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2012 17:04:00 -0000 [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document Support Samir Saad AT&T Labs From marco@juniper.net Mon Jun 18 12:13:30 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56E0021F86DE for ; Mon, 18 Jun 2012 12:13:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rRo+TUqyIix4 for ; Mon, 18 Jun 2012 12:13:29 -0700 (PDT) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by ietfa.amsl.com (Postfix) with ESMTP id EB93121F86D7 for ; Mon, 18 Jun 2012 12:13:28 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKT9991hhBJbTrPd/Nvnk8lPFxzUvcS7M4@postini.com; Mon, 18 Jun 2012 12:13:29 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 18 Jun 2012 12:12:10 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Mon, 18 Jun 2012 15:12:09 -0400 From: Marco Rodrigues To: Susan Hares , "idr@ietf.org" Date: Mon, 18 Jun 2012 15:12:07 -0400 Thread-Topic: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks Thread-Index: Ac1NhkHdulvowFyOSPyH132xcEdOzw== Message-ID: In-Reply-To: <003c01cd4b29$97d7b150$c78713f0$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.2.120421 acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "'John G. Scudder'" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2012 19:13:30 -0000 Support. Marco. From: Susan Hares > To: "idr@ietf.org" > Cc: "'John G. Scudder'" > Subject: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 m= ore weeks IDR WG and BGPers: While there is a strong debate on draft-uttaro-idr-bgp-persistence-01 as ID= R WG document, I do not see a clear consensus. We also did not get an over= whelming number of you to hum either way (11 total). Since some of those who voted =93no=94 have suggested alternate text to the= author, I would like to extend the time to consider this draft for 3 more = weeks. To accept the draft we need a few more of you to =93hum=94 yes or =93hum=94= no. Sue Hares From jgs@juniper.net Mon Jun 18 12:50:03 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2694421F86B5; Mon, 18 Jun 2012 12:50:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GynpaRxeWU+i; Mon, 18 Jun 2012 12:50:02 -0700 (PDT) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by ietfa.amsl.com (Postfix) with ESMTP id 00CE021F8647; Mon, 18 Jun 2012 12:50:00 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKT9+GaAfY33K6P2L16if+OZSyJjV695ut@postini.com; Mon, 18 Jun 2012 12:50:01 PDT Received: from [172.16.13.202] (172.16.13.202) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server id 8.3.213.0; Mon, 18 Jun 2012 12:48:47 -0700 MIME-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset="us-ascii" From: "John G. Scudder" In-Reply-To: Date: Mon, 18 Jun 2012 15:48:46 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20120617204451.26844.76025.idtracker@ietfa.amsl.com> To: "UTTARO, JAMES" X-Mailer: Apple Mail (2.1278) Cc: "idr@ietf.org" , "'internet-drafts@ietf.org'" , "i-d-announce@ietf.org" Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2012 19:50:03 -0000 Hi Jim, On Jun 17, 2012, at 8:29 PM, UTTARO, JAMES wrote: > I took a read on this ( I will read more thoroughly) but one section = jumped out at me. "Operational Considerations". >=20 >=20 > Although the "treat-as-withdraw" error-handling behavior defined in > Section 2 makes every effort to preserve BGP's correctness, we note > that if an UPDATE received on an IBGP session is subjected to this > treatment, inconsistent routing within the affected Autonomous = System > may result. The consequences of inconsistent routing can include > long-lived forwarding loops and black holes. While lamentable, this > issue is expected to be rare in practice, and more importantly is > seen as less problematic than the session-reset behavior it = replaces. >=20 > " When a malformed attribute is indeed detected over an IBGP = session, > we RECOMMEND that routes with the malformed attribute be identified > and traced back to the ingress router in the network where the = routes > were sourced or received externally, and then a filter be applied on > the ingress router to prevent the routes from being sourced or > received. This will help maintain routing consistency in the > network." >=20 >=20 > I don't think the terminology "lamentable" to describe Long lived = forwarding loops and black holes is appropriate as it would probably be = more than regrettable. My dictionary says "(of circumstances or conditions) deplorably bad or = unsatisfactory" which seems about right to me. We could have said "it = really sucks a lot" but the style seems wrong. :-) But this sentence = could be rewritten as needed, it's not a big deal. > Could you expand on the conditions One very simple case: A--B--C--D The four routers depicted form an IBGP full mesh (sessions not shown). = The links shown are the physical topology. Standard IP forwarding is = used. Routers A and D are ASBRs and both advertise a path for prefix X = into IBGP. Router C prefers the path from A, for example due to a = shorter AS Path. However, router B decides that the path from A is = malformed, so it selects the path from D. Now we have C's next hop to = reach X as B, and B's next hop to reach X as C. This is a stable = forwarding loop. (Why do B and C have different conclusions about = whether the update is malformed? Different code bases with different = assumptions, as we have seen more than once in the field.) > and how BGP would eventually recover. It wouldn't :-( without operator intervention.=20 > That would be a good addition. I am a bit confused, how does this type = of error handling which restarts GR ( As of my last read ) and which BGP = persistence lives through change the paradigm of these solutions? I don't understand this question. > There is a notion of treat as withdraw for some attrs, but don't tear = down session?? Yes. You're right to find this shocking. I find it shocking, but have = been browbeaten :-)/2 into agreeing that the cure may be a little less = bad than the disease. However, the floor is still definitely open for = debate! > How many malformed updates before the session is torn down? Ever?=20 This was discussed a while ago, inconclusively. To date, I don't recall = having seen any suggestions I really liked for how to decide a session = should be torn down. It actually seems to make things more complicated = (to implement, to debug in operation) to have two error-handling modes = you flip between according to some heuristic. The floor is still open = for more discussion. > According to the next paragraph ( See below ) there is an expectation = that the offending ingress router should be identified, and then a = filter should be applied for those paths in a given updated with the = malformed attrs :) What is the recommendation for doing this? The router should log (and possibly trap, alarm, etc) the offending = update(s). The operator should examine the logs and by so doing, figure = it out from there. Sorry this seems glib but that's what it comes down = to. Remember that the alternate (present-day) scenario is that the BGP = session to the affected router is going to flap, which is likely even = worse operationally, possibly much worse. > Will there be a draft whereby the detecting router somehow figures out = the offending ingress router, builds routing policy and then sends it = there to dynamically create the filter. I sincerely hope not and have spoken against this idea in the past. > This seems non-trivial, That's why. When you start building machinery to automatically patch = around bugs in your primary routing machinery, IMO you have officially = Jumped The Shark and started building a Rube Goldberg router. > I guess Flowspec like technology may be used not sure.. Is the ingress = router assumed to be in the same AS domain as the detecting router? Since the paragraph is talking about IBGP, yes. Of course this doesn't = mean the offending update was sourced within the same AS, but the = paragraph you're picking on is just talking about what happens within = IBGP. Note that draft-ietf-grow-ops-reqs-for-bgp-error-handling-04.txt is very = applicable to this discussion and is currently in WGLC in GROW. Since = you have opinions about this topic I strongly suggest you review it and = comment on the GROW WGLC. It runs until June 25. --John > Administrative domain may span multiple AS domains.. >=20 > Jim Uttaro >=20 >=20 >=20 >=20 > -----Original Message----- > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of = internet-drafts@ietf.org > Sent: Sunday, June 17, 2012 4:45 PM > To: i-d-announce@ietf.org > Cc: idr@ietf.org > Subject: [Idr] I-D Action: draft-ietf-idr-error-handling-02.txt >=20 >=20 > 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. >=20 > Title : Revised Error Handling for BGP UPDATE Messages > Author(s) : John G. Scudder > Enke Chen > Pradosh Mohapatra > Keyur Patel > Filename : draft-ietf-idr-error-handling-02.txt > Pages : 10 > Date : 2012-06-17 >=20 > Abstract: > According to the base BGP specification, a BGP speaker that receives > an UPDATE message containing a malformed attribute is required to > reset the session over which the offending attribute was received. > This behavior is undesirable as a session reset would impact not = only > routes with the offending attribute, but also other valid routes > exchanged over the session. This document partially revises the > error handling for UPDATE messages, and provides guidelines for the > authors of documents defining new attributes. Finally, it revises > the error handling procedures for several existing attributes. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-idr-error-handling >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-idr-error-handling-02 >=20 > A diff from previous version is available at: > http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-error-handling-02 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > 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 From jakob.heitz@ericsson.com Mon Jun 18 13:08:31 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C375111E8088; Mon, 18 Jun 2012 13:08:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.289 X-Spam-Level: X-Spam-Status: No, score=-6.289 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N2xdn+mHcSux; Mon, 18 Jun 2012 13:08:31 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 3EE7811E8086; Mon, 18 Jun 2012 13:08:31 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q5IK8Grg027185; Mon, 18 Jun 2012 15:08:28 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.64]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Mon, 18 Jun 2012 16:08:21 -0400 From: Jakob Heitz To: "John G. Scudder" , "UTTARO, JAMES" Date: Mon, 18 Jun 2012 16:08:19 -0400 Thread-Topic: [Idr] I-D Action: draft-ietf-idr-error-handling-02.txt Thread-Index: Ac1Ni5a4Z1lh+3iKSYu+BX+HzHjbFAAAgzaA Message-ID: <7309FCBCAE981B43ABBE69B31C8D213921C2294904@EUSAACMS0701.eamcs.ericsson.se> References: <20120617204451.26844.76025.idtracker@ietfa.amsl.com> 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 Cc: "idr@ietf.org" , "'internet-drafts@ietf.org'" , "i-d-announce@ietf.org" Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2012 20:08:32 -0000 On Monday, June 18, 2012 12:49 PM, John G. Scudder <> wrote: > A--B--C--D >=20 > The four routers depicted form an IBGP full mesh (sessions not > shown). The links shown are the physical topology. Standard IP > forwarding is used. Routers A and D are ASBRs and both advertise a > path for prefix X into IBGP. Router C prefers the path from A, for > example due to a shorter AS Path. However, router B decides that the > path from A is malformed, so it selects the path from D. Now we have > C's next hop to reach X as B, and B's next hop to reach X as C. This > is a stable forwarding loop. (Why do B and C have different > conclusions about whether the update is malformed? Different code > bases with different assumptions, as we have seen more than once in > the field.) =20 The draft is not changing the way that a "malformed" decision is made. It is changing the resulting action: reset session or drop route. Either way, your problem occurs. --=20 Jakob Heitz.= From jgs@juniper.net Mon Jun 18 13:20:53 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8835C11E80A3 for ; Mon, 18 Jun 2012 13:20:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MeqnyAsfrDzq for ; Mon, 18 Jun 2012 13:20:53 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id 20FEE11E809C for ; Mon, 18 Jun 2012 13:20:50 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKT9+NoeiTZrbVMuFQyQxPqqafVLAK1V7n@postini.com; Mon, 18 Jun 2012 13:20:52 PDT Received: from [172.16.13.202] (172.16.13.202) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server id 8.3.213.0; Mon, 18 Jun 2012 13:19:14 -0700 MIME-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset="us-ascii" From: "John G. Scudder" In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D213921C2294904@EUSAACMS0701.eamcs.ericsson.se> Date: Mon, 18 Jun 2012 16:19:13 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20120617204451.26844.76025.idtracker@ietfa.amsl.com> <7309FCBCAE981B43ABBE69B31C8D213921C2294904@EUSAACMS0701.eamcs.ericsson.se> To: Jakob Heitz X-Mailer: Apple Mail (2.1278) Cc: "idr@ietf.org wg" , JAMES UTTARO Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2012 20:20:53 -0000 [Trimmed i-d-announce and internet-drafts from cc list] On Jun 18, 2012, at 4:08 PM, Jakob Heitz wrote: > The draft is not changing the way that a "malformed" decision is > made. It is changing the resulting action: reset session or drop = route. >=20 > Either way, your problem occurs. Yes, exactly. The difference is in the consequences, and likelihood of = detection. The consequences of the session flap are likely more dire, = but it's a sure bet that the operator will notice. The consequences of = the forwarding loop may be bad but possibly still remain below the = radar. It's our responsibility to make sure the operator is able to = notice what's going on even without having sessions bounce like a ball. --John= From ju1738@att.com Mon Jun 18 14:13:25 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12DEB11E80C5; Mon, 18 Jun 2012 14:13:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.294 X-Spam-Level: X-Spam-Status: No, score=-106.294 tagged_above=-999 required=5 tests=[AWL=0.305, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AZDU16thsWgl; Mon, 18 Jun 2012 14:13:23 -0700 (PDT) Received: from nbfkord-smmo04.seg.att.com (nbfkord-smmo04.seg.att.com [209.65.160.86]) by ietfa.amsl.com (Postfix) with ESMTP id 761F711E80B5; Mon, 18 Jun 2012 14:13:23 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo04.seg.att.com(mxl_mta-6.11.0-10) over TLS secured channel with ESMTP id 3f99fdf4.0.320013.00-392.875207.nbfkord-smmo04.seg.att.com (envelope-from ); Mon, 18 Jun 2012 21:13:23 +0000 (UTC) X-MXL-Hash: 4fdf99f3310cc25c-1b98e94bd0ab0dfc2f66184febfc869637f78e93 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q5ILDMXm010677; Mon, 18 Jun 2012 17:13:22 -0400 Received: from sflint01.pst.cso.att.com (sflint01.pst.cso.att.com [144.154.234.228]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q5ILDGZB010631 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 18 Jun 2012 17:13:16 -0400 Received: from MISOUT7MSGHUB9D.ITServices.sbc.com (misout7msghub9d.itservices.sbc.com [144.151.223.93]) by sflint01.pst.cso.att.com (RSA Interceptor); Mon, 18 Jun 2012 17:13:05 -0400 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9D.ITServices.sbc.com ([144.151.223.93]) with mapi id 14.01.0355.002; Mon, 18 Jun 2012 17:13:04 -0400 From: "UTTARO, JAMES" To: "John G. Scudder" Thread-Topic: [Idr] I-D Action: draft-ietf-idr-error-handling-02.txt Thread-Index: AQHNTMoO3AC4WgUFwEeXslewDoqMZpb/MenAgAGOTwD//8NEcA== Date: Mon, 18 Jun 2012 21:13:04 +0000 Message-ID: References: <20120617204451.26844.76025.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.223.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=1.0 c=1 a=4aSm168Vv4sA:10 a=Crak0S_X7RUA:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=ZRNLZ4dFUbCvG8] X-AnalysisOut: [UMqPvVAA==:17 a=OUXY8nFuAAAA:8 a=48vgC7mUAAAA:8 a=tOHKcZpG] X-AnalysisOut: [J1StUCbpQSMA:9 a=CjuIK1q_8ugA:10 a=peF9eE_zjQwA:10 a=lZB81] X-AnalysisOut: [5dzVvQA:10] Cc: "idr@ietf.org" , "'internet-drafts@ietf.org'" , "i-d-announce@ietf.org" Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2012 21:13:25 -0000 John, The notion of this draft is to change the actual behavior of the protocol = in terms of the resultant action due to a update error malformed attr.. Cur= rently the session is torn down.. Another behavior would be timer expiry, i= n that case the actual NH of the update is correct, but a timer expiry betw= een a RR and the egress PE also tears down the session. Should we change th= e specification to deal with a bug where a RR cannot maintain sessions? Are= there addl bugs in the protocol implementation that are being considered ? The BGP persistence draft and GR to a lesser extent as it does not surviv= e as many error conditions accepts the base specification but simply allows= paths to persist without changing the fundamental nature of the protocol..= Why do we need this solution also? If the egress PE used BGP Persistence o= r GR ( Assume modified to persist through mal-formed attr ), then the curre= nt specification continues unchanged, and valid paths persist.. Another observation is that the draft attempts to provide a finer level of = granularity in terms of specification for some errors. The resultant action= is no longer at a session but at a path level.=20 If one path has a mal-formed update I believe that all of the paths in that= update are treated as withdrawn . If so, then this fix discards possibly d= ifferent sets of good paths at different egress PEs? This may create incons= istent routing topologies as different "good paths" may be discarded based = on update packing at the ingress PE. So not an inconsistency for the path w= ith the mal-formed attr but possibly all the others packed in.. Comments In-Line.. Thanks, Jim Uttaro -----Original Message----- From: John G. Scudder [mailto:jgs@juniper.net]=20 Sent: Monday, June 18, 2012 3:49 PM To: UTTARO, JAMES Cc: 'internet-drafts@ietf.org'; i-d-announce@ietf.org; idr@ietf.org Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-02.txt Hi Jim, On Jun 17, 2012, at 8:29 PM, UTTARO, JAMES wrote: > I took a read on this ( I will read more thoroughly) but one section jump= ed out at me. "Operational Considerations". >=20 >=20 > Although the "treat-as-withdraw" error-handling behavior defined in > Section 2 makes every effort to preserve BGP's correctness, we note > that if an UPDATE received on an IBGP session is subjected to this > treatment, inconsistent routing within the affected Autonomous System > may result. The consequences of inconsistent routing can include > long-lived forwarding loops and black holes. While lamentable, this > issue is expected to be rare in practice, and more importantly is > seen as less problematic than the session-reset behavior it replaces. >=20 > " When a malformed attribute is indeed detected over an IBGP session, > we RECOMMEND that routes with the malformed attribute be identified > and traced back to the ingress router in the network where the routes > were sourced or received externally, and then a filter be applied on > the ingress router to prevent the routes from being sourced or > received. This will help maintain routing consistency in the > network." >=20 >=20 > I don't think the terminology "lamentable" to describe Long lived forward= ing loops and black holes is appropriate as it would probably be more than = regrettable. My dictionary says "(of circumstances or conditions) deplorably bad or unsa= tisfactory" which seems about right to me. We could have said "it really su= cks a lot" but the style seems wrong. :-) But this sentence could be rewrit= ten as needed, it's not a big deal. [Jim U>] Agreed it is bad/unsatisfactory. I guess I was addressing the prem= ise. > Could you expand on the conditions One very simple case: A--B--C--D The four routers depicted form an IBGP full mesh (sessions not shown). The = links shown are the physical topology. Standard IP forwarding is used. Rout= ers A and D are ASBRs and both advertise a path for prefix X into IBGP. Rou= ter C prefers the path from A, for example due to a shorter AS Path. Howeve= r, router B decides that the path from A is malformed, so it selects the pa= th from D. Now we have C's next hop to reach X as B, and B's next hop to re= ach X as C. This is a stable forwarding loop. (Why do B and C have differen= t conclusions about whether the update is malformed? Different code bases w= ith different assumptions, as we have seen more than once in the field.) [Jim U>] Ouch. We could get some big flows going back and forth in our topo= logy based upon the path in question... would this be trading forwarding lo= ops within a network for routing churn amongst networks and/or traffic re-d= irection.. It sort of feels that way to me.. > and how BGP would eventually recover. It wouldn't :-( without operator intervention.=20 [Jim U>] Ouch +1..=20 > That would be a good addition. I am a bit confused, how does this type of= error handling which restarts GR ( As of my last read ) and which BGP pers= istence lives through change the paradigm of these solutions? I don't understand this question. [Jim U>] Assume BGP current behavior.. The sessions would be torn down, BGP= Persist/GR ( Assume GR is modified to persist through a mal-formed attr ) = would become active.. In this model for a subset of failure modes the sessi= on would not be torn down. I guess the issue is that for different error co= nditions we see different solutions/behaviors.. If malformed then no sessio= n tear down, treat as withdrawn, If timer expiry than if GR tear session do= wn flush paths, BGP Persistence session tear down maintain paths. I am war = of the lack of consistency.. > There is a notion of treat as withdraw for some attrs, but don't tear dow= n session?? Yes. You're right to find this shocking. I find it shocking, but have been = browbeaten :-)/2 into agreeing that the cure may be a little less bad than = the disease. However, the floor is still definitely open for debate! [Jim U>] Ouch.. I don't like the notion of changing the fundamental nature = of the protocol..=20 > How many malformed updates before the session is torn down? Ever?=20 This was discussed a while ago, inconclusively. To date, I don't recall hav= ing seen any suggestions I really liked for how to decide a session should = be torn down. It actually seems to make things more complicated (to impleme= nt, to debug in operation) to have two error-handling modes you flip betwee= n according to some heuristic. The floor is still open for more discussion. [Jim U>] Maybe determine the exposure to inconsistency..=20 > According to the next paragraph ( See below ) there is an expectation tha= t the offending ingress router should be identified, and then a filter shou= ld be applied for those paths in a given updated with the malformed attrs := ) What is the recommendation for doing this? The router should log (and possibly trap, alarm, etc) the offending update(= s). The operator should examine the logs and by so doing, figure it out fro= m there. Sorry this seems glib but that's what it comes down to. Remember t= hat the alternate (present-day) scenario is that the BGP session to the aff= ected router is going to flap, which is likely even worse operationally, po= ssibly much worse. [Jim U>] If we could persist the state than the damage from the flap should= be mitigated.. Of course this is different based on application i.e intern= et, VPNV4, vPNV2 etc... We would need to think about how to automate this.. > Will there be a draft whereby the detecting router somehow figures out th= e offending ingress router, builds routing policy and then sends it there t= o dynamically create the filter. I sincerely hope not and have spoken against this idea in the past. [Jim U>] LOL > This seems non-trivial, That's why. When you start building machinery to automatically patch around= bugs in your primary routing machinery, IMO you have officially Jumped The= Shark and started building a Rube Goldberg router. [Jim U>] Yes. If there is a bug that should be fixed.. There are solution t= hat allow state to persist.. I would prefer this as opposed to modifying th= e specification to deal with this one type of bug? BTW Is it extensible to = other Update Message Errors??=20 > I guess Flowspec like technology may be used not sure.. Is the ingress ro= uter assumed to be in the same AS domain as the detecting router? Since the paragraph is talking about IBGP, yes. Of course this doesn't mean= the offending update was sourced within the same AS, but the paragraph you= 're picking on is just talking about what happens within IBGP. [Jim U>] Yup. Assuming same AS then like flowspec there may be a way but ag= ain it is patching a bug in the machinery..=20 Note that draft-ietf-grow-ops-reqs-for-bgp-error-handling-04.txt is very ap= plicable to this discussion and is currently in WGLC in GROW. Since you hav= e opinions about this topic I strongly suggest you review it and comment on= the GROW WGLC. It runs until June 25.[Jim U>] I will.. Thx... --John > Administrative domain may span multiple AS domains.. >=20 > Jim Uttaro >=20 >=20 >=20 >=20 > -----Original Message----- > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of int= ernet-drafts@ietf.org > Sent: Sunday, June 17, 2012 4:45 PM > To: i-d-announce@ietf.org > Cc: idr@ietf.org > Subject: [Idr] I-D Action: draft-ietf-idr-error-handling-02.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Inter-Domain Routing Working Group of th= e IETF. >=20 > Title : Revised Error Handling for BGP UPDATE Messages > Author(s) : John G. Scudder > Enke Chen > Pradosh Mohapatra > Keyur Patel > Filename : draft-ietf-idr-error-handling-02.txt > Pages : 10 > Date : 2012-06-17 >=20 > Abstract: > According to the base BGP specification, a BGP speaker that receives > an UPDATE message containing a malformed attribute is required to > reset the session over which the offending attribute was received. > This behavior is undesirable as a session reset would impact not only > routes with the offending attribute, but also other valid routes > exchanged over the session. This document partially revises the > error handling for UPDATE messages, and provides guidelines for the > authors of documents defining new attributes. Finally, it revises > the error handling procedures for several existing attributes. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-idr-error-handling >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-idr-error-handling-02 >=20 > A diff from previous version is available at: > http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-error-handling-02 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > 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 From ju1738@att.com Mon Jun 18 14:33:06 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 882C221F8634 for ; Mon, 18 Jun 2012 14:33:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.355 X-Spam-Level: X-Spam-Status: No, score=-106.355 tagged_above=-999 required=5 tests=[AWL=0.244, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TBOU7zdhsBpJ for ; Mon, 18 Jun 2012 14:33:05 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id 832DE21F85E1 for ; Mon, 18 Jun 2012 14:33:05 -0700 (PDT) Received: from unknown [144.160.128.153] (EHLO nbfkord-smmo05.seg.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.11.0-10) with ESMTP id 19e9fdf4.2aaaf9c55940.326969.00-593.894655.nbfkord-smmo05.seg.att.com (envelope-from ); Mon, 18 Jun 2012 21:33:05 +0000 (UTC) X-MXL-Hash: 4fdf9e914149ccdd-f737fbf247261e855309f956d9c9cf91dced93d8 Received: from unknown [144.160.128.153] (EHLO flpi408.enaf.ffdc.sbc.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.11.0-10) over TLS secured channel with ESMTP id b8e9fdf4.0.326958.00-367.894607.nbfkord-smmo05.seg.att.com (envelope-from ); Mon, 18 Jun 2012 21:33:01 +0000 (UTC) X-MXL-Hash: 4fdf9e8d3ab668e1-8785c6d6cfd072dcec8925d7d16caa27badff053 Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q5ILWwbp019404; Mon, 18 Jun 2012 14:32:59 -0700 Received: from fflint04.pst.cso.att.com (fflint04.pst.cso.att.com [150.234.39.64]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q5ILWhtG019141 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 18 Jun 2012 14:32:50 -0700 Received: from MISOUT7MSGHUB9F.ITServices.sbc.com (misout7msghub9f.itservices.sbc.com [144.151.223.71]) by fflint04.pst.cso.att.com (RSA Interceptor); Mon, 18 Jun 2012 14:32:30 -0700 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9F.ITServices.sbc.com ([144.151.223.71]) with mapi id 14.01.0355.002; Mon, 18 Jun 2012 17:32:30 -0400 From: "UTTARO, JAMES" To: Jakob Heitz , "John G. Scudder" Thread-Topic: [Idr] I-D Action: draft-ietf-idr-error-handling-02.txt Thread-Index: Ac1Ni5a43AC4WgUFwEeXslewDoqMZgAAgzaAAALDBDA= Date: Mon, 18 Jun 2012 21:32:29 +0000 Message-ID: References: <20120617204451.26844.76025.idtracker@ietfa.amsl.com> <7309FCBCAE981B43ABBE69B31C8D213921C2294904@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D213921C2294904@EUSAACMS0701.eamcs.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.223.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.128.153] X-AnalysisOut: [v=1.0 c=1 a=4aSm168Vv4sA:10 a=Crak0S_X7RUA:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=xwOvzTHDVLE4u4] X-AnalysisOut: [nGvK72ag==:17 a=0FD05c-RAAAA:8 a=48vgC7mUAAAA:8 a=ZWoa1I2J] X-AnalysisOut: [59YT2RHBS24A:9 a=CjuIK1q_8ugA:10 a=f7GxY0FH8QIA:10 a=lZB81] X-AnalysisOut: [5dzVvQA:10] Cc: "idr@ietf.org" Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2012 21:33:06 -0000 Jakob, I think it is a question of inflicted the least amount of damage. Actually= brings up an interest question.. Is this service specific, is the same tra= deoff work for internet and VPNV2 solutions? Jim Uttaro -----Original Message----- From: Jakob Heitz [mailto:jakob.heitz@ericsson.com]=20 Sent: Monday, June 18, 2012 4:08 PM To: John G. Scudder; UTTARO, JAMES Cc: idr@ietf.org; 'internet-drafts@ietf.org'; i-d-announce@ietf.org Subject: RE: [Idr] I-D Action: draft-ietf-idr-error-handling-02.txt On Monday, June 18, 2012 12:49 PM, John G. Scudder <> wrote: > A--B--C--D >=20 > The four routers depicted form an IBGP full mesh (sessions not > shown). The links shown are the physical topology. Standard IP > forwarding is used. Routers A and D are ASBRs and both advertise a > path for prefix X into IBGP. Router C prefers the path from A, for > example due to a shorter AS Path. However, router B decides that the > path from A is malformed, so it selects the path from D. Now we have > C's next hop to reach X as B, and B's next hop to reach X as C. This > is a stable forwarding loop. (Why do B and C have different > conclusions about whether the update is malformed? Different code > bases with different assumptions, as we have seen more than once in > the field.) =20 The draft is not changing the way that a "malformed" decision is made. It is changing the resulting action: reset session or drop route. Either way, your problem occurs. --=20 Jakob Heitz. From randy@psg.com Mon Jun 18 15:19:48 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE9AD11E80D9 for ; Mon, 18 Jun 2012 15:19:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mtqn4dOEFcKv for ; Mon, 18 Jun 2012 15:19:48 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 35FF311E80C1 for ; Mon, 18 Jun 2012 15:19:48 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SgkIS-0003OP-2z; Mon, 18 Jun 2012 22:19:44 +0000 Date: Tue, 19 Jun 2012 07:19:42 +0900 Message-ID: From: Randy Bush To: "Henderickx, Wim (Wim)" In-Reply-To: <14C7F4F06DB5814AB0DE29716C4F6D6702DF7129F6@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> References: <003c01cd4b29$97d7b150$c78713f0$@ndzh.com> <73F3CA62A57C6148B6ECEB8DB8E40A290B97818F2F@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> <14C7F4F06DB5814AB0DE29716C4F6D6702DF7129F6@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: "idr@ietf.org" , "'John G. Scudder'" , Susan Hares Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2012 22:19:49 -0000 is there an *operator*, other than at&t, who will speak up for this? randy From shares@ndzh.com Mon Jun 18 15:23:01 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAFCF11E80CC for ; Mon, 18 Jun 2012 15:22:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BLKHXvuYbWkC for ; Mon, 18 Jun 2012 15:22:55 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [63.208.161.194]) by ietfa.amsl.com (Postfix) with ESMTP id 06A6011E8095 for ; Mon, 18 Jun 2012 15:22:54 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=166.249.98.250; Received: from SKH2012HPLT (unverified [166.249.98.250]) by hickoryhill-consulting.com (SurgeMail 5.2a) with ESMTP id 3395422-1945496 for multiple; Mon, 18 Jun 2012 18:22:43 -0400 From: "Susan Hares" To: "'Randy Bush'" , "'Henderickx, Wim \(Wim\)'" References: <003c01cd4b29$97d7b150$c78713f0$@ndzh.com> <73F3CA62A57C6148B6ECEB8DB8E40A290B97818F2F@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> <14C7F4F06DB5814AB0DE29716C4F6D6702DF7129F6@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> In-Reply-To: Date: Mon, 18 Jun 2012 18:22:39 -0400 Message-ID: <003501cd4da0$dfde8220$9f9b8660$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJZrw3uXkAWvJPZ1smjI5COtj8VlgGJKpwiAfSWYDMBLCmmigG0KM7DlbTye6A= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Cc: idr@ietf.org, "'John G. Scudder'" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2012 22:23:01 -0000 WG: I'd like to second Randy's question. If you are an operator that feels this is a good idea, please send me a note. Public notes are best. However, if you do not want to send a public note - please send a private note. Sue Co-chair -----Original Message----- From: Randy Bush [mailto:randy@psg.com] Sent: Monday, June 18, 2012 6:20 PM To: Henderickx, Wim (Wim) Cc: Paul Unbehagen; Fragassi, Roberto (Roberto); idr@ietf.org; Susan Hares; 'John G. Scudder' Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks is there an *operator*, other than at&t, who will speak up for this? randy From Donald.Smith@CenturyLink.com Mon Jun 18 15:45:46 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EFFA11E80BB for ; Mon, 18 Jun 2012 15:45:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FpRO9AGy4atu for ; Mon, 18 Jun 2012 15:45:45 -0700 (PDT) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by ietfa.amsl.com (Postfix) with ESMTP id 9CF2A11E80A0 for ; Mon, 18 Jun 2012 15:45:45 -0700 (PDT) Received: from lxomavmpc030.qintra.com (lxomavmpc030.qintra.com [151.117.207.30]) by sudnp799.qwest.com (8.14.4/8.14.4) with ESMTP id q5IMjd2l013733 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 18 Jun 2012 16:45:39 -0600 (MDT) Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 52D421E006A; Mon, 18 Jun 2012 17:45:34 -0500 (CDT) Received: from sudnp796.qintra.com (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id 202CA1E0061; Mon, 18 Jun 2012 17:45:34 -0500 (CDT) Received: from sudnp796.qintra.com (localhost [127.0.0.1]) by sudnp796.qintra.com (8.14.4/8.14.4) with ESMTP id q5IMjXZW008944; Mon, 18 Jun 2012 16:45:33 -0600 (MDT) Received: from qtdenexhtm22.AD.QINTRA.COM (qtdenexhtm22.ad.qintra.com [151.119.91.231]) by sudnp796.qintra.com (8.14.4/8.14.4) with ESMTP id q5IMjXBo008930 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Mon, 18 Jun 2012 16:45:33 -0600 (MDT) Received: from qtdenexmbm24.AD.QINTRA.COM ([151.119.91.226]) by qtdenexhtm22.AD.QINTRA.COM ([151.119.91.231]) with mapi; Mon, 18 Jun 2012 16:45:33 -0600 From: "Smith, Donald" To: Susan Hares , "'Randy Bush'" , "'Henderickx, Wim (Wim)'" Content-Class: urn:content-classes:message Date: Mon, 18 Jun 2012 16:45:52 -0600 Thread-Topic: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks Thread-Index: AQJZrw3uXkAWvJPZ1smjI5COtj8VlgGJKpwiAfSWYDMBLCmmigG0KM7DlbTye6CAAAE9E4AABcoy Message-ID: <3F6612E7-C9E5-4471-B993-88245C08E6A0@mimectl> References: <003c01cd4b29$97d7b150$c78713f0$@ndzh.com> <73F3CA62A57C6148B6ECEB8DB8E40A290B97818F2F@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> <14C7F4F06DB5814AB0DE29716C4F6D6702DF7129F6@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> , <003501cd4da0$dfde8220$9f9b8660$@ndzh.com> In-Reply-To: <003501cd4da0$dfde8220$9f9b8660$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-mimectl: Produced By Microsoft Exchange V8.3.105.0 Content-Type: multipart/alternative; boundary="_000_3F6612E7C9E54471B99388245C08E6A0mimectl_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "idr@ietf.org" , "'John G. Scudder'" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2012 22:45:46 -0000 --_000_3F6612E7C9E54471B99388245C08E6A0mimectl_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I work for Centurylink (Qwest, Embarq, Savvis are all part of CTL now) so I= qualify as an operator. I have implemented BGP Gracefull Restart in the past and am interested in t= his draft. But would like a little time to review. I have begun reviewing it but will = have to review it with the GR rfc and will probably take me a few reviews b= efore I can say one way or another if I support this beyond my support for = a slight extension. (coffee !=3D sleep) & (!coffee =3D=3D sleep) Donald.Smith@qwest.com ________________________________ From: idr-bounces@ietf.org [idr-bounces@ietf.org] On Behalf Of Susan Hares = [shares@ndzh.com] Sent: Monday, June 18, 2012 4:22 PM To: 'Randy Bush'; 'Henderickx, Wim (Wim)' Cc: idr@ietf.org; 'John G. Scudder' Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document -= 3 more weeks WG: I'd like to second Randy's question. If you are an operator that feels this is a good idea, please send me a note. Public notes are best. However, if you do not want to send a public note - please send a private note. Sue Co-chair -----Original Message----- From: Randy Bush [mailto:randy@psg.com] Sent: Monday, June 18, 2012 6:20 PM To: Henderickx, Wim (Wim) Cc: Paul Unbehagen; Fragassi, Roberto (Roberto); idr@ietf.org; Susan Hares; 'John G. Scudder' Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks is there an *operator*, other than at&t, who will speak up for this? randy _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr ________________________________ This communication is the property of CenturyLink and may contain confident= ial or privileged information. Unauthorized use of this communication is st= rictly 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. --_000_3F6612E7C9E54471B99388245C08E6A0mimectl_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I work = for Centurylink (Qwe= st, Embarq, Savvis are all part of CTL now) so I qu= alify as an operator.
I have implemented B= GP Gracefull Restart in the past and am inter= ested in this draft.
But would like a little t= ime to review. I have begun reviewing it but will have to review it with th= e GR rfc and will probably take me a few reviews before I can say one way or another if I support thi= s beyond my support for a slight extension.=
 
(coffee !=3D sleep) & (!coffee =3D=3D sleep)
 Donald.Sm= ith@qwest.com<= /div>
From: idr-bounces= @ietf.org [idr-bounces@ietf.org] On Behalf Of Susan Hares [shares@ndzh.com]=
Sent: Monday, June 18, 2012 4:22 PM
To: 'Randy Bush'; 'Henderickx, Wim (Wim)'
Cc: idr@ietf.org; 'John G. Scudder'
Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG doc= ument - 3 more weeks

WG: 

I'd like to second Randy's question. If you are an operator that feels this=
is a good idea, please send me a note.  Public notes are best.  H= owever, if
you do not want to send a public note - please send a private note.

Sue
Co-chair

-----Original Message-----
From: Randy Bush [mailto= :randy@psg.com]
Sent: Monday, June 18, 2012 6:20 PM
To: Henderickx, Wim (Wim)
Cc: Paul Unbehagen; Fragassi, Roberto (Roberto); idr@ietf.org; Susan Hares;=
'John G. Scudder'
Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document -=
3 more weeks

is there an *operator*, other than at&t, who will speak up for this?
randy

_______________________________________________
Idr mailing list
Idr@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/idr

This communication is the pr= operty of CenturyLink and may contain confidential or privileged informatio= n. 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<= br> all copies of the communication and any attachments.
 --_000_3F6612E7C9E54471B99388245C08E6A0mimectl_-- From warren@kumari.net Mon Jun 18 17:44:09 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F6E211E80CB for ; Mon, 18 Jun 2012 17:44:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.53 X-Spam-Level: X-Spam-Status: No, score=-105.53 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3I3rcj+ZaIYn for ; Mon, 18 Jun 2012 17:44:08 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id B8E7711E80C1 for ; Mon, 18 Jun 2012 17:44:08 -0700 (PDT) Received: from [5.5.8.10] (vpn.snozzages.com [204.194.22.7]) by vimes.kumari.net (Postfix) with ESMTPSA id D02821B402E5; Mon, 18 Jun 2012 20:44:04 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Warren Kumari In-Reply-To: <003c01cd4b29$97d7b150$c78713f0$@ndzh.com> Date: Mon, 18 Jun 2012 14:08:23 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0BB0F094-2ABE-4C34-B62A-44BB7234DA43@kumari.net> References: <003c01cd4b29$97d7b150$c78713f0$@ndzh.com> To: Susan Hares X-Mailer: Apple Mail (2.1278) Cc: idr@ietf.org, "'John G. Scudder'" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2012 00:44:09 -0000 On Jun 15, 2012, at 3:03 PM, Susan Hares wrote: > IDR WG and BGPers: > =20 > While there is a strong debate on draft-uttaro-idr-bgp-persistence-01 = as IDR WG document, I do not see a clear consensus. We also did not get = an overwhelming number of you to hum either way (11 total). > =20 > Since some of those who voted =93no=94 have suggested alternate text = to the author, I would like to extend the time to consider this draft = for 3 more weeks. > =20 > To accept the draft we need a few more of you to =93hum=94 yes or = =93hum=94 no. I have (re-)read and support adoption. This is a flavor of kink that I want no part of, but a number of folk = feel that this is a useful feature, and who am I to question what they = do in the privacy of their own network? W > =20 > Sue Hares > =20 > =20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr --=20 Outside of a dog, a book is your best friend, and inside of a dog, it's = too dark to read=20 From ju1738@att.com Mon Jun 18 18:09:42 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2D0C21F8704 for ; Mon, 18 Jun 2012 18:09:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.396 X-Spam-Level: X-Spam-Status: No, score=-106.396 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X4Vdb6ptxfhA for ; Mon, 18 Jun 2012 18:09:42 -0700 (PDT) Received: from nbfkord-smmo08.seg.att.com (nbfkord-smmo08.seg.att.com [209.65.160.95]) by ietfa.amsl.com (Postfix) with ESMTP id 302A521F8705 for ; Mon, 18 Jun 2012 18:09:41 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO nbfkord-smmo08.seg.att.com) by nbfkord-smmo08.seg.att.com(mxl_mta-6.11.0-10) with ESMTP id 651dfdf4.2aaafc459940.2236504.00-597.6134116.nbfkord-smmo08.seg.att.com (envelope-from ); Tue, 19 Jun 2012 01:09:42 +0000 (UTC) X-MXL-Hash: 4fdfd156046a57cb-bbbe8e1d53a7bfc8c260c604291a9d517f02b4ad Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo08.seg.att.com(mxl_mta-6.11.0-10) over TLS secured channel with ESMTP id a41dfdf4.0.2236491.00-493.6134074.nbfkord-smmo08.seg.att.com (envelope-from ); Tue, 19 Jun 2012 01:09:31 +0000 (UTC) X-MXL-Hash: 4fdfd14b656a0980-7900123e96976e80302a09ab76ed920088f84a34 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q5J19U98028804; Mon, 18 Jun 2012 21:09:30 -0400 Received: from sflint02.pst.cso.att.com (sflint02.pst.cso.att.com [144.154.234.229]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q5J19Rnp028772 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 18 Jun 2012 21:09:27 -0400 Received: from MISOUT7MSGHUB9D.ITServices.sbc.com (misout7msghub9d.itservices.sbc.com [144.151.223.93]) by sflint02.pst.cso.att.com (RSA Interceptor); Mon, 18 Jun 2012 21:09:12 -0400 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9D.ITServices.sbc.com ([144.151.223.93]) with mapi id 14.01.0355.002; Mon, 18 Jun 2012 21:09:11 -0400 From: "UTTARO, JAMES" To: "'Susan Hares'" , "'Randy Bush'" , "'Henderickx, Wim (Wim)'" Thread-Topic: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks Thread-Index: AQHNTaCCDFH/r8TZPECJQ+8yyUPCs5cA6YqA///p/MA= Date: Tue, 19 Jun 2012 01:09:11 +0000 Message-ID: References: <003c01cd4b29$97d7b150$c78713f0$@ndzh.com> <73F3CA62A57C6148B6ECEB8DB8E40A290B97818F2F@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> <14C7F4F06DB5814AB0DE29716C4F6D6702DF7129F6@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <003501cd4da0$dfde8220$9f9b8660$@ndzh.com> In-Reply-To: <003501cd4da0$dfde8220$9f9b8660$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.29.149] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=1.0 c=1 a=qpzVLOdVGoUA:10 a=8bAc-B_C_9sA:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=ZRNLZ4dFUbCvG8] X-AnalysisOut: [UMqPvVAA==:17 a=48vgC7mUAAAA:8 a=No5EcEP4AAAA:8 a=1Ub5gHSp] X-AnalysisOut: [VZsLiPR9d7UA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=PKgch] X-AnalysisOut: [sl1YdkA:10] Cc: "idr@ietf.org" , "'John G. Scudder'" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2012 01:09:43 -0000 How many operators are required? Take a look at the author list. Is there a= specific operator who is needed to validate that this document should be a= dopted? Jim Uttaro -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Susan= Hares Sent: Monday, June 18, 2012 6:23 PM To: 'Randy Bush'; 'Henderickx, Wim (Wim)' Cc: idr@ietf.org; 'John G. Scudder' Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document -= 3 more weeks WG: =20 I'd like to second Randy's question. If you are an operator that feels this is a good idea, please send me a note. Public notes are best. However, if you do not want to send a public note - please send a private note. Sue=20 Co-chair -----Original Message----- From: Randy Bush [mailto:randy@psg.com]=20 Sent: Monday, June 18, 2012 6:20 PM To: Henderickx, Wim (Wim) Cc: Paul Unbehagen; Fragassi, Roberto (Roberto); idr@ietf.org; Susan Hares; 'John G. Scudder' Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks is there an *operator*, other than at&t, who will speak up for this? randy _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From randy@psg.com Mon Jun 18 19:29:15 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8695221F85AD for ; Mon, 18 Jun 2012 19:29:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lIgkIYvU24mM for ; Mon, 18 Jun 2012 19:29:15 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 2E71921F85A4 for ; Mon, 18 Jun 2012 19:29:15 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SgoBp-0004U5-N8; Tue, 19 Jun 2012 02:29:09 +0000 Date: Tue, 19 Jun 2012 11:29:08 +0900 Message-ID: From: Randy Bush To: "UTTARO, JAMES" In-Reply-To: References: <003c01cd4b29$97d7b150$c78713f0$@ndzh.com> <73F3CA62A57C6148B6ECEB8DB8E40A290B97818F2F@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> <14C7F4F06DB5814AB0DE29716C4F6D6702DF7129F6@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <003501cd4da0$dfde8220$9f9b8660$@ndzh.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: "idr@ietf.org" , "'John G. Scudder'" , 'Susan Hares' Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2012 02:29:15 -0000 > How many operators are required? Take a look at the author list. Is > there a specific operator who is needed to validate that this document > should be adopted? 42 we can all see you have waved your dollars at the vendors. i seriously want to know if ops want to deploy this. essentially, this hack is to deal with a control plane failure when there is no corresponding data plane failure because the control plane and data plane are not congruent. the control plane failure is likely influenced by its complexity. i suspect that adding more complexity will not help a lot. randy From shane@castlepoint.net Mon Jun 18 22:34:24 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BEAA21F8649 for ; Mon, 18 Jun 2012 22:34:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pB2Z1a2U5Ba0 for ; Mon, 18 Jun 2012 22:34:23 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id 6770921F863C for ; Mon, 18 Jun 2012 22:34:23 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id EC435268063; Mon, 18 Jun 2012 23:34:22 -0600 (MDT) Received: from mbpw.castlepoint.net (174-29-213-45.hlrn.qwest.net [174.29.213.45]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Mon, 18 Jun 2012 23:34:22 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=174.29.213.45; client-port=59353; syn-fingerprint=65535:54:1:64:M1452,N,W1,N,N,T,S; data-bytes=0 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_56B05F72-9379-4526-8371-BE9468BCB171" From: Shane Amante In-Reply-To: <003c01cd4b29$97d7b150$c78713f0$@ndzh.com> Date: Mon, 18 Jun 2012 23:34:06 -0600 Message-Id: <985EF8D2-DA8A-4BE7-94D3-F4BE2B74D768@castlepoint.net> References: <003c01cd4b29$97d7b150$c78713f0$@ndzh.com> To: Susan Hares X-Mailer: Apple Mail (2.1278) Cc: idr@ietf.org, "'John G. Scudder'" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2012 05:34:24 -0000 --Apple-Mail=_56B05F72-9379-4526-8371-BE9468BCB171 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I would prefer not to see this adopted as a WG doc. At a high level, I = would rather see a more concentrated focus on implementations providing = much more detailed log messages, in particular along the lines of = "flight data recorder" type capabilities that would allow operators and = vendors to more rapidly isolate the root cause of the issue and then = take appropriate action, automatically or manually, to mitigate the = issue temporarily or even permanently. This would be of benefit for not = only L2VPN/L3VPN services, (as mentioned in the draft), but also = Internet and other applications that use BGP for signaling reachability = information. With respect to this particular draft, I have several concerns, but my = primary concern is with the following. If I'm reading this correctly, this draft states that the DO_NOT_PERSIST = community "SHOULD" be disabled by default, which means that (by default) = all routes will be set to "persist". Only through manual config on the = part of an SP, will a subset of routes be set to DO_NOT_PERSIST, i.e.: = obey the classic/current behavior of BGP, that is be withdrawn when the = session fails. This appears to be a fundamental change to BGP, which I = would not want to see deployed "by accident" because this suddenly = becomes the default behavior in implementations. Yes, it sucks, but I = would rather see routes withdrawn on session failure (like they are = today), rather than hang around until the network is "fixed". = Ultimately, problems of this nature are easy to quickly explain to = customer (so the Ops & Vendor folks can concentrate on determining root = cause and mitigating it), rather than how long it takes to sort through = and try to explain "routing anomalies" that are likely to incrementally = build-up the longer routes are held in a STALE state. Ultimately, I empathize with the co-authors that being in this situation = is not fun, nor a good day. (Been there, done that, got the T-shirts = ... happy to say I destroyed them afterward :-). Furthermore, although = it does cost money, which is not easy to come by, I believe that a = redundant architecture could be deployed in either the SP's network or = by the customer (i.e.: multi-home to two carriers) to largely mitigate = these concerns. Yes, this is not practical in all cases, but it's = certainly /possible/ and should be considered recommended before such = drastic changes are made to BGP. Just my own $0.02, -shane On Jun 15, 2012, at 1:03 PM, Susan Hares wrote: > IDR WG and BGPers: > =20 > While there is a strong debate on draft-uttaro-idr-bgp-persistence-01 = as IDR WG document, I do not see a clear consensus. We also did not get = an overwhelming number of you to hum either way (11 total). > =20 > Since some of those who voted =93no=94 have suggested alternate text = to the author, I would like to extend the time to consider this draft = for 3 more weeks. > =20 > To accept the draft we need a few more of you to =93hum=94 yes or = =93hum=94 no. > =20 > Sue Hares > =20 > =20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr --Apple-Mail=_56B05F72-9379-4526-8371-BE9468BCB171 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I = would prefer not to see this adopted as a WG doc.  At a high level, = I would rather see a more concentrated focus on implementations = providing much more detailed log messages, in particular along the lines = of "flight data recorder" type capabilities that would allow operators = and vendors to more rapidly isolate the root cause of the issue and then = take appropriate action, automatically or manually, to mitigate the = issue temporarily or even permanently.  This would be of benefit = for not only L2VPN/L3VPN services, (as mentioned in the draft), but also = Internet and other applications that use BGP for signaling reachability = information.

With respect to this particular draft, I = have several concerns, but my primary concern is with the = following.

If I'm reading this correctly, this = draft states that the DO_NOT_PERSIST community "SHOULD" be disabled by = default, which means that (by default) all routes will be set to = "persist".  Only through manual config on the part of an SP, will a = subset of routes be set to DO_NOT_PERSIST, i.e.: obey the = classic/current behavior of BGP, that is be withdrawn when the session = fails.  This appears to be a fundamental change to BGP, which I = would not want to see deployed "by accident" because this suddenly = becomes the default behavior in implementations.  Yes, it sucks, = but I would rather see routes withdrawn on session failure (like they = are today), rather than hang around until the network is "fixed". =  Ultimately, problems of this nature are easy to quickly explain to = customer (so the Ops & Vendor folks can concentrate on determining = root cause and mitigating it), rather than how long it takes to sort = through and try to explain "routing anomalies" that are likely to = incrementally build-up the longer routes are held in a STALE = state.

Ultimately, I empathize with the = co-authors that being in this situation is not fun, nor a good day. =  (Been there, done that, got the T-shirts ... happy to say I = destroyed them afterward :-).  Furthermore, although it does cost = money, which is not easy to come by, I believe that a redundant = architecture could be deployed in either the SP's network or by the = customer (i.e.: multi-home to two carriers) to largely mitigate these = concerns.  Yes, this is not practical in all cases, but it's = certainly /possible/ and should be considered recommended before such = drastic changes are made to BGP.

Just my own = $0.02,

-shane


=

On Jun 15, 2012, at = 1:03 PM, Susan Hares wrote:
IDR WG and = BGPers:
 
While there is a strong debate on = draft-uttaro-idr-bgp-persistence-01 as IDR WG document, I do not see a = clear consensus.  We also did not get an overwhelming number of you = to hum either way (11 total).
 
Since some of those who voted =93no=94= have suggested alternate text to the author, I would like to extend the = time to consider this draft for 3 more = weeks.
 
To accept the draft we need a few more of you to =93hum=94 yes = or =93hum=94 no.
 
Sue Hares
 
 
____________________________________= ___________
Idr mailing list
, "UTTARO, JAMES" Thread-Topic: [Idr] I-D Action: draft-ietf-idr-error-handling-02.txt Thread-Index: AQHNTYuS+FlUGhxMv0WDoPFSEi0nx5cBO7Cg Date: Tue, 19 Jun 2012 07:47:56 +0000 Message-ID: <16377_1340092076_4FE02EAC_16377_6476_1_53C29892C857584299CBF5D05346208A0920B5@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <20120617204451.26844.76025.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.3] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.6.19.61225 Cc: "idr@ietf.org" Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2012 07:47:59 -0000 Hi John, all, >From: John G. Scudder >Sent: Monday, June 18, 2012 9:49 PM [...] > >> Could you expand on the conditions > >One very simple case: > > A--B--C--D > >The four routers depicted form an IBGP full mesh (sessions not shown). The >links shown are the physical topology. Standard IP forwarding is used. Rou= ters >A and D are ASBRs and both advertise a path for prefix X into IBGP. Router= C >prefers the path from A, for example due to a shorter AS Path. However, ro= uter >B decides that the path from A is malformed, so it selects the path from D= . Now >we have C's next hop to reach X as B, and B's next hop to reach X as C. Th= is is >a stable forwarding loop. (Why do B and C have different conclusions about >whether the update is malformed? Different code bases with different >assumptions, as we have seen more than once in the field.) draft-ietf-idr-error-handling-02: "The consequences of inconsistent routing= can include long-lived forwarding loops and black holes." IMHO I would favor expanding a bit on this as this is an important point. E= .g. 1) adding your simple and very illustrative example in appendix. 2) discussing the applicability of such consequences. E.g. I feel that they= are different for AS/applications using tunnels between ASBR vs hop by hop= routing ones(*). Whether I'm right or wrong, IMHO a clarification is alway= s helpful. [...] "For any malformed attribute which is handled by the "attribute discard" instead of the "treat-as-withdraw" approach, it is critical to consider the potential impact of doing so." IMHO I would rather move that paragraph from the "4. Operational Considerat= ions" to "2. Revision to Base Specification" just below "A document which s= pecifies a new attribute MUST provide specifics regarding what constitutes an error for that attribute and how that erro= r is to be handled." (unless this choice is left to operators, which does n= ot seem to be the case) [...] >Yes. You're right to find this shocking. I find it shocking, but have been >browbeaten :-)/2 into agreeing that the cure may be a little less bad than= the >disease. However, the floor is still definitely open for debate! >[Jim U>] Ouch.. I don't like the notion of changing the fundamental nature= of >the protocol.. IMHO=20 - we should be cautious when changing the "fundamental nature of the protoc= ol" - but we should be able to question (, discuss and exchange arguments on) _= any_ aspects of the protocol. And on a side note, the notion of "fundamental nature of the protocol" is p= ersonal (not to say religious). E.g. the fundamental nature of BGP is Inter= net IDR. Using it for L3 VPN -not to mention L2 VPN :-) - is against nature. Regards, Bruno ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From randy@psg.com Tue Jun 19 01:14:17 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 644C521F86F4 for ; Tue, 19 Jun 2012 01:14:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4R3F0r4hyZ2X for ; Tue, 19 Jun 2012 01:14:13 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 1F14421F8555 for ; Tue, 19 Jun 2012 01:14:13 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SgtZh-0005AR-PF; Tue, 19 Jun 2012 08:14:10 +0000 Date: Tue, 19 Jun 2012 17:14:08 +0900 Message-ID: From: Randy Bush To: Saku Ytti In-Reply-To: References: <20120618161803.11671.64167.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: idr wg Subject: Re: [Idr] I-D Action: draft-ietf-idr-rfd-usable-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2012 08:14:17 -0000 > I would love to see optional local-pref based penalty instead of > suppression. > > As an operator I'm less concerned of RE usage than I am pulling > connectivity when competitor still offers connectivity. But when there > are multiple options, penalizing unstable route would be nice. what you are saying makes sense to my ops side. but, from the intro The goal is to, with absolutely minimal change, ... and the doc merely suggests a change in some constants. your suggestion would go considerably further. i am not strongly against it, more worried that it opening pandora's box. what do others think? randy From pauldotwall@gmail.com Tue Jun 19 01:50:45 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19D3621F85C2 for ; Tue, 19 Jun 2012 01:50:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qqWqZwpO-FgG for ; Tue, 19 Jun 2012 01:50:44 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7377921F859F for ; Tue, 19 Jun 2012 01:50:44 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so9823527obb.31 for ; Tue, 19 Jun 2012 01:50:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=iaNg+XO3/qH1KKu/Sp44LcIw5uokJESq2T0SZEEelFM=; b=rhQTubp1vGKj7rH8mn1Q66IpBuMaLI/SwPZtXfTxNHIfNDB6TYtoFNHg3C8yKki2Eq hyYdvajtcIZHJ5al8sOjvFOT4ipxbus6CTSdWvr+IvtziPEI7PTKT7bdHv8CTC0zkLH1 ASpYUUcxru9MykSgozzJyJPBx+/H48ZSqUALfSFh/ODCi5cElhjTQ5fmtj2AuN4R0tNC mFrgxt42F+b2ntG8/sEcW4sBoQLqFjRl5L4Ugv7MBEvNJ2j/Fd0PTbAjIP+59Cn6XSpv v/amDkLwi2gvCwWTa/ki1bh+VWjeVnG2SWTtknspj5vyGN28TC4KEry/S0c8a2u7Cttq EHFQ== MIME-Version: 1.0 Received: by 10.60.6.163 with SMTP id c3mr18387987oea.27.1340095844074; Tue, 19 Jun 2012 01:50:44 -0700 (PDT) Received: by 10.182.69.136 with HTTP; Tue, 19 Jun 2012 01:50:43 -0700 (PDT) In-Reply-To: References: <20120618161803.11671.64167.idtracker@ietfa.amsl.com> Date: Tue, 19 Jun 2012 01:50:43 -0700 Message-ID: From: Paul WALL To: Saku Ytti Content-Type: text/plain; charset=ISO-8859-1 Cc: idr@ietf.org Subject: Re: [Idr] I-D Action: draft-ietf-idr-rfd-usable-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2012 08:50:45 -0000 On 6/18/12, Saku Ytti wrote: > I would love to see optional local-pref based penalty instead of > suppression. +1 Drive Slow, Drive Low (the LP) Paul Wall From jgs@juniper.net Tue Jun 19 05:36:48 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB98D21F844E for ; Tue, 19 Jun 2012 05:36:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rneu3G4aegGd for ; Tue, 19 Jun 2012 05:36:48 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by ietfa.amsl.com (Postfix) with ESMTP id 3619521F8443 for ; Tue, 19 Jun 2012 05:36:46 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKT+ByXMlSowXWirGKEXjAv+PJz4Ufz0YG@postini.com; Tue, 19 Jun 2012 05:36:48 PDT Received: from [172.16.13.205] (172.16.13.205) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server id 8.3.213.0; Tue, 19 Jun 2012 05:36:34 -0700 MIME-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset="windows-1252" From: "John G. Scudder" In-Reply-To: <985EF8D2-DA8A-4BE7-94D3-F4BE2B74D768@castlepoint.net> Date: Tue, 19 Jun 2012 08:36:35 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <003c01cd4b29$97d7b150$c78713f0$@ndzh.com> <985EF8D2-DA8A-4BE7-94D3-F4BE2B74D768@castlepoint.net> To: Shane Amante X-Mailer: Apple Mail (2.1278) Cc: "idr@ietf.org" , Susan Hares Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2012 12:36:49 -0000 Shane, On Jun 19, 2012, at 1:34 AM, Shane Amante wrote: > If I'm reading this correctly, this draft states that the = DO_NOT_PERSIST community "SHOULD" be disabled by default, which means = that (by default) all routes will be set to "persist". I think this should be understood in the context of "... IF you have = enabled the feature in your network." [*] I.e., if you haven't chosen to = enable the feature, it would be business as usual, even if your peer = sent you the DO_NOT_PERSIST or STALE communities. Seems like the draft = should be revised (probably in S. 3) to make this more clear. I don't know if that changes your opinion any, but FWIW. --John [*] Not an actual quote from the draft.= From robert@raszuk.net Tue Jun 19 06:09:59 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CD3621F85C7 for ; Tue, 19 Jun 2012 06:09:59 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IJZDUfumWLGg for ; Tue, 19 Jun 2012 06:09:58 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id C0D3C21F85C2 for ; Tue, 19 Jun 2012 06:09:57 -0700 (PDT) Received: (qmail 6090 invoked by uid 399); 19 Jun 2012 13:09:56 -0000 Received: from unknown (HELO ?192.168.1.91?) (pbs:m42@mojaklasa.info@83.31.221.130) by mail1310.opentransfer.com with ESMTPM; 19 Jun 2012 13:09:56 -0000 X-Originating-IP: 83.31.221.130 Message-ID: <4FE07A24.7050804@raszuk.net> Date: Tue, 19 Jun 2012 15:09:56 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: "John G. Scudder" References: <003c01cd4b29$97d7b150$c78713f0$@ndzh.com> <985EF8D2-DA8A-4BE7-94D3-F4BE2B74D768@castlepoint.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Shane Amante , Susan Hares , "idr@ietf.org" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2012 13:09:59 -0000 Hi John, You are right reg the "enabling knob part" I send Shane the same comment few hours back offline ;). But I would not agree with this comment: > I.e., if you haven't chosen > to enable the feature, it would be business as usual, even if your > peer sent you the DO_NOT_PERSIST or STALE communities. Today there is no persistence in BGP. At most for the GR timer which is relatively short. Tomorrow when anyone in the co-participating set of domains for a given SAFI enables persistance I will be getting prefixes marked as STALE and those which are not. That means I can not any longer ignore this marker. I must at all of my ingress ASBRs either drop all updates with STALE community or lower local pref to make sure those would be only used as last resort within my AS. If I fail to do that I will mix live reachability with flaky one and may by normal best path rules prefer the flaky ones for days, weeks or months. Worse is that we will have a mix of both in the non-participating in the game ASes which will be true nightmare to troubleshoot it. That is a significant change which goes across anyone's single AS who wishes to use this technique. Few more questions: Did authors of the draft reached clear consensus that persistance does not override treat-as-withdraw error handling ? That means that regardless of persistance enabled or not withdraws will still be send out for the eligible prefixes in the malformed update ? What happens when router get's fatal malformed attributes or update messages which still trigger session down ? Would persistance apply or not ? In general a bit depending on the answers above what are triggers for session down then when persistance applies ? Thx, R. > Shane, > > On Jun 19, 2012, at 1:34 AM, Shane Amante wrote: > >> If I'm reading this correctly, this draft states that the >> DO_NOT_PERSIST community "SHOULD" be disabled by default, which >> means that (by default) all routes will be set to "persist". > > I think this should be understood in the context of "... IF you have > enabled the feature in your network." [*] I.e., if you haven't chosen > to enable the feature, it would be business as usual, even if your > peer sent you the DO_NOT_PERSIST or STALE communities. Seems like the > draft should be revised (probably in S. 3) to make this more clear. > > I don't know if that changes your opinion any, but FWIW. > > --John > > [*] Not an actual quote from the draft. > _______________________________________________ Idr mailing list > Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr > > From robert@raszuk.net Tue Jun 19 06:24:58 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8964021F8568 for ; Tue, 19 Jun 2012 06:24:58 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S6MNq8Md4a97 for ; Tue, 19 Jun 2012 06:24:57 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 7B50A21F8559 for ; Tue, 19 Jun 2012 06:24:57 -0700 (PDT) Received: (qmail 24532 invoked by uid 399); 19 Jun 2012 13:24:56 -0000 Received: from unknown (HELO ?192.168.1.91?) (pbs:m42@mojaklasa.info@83.31.221.130) by mail1310.opentransfer.com with ESMTPM; 19 Jun 2012 13:24:56 -0000 X-Originating-IP: 83.31.221.130 Message-ID: <4FE07DA8.8050404@raszuk.net> Date: Tue, 19 Jun 2012 15:24:56 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: idr@ietf.org References: <003c01cd4b29$97d7b150$c78713f0$@ndzh.com> <985EF8D2-DA8A-4BE7-94D3-F4BE2B74D768@castlepoint.net> <4FE07A24.7050804@raszuk.net> In-Reply-To: <4FE07A24.7050804@raszuk.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2012 13:24:58 -0000 Btw ... "business as usual" today on EBGP boundary means to clean all communities other then those I do not expect. That means that middle AS will drop all STALE/DO_NOT_PERSIST markers and no one will have a way to distinguished which prefixes are solid and which are questionable. One of the authors proposed to add BGP capability to solve this as well as legacy ASBR case. Note that for this capability to be effective in mixed legacy+upgraded networks it would need to be both for IBGP and EBGP. Is that the direction this draft is going to take ? Thx, R. > Hi John, > > You are right reg the "enabling knob part" I send Shane the same comment > few hours back offline ;). > > But I would not agree with this comment: > > > I.e., if you haven't chosen > > to enable the feature, it would be business as usual, even if your > > peer sent you the DO_NOT_PERSIST or STALE communities. > > Today there is no persistence in BGP. At most for the GR timer which is > relatively short. > > Tomorrow when anyone in the co-participating set of domains for a given > SAFI enables persistance I will be getting prefixes marked as STALE and > those which are not. That means I can not any longer ignore this marker. > I must at all of my ingress ASBRs either drop all updates with STALE > community or lower local pref to make sure those would be only used as > last resort within my AS. > > If I fail to do that I will mix live reachability with flaky one and may > by normal best path rules prefer the flaky ones for days, weeks or > months. Worse is that we will have a mix of both in the > non-participating in the game ASes which will be true nightmare to > troubleshoot it. > > That is a significant change which goes across anyone's single AS who > wishes to use this technique. > > Few more questions: > > Did authors of the draft reached clear consensus that persistance does > not override treat-as-withdraw error handling ? That means that > regardless of persistance enabled or not withdraws will still be send > out for the eligible prefixes in the malformed update ? > > What happens when router get's fatal malformed attributes or update > messages which still trigger session down ? Would persistance apply or > not ? > > In general a bit depending on the answers above what are triggers for > session down then when persistance applies ? > > Thx, > R. > > >> Shane, >> >> On Jun 19, 2012, at 1:34 AM, Shane Amante wrote: >> >>> If I'm reading this correctly, this draft states that the >>> DO_NOT_PERSIST community "SHOULD" be disabled by default, which >>> means that (by default) all routes will be set to "persist". >> >> I think this should be understood in the context of "... IF you have >> enabled the feature in your network." [*] I.e., if you haven't chosen >> to enable the feature, it would be business as usual, even if your >> peer sent you the DO_NOT_PERSIST or STALE communities. Seems like the >> draft should be revised (probably in S. 3) to make this more clear. >> >> I don't know if that changes your opinion any, but FWIW. >> >> --John >> >> [*] Not an actual quote from the draft. >> _______________________________________________ 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 > > From ju1738@att.com Tue Jun 19 06:53:08 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D7A821F8573 for ; Tue, 19 Jun 2012 06:53:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jd2w4d3scy0P for ; Tue, 19 Jun 2012 06:53:05 -0700 (PDT) Received: from nbfkord-smmo08.seg.att.com (nbfkord-smmo08.seg.att.com [209.65.160.95]) by ietfa.amsl.com (Postfix) with ESMTP id 101A421F856D for ; Tue, 19 Jun 2012 06:53:04 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO nbfkord-smmo08.seg.att.com) by nbfkord-smmo08.seg.att.com(mxl_mta-6.11.0-10) with ESMTP id 14480ef4.2aaad581b940.2341495.00-574.6419695.nbfkord-smmo08.seg.att.com (envelope-from ); Tue, 19 Jun 2012 13:53:05 +0000 (UTC) X-MXL-Hash: 4fe0844116e6abf8-826396cae2f1fd35189042fc0b34b8183426b77c Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo08.seg.att.com(mxl_mta-6.11.0-10) over TLS secured channel with ESMTP id 53480ef4.0.2341461.00-356.6419596.nbfkord-smmo08.seg.att.com (envelope-from ); Tue, 19 Jun 2012 13:52:54 +0000 (UTC) X-MXL-Hash: 4fe0843654f41ed0-4c0636ee200b8f09cf25189ca1e8830ccd0db55b Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q5JDqrKs016602; Tue, 19 Jun 2012 09:52:53 -0400 Received: from sflint02.pst.cso.att.com (sflint02.pst.cso.att.com [144.154.234.229]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q5JDqjOV016540 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Jun 2012 09:52:45 -0400 Received: from MISOUT7MSGHUB9D.ITServices.sbc.com (misout7msghub9d.itservices.sbc.com [144.151.223.93]) by sflint02.pst.cso.att.com (RSA Interceptor); Tue, 19 Jun 2012 09:52:37 -0400 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9D.ITServices.sbc.com ([144.151.223.93]) with mapi id 14.01.0355.002; Tue, 19 Jun 2012 09:52:36 -0400 From: "UTTARO, JAMES" To: "'Shane Amante'" , Susan Hares Thread-Topic: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks Thread-Index: AQHNTd04maJ+MFHgAU+sZsaGSkflN5cBpl1A Date: Tue, 19 Jun 2012 13:52:36 +0000 Message-ID: References: <003c01cd4b29$97d7b150$c78713f0$@ndzh.com> <985EF8D2-DA8A-4BE7-94D3-F4BE2B74D768@castlepoint.net> In-Reply-To: <985EF8D2-DA8A-4BE7-94D3-F4BE2B74D768@castlepoint.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.224.208] Content-Type: multipart/alternative; boundary="_000_B17A6910EEDD1F45980687268941550FB11FC8MISOUT7MSGUSR9IIT_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=1.0 c=1 a=vqnfvzHxCNEA:10 a=ZQD3OTTxKqYA:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a=48] X-AnalysisOut: [vgC7mUAAAA:8 a=pv9HrKHYqBhUxutQ-hcA:9 a=CjuIK1q_8ugA:10 a=] X-AnalysisOut: [lZB815dzVvQA:10 a=O8RoqjWKRUECYTXm:21 a=Y3_AJzKWRcVpmSPD:2] X-AnalysisOut: [1 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=lUMUvC_hagn6PNPuK7oA] X-AnalysisOut: [:9 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a] X-AnalysisOut: [=37nYxAYChXMF7w3c:21 a=UdyfLix1-r7-ljkX:21] Cc: "idr@ietf.org" , "'John G. Scudder'" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2012 13:53:08 -0000 --_000_B17A6910EEDD1F45980687268941550FB11FC8MISOUT7MSGUSR9IIT_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Shane Comments In -Line.. Jim Uttaro From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Shane= Amante Sent: Tuesday, June 19, 2012 1:34 AM To: Susan Hares Cc: idr@ietf.org; 'John G. Scudder' Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document -= 3 more weeks I would prefer not to see this adopted as a WG doc. At a high level, I wou= ld rather see a more concentrated focus on implementations providing much m= ore detailed log messages, in particular along the lines of "flight data re= corder" type capabilities that would allow operators and vendors to more ra= pidly isolate the root cause of the issue and then take appropriate action,= automatically or manually, to mitigate the issue temporarily or even perma= nently. This would be of benefit for not only L2VPN/L3VPN services, (as me= ntioned in the draft), but also Internet and other applications that use BG= P for signaling reachability information. [Jim U>] I think you are missing the point if the control plane has melted = down then all of our customers are out of service.. This basic premise is u= nacceptable.. You are speaking of fixing part and I totally agree that we = need more info/telemetry. This does not change the fact that the customer = has had a catastrophic outage... With respect to this particular draft, I have several concerns, but my prim= ary concern is with the following. If I'm reading this correctly, this draft states that the DO_NOT_PERSIST co= mmunity "SHOULD" be disabled by default, which means that (by default) all = routes will be set to "persist". Only through manual config on the part of= an SP, will a subset of routes be set to DO_NOT_PERSIST, i.e.: obey the cl= assic/current behavior of BGP, that is be withdrawn when the session fails.= This appears to be a fundamental change to BGP, which I would not want to= see deployed "by accident" because this suddenly becomes the default behav= ior in implementations. Yes, it sucks, but I would rather see routes withd= rawn on session failure (like they are today), rather than hang around unti= l the network is "fixed". Ultimately, problems of this nature are easy to = quickly explain to customer (so the Ops & Vendor folks can concentrate on d= etermining root cause and mitigating it), rather than how long it takes to = sort through and try to explain "routing anomalies" that are likely to incr= ementally build-up the longer routes are held in a STALE state. [Jim U>] I will have to bring you along the next time this happens to expla= in it to the customer.. Ultimately, I empathize with the co-authors that being in this situation is= not fun, nor a good day. (Been there, done that, got the T-shirts ... hap= py to say I destroyed them afterward :-). Furthermore, although it does co= st money, which is not easy to come by, I believe that a redundant architec= ture could be deployed in either the SP's network or by the customer (i.e.:= multi-home to two carriers) to largely mitigate these concerns. Yes, this= is not practical in all cases, but it's certainly /possible/ and should be= considered recommended before such drastic changes are made to BGP. [Jim U>] I do not understand why we are debating the reqs. Just my own $0.02, -shane On Jun 15, 2012, at 1:03 PM, Susan Hares wrote: IDR WG and BGPers: While there is a strong debate on draft-uttaro-idr-bgp-persistence-01 as ID= R WG document, I do not see a clear consensus. We also did not get an over= whelming number of you to hum either way (11 total). Since some of those who voted "no" have suggested alternate text to the aut= hor, I would like to extend the time to consider this draft for 3 more week= s. To accept the draft we need a few more of you to "hum" yes or "hum" no. Sue Hares _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr --_000_B17A6910EEDD1F45980687268941550FB11FC8MISOUT7MSGUSR9IIT_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Shane

 <= /p>

    &= nbsp;           Comments = In –Line..

 <= /p>

Jim Uttaro

 <= /p>

From: idr-boun= ces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Shane Amante
Sent: Tuesday, June 19, 2012 1:34 AM
To: Susan Hares
Cc: idr@ietf.org; 'John G. Scudder'
Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG doc= ument - 3 more weeks

 

I would prefer not to see this adopted as a WG doc. =  At a high level, I would rather see a more concentrated focus on impl= ementations providing much more detailed log messages, in particular along = the lines of "flight data recorder" type capabilities that would allow operators and vendors to more rapidly isolat= e the root cause of the issue and then take appropriate action, automatical= ly or manually, to mitigate the issue temporarily or even permanently. &nbs= p;This would be of benefit for not only L2VPN/L3VPN services, (as mentioned in the draft), but also Internet and o= ther applications that use BGP for signaling reachability information.=

[Jim U>] I think= you are missing the point if the control plane has melted down then all of= our customers are out of service.. This basic premise is unacceptable.. You are speaking of fixing part  and I totally agree that we need mor= e info/telemetry.  This does not change the fact that the customer has= had a catastrophic outage…

 

With respect to this particular draft, I have severa= l concerns, but my primary concern is with the following.

 

If I'm reading this correctly, this draft states tha= t the DO_NOT_PERSIST community "SHOULD" be disabled by default, w= hich means that (by default) all routes will be set to "persist".=  Only through manual config on the part of an SP, will a subset of routes be set to DO_NOT_PERSIST, i.e.: obey the classic/curren= t behavior of BGP, that is be withdrawn when the session fails.  This = appears to be a fundamental change to BGP, which I would not want to see de= ployed "by accident" because this suddenly becomes the default behavior in implementations.  Yes, it sucks, but = I would rather see routes withdrawn on session failure (like they are today= ), rather than hang around until the network is "fixed".  Ul= timately, problems of this nature are easy to quickly explain to customer (so the Ops & Vendor folks can concentrate on dete= rmining root cause and mitigating it), rather than how long it takes to sor= t through and try to explain "routing anomalies" that are likely = to incrementally build-up the longer routes are held in a STALE state.

[Jim U>] I will = have to bring you along the next time this happens to explain it to the cus= tomer..

 

Ultimately, I empathize with the co-authors that bei= ng in this situation is not fun, nor a good day.  (Been there, done th= at, got the T-shirts ... happy to say I destroyed them afterward :-).  = ;Furthermore, although it does cost money, which is not easy to come by, I believe that a redundant architecture could be d= eployed in either the SP's network or by the customer (i.e.: multi-home to = two carriers) to largely mitigate these concerns.  Yes, this is not pr= actical in all cases, but it's certainly /possible/ and should be considered recommended before such drastic change= s are made to BGP.

[Jim U>] I do no= t understand why we are debating the reqs.

 

Just my own $0.02,

 

-shane

 

 

 
--_000_B17A6910EEDD1F45980687268941550FB11FC8MISOUT7MSGUSR9IIT_-- From ju1738@att.com Tue Jun 19 06:57:05 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1011821F8510 for ; Tue, 19 Jun 2012 06:57:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ILVyErxS6Xt for ; Tue, 19 Jun 2012 06:57:04 -0700 (PDT) Received: from nbfkord-smmo08.seg.att.com (nbfkord-smmo08.seg.att.com [209.65.160.95]) by ietfa.amsl.com (Postfix) with ESMTP id E951321F850C for ; Tue, 19 Jun 2012 06:57:03 -0700 (PDT) Received: from unknown [144.160.128.153] (EHLO flpi408.enaf.ffdc.sbc.com) by nbfkord-smmo08.seg.att.com(mxl_mta-6.11.0-10) over TLS secured channel with ESMTP id f2580ef4.0.2342654.00-470.6423002.nbfkord-smmo08.seg.att.com (envelope-from ); Tue, 19 Jun 2012 13:57:03 +0000 (UTC) X-MXL-Hash: 4fe0852f26630851-af3e3708374970ea1647f596def9e539ff0efbda Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q5JDv2Px015353; Tue, 19 Jun 2012 06:57:03 -0700 Received: from fflint04.pst.cso.att.com (fflint04.pst.cso.att.com [150.234.39.64]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q5JDusos015292 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Jun 2012 06:56:55 -0700 Received: from MISOUT7MSGHUB9F.ITServices.sbc.com (misout7msghub9f.itservices.sbc.com [144.151.223.71]) by fflint04.pst.cso.att.com (RSA Interceptor); Tue, 19 Jun 2012 06:56:39 -0700 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9F.ITServices.sbc.com ([144.151.223.71]) with mapi id 14.01.0355.002; Tue, 19 Jun 2012 09:56:39 -0400 From: "UTTARO, JAMES" To: "'bruno.decraene@orange.com'" , "John G. Scudder" Thread-Topic: [Idr] I-D Action: draft-ietf-idr-error-handling-02.txt Thread-Index: AQHNTYuS3AC4WgUFwEeXslewDoqMZpcBO7CggABvWBA= Date: Tue, 19 Jun 2012 13:56:38 +0000 Message-ID: References: <20120617204451.26844.76025.idtracker@ietfa.amsl.com> <16377_1340092076_4FE02EAC_16377_6476_1_53C29892C857584299CBF5D05346208A0920B5@PEXCVZYM11.corporate.adroot.infra.ftgroup> In-Reply-To: <16377_1340092076_4FE02EAC_16377_6476_1_53C29892C857584299CBF5D05346208A0920B5@PEXCVZYM11.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.224.208] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.128.153] X-AnalysisOut: [v=1.0 c=1 a=vqnfvzHxCNEA:10 a=Crak0S_X7RUA:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=xwOvzTHDVLE4u4] X-AnalysisOut: [nGvK72ag==:17 a=z9tbli-vAAAA:8 a=48vgC7mUAAAA:8 a=ojfknZsW] X-AnalysisOut: [sYeDgbrEEN8A:9 a=CjuIK1q_8ugA:10 a=oAXR_kdF8uMA:10 a=lZB81] X-AnalysisOut: [5dzVvQA:10] Cc: "idr@ietf.org" Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2012 13:57:05 -0000 Bruno, Comments In-Line Thanks, Jim Uttaro -----Original Message----- From: bruno.decraene@orange.com [mailto:bruno.decraene@orange.com]=20 Sent: Tuesday, June 19, 2012 3:48 AM To: John G. Scudder; UTTARO, JAMES Cc: idr@ietf.org Subject: RE: [Idr] I-D Action: draft-ietf-idr-error-handling-02.txt Hi John, all, >From: John G. Scudder >Sent: Monday, June 18, 2012 9:49 PM [...] > >> Could you expand on the conditions > >One very simple case: > > A--B--C--D > >The four routers depicted form an IBGP full mesh (sessions not shown). The >links shown are the physical topology. Standard IP forwarding is used. Rou= ters >A and D are ASBRs and both advertise a path for prefix X into IBGP. Router= C >prefers the path from A, for example due to a shorter AS Path. However, ro= uter >B decides that the path from A is malformed, so it selects the path from D= . Now >we have C's next hop to reach X as B, and B's next hop to reach X as C. Th= is is >a stable forwarding loop. (Why do B and C have different conclusions about >whether the update is malformed? Different code bases with different >assumptions, as we have seen more than once in the field.) draft-ietf-idr-error-handling-02: "The consequences of inconsistent routing= can include long-lived forwarding loops and black holes." IMHO I would favor expanding a bit on this as this is an important point. E= .g. 1) adding your simple and very illustrative example in appendix. 2) discussing the applicability of such consequences. E.g. I feel that they= are different for AS/applications using tunnels between ASBR vs hop by hop= routing ones(*). Whether I'm right or wrong, IMHO a clarification is alway= s helpful. [...] "For any malformed attribute which is handled by the "attribute discard" instead of the "treat-as-withdraw" approach, it is critical to consider the potential impact of doing so." IMHO I would rather move that paragraph from the "4. Operational Considerat= ions" to "2. Revision to Base Specification" just below "A document which s= pecifies a new attribute MUST provide specifics regarding what constitutes an error for that attribute and how that erro= r is to be handled." (unless this choice is left to operators, which does n= ot seem to be the case) [...] >Yes. You're right to find this shocking. I find it shocking, but have been >browbeaten :-)/2 into agreeing that the cure may be a little less bad than= the >disease. However, the floor is still definitely open for debate! >[Jim U>] Ouch.. I don't like the notion of changing the fundamental nature= of >the protocol.. IMHO=20 - we should be cautious when changing the "fundamental nature of the protoc= ol" - but we should be able to question (, discuss and exchange arguments on) _= any_ aspects of the protocol. And on a side note, the notion of "fundamental nature of the protocol" is p= ersonal (not to say religious). E.g. the fundamental nature of BGP is Inter= net IDR. Using it for L3 VPN -not to mention L2 VPN :-) - is against nature= . [Jim U>] My thought here was that the resultant action would affect paths b= y "treat as withdraw", on other cases the resultant action would be at the = session level.. I know of no other change in other AFs that changes the res= ultant action in this way.. Could be but I am not aware... Regards, Bruno ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From shane@castlepoint.net Tue Jun 19 06:57:29 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D164621F85D7 for ; Tue, 19 Jun 2012 06:57:29 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y86s-Gnxn8uK for ; Tue, 19 Jun 2012 06:57:29 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id 5AF8321F85D4 for ; Tue, 19 Jun 2012 06:57:29 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id 0B155268063; Tue, 19 Jun 2012 07:57:29 -0600 (MDT) Received: from host2.tcb.net (64.78.235.218 [64.78.235.218]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Tue, 19 Jun 2012 07:57:29 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=64.78.235.218; client-port=60423; data-bytes=0 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Shane Amante In-Reply-To: Date: Tue, 19 Jun 2012 07:57:26 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <7C61E57E-19D8-4267-8DFF-5D8DE72BAF68@castlepoint.net> References: <003c01cd4b29$97d7b150$c78713f0$@ndzh.com> <985EF8D2-DA8A-4BE7-94D3-F4BE2B74D768@castlepoint.net> To: John G. Scudder X-Mailer: Apple Mail (2.1278) Cc: "idr@ietf.org" , Susan Hares Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2012 13:57:30 -0000 John, On Jun 19, 2012, at 6:36 AM, John G. Scudder wrote: > Shane, >=20 > On Jun 19, 2012, at 1:34 AM, Shane Amante wrote: >=20 >> If I'm reading this correctly, this draft states that the = DO_NOT_PERSIST community "SHOULD" be disabled by default, which means = that (by default) all routes will be set to "persist". >=20 > I think this should be understood in the context of "... IF you have = enabled the feature in your network." [*] I.e., if you haven't chosen to = enable the feature, it would be business as usual, even if your peer = sent you the DO_NOT_PERSIST or STALE communities. Seems like the draft = should be revised (probably in S. 3) to make this more clear. >=20 > I don't know if that changes your opinion any, but FWIW. Thanks for the clarification. However, that does not alleviate my = concerns on this draft, thus my original opinion still stands. Thanks, -shane >=20 > --John >=20 > [*] Not an actual quote from the draft. From randy@psg.com Tue Jun 19 07:04:43 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B815421F85D4 for ; Tue, 19 Jun 2012 07:04:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f39ANn8zIMsG for ; Tue, 19 Jun 2012 07:04:43 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 493EE21F85CF for ; Tue, 19 Jun 2012 07:04:43 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Sgz2w-0005yY-69; Tue, 19 Jun 2012 14:04:42 +0000 Date: Tue, 19 Jun 2012 23:04:41 +0900 Message-ID: From: Randy Bush To: "UTTARO, JAMES" In-Reply-To: References: <003c01cd4b29$97d7b150$c78713f0$@ndzh.com> <985EF8D2-DA8A-4BE7-94D3-F4BE2B74D768@castlepoint.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: idr wg Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2012 14:04:43 -0000 > I think you are missing the point if the control plane has melted down perhaps a control plane less, not more inclined, to melting should be considered. centralization of the control plane seriously erodes congruence of control and data planes. this leads to nasty instabilities, as i believe you have discovered. adding more complexity to the control plane is just not gonna fix it. randy, who likes the reflectors to be in the data path From jgs@juniper.net Tue Jun 19 07:36:55 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55DE421F84BF for ; Tue, 19 Jun 2012 07:36:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IcPi5bT1sKHv for ; Tue, 19 Jun 2012 07:36:52 -0700 (PDT) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by ietfa.amsl.com (Postfix) with ESMTP id 6A42021F84A2 for ; Tue, 19 Jun 2012 07:36:50 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKT+COgSuU+QTE+1NF8yN7Gjj0BkQDjtN8@postini.com; Tue, 19 Jun 2012 07:36:52 PDT Received: from [172.16.13.205] (172.16.13.205) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server id 8.3.213.0; Tue, 19 Jun 2012 07:36:25 -0700 MIME-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset="iso-8859-1" From: "John G. Scudder" In-Reply-To: <4FE07A24.7050804@raszuk.net> Date: Tue, 19 Jun 2012 10:36:24 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <2CD3ACF1-8F31-4870-825D-17662F468806@juniper.net> References: <003c01cd4b29$97d7b150$c78713f0$@ndzh.com> <985EF8D2-DA8A-4BE7-94D3-F4BE2B74D768@castlepoint.net> <4FE07A24.7050804@raszuk.net> To: "robert@raszuk.net" X-Mailer: Apple Mail (2.1278) Cc: Shane Amante , Susan Hares , "idr@ietf.org" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2012 14:36:55 -0000 On Jun 19, 2012, at 9:09 AM, Robert Raszuk wrote: > Did authors of the draft reached clear consensus that persistance does=20= > not override treat-as-withdraw error handling ? That means that=20 > regardless of persistance enabled or not withdraws will still be send=20= > out for the eligible prefixes in the malformed update ? I do not recall this having been discussed, however given that the draft = specifically targets session failure (see S. 4.1) I would expect that if = the session has *not* failed (including not failing because of the = operation of draft-ietf-idr-error-handling) then persistence wouldn't = come into play. --John= From ju1738@att.com Tue Jun 19 07:52:55 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A98D21F8504 for ; Tue, 19 Jun 2012 07:52:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 47RRQz5vQ+tf for ; Tue, 19 Jun 2012 07:52:49 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id 4A73F21F851B for ; Tue, 19 Jun 2012 07:52:48 -0700 (PDT) Received: from unknown [144.160.128.153] (EHLO nbfkord-smmo05.seg.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.11.0-10) with ESMTP id 14290ef4.4b410940.31380.00-586.89643.nbfkord-smmo05.seg.att.com (envelope-from ); Tue, 19 Jun 2012 14:52:49 +0000 (UTC) X-MXL-Hash: 4fe0924133bd9048-c93f71d15eaf25c6ac9ff68fb90c3d09fe404910 Received: from unknown [144.160.128.153] (EHLO flpi408.enaf.ffdc.sbc.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.11.0-10) over TLS secured channel with ESMTP id 72290ef4.0.31181.00-458.89074.nbfkord-smmo05.seg.att.com (envelope-from ); Tue, 19 Jun 2012 14:52:38 +0000 (UTC) X-MXL-Hash: 4fe092362bbf3c15-c9a0d00c88b9effde973b64a66880a079649edcd Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q5JEqM42013702; Tue, 19 Jun 2012 07:52:23 -0700 Received: from fflint04.pst.cso.att.com (fflint04.pst.cso.att.com [150.234.39.64]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q5JEq92Z013450 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Jun 2012 07:52:17 -0700 Received: from MISOUT7MSGHUB9B.ITServices.sbc.com (misout7msghub9b.itservices.sbc.com [144.151.223.72]) by fflint04.pst.cso.att.com (RSA Interceptor); Tue, 19 Jun 2012 07:51:54 -0700 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9B.ITServices.sbc.com ([144.151.223.72]) with mapi id 14.01.0355.002; Tue, 19 Jun 2012 10:51:53 -0400 From: "UTTARO, JAMES" To: "'John G. Scudder'" , "robert@raszuk.net" Thread-Topic: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks Thread-Index: AQHNTikC/KfNtUSTqEWkSqZNSuWTmpcBuSog Date: Tue, 19 Jun 2012 14:51:53 +0000 Message-ID: References: <003c01cd4b29$97d7b150$c78713f0$@ndzh.com> <985EF8D2-DA8A-4BE7-94D3-F4BE2B74D768@castlepoint.net> <4FE07A24.7050804@raszuk.net> <2CD3ACF1-8F31-4870-825D-17662F468806@juniper.net> In-Reply-To: <2CD3ACF1-8F31-4870-825D-17662F468806@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.224.208] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.128.153] X-AnalysisOut: [v=1.0 c=1 a=vqnfvzHxCNEA:10 a=ZQD3OTTxKqYA:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=xwOvzTHDVLE4u4] X-AnalysisOut: [nGvK72ag==:17 a=48vgC7mUAAAA:8 a=2clOPd4PAAAA:8 a=IwmFo0fu] X-AnalysisOut: [uGul1B-RqdoA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=bDUki] X-AnalysisOut: [_mJ7DgA:10] Cc: Shane Amante , Susan Hares , "idr@ietf.org" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2012 14:52:56 -0000 John, Comments In-line.. Jim Uttaro -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of John = G. Scudder Sent: Tuesday, June 19, 2012 10:36 AM To: robert@raszuk.net Cc: Shane Amante; Susan Hares; idr@ietf.org Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document -= 3 more weeks On Jun 19, 2012, at 9:09 AM, Robert Raszuk wrote: > Did authors of the draft reached clear consensus that persistance does=20 > not override treat-as-withdraw error handling ? That means that=20 > regardless of persistance enabled or not withdraws will still be send=20 > out for the eligible prefixes in the malformed update ? I do not recall this having been discussed, however given that the draft sp= ecifically targets session failure (see S. 4.1) I would expect that if the = session has *not* failed (including not failing because of the operation of= draft-ietf-idr-error-handling) then persistence wouldn't come into play. [Jim U>] This is right.. Of course we are assuming that draft-ietf-idr-err= or-handling is actually agreed to and then built/deployed.. I assume that t= he behavior in the error handling is configurable and not default behavior.= =20 --John _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From robert@raszuk.net Tue Jun 19 08:19:34 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D42FD21F85C4 for ; Tue, 19 Jun 2012 08:19:34 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rIl3eZvXbdz9 for ; Tue, 19 Jun 2012 08:19:34 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 0405421F85EF for ; Tue, 19 Jun 2012 08:19:34 -0700 (PDT) Received: (qmail 27660 invoked by uid 399); 19 Jun 2012 15:19:33 -0000 Received: from unknown (HELO ?192.168.1.91?) (pbs:robert@raszuk.net@83.31.221.130) by mail1310.opentransfer.com with ESMTPM; 19 Jun 2012 15:19:33 -0000 X-Originating-IP: 83.31.221.130 Message-ID: <4FE09885.1020106@raszuk.net> Date: Tue, 19 Jun 2012 17:19:33 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: idr@ietf.org References: <003c01cd4b29$97d7b150$c78713f0$@ndzh.com> <985EF8D2-DA8A-4BE7-94D3-F4BE2B74D768@castlepoint.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2012 15:19:35 -0000 I do not understand how the point on centralized RRs is relevant to the draft discussed. BGP control plane can melt by the very same trigger regardless if it is centralized and consists of handful of RRs or if RRs are in data plane and their number goes in 100s. One could argue that in the latter case it will take much longer for the domain to stabilize. IMHO the issue is not in the centralized vs distributed control plane architecture. The issue is in use of limited number of control plane implementations. The more you distribute it the harder it get's to deploy more independent control plane brains for the network, hence as Jim observed his services suffered. R. >> I think you are missing the point if the control plane has melted down > > perhaps a control plane less, not more inclined, to melting should be > considered. > > centralization of the control plane seriously erodes congruence of > control and data planes. this leads to nasty instabilities, as i > believe you have discovered. adding more complexity to the control > plane is just not gonna fix it. > > randy, who likes the reflectors to be in the data path > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > From shane@castlepoint.net Tue Jun 19 08:29:16 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C97911E8087 for ; Tue, 19 Jun 2012 08:29:16 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zlJV6NqG7fcV for ; Tue, 19 Jun 2012 08:29:15 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id 7F58221F84FF for ; Tue, 19 Jun 2012 08:29:15 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id 20D60368199; Tue, 19 Jun 2012 09:29:15 -0600 (MDT) Received: from host2.tcb.net (64.78.235.218 [64.78.235.218]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Tue, 19 Jun 2012 09:29:15 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=64.78.235.218; client-port=61136; data-bytes=0 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Shane Amante In-Reply-To: <4FE07A24.7050804@raszuk.net> Date: Tue, 19 Jun 2012 09:29:14 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <1C1F2B2E-2EB7-42F0-8CFF-57965443C074@castlepoint.net> References: <003c01cd4b29$97d7b150$c78713f0$@ndzh.com> <985EF8D2-DA8A-4BE7-94D3-F4BE2B74D768@castlepoint.net> <4FE07A24.7050804@raszuk.net> To: robert@raszuk.net X-Mailer: Apple Mail (2.1278) Cc: Susan Hares , "idr@ietf.org" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2012 15:29:16 -0000 Robert, On Jun 19, 2012, at 7:09 AM, Robert Raszuk wrote: > Hi John, >=20 > You are right reg the "enabling knob part" I send Shane the same = comment > few hours back offline ;). >=20 > But I would not agree with this comment: >=20 > > I.e., if you haven't chosen > > to enable the feature, it would be business as usual, even if your > > peer sent you the DO_NOT_PERSIST or STALE communities. >=20 > Today there is no persistence in BGP. At most for the GR timer which = is relatively short. >=20 > Tomorrow when anyone in the co-participating set of domains for a = given SAFI enables persistance I will be getting prefixes marked as = STALE and those which are not. That means I can not any longer ignore = this marker. I must at all of my ingress ASBRs either drop all updates = with STALE community or lower local pref to make sure those would be = only used as last resort within my AS. >=20 > If I fail to do that I will mix live reachability with flaky one and = may by normal best path rules prefer the flaky ones for days, weeks or = months. Worse is that we will have a mix of both in the = non-participating in the game ASes which will be true nightmare to = troubleshoot it. I also have similar concerns with this draft. In particular, is there = an assumption in here that BGP sessions that are "failed" expected to be = held down for the same period of time as the "persist" timer(s)? = Otherwise, wouldn't the BGP sessions automatically try to come back up, = indefinitely, leading to more churn of adding/removing the STALE = community toward other neighbors each time the "bad" implementation = receives a malformed attribute and causes a session to fail? In some = ways, that seems to be making the problem worse in that sessions that = may otherwise be providing redundancy are now held down for some lengthy = period of time, which the NOC may not be as aware of. Although the = draft tries to cover-off the latter issue by checking for availability = to the NEXT_HOP on routes advertised as STALE, that seems to be fighting = a symptom of the problem caused by this draft and not addressing the = real, underlying root cause IMHO. In summary, I'd much rather see a more general-purpose solution be = developed that is applicable to _ALL_ address families, because that way = all services can benefit from it, Ops folks only need to learn/train on = one technique/mechanism (regardless of service type), it makes it more = straightforward for the IDR WG to enhance/extend BGP down the road w/out = (too much) consideration of address-family specific behaviors, etc. -shane > That is a significant change which goes across anyone's single AS who = wishes to use this technique. >=20 > Few more questions: >=20 > Did authors of the draft reached clear consensus that persistance does = not override treat-as-withdraw error handling ? That means that = regardless of persistance enabled or not withdraws will still be send = out for the eligible prefixes in the malformed update ? >=20 > What happens when router get's fatal malformed attributes or update = messages which still trigger session down ? Would persistance apply or = not ? >=20 > In general a bit depending on the answers above what are triggers for = session down then when persistance applies ? >=20 > Thx, > R. >=20 >=20 >> Shane, >>=20 >> On Jun 19, 2012, at 1:34 AM, Shane Amante wrote: >>=20 >>> If I'm reading this correctly, this draft states that the >>> DO_NOT_PERSIST community "SHOULD" be disabled by default, which >>> means that (by default) all routes will be set to "persist". >>=20 >> I think this should be understood in the context of "... IF you have >> enabled the feature in your network." [*] I.e., if you haven't chosen >> to enable the feature, it would be business as usual, even if your >> peer sent you the DO_NOT_PERSIST or STALE communities. Seems like the >> draft should be revised (probably in S. 3) to make this more clear. >>=20 >> I don't know if that changes your opinion any, but FWIW. >>=20 >> --John >>=20 >> [*] Not an actual quote from the draft. >> _______________________________________________ Idr mailing list >> Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr >>=20 >>=20 >=20 >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From robert@raszuk.net Tue Jun 19 08:48:48 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32B1D21F85CC for ; Tue, 19 Jun 2012 08:48:48 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GHAOgT8ufKVj for ; Tue, 19 Jun 2012 08:48:47 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 3D25421F85C7 for ; Tue, 19 Jun 2012 08:48:47 -0700 (PDT) Received: (qmail 5799 invoked by uid 399); 19 Jun 2012 15:48:46 -0000 Received: from unknown (HELO ?192.168.1.91?) (pbs:robert@raszuk.net@83.31.221.130) by mail1310.opentransfer.com with ESMTPM; 19 Jun 2012 15:48:46 -0000 X-Originating-IP: 83.31.221.130 Message-ID: <4FE09F5E.7060102@raszuk.net> Date: Tue, 19 Jun 2012 17:48:46 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Shane Amante References: <003c01cd4b29$97d7b150$c78713f0$@ndzh.com> <985EF8D2-DA8A-4BE7-94D3-F4BE2B74D768@castlepoint.net> <4FE07A24.7050804@raszuk.net> <1C1F2B2E-2EB7-42F0-8CFF-57965443C074@castlepoint.net> In-Reply-To: <1C1F2B2E-2EB7-42F0-8CFF-57965443C074@castlepoint.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org" , Susan Hares , DECRAENE Bruno RD-CORE Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2012 15:48:48 -0000 Hi Shane, > In summary, I'd much rather see a more general-purpose solution be > developed that is applicable to_ALL_ address families, because that > way all services can benefit from it, Ops folks only need to > learn/train on one technique/mechanism (regardless of service type), > it makes it more straightforward for the IDR WG to enhance/extend BGP > down the road w/out (too much) consideration of address-family > specific behaviors, etc. Indeed this is great observation. Moreover the draft on one hand talks about session failing while on the other hand authors talk about control plane "melting". Let's make it very clear that if my BGP crashes on PEs even if data plane is all fine - this proposal brings nothing to the service stability as routes will be removed from RIBs. GR seems to be solving both cases via it's implicit interaction with RIB and FIB. Also in one of the mails Bruno said: "In short: persistence and GR address largely independent use cases and can be enabled independently." + "So far, I don't see a reason to mandate GR when persistence is used." While in the same time draft says when mentioning briefly how to synchronize the state: -- 4.3. BGP session re-establishement When a failed persistent BGP session is re-established, the Receiving Speaker MUST replace the stale routes by the routing updates received from the peer. Once the End-of-RIB marker for an address family is received from the peer, it MUST immediately remove any paths from the peer that are still marked as stale for that address family. -- The similar procedure from RFC4724 section 4.2: -- The Receiving Speaker MUST replace the stale routes by the routing updates received from the peer. Once the End-of-RIB marker for an address family is received from the peer, it MUST immediately remove any routes from the peer that are still marked as stale for that address family. -- To mandate peer that it needs to send EOR marker when session get's reestablished you need to agree with your peers on it. Today it is done via GR (null) capability. Moreover if BGP process crashed the above does not apply as RFC4724 clearly mandates marking the routes in loc-RIB while this draft only mentions: "attach the STALE community value" The difference is that GR stale marker is preserved upon BGP restart caused by meltdown of control plane while draft-persistance stale marker in the form of BGP community is not preserved. Two more reasons to use GR as a more general and already deployed solution. Regards, R. From Faisal.Hashmi@alcatel-lucent.com Tue Jun 19 09:21:39 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 962D421F8435 for ; Tue, 19 Jun 2012 09:21:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lxRUKMRCkqcq for ; Tue, 19 Jun 2012 09:21:39 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id C0D5111E80B7 for ; Tue, 19 Jun 2012 09:21:14 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id q5JGLEGM022695 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 19 Jun 2012 11:21:14 -0500 (CDT) Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q5JGLEXE008938 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 19 Jun 2012 11:21:14 -0500 Received: from USNAVSXCHMBSC3.ndc.alcatel-lucent.com ([135.3.39.144]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Tue, 19 Jun 2012 11:21:14 -0500 From: "Hashmi, Faisal (Faisal)" To: "'idr@ietf.org'" Date: Tue, 19 Jun 2012 11:21:10 -0500 Thread-Topic: draft-uttaro-idr-bgp-persistence-01 Thread-Index: Ac1Nbtis5YKjVxdZTOqd5RXxohYewwAyJp2g Message-ID: <8E9515536A871047BDE6B631B17A425E02B8F75870@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_8E9515536A871047BDE6B631B17A425E02B8F75870USNAVSXCHMBSC_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Subject: [Idr] draft-uttaro-idr-bgp-persistence-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2012 16:21:39 -0000 --_000_8E9515536A871047BDE6B631B17A425E02B8F75870USNAVSXCHMBSC_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document I support this draft. Thanks Faisal Hashmi Senior Systems Engineer Alcatel-Lucent 832 520 4052 CCIE Service Provider. CCIE#19248 Project Management Professional (PMP) --_000_8E9515536A871047BDE6B631B17A425E02B8F75870USNAVSXCHMBSC_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
[Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document
 
I support this draft.
 
 
Thanks
 
Faisal Hashmi
Senior Systems Engineer
Alcatel-Lucent
832 520 4052
CCIE Service Provider. CCIE#19248
Project Management Professional (PMP)
 
 --_000_8E9515536A871047BDE6B631B17A425E02B8F75870USNAVSXCHMBSC_-- From ju1738@att.com Tue Jun 19 09:27:40 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B31F621F8555 for ; Tue, 19 Jun 2012 09:27:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SAAfviopuw-7 for ; Tue, 19 Jun 2012 09:27:39 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id 8E8B521F854F for ; Tue, 19 Jun 2012 09:27:39 -0700 (PDT) Received: from unknown [144.160.128.153] (EHLO nbfkord-smmo07.seg.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.11.0-10) with ESMTP id b78a0ef4.2aaac7204940.997013.00-562.2697013.nbfkord-smmo07.seg.att.com (envelope-from ); Tue, 19 Jun 2012 16:27:39 +0000 (UTC) X-MXL-Hash: 4fe0a87b61f81620-e7773a5efc11c6296a4d22ae8acb2c14c2a1874c Received: from unknown [144.160.128.153] (EHLO flpi408.enaf.ffdc.sbc.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.11.0-10) over TLS secured channel with ESMTP id d58a0ef4.0.996910.00-440.2696714.nbfkord-smmo07.seg.att.com (envelope-from ); Tue, 19 Jun 2012 16:27:24 +0000 (UTC) X-MXL-Hash: 4fe0a86c5dab1843-597f147b67cecfc50992bcc9ce629f7cf1d4c683 Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q5JGR8iT001747; Tue, 19 Jun 2012 09:27:09 -0700 Received: from fflint03.pst.cso.att.com (fflint03.pst.cso.att.com [150.234.39.63]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q5JGR05o001649 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Jun 2012 09:27:06 -0700 Received: from MISOUT7MSGHUB9B.ITServices.sbc.com (misout7msghub9b.itservices.sbc.com [144.151.223.72]) by fflint03.pst.cso.att.com (RSA Interceptor); Tue, 19 Jun 2012 09:26:44 -0700 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9B.ITServices.sbc.com ([144.151.223.72]) with mapi id 14.01.0355.002; Tue, 19 Jun 2012 12:26:28 -0400 From: "UTTARO, JAMES" To: "'Shane Amante'" , "robert@raszuk.net" Thread-Topic: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks Thread-Index: AQHNTjBROE7XDsZHUkufuSuNr53onJcB00cQ Date: Tue, 19 Jun 2012 16:26:28 +0000 Message-ID: References: <003c01cd4b29$97d7b150$c78713f0$@ndzh.com> <985EF8D2-DA8A-4BE7-94D3-F4BE2B74D768@castlepoint.net> <4FE07A24.7050804@raszuk.net> <1C1F2B2E-2EB7-42F0-8CFF-57965443C074@castlepoint.net> In-Reply-To: <1C1F2B2E-2EB7-42F0-8CFF-57965443C074@castlepoint.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.224.208] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.128.153] X-AnalysisOut: [v=1.0 c=1 a=vqnfvzHxCNEA:10 a=ZQD3OTTxKqYA:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=xwOvzTHDVLE4u4] X-AnalysisOut: [nGvK72ag==:17 a=48vgC7mUAAAA:8 a=2clOPd4PAAAA:8 a=AoV52UPA] X-AnalysisOut: [b2Mb54r-NMoA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=bDUki] X-AnalysisOut: [_mJ7DgA:10 a=xOwjL6Dz5TZtKnpq:21 a=LRQCDygtssP3siGs:21] Cc: "idr@ietf.org" , Susan Hares Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2012 16:27:40 -0000 Comments In-Line.. Jim Uttaro -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Shane= Amante Sent: Tuesday, June 19, 2012 11:29 AM To: robert@raszuk.net Cc: Susan Hares; idr@ietf.org Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document -= 3 more weeks Robert, On Jun 19, 2012, at 7:09 AM, Robert Raszuk wrote: > Hi John, >=20 > You are right reg the "enabling knob part" I send Shane the same comment > few hours back offline ;). >=20 > But I would not agree with this comment: >=20 > > I.e., if you haven't chosen > > to enable the feature, it would be business as usual, even if your > > peer sent you the DO_NOT_PERSIST or STALE communities. >=20 > Today there is no persistence in BGP. At most for the GR timer which is r= elatively short. >=20 > Tomorrow when anyone in the co-participating set of domains for a given S= AFI enables persistance I will be getting prefixes marked as STALE and thos= e which are not. That means I can not any longer ignore this marker. I must= at all of my ingress ASBRs either drop all updates with STALE community or= lower local pref to make sure those would be only used as last resort with= in my AS. >=20 > If I fail to do that I will mix live reachability with flaky one and may = by normal best path rules prefer the flaky ones for days, weeks or months. = Worse is that we will have a mix of both in the non-participating in the ga= me ASes which will be true nightmare to troubleshoot it. I also have similar concerns with this draft. In particular, is there an a= ssumption in here that BGP sessions that are "failed" expected to be held d= own for the same period of time as the "persist" timer(s)? [Jim U>] No. The Persist-Timer indicates the length of time that the paths = should persist, after this timer expires the paths are withdrawn. =20 Otherwise, wouldn't the BGP sessions automatically try to come back up, ind= efinitely, leading to more churn of adding/removing the STALE community tow= ard other neighbors each time the "bad" implementation receives a malformed= attribute and causes a session to fail? In some ways, that seems to be ma= king the problem worse in that sessions that may otherwise be providing red= undancy are now held down for some lengthy period of time, which the NOC ma= y not be as aware of. Although the draft tries to cover-off the latter iss= ue by checking for availability to the NEXT_HOP on routes advertised as STA= LE, that seems to be fighting a symptom of the problem caused by this draft= and not addressing the real, underlying root cause IMHO. In summary, I'd much rather see a more general-purpose solution be develope= d that is applicable to _ALL_ address families, because that way all servic= es can benefit from it, Ops folks only need to learn/train on one technique= /mechanism (regardless of service type), it makes it more straightforward f= or the IDR WG to enhance/extend BGP down the road w/out (too much) consider= ation of address-family specific behaviors, etc. [Jim U>] Different AFs have different behaviors. Some are more static than = other i.e 3107, L2VPN others more dynamic IPV4.. As made clear in the draft= persisting IPV4 AF may not be desirable. Although I have not really looked= at it as a use case I have gotten notes describing how it BGP Persistence = could be applied. -shane > That is a significant change which goes across anyone's single AS who wis= hes to use this technique. >=20 > Few more questions: >=20 > Did authors of the draft reached clear consensus that persistance does no= t override treat-as-withdraw error handling ? That means that regardless of= persistance enabled or not withdraws will still be send out for the eligib= le prefixes in the malformed update ? >=20 > What happens when router get's fatal malformed attributes or update messa= ges which still trigger session down ? Would persistance apply or not ? >=20 > In general a bit depending on the answers above what are triggers for ses= sion down then when persistance applies ? >=20 > Thx, > R. >=20 >=20 >> Shane, >>=20 >> On Jun 19, 2012, at 1:34 AM, Shane Amante wrote: >>=20 >>> If I'm reading this correctly, this draft states that the >>> DO_NOT_PERSIST community "SHOULD" be disabled by default, which >>> means that (by default) all routes will be set to "persist". >>=20 >> I think this should be understood in the context of "... IF you have >> enabled the feature in your network." [*] I.e., if you haven't chosen >> to enable the feature, it would be business as usual, even if your >> peer sent you the DO_NOT_PERSIST or STALE communities. Seems like the >> draft should be revised (probably in S. 3) to make this more clear. >>=20 >> I don't know if that changes your opinion any, but FWIW. >>=20 >> --John >>=20 >> [*] Not an actual quote from the draft. >> _______________________________________________ Idr mailing list >> Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr >>=20 >>=20 >=20 >=20 > _______________________________________________ > 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 From robert@raszuk.net Tue Jun 19 09:39:26 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 939BE21F85C5 for ; Tue, 19 Jun 2012 09:39:26 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l1dwWb8HJiuV for ; Tue, 19 Jun 2012 09:39:26 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id B034E21F8540 for ; Tue, 19 Jun 2012 09:39:25 -0700 (PDT) Received: (qmail 12118 invoked by uid 399); 19 Jun 2012 16:39:25 -0000 Received: from unknown (HELO ?192.168.1.91?) (pbs:m42@mojaklasa.info@83.31.221.130) by mail1310.opentransfer.com with ESMTPM; 19 Jun 2012 16:39:25 -0000 X-Originating-IP: 83.31.221.130 Message-ID: <4FE0AB3C.70703@raszuk.net> Date: Tue, 19 Jun 2012 18:39:24 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: "UTTARO, JAMES" References: <003c01cd4b29$97d7b150$c78713f0$@ndzh.com> <985EF8D2-DA8A-4BE7-94D3-F4BE2B74D768@castlepoint.net> <4FE07A24.7050804@raszuk.net> <1C1F2B2E-2EB7-42F0-8CFF-57965443C074@castlepoint.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 'Shane Amante' , Susan Hares , "idr@ietf.org" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2012 16:39:26 -0000 > [Jim U>] No. The Persist-Timer indicates the length of time that the > paths should persist, after this timer expires the paths are > withdrawn. The question was different. Isn't it the case that if the session which just went down .. comes back in X sec (where X sec is less then your persist timer) you will start re-advertising all best paths again without the STALE community or start withdrawing previously advertised paths if others are best ? What is the mechanism to stop this churn ? r. From robert@raszuk.net Tue Jun 19 09:45:15 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61A3821F860E for ; Tue, 19 Jun 2012 09:45:15 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JDX96B-ysX-f for ; Tue, 19 Jun 2012 09:45:13 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 7CD9821F860B for ; Tue, 19 Jun 2012 09:45:13 -0700 (PDT) Received: (qmail 17313 invoked by uid 399); 19 Jun 2012 16:45:13 -0000 Received: from unknown (HELO ?192.168.1.91?) (pbs:robert@raszuk.net@83.31.221.130) by mail1310.opentransfer.com with ESMTPM; 19 Jun 2012 16:45:13 -0000 X-Originating-IP: 83.31.221.130 Message-ID: <4FE0AC99.8030601@raszuk.net> Date: Tue, 19 Jun 2012 18:45:13 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: "Hashmi, Faisal (Faisal)" References: <8E9515536A871047BDE6B631B17A425E02B8F75870@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> In-Reply-To: <8E9515536A871047BDE6B631B17A425E02B8F75870@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "'idr@ietf.org'" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2012 16:45:15 -0000 Do you think that sending the identical "support" mail every day helps and counts as two ? Looking at the time I guess it's not cron, but must be a calendar reminder set for this week ;) Cheers, R. -------- Original Message -------- Subject: [Idr] draft-uttaro-idr-bgp-persistence-01 Date: Mon, 18 Jun 2012 11:24:34 -0500 From: Hashmi, Faisal (Faisal) To: 'idr@ietf.org' -------- Original Message -------- Subject: [Idr] draft-uttaro-idr-bgp-persistence-01 Date: Tue, 19 Jun 2012 11:21:10 -0500 From: Hashmi, Faisal (Faisal) To: 'idr@ietf.org' > [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document > I support this draft. > Thanks > Faisal Hashmi > Senior Systems Engineer > Alcatel-Lucent > 832 520 4052 > CCIE Service Provider. CCIE#19248 > Project Management Professional (PMP) > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > From Faisal.Hashmi@alcatel-lucent.com Tue Jun 19 09:55:11 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13FCC21F8552 for ; Tue, 19 Jun 2012 09:55:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.742 X-Spam-Level: X-Spam-Status: No, score=-7.742 tagged_above=-999 required=5 tests=[AWL=-1.143, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q--3DbbTht+t for ; Tue, 19 Jun 2012 09:55:10 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 3C5D921F854E for ; Tue, 19 Jun 2012 09:55:10 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id q5JGt3CG009295 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 19 Jun 2012 11:55:03 -0500 (CDT) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q5JGt3cE001705 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 19 Jun 2012 11:55:03 -0500 Received: from USNAVSXCHMBSC3.ndc.alcatel-lucent.com ([135.3.39.144]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Tue, 19 Jun 2012 11:55:03 -0500 From: "Hashmi, Faisal (Faisal)" To: "robert@raszuk.net" Date: Tue, 19 Jun 2012 11:54:57 -0500 Thread-Topic: [Idr] draft-uttaro-idr-bgp-persistence-01 Thread-Index: Ac1OPETpWXzRA8DJRDi2PjF6sYqlVg== Message-ID: <06BB6DC8-AD82-4019-9772-7F941BF6CD9F@alcatel-lucent.com> References: <8E9515536A871047BDE6B631B17A425E02B8F75870@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> <4FE0AC99.8030601@raszuk.net> In-Reply-To: <4FE0AC99.8030601@raszuk.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Cc: "idr@ietf.org" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2012 16:55:11 -0000 No, I thought my first one did not go through as I got a message back from = bounce server. Today I got conformation that my subscription is confirmed s= o I resent it again. Sorry for the confusion just put it on the column of t= echnical glitch . Faisal Sent from my iPhone On Jun 19, 2012, at 11:45 AM, "Robert Raszuk" wrote: >=20 > Do you think that sending the identical "support" mail every day helps=20 > and counts as two ? >=20 > Looking at the time I guess it's not cron, but must be a calendar=20 > reminder set for this week ;) >=20 > Cheers, > R. >=20 > -------- Original Message -------- > Subject: [Idr] draft-uttaro-idr-bgp-persistence-01 > Date: Mon, 18 Jun 2012 11:24:34 -0500 > From: Hashmi, Faisal (Faisal) > To: 'idr@ietf.org' >=20 > -------- Original Message -------- > Subject: [Idr] draft-uttaro-idr-bgp-persistence-01 > Date: Tue, 19 Jun 2012 11:21:10 -0500 > From: Hashmi, Faisal (Faisal) > To: 'idr@ietf.org' >=20 >=20 >> [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document >> I support this draft. >> Thanks >> Faisal Hashmi >> Senior Systems Engineer >> Alcatel-Lucent >> 832 520 4052 >> CCIE Service Provider. CCIE#19248 >> Project Management Professional (PMP) >>=20 >>=20 >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr >>=20 >=20 >=20 From shane@castlepoint.net Tue Jun 19 10:11:28 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1540111E80DE for ; Tue, 19 Jun 2012 10:11:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_41=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2aIbLa1H-mVh for ; Tue, 19 Jun 2012 10:11:27 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id 87B9311E80D7 for ; Tue, 19 Jun 2012 10:11:27 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id 2DD3F368199; Tue, 19 Jun 2012 11:11:27 -0600 (MDT) Received: from host2.tcb.net (64.78.235.218 [64.78.235.218]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Tue, 19 Jun 2012 11:11:27 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=64.78.235.218; client-port=61589; data-bytes=0 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Shane Amante In-Reply-To: Date: Tue, 19 Jun 2012 11:11:26 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <61E20EE1-F204-41CB-A50B-F005661C5ADD@castlepoint.net> References: <20120618161803.11671.64167.idtracker@ietfa.amsl.com> To: Paul WALL X-Mailer: Apple Mail (2.1278) Cc: idr@ietf.org Subject: Re: [Idr] I-D Action: draft-ietf-idr-rfd-usable-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2012 17:11:28 -0000 On Jun 19, 2012, at 2:50 AM, Paul WALL wrote: > On 6/18/12, Saku Ytti wrote: >> I would love to see optional local-pref based penalty instead of >> suppression. >=20 > +1 IMO, suppress is nice, particularly when you've got to deal with legacy = platforms w/out a lot of CPU, and no (short-term) plans to upgrade. = Unfortunately, LP will mean addt'l churn in the AS as LP is adjusted = upward/downward as the penalty increases and decreases. In addition, = given the number of "applications" that LP is currently being used for, = (e.g.: BGP Traffic Engineering), and _planned_ to be used for, (e.g.: = SIDR origin and path validation, BGP persistence, etc.), I wonder if = such manipulation of LP is even practical wrt RFD? Instead, what about = MED-based penalty -- at least to mitigate this latter concern? Regardless, I can see the utility of LP or MED-based penalty and as long = as it's just an optional knob to be enabled, then I wouldn't mind seeing = it included in a future rev of the draft, for those that wish to = [explicitly] enable it. -shane= From bruno.decraene@orange.com Tue Jun 19 10:23:48 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A2C811E80F7 for ; Tue, 19 Jun 2012 10:23:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FkoroU0qN7yx for ; Tue, 19 Jun 2012 10:23:47 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 651DE11E80F3 for ; Tue, 19 Jun 2012 10:23:46 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 2778E22C5DB; Tue, 19 Jun 2012 19:23:45 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 0600C35C048; Tue, 19 Jun 2012 19:23:45 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Tue, 19 Jun 2012 19:23:44 +0200 From: To: "robert@raszuk.net" Thread-Topic: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks Thread-Index: AQHNThzakzFtDweGF06QjEz6Tygl8ZcBn+KA Date: Tue, 19 Jun 2012 17:23:43 +0000 Message-ID: <12932_1340126625_4FE0B5A1_12932_2820_1_53C29892C857584299CBF5D05346208A0925DF@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <003c01cd4b29$97d7b150$c78713f0$@ndzh.com> <985EF8D2-DA8A-4BE7-94D3-F4BE2B74D768@castlepoint.net> <4FE07A24.7050804@raszuk.net> In-Reply-To: <4FE07A24.7050804@raszuk.net> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.6.19.115414 Cc: Shane Amante , Susan Hares , "idr@ietf.org" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2012 17:23:48 -0000 Hi Robert, >From: Robert Raszuk >Sent: Tuesday, June 19, 2012 3:10 PM [...] >Today there is no persistence in BGP. At most for the GR timer which is >relatively short. GR timer is specified to be up to an hour. I would not call this "short", e= specially with regards to current users' expectations on the network (e.g. = 50ms FRR, sub-second convergence) And that's just the timer for session re-establishment. Then you have to wa= it for all routes to be learnt on all sessions and then perform best path s= election on all routes, before being able to flush the invalid GR stale rou= tes. Really, if you can handle GR stale routes -which are still preferred and us= ed- for one hour, I'd say you can handle persistence stale routes -which ar= e de-prefered and hence not used if a backup exist- for one hour. Bottom line, I think the argument: "GR is fine, Persistence is bad" is a bi= t short. >Tomorrow when anyone in the co-participating set of domains for a given >SAFI enables persistance I will be getting prefixes marked as STALE and >those which are not. That means I can not any longer ignore this marker. >I must at all of my ingress ASBRs either drop all updates with STALE >community or lower local pref to make sure those would be only used as >last resort within my AS. That's technically inaccurate. And we have already discussed this. In short inter-domain persistence and hence the use of the STALE marker is = only between ASes which have agreed on using this marker. If you don't beli= eve ISP can achieve such BGP inter domain route filtering, this could proba= bly be automated (e.g. If I have not received a BGP "Persistence" capabilit= y from my eBGP peer, then I don't send him STALE routes (i.e. there are wit= hdrawn). IMO, that's a technical detail which can be worked on. >If I fail to do that I will mix live reachability with flaky one and may >by normal best path rules prefer the flaky ones for days, weeks or >months. Worse is that we will have a mix of both in the >non-participating in the game ASes which will be true nightmare to >troubleshoot it. > >That is a significant change which goes across anyone's single AS who >wishes to use this technique. > >Few more questions: > >Did authors of the draft reached clear consensus that persistance does >not override treat-as-withdraw error handling ? That means that >regardless of persistance enabled or not withdraws will still be send >out for the eligible prefixes in the malformed update ? As for myself, "yes" for your last question. >What happens when router get's fatal malformed attributes or update >messages which still trigger session down ? Would persistance apply or not= ? IMHO, if BGP session goes down, persistence could apply on the previously r= eceived valid route (and again, if GR is used in addition of persistence, G= R applies first hence GR already keep the routes as per draft-ietf-idr-bgp-= gr-notification-00) >In general a bit depending on the answers above what are triggers for >session down then when persistance applies ? > > > >Thx, >R. > > >> Shane, >> >> On Jun 19, 2012, at 1:34 AM, Shane Amante wrote: >> >>> If I'm reading this correctly, this draft states that the >>> DO_NOT_PERSIST community "SHOULD" be disabled by default, which >>> means that (by default) all routes will be set to "persist". >> >> I think this should be understood in the context of "... IF you have >> enabled the feature in your network." [*] I.e., if you haven't chosen >> to enable the feature, it would be business as usual, even if your >> peer sent you the DO_NOT_PERSIST or STALE communities. Seems like the >> draft should be revised (probably in S. 3) to make this more clear. >> >> I don't know if that changes your opinion any, but FWIW. >> >> --John >> >> [*] Not an actual quote from the draft. >> _______________________________________________ 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 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From bruno.decraene@orange.com Tue Jun 19 10:23:48 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFBB011E80F3 for ; Tue, 19 Jun 2012 10:23:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bm+TmRMZxpPR for ; Tue, 19 Jun 2012 10:23:48 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id B00B611E80F5 for ; Tue, 19 Jun 2012 10:23:47 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 16D443241F3; Tue, 19 Jun 2012 19:23:47 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id EC4E2238056; Tue, 19 Jun 2012 19:23:46 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Tue, 19 Jun 2012 19:23:46 +0200 From: To: "robert@raszuk.net" Thread-Topic: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks Thread-Index: AQHNTjoan8YtkMHItUeM5m74hAbL4pcB23cg Date: Tue, 19 Jun 2012 17:23:45 +0000 Message-ID: <10878_1340126627_4FE0B5A2_10878_4315_1_53C29892C857584299CBF5D05346208A0925E6@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <003c01cd4b29$97d7b150$c78713f0$@ndzh.com> <985EF8D2-DA8A-4BE7-94D3-F4BE2B74D768@castlepoint.net> <4FE07A24.7050804@raszuk.net> <1C1F2B2E-2EB7-42F0-8CFF-57965443C074@castlepoint.net> <4FE0AB3C.70703@raszuk.net> In-Reply-To: <4FE0AB3C.70703@raszuk.net> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.6.19.115414 Cc: 'Shane Amante' , "UTTARO, JAMES" , Susan Hares , "idr@ietf.org" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2012 17:23:49 -0000 Robert, >From: Robert >Raszuk >Sent: Tuesday, June 19, 2012 6:39 PM > > >> [Jim U>] No. The Persist-Timer indicates the length of time that the >> paths should persist, after this timer expires the paths are >> withdrawn. > >The question was different. Isn't it the case that if the session which >just went down .. comes back in X sec (where X sec is less then your >persist timer) you will start re-advertising all best paths again >without the STALE community or start withdrawing previously advertised >paths if others are best ? "Persistence" or "no persistence" does not fundamentally change the churn a= t the NLRI level. With persistence, NLRI are re-advertised with different path attribute. Without persistence, NLRI are withdrawn. In both cases, there are updated and re-advertised. Agreed, at the BGP update message level, churn is different, depending on N= LRI packing. Is this what you meant? >What is the mechanism to stop this churn ? GR could help. Provided that you have sufficient faith in the validity of t= he routes to choose to hide and not propagate the error condition. And you can use it with or without persistence. In the GR vs persistence discussion, there is clearly a trade-off between r= e-advertising the updated route status -which create churn- and not re-adve= rtising it -which will create loss of connectivity if your (more or less) b= lind assumption turn to be wrong. I'm fine if you prefer the no churn/GR option. But I have trouble understan= ding why you refuse to consider that others may favor the other option. Whi= ch BTW is more accurate from a routing correctness perspective. PS: I feel that both of us are looping on this churn point again and again. >r. >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www.ietf.org/mailman/listinfo/idr ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From bruno.decraene@orange.com Tue Jun 19 10:33:21 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D87511E810E for ; Tue, 19 Jun 2012 10:33:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ZC65RXQzRjg for ; Tue, 19 Jun 2012 10:33:20 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 1820311E8107 for ; Tue, 19 Jun 2012 10:33:20 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id F1FBE3B44E2; Tue, 19 Jun 2012 19:33:18 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id D64224C015; Tue, 19 Jun 2012 19:33:18 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Tue, 19 Jun 2012 19:33:18 +0200 From: To: "robert@raszuk.net" Thread-Topic: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks Thread-Index: AQHNTh7qkzFtDweGF06QjEz6Tygl8ZcB5IsQ Date: Tue, 19 Jun 2012 17:33:18 +0000 Message-ID: <30501_1340127198_4FE0B7DE_30501_11925_1_53C29892C857584299CBF5D05346208A092626@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <003c01cd4b29$97d7b150$c78713f0$@ndzh.com> <985EF8D2-DA8A-4BE7-94D3-F4BE2B74D768@castlepoint.net> <4FE07A24.7050804@raszuk.net> <4FE07DA8.8050404@raszuk.net> In-Reply-To: <4FE07DA8.8050404@raszuk.net> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.6.19.115414 Cc: "idr@ietf.org" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2012 17:33:21 -0000 Robert, >From: Robert Raszuk >Sent: Tuesday, June 19, 2012 3:25 PM > > >Btw ... "business as usual" today on EBGP boundary means to clean all >communities other then those I do not expect. That means that middle AS >will drop all STALE/DO_NOT_PERSIST markers and no one will have a way to >distinguished which prefixes are solid and which are questionable. For any AS (adjacent, middle...) on the eBGP propagation path: - either I agreed to use the STALE marker (hence it "expects" the community) - or the previous BGP speaker will not advertise me the STALE path. You example does not work. >One of the authors proposed to add BGP capability to solve this as well >as legacy ASBR case. Note that for this capability to be effective in >mixed legacy+upgraded networks it would need to be both for IBGP and EBGP. I'm not sure to see what you mean. On iBGP (hence within the AS), you can assume that the AS can guaranty a co= nsistent behavior. E.g. local_pref are used to lower the preference & on eB= GP sessions which have not agreed to use STALE, a BGP policy filter out the= route with the STALE community. So there is no issue with legacy. >Is that the direction this draft is going to take ? > >Thx, >R. > > >> Hi John, >> >> You are right reg the "enabling knob part" I send Shane the same comment >> few hours back offline ;). >> >> But I would not agree with this comment: >> >> > I.e., if you haven't chosen >> > to enable the feature, it would be business as usual, even if your >> > peer sent you the DO_NOT_PERSIST or STALE communities. >> >> Today there is no persistence in BGP. At most for the GR timer which is >> relatively short. >> >> Tomorrow when anyone in the co-participating set of domains for a given >> SAFI enables persistance I will be getting prefixes marked as STALE and >> those which are not. That means I can not any longer ignore this marker. >> I must at all of my ingress ASBRs either drop all updates with STALE >> community or lower local pref to make sure those would be only used as >> last resort within my AS. >> >> If I fail to do that I will mix live reachability with flaky one and may >> by normal best path rules prefer the flaky ones for days, weeks or >> months. Worse is that we will have a mix of both in the >> non-participating in the game ASes which will be true nightmare to >> troubleshoot it. >> >> That is a significant change which goes across anyone's single AS who >> wishes to use this technique. >> >> Few more questions: >> >> Did authors of the draft reached clear consensus that persistance does >> not override treat-as-withdraw error handling ? That means that >> regardless of persistance enabled or not withdraws will still be send >> out for the eligible prefixes in the malformed update ? >> >> What happens when router get's fatal malformed attributes or update >> messages which still trigger session down ? Would persistance apply or >> not ? >> >> In general a bit depending on the answers above what are triggers for >> session down then when persistance applies ? >> >> Thx, >> R. >> >> >>> Shane, >>> >>> On Jun 19, 2012, at 1:34 AM, Shane Amante wrote: >>> >>>> If I'm reading this correctly, this draft states that the >>>> DO_NOT_PERSIST community "SHOULD" be disabled by default, which >>>> means that (by default) all routes will be set to "persist". >>> >>> I think this should be understood in the context of "... IF you have >>> enabled the feature in your network." [*] I.e., if you haven't chosen >>> to enable the feature, it would be business as usual, even if your >>> peer sent you the DO_NOT_PERSIST or STALE communities. Seems like the >>> draft should be revised (probably in S. 3) to make this more clear. >>> >>> I don't know if that changes your opinion any, but FWIW. >>> >>> --John >>> >>> [*] Not an actual quote from the draft. >>> _______________________________________________ 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 >> >> > > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www.ietf.org/mailman/listinfo/idr ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From jgs@juniper.net Tue Jun 19 11:34:06 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B94E221F860E for ; Tue, 19 Jun 2012 11:34:06 -0700 (PDT) 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.292, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6IXHpEd0cwjZ for ; Tue, 19 Jun 2012 11:34:06 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id 877D121F8606 for ; Tue, 19 Jun 2012 11:34:04 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKT+DGG/qhiG1TwxS750PdD58WoOvGkZq5@postini.com; Tue, 19 Jun 2012 11:34:05 PDT Received: from [172.16.13.202] (172.16.13.202) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server id 8.3.213.0; Tue, 19 Jun 2012 11:32:49 -0700 MIME-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset="us-ascii" From: "John G. Scudder" In-Reply-To: <1C1F2B2E-2EB7-42F0-8CFF-57965443C074@castlepoint.net> Date: Tue, 19 Jun 2012 14:32:47 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <7A614998-8FB1-4A51-9937-DE501FF31EB6@juniper.net> References: <003c01cd4b29$97d7b150$c78713f0$@ndzh.com> <985EF8D2-DA8A-4BE7-94D3-F4BE2B74D768@castlepoint.net> <4FE07A24.7050804@raszuk.net> <1C1F2B2E-2EB7-42F0-8CFF-57965443C074@castlepoint.net> To: Shane Amante X-Mailer: Apple Mail (2.1278) Cc: "idr@ietf.org" , Susan Hares , "robert@raszuk.net" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2012 18:34:06 -0000 On Jun 19, 2012, at 11:29 AM, Shane Amante wrote: > I also have similar concerns with this draft. In particular, is there = an assumption in here that BGP sessions that are "failed" expected to be = held down for the same period of time as the "persist" timer(s)? =20 I don't think so. > Otherwise, wouldn't the BGP sessions automatically try to come back = up, indefinitely, leading to more churn of adding/removing the STALE = community toward other neighbors each time the "bad" implementation = receives a malformed attribute and causes a session to fail? Waiting for EoR before running best path and advertising routes should = prevent this, though there is scope for excessive local CPU consumption = if you get into a lather-rinse-repeat cycle. One way to address this = would be to hold down flapping sessions, as the base spec already = recommends. The worst pathology would occur if for some reason you had a = session that came up, fully converged, *then* went down shortly after = that, and then repeated that cycle. It seems fairly unlikely but of = course, the universe is large and weird things can and do happen. The draft is light on discussion of what to do in a flapping situation, = this would need to be fixed. Equally, it's light on discussion of = whether all session resets should result in persistence, or only certain = classes of reset.=20 > In some ways, that seems to be making the problem worse in that = sessions that may otherwise be providing redundancy are now held down = for some lengthy period of time, which the NOC may not be as aware of. = Although the draft tries to cover-off the latter issue by checking for = availability to the NEXT_HOP on routes advertised as STALE, that seems = to be fighting a symptom of the problem caused by this draft and not = addressing the real, underlying root cause IMHO. >=20 > In summary, I'd much rather see a more general-purpose solution To what problem? I think a big part of the disagreement so far is that = folks are not in agreement as to whether the problem statement is worth = addressing. The problem statement is kind of buried in S. 1.1: BGP Persistence targets the different use case of a catastrophic failure when the BGP control plane can remain down for a longer time (e.g. hours). It may be valuable to refocus the discussion on whether folks do, or = don't, think the problem statement is worth addressing at all. (I've = also pinged GROW on this since they are WGLC'ing = draft-ietf-grow-ops-reqs-for-bgp-error-handling-04 right now, and you = would think that this topic falls under the heading of "Operational = Requirements for Enhanced Error Handling Behaviour in BGP-4".) > be developed that is applicable to _ALL_ address families, because = that way all services can benefit from it, Ops folks only need to = learn/train on one technique/mechanism (regardless of service type), it = makes it more straightforward for the IDR WG to enhance/extend BGP down = the road w/out (too much) consideration of address-family specific = behaviors, etc. I couldn't agree more that all things being equal, orthogonal and = general solutions are to be preferred.=20 --John From robert@raszuk.net Tue Jun 19 11:40:12 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C2EF11E8131 for ; Tue, 19 Jun 2012 11:40:12 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tdRJ5xfyqac9 for ; Tue, 19 Jun 2012 11:40:11 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id EFA5D11E80DB for ; Tue, 19 Jun 2012 11:40:10 -0700 (PDT) Received: (qmail 22159 invoked by uid 399); 19 Jun 2012 18:40:10 -0000 Received: from unknown (HELO ?192.168.1.58?) (pbs:robert@raszuk.net@83.9.122.251) by mail1310.opentransfer.com with ESMTPM; 19 Jun 2012 18:40:10 -0000 X-Originating-IP: 83.9.122.251 Message-ID: <4FE0C78A.9090606@raszuk.net> Date: Tue, 19 Jun 2012 20:40:10 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: bruno.decraene@orange.com References: <003c01cd4b29$97d7b150$c78713f0$@ndzh.com> <985EF8D2-DA8A-4BE7-94D3-F4BE2B74D768@castlepoint.net> <4FE07A24.7050804@raszuk.net> <4FE07DA8.8050404@raszuk.net> <30501_1340127198_4FE0B7DE_30501_11925_1_53C29892C857584299CBF5D05346208A092626@PEXCVZYM11.corporate.adroot.infra.ftgroup> In-Reply-To: <30501_1340127198_4FE0B7DE_30501_11925_1_53C29892C857584299CBF5D05346208A092626@PEXCVZYM11.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2012 18:40:12 -0000 Hi Bruno, >> Btw ... "business as usual" today on EBGP boundary means to clean >> all communities other then those I do not expect. That means that >> middle AS will drop all STALE/DO_NOT_PERSIST markers and no one >> will have a way to distinguished which prefixes are solid and which >> are questionable. > > For any AS (adjacent, middle...) on the eBGP propagation path: - > either I agreed to use the STALE marker (hence it "expects" the > community) - or the previous BGP speaker will not advertise me the > STALE path. > > You example does not work. We are discussing current draft not it's future revisions. In the current draft there is no EBGP capabilities defined ... my example applies fully. >> One of the authors proposed to add BGP capability to solve this as >> well as legacy ASBR case. Note that for this capability to be >> effective in mixed legacy+upgraded networks it would need to be >> both for IBGP and EBGP. > > I'm not sure to see what you mean. On iBGP (hence within the AS), you > can assume that the AS can guaranty a consistent behavior. E.g. > local_pref are used to lower the preference & on eBGP sessions which > have not agreed to use STALE, a BGP policy filter out the route with > the STALE community. So there is no issue with legacy. Of course there is. As I have provided the description in the former email persistence relies on End-of-RIB to sync it's state when the session comes back up. Without IBGP capability you have no way of indicating that to your peer. -- Bottom line: Adding BGP capability negotiation and defining it's format to overlap or not overlap with GR is not a "minor detail". It fundamentally changing the operational model of the proposal. For me personally this is like supporting the draft or maybe better said: "not being against it" or not. Best, R. From enkechen@cisco.com Tue Jun 19 12:23:14 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A03A911E815B for ; Tue, 19 Jun 2012 12:23:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JZyJQWwBA7t4 for ; Tue, 19 Jun 2012 12:23:14 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 0A39E11E814A for ; Tue, 19 Jun 2012 12:23:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=enkechen@cisco.com; l=1398; q=dns/txt; s=iport; t=1340133794; x=1341343394; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=TjwxBydncFp4pie+sbz+N7iM4mYvN1QQKE6GNZ577HQ=; b=DEhXq7/xd4guII5J18O5fni+R1mIWuSvX/lDsV2X9Sil/aFoPXgTEkJF iNBg1MMNE6Go6usGYJ3bB8HKKhJ2/IjtIuSFL9dy9WJj85nr3TYopD0GA jGfreUH1/TMavMQYgM+p6ohxyz2Dd82redqqAWL2qQRYQYAUh58aOhXt1 0=; X-IronPort-AV: E=Sophos;i="4.75,799,1330905600"; d="scan'208";a="46954535" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 19 Jun 2012 19:23:14 +0000 Received: from dhcp-171-71-139-24.cisco.com (dhcp-171-71-139-24.cisco.com [171.71.139.24]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q5JJNDqi024057; Tue, 19 Jun 2012 19:23:13 GMT Message-ID: <4FE0D1F4.9070208@cisco.com> Date: Tue, 19 Jun 2012 12:24:36 -0700 From: Enke Chen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: "John G. Scudder" References: <003c01cd4b29$97d7b150$c78713f0$@ndzh.com> <985EF8D2-DA8A-4BE7-94D3-F4BE2B74D768@castlepoint.net> <4FE07A24.7050804@raszuk.net> <1C1F2B2E-2EB7-42F0-8CFF-57965443C074@castlepoint.net> <7A614998-8FB1-4A51-9937-DE501FF31EB6@juniper.net> In-Reply-To: <7A614998-8FB1-4A51-9937-DE501FF31EB6@juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Shane Amante , "robert@raszuk.net" , Susan Hares , "idr@ietf.org" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2012 19:23:14 -0000 Hi, John: Thanks for pointing out the importance of the "problem statement" in this discussion. Yes, this topic does fall into the category of error/fault recovery, and we will need to evaluate and strike the balance between simplicity vs complexity, and common cases vs rare cases, etc al. IMO the complete failure of the redundant control plane falls into the category of "rare cases". They should be addressed from the "root cause" instead of building more bandages and complexities both operationally and in the software. -- Enke On 6/19/12 11:32 AM, John G. Scudder wrote: [snip] > To what problem? I think a big part of the disagreement so far is that folks are not in agreement as to whether the problem statement is worth addressing. The problem statement is kind of buried in S. 1.1: > > BGP Persistence targets the different use case of a catastrophic > failure when the BGP control plane can remain down for a longer time > (e.g. hours). > > It may be valuable to refocus the discussion on whether folks do, or don't, think the problem statement is worth addressing at all. (I've also pinged GROW on this since they are WGLC'ing draft-ietf-grow-ops-reqs-for-bgp-error-handling-04 right now, and you would think that this topic falls under the heading of "Operational Requirements for Enhanced Error Handling Behaviour in BGP-4".) > > From shane@castlepoint.net Tue Jun 19 12:28:41 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D36611E8163 for ; Tue, 19 Jun 2012 12:28:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hVpKmMfRYC8b for ; Tue, 19 Jun 2012 12:28:41 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id 0E26711E8161 for ; Tue, 19 Jun 2012 12:28:41 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id 3DCE6368199; Tue, 19 Jun 2012 13:28:40 -0600 (MDT) Received: from host2.tcb.net (64.78.235.218 [64.78.235.218]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Tue, 19 Jun 2012 13:28:40 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=64.78.235.218; client-port=62853; data-bytes=0 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Shane Amante In-Reply-To: <4FE0D1F4.9070208@cisco.com> Date: Tue, 19 Jun 2012 13:28:38 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <003c01cd4b29$97d7b150$c78713f0$@ndzh.com> <985EF8D2-DA8A-4BE7-94D3-F4BE2B74D768@castlepoint.net> <4FE07A24.7050804@raszuk.net> <1C1F2B2E-2EB7-42F0-8CFF-57965443C074@castlepoint.net> <7A614998-8FB1-4A51-9937-DE501FF31EB6@juniper.net> <4FE0D1F4.9070208@cisco.com> To: Enke Chen X-Mailer: Apple Mail (2.1278) Cc: Susan Hares , "robert@raszuk.net" , "idr@ietf.org" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2012 19:28:41 -0000 Hi John, Enke, On Jun 19, 2012, at 1:24 PM, Enke Chen wrote: > Hi, John: >=20 > Thanks for pointing out the importance of the "problem statement" in = this discussion. Yes, this topic does fall into the category of = error/fault recovery, and we will need to evaluate and strike the = balance between simplicity vs complexity, and common cases vs rare = cases, etc al. >=20 > IMO the complete failure of the redundant control plane falls into the = category of "rare cases". They should be addressed from the "root = cause" instead of building more bandages and complexities both = operationally and in the software. I completely agree with Enke. -shane > -- Enke >=20 > On 6/19/12 11:32 AM, John G. Scudder wrote: >=20 > [snip] >> To what problem? I think a big part of the disagreement so far is = that folks are not in agreement as to whether the problem statement is = worth addressing. The problem statement is kind of buried in S. 1.1: >>=20 >> BGP Persistence targets the different use case of a catastrophic >> failure when the BGP control plane can remain down for a longer = time >> (e.g. hours). >>=20 >> It may be valuable to refocus the discussion on whether folks do, or = don't, think the problem statement is worth addressing at all. (I've = also pinged GROW on this since they are WGLC'ing = draft-ietf-grow-ops-reqs-for-bgp-error-handling-04 right now, and you = would think that this topic falls under the heading of "Operational = Requirements for Enhanced Error Handling Behaviour in BGP-4".) >>=20 >>=20 >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From Donald.Smith@CenturyLink.com Tue Jun 19 12:52:37 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17A2211E8134 for ; Tue, 19 Jun 2012 12:52:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AqOBtMADTSJn for ; Tue, 19 Jun 2012 12:52:36 -0700 (PDT) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by ietfa.amsl.com (Postfix) with ESMTP id 53E2311E8125 for ; Tue, 19 Jun 2012 12:52:36 -0700 (PDT) Received: from lxdenvmpc030.qintra.com (lxdenvmpc030.qintra.com [10.1.51.30]) by sudnp799.qwest.com (8.14.4/8.14.4) with ESMTP id q5JJqZue019342 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 19 Jun 2012 13:52:35 -0600 (MDT) Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 16A311E0081 for ; Tue, 19 Jun 2012 13:52:30 -0600 (MDT) Received: from suomp61i.qintra.com (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id 02EE81E0083 for ; Tue, 19 Jun 2012 13:52:29 -0600 (MDT) Received: from suomp61i.qintra.com (localhost [127.0.0.1]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id q5JJqTTC000060 for ; Tue, 19 Jun 2012 14:52:29 -0500 (CDT) Received: from qtdenexhtm22.AD.QINTRA.COM (qtdenexhtm22.ad.qintra.com [151.119.91.231]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id q5JJqTQt000054 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL) for ; Tue, 19 Jun 2012 14:52:29 -0500 (CDT) Received: from qtdenexmbm24.AD.QINTRA.COM ([151.119.91.226]) by qtdenexhtm22.AD.QINTRA.COM ([151.119.91.231]) with mapi; Tue, 19 Jun 2012 13:52:29 -0600 From: "Smith, Donald" To: "'idr@ietf.org'" Date: Tue, 19 Jun 2012 13:52:27 -0600 Thread-Topic: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks Thread-Index: Ac1OHvMqOvmba5YBR4aYuJPJ3iMQ+gANQGRA Message-ID: References: <003c01cd4b29$97d7b150$c78713f0$@ndzh.com> <985EF8D2-DA8A-4BE7-94D3-F4BE2B74D768@castlepoint.net> <4FE07A24.7050804@raszuk.net> <4FE07DA8.8050404@raszuk.net> In-Reply-To: <4FE07DA8.8050404@raszuk.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2012 19:52:37 -0000 Why isn't this: 2.1. DO_NOT_PERSIST This memo defines a new BGP community, DO_NOT_PERSIST, with value TBD (to be assigned by IANA). Attaching of the DO_NOT_PERSIST community SHOULD be controlled by configuration. The functionality SHOULD default to being disabled. This: 2.1. PERSIST This memo defines a new BGP community, PERSIST, with value TBD (to be assigned by IANA). Attaching of the PERSIST community SHOULD be controlled by configuration. The functionality SHOULD default to being disabled. I don't think persist should be the default and dislike negative variables = (do_not_....) as it makes following the logic a bit more difficult. When packets collide the controllers cease transmission AND wait a random t= ime before retransmission (mostly)! Donald.Smith@CenturyLink.com This communication is the property of CenturyLink and may contain confident= ial or privileged information. Unauthorized use of this communication is st= rictly 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 ju1738@att.com Tue Jun 19 12:53:21 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6680011E815D for ; Tue, 19 Jun 2012 12:53:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LpgI2Jy+wY7l for ; Tue, 19 Jun 2012 12:53:20 -0700 (PDT) Received: from nbfkord-smmo08.seg.att.com (nbfkord-smmo08.seg.att.com [209.65.160.95]) by ietfa.amsl.com (Postfix) with ESMTP id A41CC11E8176 for ; Tue, 19 Jun 2012 12:53:18 -0700 (PDT) Received: from unknown [144.160.128.153] (EHLO nbfkord-smmo08.seg.att.com) by nbfkord-smmo08.seg.att.com(mxl_mta-6.11.0-10) with ESMTP id ea8d0ef4.2aaaca409940.2467603.00-573.6779713.nbfkord-smmo08.seg.att.com (envelope-from ); Tue, 19 Jun 2012 19:53:18 +0000 (UTC) X-MXL-Hash: 4fe0d8ae2cb88dca-6b5c2175edaace865982ffd26d827161b7c42c7f Received: from unknown [144.160.128.153] (EHLO flpi408.enaf.ffdc.sbc.com) by nbfkord-smmo08.seg.att.com(mxl_mta-6.11.0-10) over TLS secured channel with ESMTP id f88d0ef4.0.2467333.00-287.6778946.nbfkord-smmo08.seg.att.com (envelope-from ); Tue, 19 Jun 2012 19:53:02 +0000 (UTC) X-MXL-Hash: 4fe0d89e69b94e30-b241cfad2fea4c2cb09163919ac4d8c8cf3f2eb9 Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q5JJqjZO008765; Tue, 19 Jun 2012 12:52:47 -0700 Received: from fflint04.pst.cso.att.com (fflint04.pst.cso.att.com [150.234.39.64]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q5JJqWbJ008452 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Jun 2012 12:52:36 -0700 Received: from MISOUT7MSGHUB9E.ITServices.sbc.com (misout7msghub9e.itservices.sbc.com [144.151.223.61]) by fflint04.pst.cso.att.com (RSA Interceptor); Tue, 19 Jun 2012 12:52:21 -0700 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9E.ITServices.sbc.com ([144.151.223.61]) with mapi id 14.01.0355.002; Tue, 19 Jun 2012 15:52:20 -0400 From: "UTTARO, JAMES" To: "'Shane Amante'" , Enke Chen Thread-Topic: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks Thread-Index: AQHNTlHBytD8TdIhN0mhSLyl+cMJGZcCCWjw Date: Tue, 19 Jun 2012 19:52:19 +0000 Message-ID: References: <003c01cd4b29$97d7b150$c78713f0$@ndzh.com> <985EF8D2-DA8A-4BE7-94D3-F4BE2B74D768@castlepoint.net> <4FE07A24.7050804@raszuk.net> <1C1F2B2E-2EB7-42F0-8CFF-57965443C074@castlepoint.net> <7A614998-8FB1-4A51-9937-DE501FF31EB6@juniper.net> <4FE0D1F4.9070208@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.224.208] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.128.153] X-AnalysisOut: [v=1.0 c=1 a=vqnfvzHxCNEA:10 a=ZQD3OTTxKqYA:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=xwOvzTHDVLE4u4] X-AnalysisOut: [nGvK72ag==:17 a=48vgC7mUAAAA:8 a=2clOPd4PAAAA:8 a=c4S5IvFx] X-AnalysisOut: [Na0l1yYRUDQA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=bDUki] X-AnalysisOut: [_mJ7DgA:10] Cc: "idr@ietf.org" , "robert@raszuk.net" , Susan Hares Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2012 19:53:22 -0000 All, This is a real problem with real consequences. It is not as rare as you th= ink and when it occurs it is a total outage. This is simply not acceptable = for a protocol who functionality serves many use cases today. The issue wit= h addressing the "root cause" is that there are many "root causes". I am ti= red of discovering them by seeing the network fail. We can preserve the net= work forwarding state in the face of this type of failure and fix the "root= causes" without a catastrophic outage.. I am concerned that folks simply do not get it.. The network is only releva= nt in that it is there to support customers, it does not exist for any othe= r purpose. It needs to be made as reliable and resilient as possible for al= l BGP use cases.=20 The BGP Persistence draft is a simple straightforward approach to maintaini= ng the network in the face of catastrophic control plane failure. We are no= t dictating it's use, don't use it if you do not want to, but don't state/i= mply/infer etc that this is not a real issue. It is. Jim Uttaro -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Shane= Amante Sent: Tuesday, June 19, 2012 3:29 PM To: Enke Chen Cc: Susan Hares; robert@raszuk.net; idr@ietf.org Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document -= 3 more weeks Hi John, Enke, On Jun 19, 2012, at 1:24 PM, Enke Chen wrote: > Hi, John: >=20 > Thanks for pointing out the importance of the "problem statement" in this= discussion. Yes, this topic does fall into the category of error/fault re= covery, and we will need to evaluate and strike the balance between simplic= ity vs complexity, and common cases vs rare cases, etc al. >=20 > IMO the complete failure of the redundant control plane falls into the ca= tegory of "rare cases". They should be addressed from the "root cause" ins= tead of building more bandages and complexities both operationally and in t= he software. I completely agree with Enke. -shane > -- Enke >=20 > On 6/19/12 11:32 AM, John G. Scudder wrote: >=20 > [snip] >> To what problem? I think a big part of the disagreement so far is that f= olks are not in agreement as to whether the problem statement is worth addr= essing. The problem statement is kind of buried in S. 1.1: >>=20 >> BGP Persistence targets the different use case of a catastrophic >> failure when the BGP control plane can remain down for a longer time >> (e.g. hours). >>=20 >> It may be valuable to refocus the discussion on whether folks do, or don= 't, think the problem statement is worth addressing at all. (I've also ping= ed GROW on this since they are WGLC'ing draft-ietf-grow-ops-reqs-for-bgp-er= ror-handling-04 right now, and you would think that this topic falls under = the heading of "Operational Requirements for Enhanced Error Handling Behavi= our in BGP-4".) >>=20 >>=20 >=20 > _______________________________________________ > 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 From Donald.Smith@CenturyLink.com Tue Jun 19 12:55:57 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D12611E817C for ; Tue, 19 Jun 2012 12:55:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.46 X-Spam-Level: X-Spam-Status: No, score=-1.46 tagged_above=-999 required=5 tests=[AWL=-0.938, BAYES_00=-2.599, SUBJ_ALL_CAPS=2.077] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hUyWudX19M7J for ; Tue, 19 Jun 2012 12:55:57 -0700 (PDT) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by ietfa.amsl.com (Postfix) with ESMTP id C989D11E815D for ; Tue, 19 Jun 2012 12:55:40 -0700 (PDT) Received: from lxdenvmpc030.qintra.com (lxdenvmpc030.qintra.com [10.1.51.30]) by suomp64i.qwest.com (8.14.4/8.14.4) with ESMTP id q5JJtdBM011212 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 19 Jun 2012 14:55:40 -0500 (CDT) Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id B446B1E006C for ; Tue, 19 Jun 2012 13:55:34 -0600 (MDT) Received: from sudnp796.qintra.com (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id 9A0F81E0060 for ; Tue, 19 Jun 2012 13:55:34 -0600 (MDT) Received: from sudnp796.qintra.com (localhost [127.0.0.1]) by sudnp796.qintra.com (8.14.4/8.14.4) with ESMTP id q5JJtYPi026807 for ; Tue, 19 Jun 2012 13:55:34 -0600 (MDT) Received: from qtdenexhtm22.AD.QINTRA.COM (qtdenexhtm22.ad.qintra.com [151.119.91.231]) by sudnp796.qintra.com (8.14.4/8.14.4) with ESMTP id q5JJtYA8026800 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL) for ; Tue, 19 Jun 2012 13:55:34 -0600 (MDT) Received: from qtdenexmbm24.AD.QINTRA.COM ([151.119.91.226]) by qtdenexhtm22.AD.QINTRA.COM ([151.119.91.231]) with mapi; Tue, 19 Jun 2012 13:55:32 -0600 From: "Smith, Donald" To: "'idr@ietf.org'" Date: Tue, 19 Jun 2012 13:55:30 -0600 Thread-Topic: BGP GR FSM Thread-Index: Ac1OHvMqOvmba5YBR4aYuJPJ3iMQ+gANh3YQ Message-ID: References: <003c01cd4b29$97d7b150$c78713f0$@ndzh.com> <985EF8D2-DA8A-4BE7-94D3-F4BE2B74D768@castlepoint.net> <4FE07A24.7050804@raszuk.net> <4FE07DA8.8050404@raszuk.net> In-Reply-To: <4FE07DA8.8050404@raszuk.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [Idr] BGP GR FSM X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2012 19:55:57 -0000 Maybe it is my google fu failing me but several times I have gone looking f= or a drawing of the BGP +GR FSM and haven't found one. I have seen many dra= wings of the BGP FSM but none with GR and its timers. Anyone have one or kn= ow of one? 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." Kevin Oberman RTD Donald.Smith@CenturyLink.com This communication is the property of CenturyLink and may contain confident= ial or privileged information. Unauthorized use of this communication is st= rictly 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 ju1738@att.com Tue Jun 19 13:02:52 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 272E011E8095 for ; Tue, 19 Jun 2012 13:02:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.539 X-Spam-Level: X-Spam-Status: No, score=-106.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H3pv35KNOWG3 for ; Tue, 19 Jun 2012 13:02:51 -0700 (PDT) Received: from nbfkord-smmo04.seg.att.com (nbfkord-smmo04.seg.att.com [209.65.160.86]) by ietfa.amsl.com (Postfix) with ESMTP id 13A0921F859F for ; Tue, 19 Jun 2012 13:02:51 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO nbfkord-smmo04.seg.att.com) by nbfkord-smmo04.seg.att.com(mxl_mta-6.11.0-10) with ESMTP id bead0ef4.2aaaec439940.605093.00-582.1671744.nbfkord-smmo04.seg.att.com (envelope-from ); Tue, 19 Jun 2012 20:02:51 +0000 (UTC) X-MXL-Hash: 4fe0daeb20d243f0-c9a4f11ece8d75c95ef687d72bb1e524443098c4 Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo04.seg.att.com(mxl_mta-6.11.0-10) over TLS secured channel with ESMTP id 8ead0ef4.0.605079.00-437.1671698.nbfkord-smmo04.seg.att.com (envelope-from ); Tue, 19 Jun 2012 20:02:48 +0000 (UTC) X-MXL-Hash: 4fe0dae84de63aab-f99c529e3da35101dc306ecce72b618f72b2edd7 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q5JK2lKv028583; Tue, 19 Jun 2012 16:02:48 -0400 Received: from sflint02.pst.cso.att.com (sflint02.pst.cso.att.com [144.154.234.229]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q5JK2e7t028543 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Jun 2012 16:02:41 -0400 Received: from MISOUT7MSGHUB9D.ITServices.sbc.com (misout7msghub9d.itservices.sbc.com [144.151.223.93]) by sflint02.pst.cso.att.com (RSA Interceptor); Tue, 19 Jun 2012 16:02:23 -0400 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9D.ITServices.sbc.com ([144.151.223.93]) with mapi id 14.01.0355.002; Tue, 19 Jun 2012 16:02:23 -0400 From: "UTTARO, JAMES" To: "'Smith, Donald'" , "'idr@ietf.org'" Thread-Topic: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks Thread-Index: AQHNThzZiPM9d0ETVU2CkZ6FMpu2QZcB5KoAgABsRYD//74yEA== Date: Tue, 19 Jun 2012 20:02:22 +0000 Message-ID: References: <003c01cd4b29$97d7b150$c78713f0$@ndzh.com> <985EF8D2-DA8A-4BE7-94D3-F4BE2B74D768@castlepoint.net> <4FE07A24.7050804@raszuk.net> <4FE07DA8.8050404@raszuk.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.224.208] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=1.0 c=1 a=vqnfvzHxCNEA:10 a=ZQD3OTTxKqYA:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=ZRNLZ4dFUbCvG8] X-AnalysisOut: [UMqPvVAA==:17 a=48vgC7mUAAAA:8 a=J_N6KFswAAAA:8 a=w3DVTE7f] X-AnalysisOut: [xwIr8Jwb-xQA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=Pwbdu] X-AnalysisOut: [c0PQ3sA:10 a=OaGMYzP8NMurOIgB:21 a=bx_vJWEHYJkAavs9:21] Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2012 20:02:52 -0000 Donald, We selected the negative as it seemed logical that a session that had been= configured for Persist should then assume that the exception is DO_NOT_PER= SIST.. See section 3 below.. " 3. Configuration (Persistence Timer and DO_NOT_PERSIST Community) Persistence is configured on a per session and per AFI/SAFI basis. Through the use of an inbound BGP policy selectively setting the DO_NOT_PERSIST community, the persistence behavior can be set on a per route basis. A speaker configures the ability to persist independently of its peer. There is no negotiation between the peers. A timer must be configured indicating the time to persist stale state from a peer where the session is no longer viable. This timer is designated as the persist-timer. A speaker may also attach the DO_NOT_PERSIST community value indicating if a path to a route should not persist." Jim Uttaro -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Smith= , Donald Sent: Tuesday, June 19, 2012 3:52 PM To: 'idr@ietf.org' Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document -= 3 more weeks Why isn't this: 2.1. DO_NOT_PERSIST This memo defines a new BGP community, DO_NOT_PERSIST, with value TBD (to be assigned by IANA). Attaching of the DO_NOT_PERSIST community SHOULD be controlled by configuration. The functionality SHOULD default to being disabled. This: 2.1. PERSIST This memo defines a new BGP community, PERSIST, with value TBD (to be assigned by IANA). Attaching of the PERSIST community SHOULD be controlled by configuration. The functionality SHOULD default to being disabled. I don't think persist should be the default and dislike negative variables = (do_not_....) as it makes following the logic a bit more difficult. When packets collide the controllers cease transmission AND wait a random t= ime before retransmission (mostly)! Donald.Smith@CenturyLink.com This communication is the property of CenturyLink and may contain confident= ial or privileged information. Unauthorized use of this communication is st= rictly 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 robert@raszuk.net Tue Jun 19 13:26:30 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CD6D11E80FB for ; Tue, 19 Jun 2012 13:26:30 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nYkenpmMBMpQ for ; Tue, 19 Jun 2012 13:26:29 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id A08A011E80FC for ; Tue, 19 Jun 2012 13:26:29 -0700 (PDT) Received: (qmail 8361 invoked by uid 399); 19 Jun 2012 20:26:29 -0000 Received: from unknown (HELO ?192.168.1.58?) (pbs:robert@raszuk.net@83.9.122.251) by mail1310.opentransfer.com with ESMTPM; 19 Jun 2012 20:26:29 -0000 X-Originating-IP: 83.9.122.251 Message-ID: <4FE0E074.3070905@raszuk.net> Date: Tue, 19 Jun 2012 22:26:28 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: "UTTARO, JAMES" References: <003c01cd4b29$97d7b150$c78713f0$@ndzh.com> <985EF8D2-DA8A-4BE7-94D3-F4BE2B74D768@castlepoint.net> <4FE07A24.7050804@raszuk.net> <1C1F2B2E-2EB7-42F0-8CFF-57965443C074@castlepoint.net> <7A614998-8FB1-4A51-9937-DE501FF31EB6@juniper.net> <4FE0D1F4.9070208@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 'Shane Amante' , Susan Hares , "idr@ietf.org" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2012 20:26:30 -0000 > It needs to be made as reliable and resilient as possible for all BGP use cases. True. But it needs to be engineered correctly to work well. You are proposing a bandage to cover for bad control plane architecture. This is fine if this is just within your network boundaries. Unfortunately draft -01 goes beyond that at this point. IMO the right design would be to provide robust x86 based control plane. I admit we do not have today a ready commercial way to build one as it needs to be seamless to clients (I am not talking about more then two IBGP sessions) and really-multi-vendor which goes against any vendor's business case. Perhaps those who have in-house multiple BGP implementations could provide one .... But operators are free to enhance what's commercially available with their own development. No need to modify any shipping BGP implementation or make any changes to BGP protocol is needed. Best regards, R. From randy@psg.com Tue Jun 19 15:31:27 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C36011E80D6 for ; Tue, 19 Jun 2012 15:31:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nO5MHc6OMKnT for ; Tue, 19 Jun 2012 15:31:26 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id D0E5E11E80D1 for ; Tue, 19 Jun 2012 15:31:26 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Sh6xJ-00078S-M8; Tue, 19 Jun 2012 22:31:26 +0000 Date: Wed, 20 Jun 2012 07:31:24 +0900 Message-ID: From: Randy Bush To: "John G. Scudder" In-Reply-To: <7A614998-8FB1-4A51-9937-DE501FF31EB6@juniper.net> References: <003c01cd4b29$97d7b150$c78713f0$@ndzh.com> <985EF8D2-DA8A-4BE7-94D3-F4BE2B74D768@castlepoint.net> <4FE07A24.7050804@raszuk.net> <1C1F2B2E-2EB7-42F0-8CFF-57965443C074@castlepoint.net> <7A614998-8FB1-4A51-9937-DE501FF31EB6@juniper.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: idr wg Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2012 22:31:27 -0000 > To what problem? I think a big part of the disagreement so far is that > folks are not in agreement as to whether the problem statement is > worth addressing. The problem statement is kind of buried in S. 1.1: > > BGP Persistence targets the different use case of a catastrophic > failure when the BGP control plane can remain down for a longer time > (e.g. hours). why keep the bgp control plane up when you can not deliver packets? oh, you mean the control plane is not congruent with the data plane? then i think you should say so. randy From randy@psg.com Tue Jun 19 15:32:13 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95A2D11E80F8 for ; Tue, 19 Jun 2012 15:32:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SD2M-NGAH7wX for ; Tue, 19 Jun 2012 15:32:13 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 2BF5F11E80D6 for ; Tue, 19 Jun 2012 15:32:13 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Sh6xy-00078g-Vg; Tue, 19 Jun 2012 22:32:07 +0000 Date: Wed, 20 Jun 2012 07:32:05 +0900 Message-ID: From: Randy Bush To: Enke Chen In-Reply-To: <4FE0D1F4.9070208@cisco.com> References: <003c01cd4b29$97d7b150$c78713f0$@ndzh.com> <985EF8D2-DA8A-4BE7-94D3-F4BE2B74D768@castlepoint.net> <4FE07A24.7050804@raszuk.net> <1C1F2B2E-2EB7-42F0-8CFF-57965443C074@castlepoint.net> <7A614998-8FB1-4A51-9937-DE501FF31EB6@juniper.net> <4FE0D1F4.9070208@cisco.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: "idr@ietf.org" , Susan Hares , "robert@raszuk.net" , Shane Amante Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2012 22:32:13 -0000 > Thanks for pointing out the importance of the "problem statement" in > this discussion. Yes, this topic does fall into the category of > error/fault recovery, and we will need to evaluate and strike the > balance between simplicity vs complexity, and common cases vs rare > cases, etc al. > > IMO the complete failure of the redundant control plane falls into the > category of "rare cases". They should be addressed from the "root > cause" instead of building more bandages and complexities both > operationally and in the software. +1 From randy@psg.com Tue Jun 19 15:37:53 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AE1421F8642 for ; Tue, 19 Jun 2012 15:37:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YPGvtTCJkD-7 for ; Tue, 19 Jun 2012 15:37:53 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 4277721F863E for ; Tue, 19 Jun 2012 15:37:53 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Sh73W-0007AI-72; Tue, 19 Jun 2012 22:37:50 +0000 Date: Wed, 20 Jun 2012 07:37:48 +0900 Message-ID: From: Randy Bush To: "UTTARO, JAMES" In-Reply-To: References: <003c01cd4b29$97d7b150$c78713f0$@ndzh.com> <985EF8D2-DA8A-4BE7-94D3-F4BE2B74D768@castlepoint.net> <4FE07A24.7050804@raszuk.net> <1C1F2B2E-2EB7-42F0-8CFF-57965443C074@castlepoint.net> <7A614998-8FB1-4A51-9937-DE501FF31EB6@juniper.net> <4FE0D1F4.9070208@cisco.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: 'Shane Amante' , Susan Hares , "robert@raszuk.net" , "idr@ietf.org" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2012 22:37:53 -0000 jim, > This is a real problem with real consequences. It is not as rare as > you think and when it occurs it is a total outage. why is it not being seen in a lot of other folk's networks? > The issue with addressing the "root cause" is that there are many > "root causes". in your case, i suspect there are a few key ones. but this may not be the place to discuss them. > I am tired of discovering them by seeing the network fail. then fix it, don't make it even more complex. randy From bruno.decraene@orange.com Wed Jun 20 00:34:59 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FA2721F871A for ; Wed, 20 Jun 2012 00:34:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s6IQdow6S-Hd for ; Wed, 20 Jun 2012 00:34:58 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 5CE9421F8717 for ; Wed, 20 Jun 2012 00:34:58 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id CABA422C6F8; Wed, 20 Jun 2012 09:34:56 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id B085E27C064; Wed, 20 Jun 2012 09:34:56 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Wed, 20 Jun 2012 09:34:56 +0200 From: To: "robert@raszuk.net" Thread-Topic: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks Thread-Index: AQHNTkr0kzFtDweGF06QjEz6Tygl8ZcCzQAg Date: Wed, 20 Jun 2012 07:34:55 +0000 Message-ID: <16810_1340177696_4FE17D20_16810_614_1_53C29892C857584299CBF5D05346208A092842@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <003c01cd4b29$97d7b150$c78713f0$@ndzh.com> <985EF8D2-DA8A-4BE7-94D3-F4BE2B74D768@castlepoint.net> <4FE07A24.7050804@raszuk.net> <4FE07DA8.8050404@raszuk.net> <30501_1340127198_4FE0B7DE_30501_11925_1_53C29892C857584299CBF5D05346208A092626@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FE0C78A.9090606@raszuk.net> In-Reply-To: <4FE0C78A.9090606@raszuk.net> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.6.19.115414 Cc: "idr@ietf.org" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2012 07:34:59 -0000 Hi Robert, >From: Robert Raszuk [mailto:robert@raszuk.net] >Sent: Tuesday, June 19, 2012 8:40 PM > >Hi Bruno, > >>> Btw ... "business as usual" today on EBGP boundary means to clean >>> all communities other then those I do not expect. That means that >>> middle AS will drop all STALE/DO_NOT_PERSIST markers and no one >>> will have a way to distinguished which prefixes are solid and which >>> are questionable. >> >> For any AS (adjacent, middle...) on the eBGP propagation path: - >> either I agreed to use the STALE marker (hence it "expects" the >> community) - or the previous BGP speaker will not advertise me the >> STALE path. >> >> You example does not work. > >We are discussing current draft not it's future revisions. In the >current draft there is no EBGP capabilities defined ... my example >applies fully. No. Agreement between ASes do not require BGP capability. E.g. People can t= alk. >>> One of the authors proposed to add BGP capability to solve this as >>> well as legacy ASBR case. Note that for this capability to be >>> effective in mixed legacy+upgraded networks it would need to be >>> both for IBGP and EBGP. >> >> I'm not sure to see what you mean. On iBGP (hence within the AS), you >> can assume that the AS can guaranty a consistent behavior. E.g. >> local_pref are used to lower the preference & on eBGP sessions which >> have not agreed to use STALE, a BGP policy filter out the route with >> the STALE community. So there is no issue with legacy. > >Of course there is. As I have provided the description in the former >email persistence relies on End-of-RIB to sync it's state when the >session comes back up. Without IBGP capability you have no way of >indicating that to your peer. No. 1) It has been considered that End-of-RIB is a widely available feature 2) Persistence does not rely on End-of-RIB. You can use a timer to fix an u= pper bound on the convergence (e.g. cf Selection_Deferral_Timer in GR). The= n End-of-RIB is simply an add-on to speed up to convergence. Then if you re= ally feel speeding a the convergence is needed (could be discussed how much= minutes matter after a 1 hour BGP freeze), all you need is ask for EoR sup= port on your router. No need for capability. 3) Finally, if you ever needed to know the EoR capability of your peer, the= re is already a capability for this (cf GR). >-- > >Bottom line: Adding BGP capability negotiation and defining it's format >to overlap or not overlap with GR is not a "minor detail". It >fundamentally changing the operational model of the proposal. Capability negotiation is not required. Even if it were, IMHO I feel that this is a small point compared to the BGP= persistence proposition, which could be discussed & challenged on bigger a= spects. However, I surely can be wrong and you have a bigger experience tha= n me on designing protocols.=20 >For me personally this is like supporting the draft or maybe better >said: "not being against it" or not. Ack. Regards, Bruno >Best, >R. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From bruno.decraene@orange.com Wed Jun 20 01:01:44 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9223021F86BA for ; Wed, 20 Jun 2012 01:01:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mNN3Bv0mU4mP for ; Wed, 20 Jun 2012 01:01:44 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id A505D21F86B1 for ; Wed, 20 Jun 2012 01:01:43 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 954F43243AF; Wed, 20 Jun 2012 10:01:42 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 5384E23805C; Wed, 20 Jun 2012 10:01:42 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Wed, 20 Jun 2012 10:01:41 +0200 From: To: Enke Chen Thread-Topic: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks Thread-Index: AQHNTlEpkzFtDweGF06QjEz6Tygl8ZcCzPsA Date: Wed, 20 Jun 2012 08:01:40 +0000 Message-ID: <2135_1340179302_4FE18366_2135_284_10_53C29892C857584299CBF5D05346208A092872@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <003c01cd4b29$97d7b150$c78713f0$@ndzh.com> <985EF8D2-DA8A-4BE7-94D3-F4BE2B74D768@castlepoint.net> <4FE07A24.7050804@raszuk.net> <1C1F2B2E-2EB7-42F0-8CFF-57965443C074@castlepoint.net> <7A614998-8FB1-4A51-9937-DE501FF31EB6@juniper.net> <4FE0D1F4.9070208@cisco.com> In-Reply-To: <4FE0D1F4.9070208@cisco.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.6.19.115414 Cc: Shane Amante , Susan Hares , "robert@raszuk.net" , "idr@ietf.org" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2012 08:01:44 -0000 Enke, >From: Enke Chen >Sent: Tuesday, June 19, 2012 9:25 PM > >Hi, John: > >Thanks for pointing out the importance of the "problem statement" in >this discussion.=20 +1 > Yes, this topic does fall into the category of >error/fault recovery +1 > and we will need to evaluate and strike the >balance between simplicity vs complexity, and common cases vs rare >cases, etc al. True, but the statement is a bit too general so far. The hard point is the = evaluation, not just stating that it's needed Independently of the persistence draft, I would be interested in such evalu= ation " evaluate and strike the balance between simplicity vs complexity, a= nd common cases vs rare cases" for different features. E.g. BGP persistence= , BGP Non Stop Routing, BGPSEC, multiple software train ... >IMO the complete failure of the redundant control plane falls into the >category of "rare cases".=20=20 Agreed. >They should be addressed from the "root >cause" instead of building more bandages and complexities both >operationally and in the software. IMO this is a good proposition to think beyond the BGP persistence proposit= ion. Thanks to John and you for this. And I think I would welcome and consi= der better propositions. And I agree that fixing the root causes are required and better than using = BGP persistence (IMHO it's self evident that we all prefer not having failu= res to deal with). Now, do you mean fixing the root causes before or after the failures? If it's after, I feel that this does not address the concern of people expe= riencing the network issues. If it's before, IMHO this may not be so easy as the causes may be diverse a= nd hard to identify upfront. Clearly some are SP specific, others vendors s= pecific, others some combination of sub-optimalities on both sides. Since you are proposing to address the root causes, IMO, at the minimum you= need to tackle the vendor side. E.g. what do you propose to improve the si= tuation? When? what are the proposed guaranties or metrics to measure the i= mprovement? And BTW, this should not be limited to BGP. Some points are ven= dor specific and I'm ready to have an offline discussion and meeting on thi= s. The point is that you can't disregard the persistence proposal to say th= at it's better to work on the root causes, without working and solving thes= es root causes. Thanks, Regards, Bruno >-- Enke > >On 6/19/12 11:32 AM, John G. Scudder wrote: > >[snip] >> To what problem? I think a big part of the disagreement so far is that f= olks >are not in agreement as to whether the problem statement is worth addressi= ng. >The problem statement is kind of buried in S. 1.1: >> >> BGP Persistence targets the different use case of a catastrophic >> failure when the BGP control plane can remain down for a longer time >> (e.g. hours). >> >> It may be valuable to refocus the discussion on whether folks do, or don= 't, >think the problem statement is worth addressing at all. (I've also pinged = GROW >on this since they are WGLC'ing draft-ietf-grow-ops-reqs-for-bgp-error- >handling-04 right now, and you would think that this topic falls under the >heading of "Operational Requirements for Enhanced Error Handling Behaviour= in >BGP-4".) >> >> > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www.ietf.org/mailman/listinfo/idr ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From tony.li@tony.li Wed Jun 20 01:16:52 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72C3321F86F1 for ; Wed, 20 Jun 2012 01:16:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kzwgt+u6BLde for ; Wed, 20 Jun 2012 01:16:49 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by ietfa.amsl.com (Postfix) with ESMTP id E71C321F845F for ; Wed, 20 Jun 2012 01:16:46 -0700 (PDT) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta05.westchester.pa.mail.comcast.net with comcast id QYGR1j0021ZXKqc55YGmon; Wed, 20 Jun 2012 08:16:46 +0000 Received: from sjc-vpn7-984.cisco.com ([128.107.239.233]) by omta21.westchester.pa.mail.comcast.net with comcast id QYFz1j00R52qHCY3hYGDrn; Wed, 20 Jun 2012 08:16:46 +0000 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Tony Li In-Reply-To: <20120620033618.5005672E002@rfc-editor.org> Date: Tue, 19 Jun 2012 22:15:55 -1000 Content-Transfer-Encoding: 7bit Message-Id: <78900BBB-E447-4EE6-ACD9-C7FEA675709A@tony.li> References: <20120620033618.5005672E002@rfc-editor.org> To: RFC Errata System X-Mailer: Apple Mail (2.1278) Cc: skh@nexthop.com, idr@ietf.org, anmol.khirbat@alcatel-lucent.com, yakov@juniper.net, shares@ndzh.com Subject: Re: [Idr] [Editorial Errata Reported] RFC4271 (3264) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2012 08:16:52 -0000 Verified. Tony On Jun 19, 2012, at 5:36 PM, RFC Errata System wrote: > > The following errata report has been submitted for RFC4271, > "A Border Gateway Protocol 4 (BGP-4)". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=4271&eid=3264 > > -------------------------------------- > Type: Editorial > Reported by: Anmol Khirbat > > Section: Appendix F.3 > > Original Text > ------------- > Implementations that combine update messages (as described above in > > Section 6.1) may prefer to see all path attributes presented in a > > known order. > > Corrected Text > -------------- > Implementations that combine update messages (as described above in > > Appendix F.1) may prefer to see all path attributes presented in a > > known order. > > Notes > ----- > Section 6.1 does not say anything about combining update messages. > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC4271 (draft-ietf-idr-bgp4-26) > -------------------------------------- > Title : A Border Gateway Protocol 4 (BGP-4) > Publication Date : January 2006 > Author(s) : Y. Rekhter, Ed., T. Li, Ed., S. Hares, Ed. > Category : DRAFT STANDARD > Source : Inter-Domain Routing > Area : Routing > Stream : IETF > Verifying Party : IESG From bruno.decraene@orange.com Wed Jun 20 01:22:48 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ACB821F8666 for ; Wed, 20 Jun 2012 01:22:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZVnMB61h09rh for ; Wed, 20 Jun 2012 01:22:47 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 21DFE21F85CD for ; Wed, 20 Jun 2012 01:22:46 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 80D533B4540; Wed, 20 Jun 2012 10:22:45 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 5F79835C045; Wed, 20 Jun 2012 10:22:45 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Wed, 20 Jun 2012 10:22:45 +0200 From: To: "robert@raszuk.net" , "UTTARO, JAMES" Thread-Topic: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks Thread-Index: AQHNTlnOkzFtDweGF06QjEz6Tygl8ZcCzSWQ Date: Wed, 20 Jun 2012 08:22:44 +0000 Message-ID: <17490_1340180565_4FE18855_17490_15423_1_53C29892C857584299CBF5D05346208A0928AA@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <003c01cd4b29$97d7b150$c78713f0$@ndzh.com> <985EF8D2-DA8A-4BE7-94D3-F4BE2B74D768@castlepoint.net> <4FE07A24.7050804@raszuk.net> <1C1F2B2E-2EB7-42F0-8CFF-57965443C074@castlepoint.net> <7A614998-8FB1-4A51-9937-DE501FF31EB6@juniper.net> <4FE0D1F4.9070208@cisco.com> <4FE0E074.3070905@raszuk.net> In-Reply-To: <4FE0E074.3070905@raszuk.net> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.6.20.73323 Cc: 'Shane Amante' , Susan Hares , "idr@ietf.org" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2012 08:22:48 -0000 Robert, >From: Robert Raszuk >Sent: Tuesday, June 19, 2012 10:26 PM > >> It needs to be made as reliable and resilient as possible for all BGP use >cases. > >True. > >But it needs to be engineered correctly to work well. You are proposing >a bandage to cover for bad control plane architecture. This is fine if >this is just within your network boundaries. Unfortunately draft -01 >goes beyond that at this point. > >IMO the right design would be to provide robust x86 based control plane. >I admit we do not have today a ready commercial way to build one as it >needs to be seamless to clients (I am not talking about more then two >IBGP sessions) and really-multi-vendor which goes against any vendor's >business case.=20 Idem, thanks for the proposition and for thinking beyond the persistence dr= aft. IMHO that may be a valid thing to try, at least on the RR side of the BGP s= ession. Yet, IMHO building a good (reliable, performant) BGP implementation= is hard. However, that would only cover the (some) software issues on the RR side. I= see persistence as a bigger safety net. > Perhaps those who have in-house multiple BGP implementations could provid= e one .... >But operators are free to enhance what's commercially available with >their own development.=20 I don't think operators would do a better job on the BGP implementation sid= e. Building software and operating a network is a different business and re= quires different skills. An open source effort may have value to openly and= collectively identify and correct bugs but this is a much wider discussion= . And a very long term effort. Best regards, Bruno >No need to modify any shipping BGP implementation >or make any changes to BGP protocol is needed. > >Best regards, >R. >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www.ietf.org/mailman/listinfo/idr ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From robert@raszuk.net Wed Jun 20 01:31:31 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC11721F871E for ; Wed, 20 Jun 2012 01:31:31 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GoT0oAUvsz3b for ; Wed, 20 Jun 2012 01:31:31 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 2D91621F8733 for ; Wed, 20 Jun 2012 01:31:31 -0700 (PDT) Received: (qmail 27712 invoked by uid 399); 20 Jun 2012 08:31:30 -0000 Received: from unknown (HELO ?192.168.1.58?) (pbs:robert@raszuk.net@83.31.182.221) by mail1310.opentransfer.com with ESMTPM; 20 Jun 2012 08:31:30 -0000 X-Originating-IP: 83.31.182.221 Message-ID: <4FE18A61.8000405@raszuk.net> Date: Wed, 20 Jun 2012 10:31:29 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: bruno.decraene@orange.com References: <003c01cd4b29$97d7b150$c78713f0$@ndzh.com> <985EF8D2-DA8A-4BE7-94D3-F4BE2B74D768@castlepoint.net> <4FE07A24.7050804@raszuk.net> <1C1F2B2E-2EB7-42F0-8CFF-57965443C074@castlepoint.net> <7A614998-8FB1-4A51-9937-DE501FF31EB6@juniper.net> <4FE0D1F4.9070208@cisco.com> <4FE0E074.3070905@raszuk.net> <17490_1340180565_4FE18855_17490_15423_1_53C29892C857584299CBF5D05346208A0928AA@PEXCVZYM11.corporate.adroot.infra.ftgroup> In-Reply-To: <17490_1340180565_4FE18855_17490_15423_1_53C29892C857584299CBF5D05346208A0928AA@PEXCVZYM11.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 'Shane Amante' , "UTTARO, JAMES" , Susan Hares , "idr@ietf.org" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2012 08:31:32 -0000 > Yet, IMHO building a good (reliable, performant) BGP implementation is hard. True. And changing it's fundamental behaviour every few months does not help to make it reliable/ performant either ;) > I don't think operators would do a better job on the BGP implementation side. I am not asking for that at all. I am asking to simply use multiple implementations in the backend. Not two .. but 4 or 5. Probability that all fail/melt with the same bug I think is very very low. Of course I admit that if you one uses service which only single vendor supports in BGP then one get's a bit stuck with the risk. And that seems to be one of the silent "problem statement" here. Rgs, R. From warren@kumari.net Wed Jun 20 01:35:24 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E881F21F86FD for ; Wed, 20 Jun 2012 01:35:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.107 X-Spam-Level: X-Spam-Status: No, score=-106.107 tagged_above=-999 required=5 tests=[AWL=0.492, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qJB8gwcAwUuy for ; Wed, 20 Jun 2012 01:35:24 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 5F0DA21F86F8 for ; Wed, 20 Jun 2012 01:35:24 -0700 (PDT) Received: from [5.5.8.13] (vpn.snozzages.com [204.194.22.7]) by vimes.kumari.net (Postfix) with ESMTPSA id 57DE71B40A98; Wed, 20 Jun 2012 04:35:23 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Warren Kumari In-Reply-To: <0BB0F094-2ABE-4C34-B62A-44BB7234DA43@kumari.net> Date: Wed, 20 Jun 2012 09:34:48 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <003c01cd4b29$97d7b150$c78713f0$@ndzh.com> <0BB0F094-2ABE-4C34-B62A-44BB7234DA43@kumari.net> To: Susan Hares X-Mailer: Apple Mail (2.1278) Cc: idr@ietf.org, "'John G. Scudder'" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2012 08:35:25 -0000 On Jun 18, 2012, at 7:08 PM, Warren Kumari wrote: >=20 > On Jun 15, 2012, at 3:03 PM, Susan Hares wrote: >=20 >> IDR WG and BGPers: >>=20 >> While there is a strong debate on draft-uttaro-idr-bgp-persistence-01 = as IDR WG document, I do not see a clear consensus. We also did not get = an overwhelming number of you to hum either way (11 total). >>=20 >> Since some of those who voted =93no=94 have suggested alternate text = to the author, I would like to extend the time to consider this draft = for 3 more weeks. >>=20 >> To accept the draft we need a few more of you to =93hum=94 yes or = =93hum=94 no. >=20 > I have (re-)read and support adoption. When I read this I understood that this would cause less, not more churn = (figuring that a failure within an AS this would be less likely to = result in withdrawl / readvertisement), but it seems I didn't have my = brain fully engaged... I was also viewing this with a "standard" design in place and so only = kicking in in rare cases (such as when one device ups and dies and the = other device *in the forwarding path* loses its RE / CP) and didn't = consider how often this would occur in other designs.=20 Having read the thread, having a better understanding of the draft and = having considered it further I withdraw my support=85 >=20 > This is a flavor of kink that I want no part of, but a number of folk = feel that this is a useful feature, and who am I to question what they = do in the privacy of their own network? I stand by my "your network, your rules" stance, but it seems that this = won't actually be in the privacy of your own network=85 W >=20 > W >=20 >=20 >>=20 >> Sue Hares >>=20 >>=20 >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr >=20 > --=20 > Outside of a dog, a book is your best friend, and inside of a dog, = it's too dark to read=20 >=20 >=20 -- It's a mistake trying to cheer up camels. You might as well drop = meringues into a black hole. -- Terry Prachett From wwwrun@rfc-editor.org Tue Jun 19 20:36:58 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0183B11E80A3 for ; Tue, 19 Jun 2012 20:36:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.078 X-Spam-Level: X-Spam-Status: No, score=-102.078 tagged_above=-999 required=5 tests=[AWL=0.522, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OxmeCwiiYNiN for ; Tue, 19 Jun 2012 20:36:57 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id C0ABE11E808E for ; Tue, 19 Jun 2012 20:36:53 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 5005672E002; Tue, 19 Jun 2012 20:36:18 -0700 (PDT) To: yakov@juniper.net, tony.li@tony.li, skh@nexthop.com, stbryant@cisco.com, adrian@olddog.co.uk, shares@ndzh.com, jgs@juniper.net From: RFC Errata System Message-Id: <20120620033618.5005672E002@rfc-editor.org> Date: Tue, 19 Jun 2012 20:36:18 -0700 (PDT) X-Mailman-Approved-At: Wed, 20 Jun 2012 08:04:01 -0700 Cc: anmol.khirbat@alcatel-lucent.com, rfc-editor@rfc-editor.org, idr@ietf.org Subject: [Idr] [Editorial Errata Reported] RFC4271 (3264) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2012 03:36:58 -0000 The following errata report has been submitted for RFC4271, "A Border Gateway Protocol 4 (BGP-4)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4271&eid=3264 -------------------------------------- Type: Editorial Reported by: Anmol Khirbat Section: Appendix F.3 Original Text ------------- Implementations that combine update messages (as described above in Section 6.1) may prefer to see all path attributes presented in a known order. Corrected Text -------------- Implementations that combine update messages (as described above in Appendix F.1) may prefer to see all path attributes presented in a known order. Notes ----- Section 6.1 does not say anything about combining update messages. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC4271 (draft-ietf-idr-bgp4-26) -------------------------------------- Title : A Border Gateway Protocol 4 (BGP-4) Publication Date : January 2006 Author(s) : Y. Rekhter, Ed., T. Li, Ed., S. Hares, Ed. Category : DRAFT STANDARD Source : Inter-Domain Routing Area : Routing Stream : IETF Verifying Party : IESG From jeff.tantsura@ericsson.com Wed Jun 20 11:43:13 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 834B021F8792 for ; Wed, 20 Jun 2012 11:43:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mbr29g+LiWe2 for ; Wed, 20 Jun 2012 11:43:11 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 0EB1321F8667 for ; Wed, 20 Jun 2012 11:43:11 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q5KIgc8k017010 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 20 Jun 2012 13:42:40 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.64]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Wed, 20 Jun 2012 14:42:38 -0400 From: Jeff Tantsura To: Enke Chen Date: Wed, 20 Jun 2012 14:42:38 -0400 Thread-Topic: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks Thread-Index: Ac1PFHdcUzs1E6CqSGS6YSjbclHp1g== Message-ID: <5A5761AA-3661-4634-A63D-E52F9E4843E6@ericsson.com> References: <003c01cd4b29$97d7b150$c78713f0$@ndzh.com> <985EF8D2-DA8A-4BE7-94D3-F4BE2B74D768@castlepoint.net> <4FE07A24.7050804@raszuk.net> <1C1F2B2E-2EB7-42F0-8CFF-57965443C074@castlepoint.net> <7A614998-8FB1-4A51-9937-DE501FF31EB6@juniper.net> <4FE0D1F4.9070208@cisco.com> In-Reply-To: <4FE0D1F4.9070208@cisco.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" , Susan Hares , "robert@raszuk.net" , Shane Amante Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2012 18:43:13 -0000 +1 Regards, Jeff On Jun 19, 2012, at 12:23, "Enke Chen" wrote: > Hi, John: >=20 > Thanks for pointing out the importance of the "problem statement" in=20 > this discussion. Yes, this topic does fall into the category of=20 > error/fault recovery, and we will need to evaluate and strike the=20 > balance between simplicity vs complexity, and common cases vs rare=20 > cases, etc al. >=20 > IMO the complete failure of the redundant control plane falls into the=20 > category of "rare cases". They should be addressed from the "root=20 > cause" instead of building more bandages and complexities both=20 > operationally and in the software. >=20 > -- Enke >=20 > On 6/19/12 11:32 AM, John G. Scudder wrote: >=20 > [snip] >> To what problem? I think a big part of the disagreement so far is that f= olks are not in agreement as to whether the problem statement is worth addr= essing. The problem statement is kind of buried in S. 1.1: >>=20 >> BGP Persistence targets the different use case of a catastrophic >> failure when the BGP control plane can remain down for a longer time >> (e.g. hours). >>=20 >> It may be valuable to refocus the discussion on whether folks do, or don= 't, think the problem statement is worth addressing at all. (I've also ping= ed GROW on this since they are WGLC'ing draft-ietf-grow-ops-reqs-for-bgp-er= ror-handling-04 right now, and you would think that this topic falls under = the heading of "Operational Requirements for Enhanced Error Handling Behavi= our in BGP-4".) >>=20 >>=20 >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From jgs@juniper.net Wed Jun 20 16:00:51 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5A4821F844B for ; Wed, 20 Jun 2012 16:00:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.873 X-Spam-Level: X-Spam-Status: No, score=-5.873 tagged_above=-999 required=5 tests=[AWL=-0.670, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1vvl6e6rKCH9 for ; Wed, 20 Jun 2012 16:00:48 -0700 (PDT) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by ietfa.amsl.com (Postfix) with ESMTP id 6C75B21F8445 for ; Wed, 20 Jun 2012 16:00:48 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKT+JWHxST7RB24t/Qp0sH8Y6g+yPk06GS@postini.com; Wed, 20 Jun 2012 16:00:48 PDT Received: from [172.19.168.48] (172.19.168.48) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server id 8.3.213.0; Wed, 20 Jun 2012 15:59:52 -0700 References: <20120617204451.26844.76025.idtracker@ietfa.amsl.com> In-Reply-To: MIME-Version: 1.0 (1.0) Content-Type: text/plain; charset="us-ascii" Message-ID: Content-Transfer-Encoding: quoted-printable From: "John G. Scudder" Date: Wed, 20 Jun 2012 18:48:35 -0400 To: "UTTARO, JAMES" X-Mailer: iPhone Mail (9B206) Cc: "idr@ietf.org" Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2012 23:00:51 -0000 [trimmed cc] Jim, On Jun 18, 2012, at 5:13 PM, "UTTARO, JAMES" wrote: > John, >=20 > The notion of this draft is to change the actual behavior of the pr= otocol in terms of the resultant action due to a update error malformed attr= .. Currently the session is torn down.. Another behavior would be timer expi= ry, in that case the actual NH of the update is correct, but a timer expiry b= etween a RR and the egress PE also tears down the session. Should we change t= he specification to deal with a bug where a RR cannot maintain sessions? Are= there addl bugs in the protocol implementation that are being considered ? No. If you or another WG member would like to propose such, feel free to bri= ng it up.=20 > The BGP persistence draft and GR to a lesser extent as it does not s= urvive as many error conditions accepts the base specification but simply al= lows paths to persist without changing the fundamental nature of the protoco= l.. Why do we need this solution also? If the egress PE used BGP Persistence= or GR ( Assume modified to persist through mal-formed attr ), then the curr= ent specification continues unchanged, and valid paths persist. There are several answers to this but the most fundamental is that if you've= got a poison route in the system then when you restart your session (whethe= r with GR, persistence, or what-have-you) you'll eventually get the poison r= oute again, reset the session again, repeat forever. In the mean time your r= outing will be badly degraded and anything that would arrive after the poiso= n route in the initial convergence will be completely stuck since you'll alw= ays reset before seeing it.=20 By ignoring the poison route you allow the rest of your routes to continue g= etting service. You may even be able to use an alternate path toward the pre= fixes in the poison route.=20 > Another observation is that the draft attempts to provide a finer level of= granularity in terms of specification for some errors. The resultant action= is no longer at a session but at a path level. >=20 > If one path has a mal-formed update I believe that all of the paths in tha= t update are treated as withdrawn . If so, then this fix discards possibly d= ifferent sets of good paths at different egress PEs? I guess? Though if you're distributing a consistent set of routes within you= r AS I think you'll normally end up discarding them consistently too because= they'll arrive with the same (presumed to be malformed) attributes, whether= packed into one update or spread across several. OTOH if you're not distrib= uting a consistent set of routes within your AS then yes, you are hoist on y= our own petard.=20 Anything can happen of course if you posit just the right (wrong) set of bug= s, but that way lies madness. I think in reasonably foreseeable circumstance= s things will tend to go as I've described above. Even in the case where inc= onsistency ensues, well, this is already broadly speaking a known side-effec= t of the proposal and the notion is it's acceptable if the other alternative= is session reset.=20 > This may create inconsistent routing topologies as different "good paths" m= ay be discarded based on update packing at the ingress PE. So not an inconsi= stency for the path with the mal-formed attr but possibly all the others pac= ked in.. By definition all the prefixes packed in the same update share the same (pre= sumed to be malformed) attributes, so there is zero chance of an "innocent" r= oute catching a drive-by bullet as you describe.=20 > Comments In-Line.. Ditto.=20 > Thanks, > Jim Uttaro >=20 >=20 > -----Original Message----- > From: John G. Scudder [mailto:jgs@juniper.net] > Sent: Monday, June 18, 2012 3:49 PM > To: UTTARO, JAMES > Cc: 'internet-drafts@ietf.org'; i-d-announce@ietf.org; idr@ietf.org > Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-02.txt >=20 > Hi Jim, >=20 > On Jun 17, 2012, at 8:29 PM, UTTARO, JAMES wrote: >=20 >> I took a read on this ( I will read more thoroughly) but one section jump= ed out at me. "Operational Considerations". >>=20 >>=20 >> Although the "treat-as-withdraw" error-handling behavior defined in >> Section 2 makes every effort to preserve BGP's correctness, we note >> that if an UPDATE received on an IBGP session is subjected to this >> treatment, inconsistent routing within the affected Autonomous System >> may result. The consequences of inconsistent routing can include >> long-lived forwarding loops and black holes. While lamentable, this >> issue is expected to be rare in practice, and more importantly is >> seen as less problematic than the session-reset behavior it replaces. >>=20 >> " When a malformed attribute is indeed detected over an IBGP session, >> we RECOMMEND that routes with the malformed attribute be identified >> and traced back to the ingress router in the network where the routes >> were sourced or received externally, and then a filter be applied on >> the ingress router to prevent the routes from being sourced or >> received. This will help maintain routing consistency in the >> network." >>=20 >>=20 >> I don't think the terminology "lamentable" to describe Long lived forward= ing loops and black holes is appropriate as it would probably be more than r= egrettable. >=20 > My dictionary says "(of circumstances or conditions) deplorably bad or uns= atisfactory" which seems about right to me. We could have said "it really su= cks a lot" but the style seems wrong. :-) But this sentence could be rewritt= en as needed, it's not a big deal. > [Jim U>] Agreed it is bad/unsatisfactory. I guess I was addressing the pre= mise. >=20 >> Could you expand on the conditions >=20 > One very simple case: >=20 > A--B--C--D >=20 > The four routers depicted form an IBGP full mesh (sessions not shown). The= links shown are the physical topology. Standard IP forwarding is used. Rout= ers A and D are ASBRs and both advertise a path for prefix X into IBGP. Rout= er C prefers the path from A, for example due to a shorter AS Path. However,= router B decides that the path from A is malformed, so it selects the path f= rom D. Now we have C's next hop to reach X as B, and B's next hop to reach X= as C. This is a stable forwarding loop. (Why do B and C have different conc= lusions about whether the update is malformed? Different code bases with dif= ferent assumptions, as we have seen more than once in the field.) > [Jim U>] Ouch. We could get some big flows going back and forth in our top= ology based upon the path in question... would this be trading forwarding lo= ops within a network for routing churn amongst networks and/or traffic re-di= rection.. It sort of feels that way to me.. Potentially, yes. Devil, deep blue sea. One thing to observe is that a flapp= ing bgp session in the middle of your network is the other alternative in th= is scenario. Does that sound better to you? Most reviewers have thought it s= ounded worse.=20 >> and how BGP would eventually recover. >=20 > It wouldn't :-( without operator intervention. > [Jim U>] Ouch +1.. >=20 >> That would be a good addition. I am a bit confused, how does this type of= error handling which restarts GR ( As of my last read ) and which BGP persi= stence lives through change the paradigm of these solutions? >=20 > I don't understand this question. > [Jim U>] Assume BGP current behavior.. The sessions would be torn down, BG= P Persist/GR ( Assume GR is modified to persist through a mal-formed attr ) w= ould become active.. See discussion above.=20 > In this model for a subset of failure modes the session would not be torn d= own. I guess the issue is that for different error conditions we see differe= nt solutions/behaviors.. If malformed then no session tear down, treat as wi= thdrawn, If timer expiry than if GR tear session down flush paths, BGP Persi= stence session tear down maintain paths. I am war of the lack of consistency= .. I think this is a legitimate case of different diseases having different cur= es, although as Enke (I think) mentioned in a different context, if we can c= ome up with a single, simpler, unified solution to these problems then that'= s great. Big "if", though.=20 >> There is a notion of treat as withdraw for some attrs, but don't tear dow= n session?? >=20 > Yes. You're right to find this shocking. I find it shocking, but have been= browbeaten :-)/2 into agreeing that the cure may be a little less bad than t= he disease. However, the floor is still definitely open for debate! > [Jim U>] Ouch.. I don't like the notion of changing the fundamental nature= of the protocol.. >=20 >> How many malformed updates before the session is torn down? Ever? >=20 > This was discussed a while ago, inconclusively. To date, I don't recall ha= ving seen any suggestions I really liked for how to decide a session should b= e torn down. It actually seems to make things more complicated (to implement= , to debug in operation) to have two error-handling modes you flip between a= ccording to some heuristic. The floor is still open for more discussion. > [Jim U>] Maybe determine the exposure to inconsistency.. >=20 >> According to the next paragraph ( See below ) there is an expectation tha= t the offending ingress router should be identified, and then a filter shoul= d be applied for those paths in a given updated with the malformed attrs :) W= hat is the recommendation for doing this? >=20 > The router should log (and possibly trap, alarm, etc) the offending update= (s). The operator should examine the logs and by so doing, figure it out fro= m there. Sorry this seems glib but that's what it comes down to. Remember th= at the alternate (present-day) scenario is that the BGP session to the affec= ted router is going to flap, which is likely even worse operationally, possi= bly much worse. > [Jim U>] If we could persist the state than the damage from the flap shoul= d be mitigated.. Again, see above.=20 > Of course this is different based on application i.e internet, VPNV4, vPNV= 2 etc... We would need to think about how to automate this.. >=20 >> Will there be a draft whereby the detecting router somehow figures out th= e offending ingress router, builds routing policy and then sends it there to= dynamically create the filter. >=20 > I sincerely hope not and have spoken against this idea in the past. > [Jim U>] LOL >=20 >> This seems non-trivial, >=20 > That's why. When you start building machinery to automatically patch aroun= d bugs in your primary routing machinery, IMO you have officially Jumped The= Shark and started building a Rube Goldberg router. > [Jim U>] Yes. If there is a bug that should be fixed.. There are solution t= hat allow state to persist.. I would prefer this as opposed to modifying the= specification to deal with this one type of bug? BTW Is it extensible to ot= her Update Message Errors?? The idea is to cover pretty much every message error, as long as the prefixe= s still can be extracted and the update boundaries determined, yes.=20 Thanks, =20 --John >> I guess Flowspec like technology may be used not sure.. Is the ingress ro= uter assumed to be in the same AS domain as the detecting router? >=20 > Since the paragraph is talking about IBGP, yes. Of course this doesn't mea= n the offending update was sourced within the same AS, but the paragraph you= 're picking on is just talking about what happens within IBGP. > [Jim U>] Yup. Assuming same AS then like flowspec there may be a way but a= gain it is patching a bug in the machinery.. >=20 > Note that draft-ietf-grow-ops-reqs-for-bgp-error-handling-04.txt is very a= pplicable to this discussion and is currently in WGLC in GROW. Since you hav= e opinions about this topic I strongly suggest you review it and comment on t= he GROW WGLC. It runs until June 25.[Jim U>] I will.. Thx... >=20 > --John >=20 >> Administrative domain may span multiple AS domains.. >>=20 >> Jim Uttaro >>=20 >>=20 >>=20 >>=20 >> -----Original Message----- >> From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of int= ernet-drafts@ietf.org >> Sent: Sunday, June 17, 2012 4:45 PM >> To: i-d-announce@ietf.org >> Cc: idr@ietf.org >> Subject: [Idr] I-D Action: draft-ietf-idr-error-handling-02.txt >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. >> This draft is a work item of the Inter-Domain Routing Working Group of th= e IETF. >>=20 >> Title : Revised Error Handling for BGP UPDATE Messages >> Author(s) : John G. Scudder >> Enke Chen >> Pradosh Mohapatra >> Keyur Patel >> Filename : draft-ietf-idr-error-handling-02.txt >> Pages : 10 >> Date : 2012-06-17 >>=20 >> Abstract: >> According to the base BGP specification, a BGP speaker that receives >> an UPDATE message containing a malformed attribute is required to >> reset the session over which the offending attribute was received. >> This behavior is undesirable as a session reset would impact not only >> routes with the offending attribute, but also other valid routes >> exchanged over the session. This document partially revises the >> error handling for UPDATE messages, and provides guidelines for the >> authors of documents defining new attributes. Finally, it revises >> the error handling procedures for several existing attributes. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-idr-error-handling >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-idr-error-handling-02 >>=20 >> A diff from previous version is available at: >> http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-error-handling-02 >>=20 >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> 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 From hj2387@att.com Thu Jun 21 12:11:01 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 819BB21F8683 for ; Thu, 21 Jun 2012 12:11:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D6G4q+Jtc7bt for ; Thu, 21 Jun 2012 12:11:00 -0700 (PDT) Received: from nbfkord-smmo04.seg.att.com (nbfkord-smmo04.seg.att.com [209.65.160.86]) by ietfa.amsl.com (Postfix) with ESMTP id 3548721F86EF for ; Thu, 21 Jun 2012 12:11:00 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo04.seg.att.com(mxl_mta-6.11.0-10) over TLS secured channel with ESMTP id 3c173ef4.0.1222842.00-392.3385145.nbfkord-smmo04.seg.att.com (envelope-from ); Thu, 21 Jun 2012 19:11:00 +0000 (UTC) X-MXL-Hash: 4fe371c41a5fec19-e6843c539e93a0bc5f1fed7083fc642679ee36e4 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q5LJAxHt001540 for ; Thu, 21 Jun 2012 15:10:59 -0400 Received: from sflint02.pst.cso.att.com (sflint02.pst.cso.att.com [144.154.234.229]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q5LJArIJ001448 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 21 Jun 2012 15:10:53 -0400 Received: from MISOUT7MSGHUB9B.ITServices.sbc.com (misout7msghub9b.itservices.sbc.com [144.151.223.72]) by sflint02.pst.cso.att.com (RSA Interceptor) for ; Thu, 21 Jun 2012 15:10:35 -0400 Received: from MISOUT7MSGUSR9O.ITServices.sbc.com ([144.151.223.75]) by MISOUT7MSGHUB9B.ITServices.sbc.com ([144.151.223.72]) with mapi id 14.02.0298.004; Thu, 21 Jun 2012 15:10:35 -0400 From: "JENG, HUAJIN" To: "idr@ietf.org" Thread-Topic: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document Thread-Index: Ac1P4Yi8mRfQSQG4RvKNUE7IVIcP+w== Date: Thu, 21 Jun 2012 19:10:35 +0000 Message-ID: <6A9BBBEC91E7544BA6D6A577899EDACC116E0B@MISOUT7MSGUSR9O.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.115.215] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=1.0 c=1 a=_LOeqIuIqpAA:10 a=LpFatD6TD90A:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=ZRNLZ4dFUbCvG8] X-AnalysisOut: [UMqPvVAA==:17 a=w7WksNoz1uT24rKhapQA:9 a=CjuIK1q_8ugA:10] X-Mailman-Approved-At: Thu, 21 Jun 2012 12:15:48 -0700 Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2012 19:11:01 -0000 Support. From shares@ndzh.com Thu Jun 21 22:17:21 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 767A421F8694 for ; Thu, 21 Jun 2012 22:17:21 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vNEaQ3M8AXUW for ; Thu, 21 Jun 2012 22:17:21 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web.hickoryhill-consulting.com [64.9.205.140]) by ietfa.amsl.com (Postfix) with ESMTP id CBD7021F8690 for ; Thu, 21 Jun 2012 22:17:20 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=64.112.195.202; Received: from SKH2012HPLT (unverified [64.112.195.202]) by hickoryhill-consulting.com (SurgeMail 5.2a) with ESMTP id 3402683-1945496 for multiple; Thu, 21 Jun 2012 17:58:51 -0400 From: "Susan Hares" To: "'Randy Bush'" , "'John G. Scudder'" References: <003c01cd4b29$97d7b150$c78713f0$@ndzh.com> <985EF8D2-DA8A-4BE7-94D3-F4BE2B74D768@castlepoint.net> <4FE07A24.7050804@raszuk.net> <1C1F2B2E-2EB7-42F0-8CFF-57965443C074@castlepoint.net> <7A614998-8FB1-4A51-9937-DE501FF31EB6@juniper.net> In-Reply-To: Date: Thu, 21 Jun 2012 17:58:45 -0400 Message-ID: <019d01cd4ff9$081b99d0$1852cd70$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJZrw3uXkAWvJPZ1smjI5COtj8VlgFw2vQ/Ahn6W5cCmr5cewHUFbq3AlRSYL4BxSdFc5WL+AAQ Content-Language: en-us X-Authenticated-User: skh@ndzh.com Cc: 'idr wg' Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2012 05:17:21 -0000 Randy: [co-chair hat off] Your point is well-taken. Data planes can continue while BGP drops, but I do not understand the point of doing heroic efforts to keep the BGP control plane up when the data plane is down. Perhaps someone can enlighten me. [co-chair hat on] Sue Hares -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Randy Bush Sent: Tuesday, June 19, 2012 6:31 PM To: John G. Scudder Cc: idr wg Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks > To what problem? I think a big part of the disagreement so far is that > folks are not in agreement as to whether the problem statement is > worth addressing. The problem statement is kind of buried in S. 1.1: > > BGP Persistence targets the different use case of a catastrophic > failure when the BGP control plane can remain down for a longer time > (e.g. hours). why keep the bgp control plane up when you can not deliver packets? oh, you mean the control plane is not congruent with the data plane? then i think you should say so. randy _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From shares@ndzh.com Thu Jun 21 22:53:03 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1675521F85F1 for ; Thu, 21 Jun 2012 22:53:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.612 X-Spam-Level: X-Spam-Status: No, score=-1.612 tagged_above=-999 required=5 tests=[AWL=0.986, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CJIPEopPlx8x for ; Thu, 21 Jun 2012 22:53:00 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web.hickoryhill-consulting.com [64.9.205.140]) by ietfa.amsl.com (Postfix) with ESMTP id 6300421F85DF for ; Thu, 21 Jun 2012 22:53:00 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=166.249.100.131; Received: from SKH2012HPLT (unverified [166.249.100.131]) by hickoryhill-consulting.com (SurgeMail 5.2a) with ESMTP id 3399566-1945496 for multiple; Wed, 20 Jun 2012 13:25:17 -0400 From: "Susan Hares" To: "'Shane Amante'" References: <003c01cd4b29$97d7b150$c78713f0$@ndzh.com> <985EF8D2-DA8A-4BE7-94D3-F4BE2B74D768@castlepoint.net> In-Reply-To: <985EF8D2-DA8A-4BE7-94D3-F4BE2B74D768@castlepoint.net> Date: Wed, 20 Jun 2012 13:25:11 -0400 Message-ID: <004501cd4f09$a6b7dd60$f4279820$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0046_01CD4EE8.1FA8AE60" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJZrw3uXkAWvJPZ1smjI5COtj8VlgFw2vQ/ld8uLJA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Cc: idr@ietf.org, "'John G. Scudder'" Subject: Re: [Idr] Spam:********, Re: draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2012 05:53:03 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0046_01CD4EE8.1FA8AE60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Shane: Thank you for your comments on the concerns from an operator's viewpoint. Sue From: Shane Amante [mailto:shane@castlepoint.net] Sent: Tuesday, June 19, 2012 1:34 AM To: Susan Hares Cc: idr@ietf.org; 'John G. Scudder' Subject: Spam:********, Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks I would prefer not to see this adopted as a WG doc. At a high level, I would rather see a more concentrated focus on implementations providing much more detailed log messages, in particular along the lines of "flight data recorder" type capabilities that would allow operators and vendors to more rapidly isolate the root cause of the issue and then take appropriate action, automatically or manually, to mitigate the issue temporarily or even permanently. This would be of benefit for not only L2VPN/L3VPN services, (as mentioned in the draft), but also Internet and other applications that use BGP for signaling reachability information. With respect to this particular draft, I have several concerns, but my primary concern is with the following. If I'm reading this correctly, this draft states that the DO_NOT_PERSIST community "SHOULD" be disabled by default, which means that (by default) all routes will be set to "persist". Only through manual config on the part of an SP, will a subset of routes be set to DO_NOT_PERSIST, i.e.: obey the classic/current behavior of BGP, that is be withdrawn when the session fails. This appears to be a fundamental change to BGP, which I would not want to see deployed "by accident" because this suddenly becomes the default behavior in implementations. Yes, it sucks, but I would rather see routes withdrawn on session failure (like they are today), rather than hang around until the network is "fixed". Ultimately, problems of this nature are easy to quickly explain to customer (so the Ops & Vendor folks can concentrate on determining root cause and mitigating it), rather than how long it takes to sort through and try to explain "routing anomalies" that are likely to incrementally build-up the longer routes are held in a STALE state. Ultimately, I empathize with the co-authors that being in this situation is not fun, nor a good day. (Been there, done that, got the T-shirts ... happy to say I destroyed them afterward :-). Furthermore, although it does cost money, which is not easy to come by, I believe that a redundant architecture could be deployed in either the SP's network or by the customer (i.e.: multi-home to two carriers) to largely mitigate these concerns. Yes, this is not practical in all cases, but it's certainly /possible/ and should be considered recommended before such drastic changes are made to BGP. Just my own $0.02, -shane On Jun 15, 2012, at 1:03 PM, Susan Hares wrote: IDR WG and BGPers: While there is a strong debate on draft-uttaro-idr-bgp-persistence-01 as IDR WG document, I do not see a clear consensus. We also did not get an overwhelming number of you to hum either way (11 total). Since some of those who voted "no" have suggested alternate text to the author, I would like to extend the time to consider this draft for 3 more weeks. To accept the draft we need a few more of you to "hum" yes or "hum" no. Sue Hares _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr ------=_NextPart_000_0046_01CD4EE8.1FA8AE60 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Shane:

 

Thank you for your comments on the concerns from an operator’s = viewpoint.

 

Sue

 

From:= = Shane Amante [mailto:shane@castlepoint.net]
Sent: Tuesday, = June 19, 2012 1:34 AM
To: Susan Hares
Cc: = idr@ietf.org; 'John G. Scudder'
Subject: Spam:********, Re: = [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more = weeks

 

I would = prefer not to see this adopted as a WG doc.  At a high level, I = would rather see a more concentrated focus on implementations providing = much more detailed log messages, in particular along the lines of = "flight data recorder" type capabilities that would allow = operators and vendors to more rapidly isolate the root cause of the = issue and then take appropriate action, automatically or manually, to = mitigate the issue temporarily or even permanently.  This would be = of benefit for not only L2VPN/L3VPN services, (as mentioned in the = draft), but also Internet and other applications that use BGP for = signaling reachability information.

 

With respect to this particular draft, I have several = concerns, but my primary concern is with the = following.

 

If I'm reading this correctly, this draft states that = the DO_NOT_PERSIST community "SHOULD" be disabled by default, = which means that (by default) all routes will be set to = "persist".  Only through manual config on the part of an = SP, will a subset of routes be set to DO_NOT_PERSIST, i.e.: obey the = classic/current behavior of BGP, that is be withdrawn when the session = fails.  This appears to be a fundamental change to BGP, which I = would not want to see deployed "by accident" because this = suddenly becomes the default behavior in implementations.  Yes, it = sucks, but I would rather see routes withdrawn on session failure (like = they are today), rather than hang around until the network is = "fixed".  Ultimately, problems of this nature are easy to = quickly explain to customer (so the Ops & Vendor folks can = concentrate on determining root cause and mitigating it), rather than = how long it takes to sort through and try to explain "routing = anomalies" that are likely to incrementally build-up the longer = routes are held in a STALE state.

 

Ultimately, I empathize with the co-authors that being = in this situation is not fun, nor a good day.  (Been there, done = that, got the T-shirts ... happy to say I destroyed them afterward :-). =  Furthermore, although it does cost money, which is not easy to = come by, I believe that a redundant architecture could be deployed in = either the SP's network or by the customer (i.e.: multi-home to two = carriers) to largely mitigate these concerns.  Yes, this is not = practical in all cases, but it's certainly /possible/ and should be = considered recommended before such drastic changes are made to = BGP.

 

Just my own $0.02,

 

-shane

 

 

 

On Jun 15, 2012, at 1:03 PM, Susan Hares = wrote:

IDR WG and BGPers:=

 =

While there is a = strong debate on draft-uttaro-idr-bgp-persistence-01 as IDR WG document, = I do not see a clear consensus.  We also did not get an = overwhelming number of you to hum either way (11 total).=

 =

Since some of those = who voted “no” have suggested alternate text to the author, = I would like to extend the time to consider this draft for 3 more = weeks.=

 =

To accept the draft = we need a few more of you to “hum” yes or “hum” = no.=

 =

Sue = Hares=

 =

 =

_______________________________________________
Idr = mailing list
Idr@ietf.org
https://www.ietf.org/m= ailman/listinfo/idr

 

------=_NextPart_000_0046_01CD4EE8.1FA8AE60-- From senad.ietf@gmail.com Fri Jun 22 04:58:22 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E35E521F86B0 for ; Fri, 22 Jun 2012 04:58:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.332 X-Spam-Level: X-Spam-Status: No, score=-1.332 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dbG9KrCmvgof for ; Fri, 22 Jun 2012 04:58:22 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4E02B21F85F2 for ; Fri, 22 Jun 2012 04:58:22 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so3565197pbc.31 for ; Fri, 22 Jun 2012 04:58:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+az3PhLxG9e6NSSdyq0igLoPV+SZdAQnXwGeXdafMPM=; b=N1DFIgZ7XyXgkfe2zLKhR8YwiBNcmvuN2ruwoyxYoFFc2l09sfmZXEIdfMwmnpHdeT TlqzLT8xw+j1imanCyYwYS7cSly6F8UFicmX3bAvVrJrOppo1AIhmdEbq6hpr2ACWEst RB7M4Z8MVNaIk1+fO5Zu3mG4EyYOa62tl/Oc2VXRAabTmFYCgJVIFZ5atYVt0vBiGsYr Gl5IE/U78MEpwK0kyIBJGSowtAPjezMSqUcWMiBpoLSYNUrDM9XaDffQ5fhGo57op9U8 qhQJVORYRut0QNtPaXIkicbSQ3Q+GZJID47U0Ns+4PuzbjknUIvxtidvtGaS43GelNzO fA1A== MIME-Version: 1.0 Received: by 10.68.211.41 with SMTP id mz9mr9825723pbc.12.1340366301654; Fri, 22 Jun 2012 04:58:21 -0700 (PDT) Received: by 10.68.237.130 with HTTP; Fri, 22 Jun 2012 04:58:20 -0700 (PDT) In-Reply-To: <4FE18A61.8000405@raszuk.net> References: <003c01cd4b29$97d7b150$c78713f0$@ndzh.com> <985EF8D2-DA8A-4BE7-94D3-F4BE2B74D768@castlepoint.net> <4FE07A24.7050804@raszuk.net> <1C1F2B2E-2EB7-42F0-8CFF-57965443C074@castlepoint.net> <7A614998-8FB1-4A51-9937-DE501FF31EB6@juniper.net> <4FE0D1F4.9070208@cisco.com> <4FE0E074.3070905@raszuk.net> <17490_1340180565_4FE18855_17490_15423_1_53C29892C857584299CBF5D05346208A0928AA@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FE18A61.8000405@raszuk.net> Date: Fri, 22 Jun 2012 07:58:20 -0400 Message-ID: From: "Senad .Palislamovic" To: robert@raszuk.net Content-Type: multipart/alternative; boundary=e89a8ff1c4f847707404c30e594b Cc: bruno.decraene@orange.com, "idr@ietf.org" , "UTTARO, JAMES" , Susan Hares , Shane Amante Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2012 11:58:23 -0000 --e89a8ff1c4f847707404c30e594b Content-Type: text/plain; charset=ISO-8859-1 Apologize for the delay on comments, Robert, After going through all the emails, I admit, you've made a lot of valuable comments that 'seriously' MUST be considered in the new version of the draft. However, putting that aside, I would really expect this to be saved for WG discussions. I would think that at this stage, we are more less agreeing to take a look at this problem and its solution space. Robert, Randy, Shane, The main question I have for you is why object something that might not even affect you. Draft's primary purpose is for the protection of the control plane for non-internet services (vpls, l2vpn, or infrustructure routes, i.e. BGP-3107), which in all cases does not affect you or me in any shape or form. For folks to chose to extend this to l3vpn or even to IPv4/IPv6 space, they are doing it consciously knowing the nature of their network and its dynamics. If you do see a route with the STALE community, and do not desire to use this path due its "unreliable" nature, you can request your provider to withdraw the routes with STALE community effectively making them DO_NOT_PERSIST at the source which effectively mimics the standard GR behavior; as Bruno stated, at eBGP, people are talking and negotiating. So given all that, help me understand how could this impact anyone who chooses not to use it. Am I missing anything? On the side note, Susan, I do support this draft as WG document. Senad On Wed, Jun 20, 2012 at 4:31 AM, Robert Raszuk wrote: > > Yet, IMHO building a good (reliable, performant) BGP implementation is >> hard. >> > > True. And changing it's fundamental behaviour every few months does not > help to make it reliable/ performant either ;) > > > I don't think operators would do a better job on the BGP implementation >> side. >> > > I am not asking for that at all. I am asking to simply use multiple > implementations in the backend. Not two .. but 4 or 5. Probability that all > fail/melt with the same bug I think is very very low. > > Of course I admit that if you one uses service which only single vendor > supports in BGP then one get's a bit stuck with the risk. And that seems to > be one of the silent "problem statement" here. > > Rgs, > > R. > > ______________________________**_________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/**listinfo/idr > --e89a8ff1c4f847707404c30e594b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Apologize for the delay on comments,

Robert,

After going through all the emails, I admit, you've mad= e a lot of valuable comments that 'seriously' MUST be considered in= the new version of the draft.=A0 However, putting that aside, I would real= ly expect this to be saved for WG discussions.=A0 I would think that at thi= s stage, we are more less agreeing to take a look at this problem and its s= olution space.=A0

Robert, Randy, Shane,

The main question = I have for you is why object something that might not even affect you.=A0 D= raft's=A0primary purpose is for the protection of the control plane for= non-internet services (vpls, l2vpn, or infrustructure routes, i.e. BGP-310= 7), which in all cases does not affect you or me in any shape or form.=A0 F= or folks to chose to extend this to l3vpn or even to IPv4/IPv6 space, they = are doing it consciously knowing the nature of their network and its dynami= cs.=A0 If you do see a route with the STALE community, and do not desire to= use this path due its "unreliable" nature, you can request your = provider to withdraw the routes with STALE community effectively making the= m DO_NOT_PERSIST at the source which effectively mimics the standard GR beh= avior; as Bruno stated, at eBGP, people are talking and negotiating.

So given all that, help me understand how could this impact= anyone who chooses not to use it. =A0Am I missing anything?

On the side note, Susan, I do support this draft as WG docu= ment.

Senad


On Wed, Ju= n 20, 2012 at 4:31 AM, Robert Raszuk <robert@raszuk.net> wro= te:

Yet, IMHO building a good (reliable, performant) BGP implementation is hard= .

True. And changing it's fundamental behaviour every few months does not= help to make it reliable/ performant either ;)


I don't think operators would do a better job on the BGP implementation= side.

I am not asking for that at all. I am asking to simply use multiple impleme= ntations in the backend. Not two .. but 4 or 5. Probability that all fail/m= elt with the same bug I think is very very low.

Of course I admit that if you one uses service which only single vendor sup= ports in BGP then one get's a bit stuck with the risk. And that seems t= o be one of the silent "problem statement" here.

Rgs,

R.

_______________________________________________
Idr mailing list
Idr@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/idr

--e89a8ff1c4f847707404c30e594b-- From ju1738@att.com Fri Jun 22 05:21:25 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27DA721F85F3 for ; Fri, 22 Jun 2012 05:21:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.425 X-Spam-Level: X-Spam-Status: No, score=-106.425 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OrU8Qhv75uyV for ; Fri, 22 Jun 2012 05:21:24 -0700 (PDT) Received: from nbfkord-smmo04.seg.att.com (nbfkord-smmo04.seg.att.com [209.65.160.86]) by ietfa.amsl.com (Postfix) with ESMTP id 0994721F85CC for ; Fri, 22 Jun 2012 05:21:23 -0700 (PDT) Received: from unknown [144.160.128.153] (EHLO flpi408.enaf.ffdc.sbc.com) by nbfkord-smmo04.seg.att.com(mxl_mta-6.11.0-10) over TLS secured channel with ESMTP id 34364ef4.0.1392183.00-499.3847829.nbfkord-smmo04.seg.att.com (envelope-from ); Fri, 22 Jun 2012 12:21:24 +0000 (UTC) X-MXL-Hash: 4fe4634449ba43ce-6d66a1c0ae44b18e50d5e9f2b04423c5cf47fb39 Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q5MCLMSS003825; Fri, 22 Jun 2012 05:21:22 -0700 Received: from fflint04.pst.cso.att.com (fflint04.pst.cso.att.com [150.234.39.64]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q5MCL8Fq003581 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Jun 2012 05:21:15 -0700 Received: from MISOUT7MSGHUB9C.ITServices.sbc.com (misout7msghub9c.itservices.sbc.com [144.151.223.82]) by fflint04.pst.cso.att.com (RSA Interceptor); Fri, 22 Jun 2012 05:20:41 -0700 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9C.ITServices.sbc.com ([144.151.223.82]) with mapi id 14.02.0298.004; Fri, 22 Jun 2012 08:20:41 -0400 From: "UTTARO, JAMES" To: "'Susan Hares'" , "'Randy Bush'" , "'John G. Scudder'" Thread-Topic: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks Thread-Index: AQHNUDZZGzEliv6izkmkhPA4i16ZJ5cGP5eA Date: Fri, 22 Jun 2012 12:20:40 +0000 Message-ID: References: <003c01cd4b29$97d7b150$c78713f0$@ndzh.com> <985EF8D2-DA8A-4BE7-94D3-F4BE2B74D768@castlepoint.net> <4FE07A24.7050804@raszuk.net> <1C1F2B2E-2EB7-42F0-8CFF-57965443C074@castlepoint.net> <7A614998-8FB1-4A51-9937-DE501FF31EB6@juniper.net> <019d01cd4ff9$081b99d0$1852cd70$@ndzh.com> In-Reply-To: <019d01cd4ff9$081b99d0$1852cd70$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.151.80] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.128.153] X-AnalysisOut: [v=1.0 c=1 a=dXkvp1zHZaMA:10 a=8bAc-B_C_9sA:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=xwOvzTHDVLE4u4] X-AnalysisOut: [nGvK72ag==:17 a=48vgC7mUAAAA:8 a=yMUiUdUF2xnK8SVWr3UA:9 a=] X-AnalysisOut: [CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=UuHM7YByzoHtMfbw:21 a=] X-AnalysisOut: [npwp6z3_4Gq2GBh-:21] Cc: 'idr wg' Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2012 12:21:25 -0000 Sue, I think there is some confusion.. The BGP Control is down not up, while th= e data plane is up not down. Unlike the internet there are many services th= at do not have the control and data planes symmetric although even in these= cases where there is tunneling I am not so sure it matters. .=20 The situation is if we lose the control plane we want forwarding state to p= ersist as long as the NH of the path is still valid. The path should be con= sidered as path of least resort.. There as services such as 3107 ( Labeled BGP ), L2VPN, etc... which use BGP= for signaling and dynamic discovery.. SO let's look at L2VPN, BGP is used = to dynamically discover and signal state to create PWs which are then used = as part of a customer's VPLS ethernet network. There is no exchange of rout= ing state outside of creating PWs internal to the operator or between coope= rating operators. BGP is used here to create a static set of PWs that can o= nly be formed in response to config changes on a PE.. So if we lose the sig= naling path i.e RR, this in no way implies that the forwarding state is sus= pect. We need to consider all of the services that are using BGP. As stated in th= e draft the use case is not directed to IPV4 or the Internet, it would be g= reat if I could hear any comment about the AFs and services that draft is d= irected towards. Jim Uttaro -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Susan= Hares Sent: Thursday, June 21, 2012 5:59 PM To: 'Randy Bush'; 'John G. Scudder' Cc: 'idr wg' Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document -= 3 more weeks Randy: [co-chair hat off] Your point is well-taken. =20 Data planes can continue while BGP drops, but I do not understand the point of doing heroic efforts to keep the BGP control plane up when the data plan= e is down. Perhaps someone can enlighten me.=20 [co-chair hat on] Sue Hares=20 -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Randy Bush Sent: Tuesday, June 19, 2012 6:31 PM To: John G. Scudder Cc: idr wg Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks > To what problem? I think a big part of the disagreement so far is that=20 > folks are not in agreement as to whether the problem statement is=20 > worth addressing. The problem statement is kind of buried in S. 1.1: >=20 > BGP Persistence targets the different use case of a catastrophic > failure when the BGP control plane can remain down for a longer time > (e.g. hours). why keep the bgp control plane up when you can not deliver packets? oh, yo= u mean the control plane is not congruent with the data plane? then i think you should say so. randy _______________________________________________ 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 From robert@raszuk.net Fri Jun 22 06:07:06 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0C6121F85F3 for ; Fri, 22 Jun 2012 06:07:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.288 X-Spam-Level: X-Spam-Status: No, score=-2.288 tagged_above=-999 required=5 tests=[AWL=-0.289, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fehl9usgm+ez for ; Fri, 22 Jun 2012 06:07:06 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id C754E21F85F2 for ; Fri, 22 Jun 2012 06:07:05 -0700 (PDT) Received: (qmail 19485 invoked by uid 399); 22 Jun 2012 13:07:04 -0000 Received: from unknown (HELO ?192.168.1.91?) (pbs:robert@raszuk.net@83.31.147.254) by mail1310.opentransfer.com with ESMTPM; 22 Jun 2012 13:07:04 -0000 X-Originating-IP: 83.31.147.254 Message-ID: <4FE46DF7.20906@raszuk.net> Date: Fri, 22 Jun 2012 15:07:03 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: "Senad .Palislamovic" References: <003c01cd4b29$97d7b150$c78713f0$@ndzh.com> <985EF8D2-DA8A-4BE7-94D3-F4BE2B74D768@castlepoint.net> <4FE07A24.7050804@raszuk.net> <1C1F2B2E-2EB7-42F0-8CFF-57965443C074@castlepoint.net> <7A614998-8FB1-4A51-9937-DE501FF31EB6@juniper.net> <4FE0D1F4.9070208@cisco.com> <4FE0E074.3070905@raszuk.net> <17490_1340180565_4FE18855_17490_15423_1_53C29892C857584299CBF5D05346208A0928AA@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FE18A61.8000405@raszuk.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Shane Amante , bruno.decraene@orange.com, "UTTARO, JAMES" , Susan Hares , "idr@ietf.org" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2012 13:07:06 -0000 Hello Senad, Many thx for your comments. As you see from my original post I asked to limit the scope of the draft only to services AFI/SAFIs (eg VPLS). The authors answer was NO .. as they may transport their infrastructure routes in Internet SAFI and they want to make them persistent. To your point .. marking the route with a community is a very fragile marker. Imagine I am peering to IX which in turn is connected to 500 peers. I can not imagine how I can "talk with people" to make sure I will not get any STALE routes or that my DO_NOT_PERSIST marked routes will not be cleaned from that community two ASes down the road. That simply does not work across more then two directly connected ASes for any AFI/SAFI (and 3107 may easily extend over more then two ASes even today). At most I may enforce to negotiate BGP capability so when I am not configured for persistence and not aware of it my peer will send me withdraw. That is not "talk-talk" thing, but must be hard assured in the proposal by use of real BGP capabilities. BGP state synchronization when the session comes up using EOR requires GR capability which authors claim is not mandatory for this proposal. Last .. the session down event while BGP process is still healthy and running is being addressed by various other proposals in IDR and GROW which do target opposite solution .. keep the session up even if some errors which would trigger it down are received. So this draft going against that will generate a lot of confusion in the field which solution to use if IETF folks are going in many directions between themselves. I am not making any judgement here which way is better .. just observing the proposals. Regards, R. > Apologize for the delay on comments, > > Robert, > > After going through all the emails, I admit, you've made a lot of > valuable comments that 'seriously' MUST be considered in the new version > of the draft. However, putting that aside, I would really expect this > to be saved for WG discussions. I would think that at this stage, we > are more less agreeing to take a look at this problem and its solution > space. > > Robert, Randy, Shane, > > The main question I have for you is why object something that might not > even affect you. Draft's primary purpose is for the protection of the > control plane for non-internet services (vpls, l2vpn, or infrustructure > routes, i.e. BGP-3107), which in all cases does not affect you or me in > any shape or form. For folks to chose to extend this to l3vpn or even > to IPv4/IPv6 space, they are doing it consciously knowing the nature of > their network and its dynamics. If you do see a route with the STALE > community, and do not desire to use this path due its "unreliable" > nature, you can request your provider to withdraw the routes with STALE > community effectively making them DO_NOT_PERSIST at the source which > effectively mimics the standard GR behavior; as Bruno stated, at eBGP, > people are talking and negotiating. > > So given all that, help me understand how could this impact anyone who > chooses not to use it. Am I missing anything? > > On the side note, Susan, I do support this draft as WG document. > > Senad > > > On Wed, Jun 20, 2012 at 4:31 AM, Robert Raszuk > wrote: > > > Yet, IMHO building a good (reliable, performant) BGP > implementation is hard. > > > True. And changing it's fundamental behaviour every few months does > not help to make it reliable/ performant either ;) > > > I don't think operators would do a better job on the BGP > implementation side. > > > I am not asking for that at all. I am asking to simply use multiple > implementations in the backend. Not two .. but 4 or 5. Probability > that all fail/melt with the same bug I think is very very low. > > Of course I admit that if you one uses service which only single > vendor supports in BGP then one get's a bit stuck with the risk. And > that seems to be one of the silent "problem statement" here. > > Rgs, > > R. > > _________________________________________________ > 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 > From senad.ietf@gmail.com Fri Jun 22 07:24:10 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4489521F8610 for ; Fri, 22 Jun 2012 07:24:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.332 X-Spam-Level: X-Spam-Status: No, score=-1.332 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4-UFEfudDW9Y for ; Fri, 22 Jun 2012 07:24:09 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 95AC821F860D for ; Fri, 22 Jun 2012 07:24:09 -0700 (PDT) Received: by dacx6 with SMTP id x6so2464924dac.31 for ; Fri, 22 Jun 2012 07:24:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QK0DVvkEw9JZv9UNtAWCA8yzUir1R797sMf3OzNSnKo=; b=z4yhkyV2eNo5iIZiga3fn/vjM60D2wipma8tErpSLg1OJ5uJK6mcTsS1RYjh5DNcpl qXkqM8BAE2k6AHOl6YgZEvdSd59c+GkTtjk8gOw0xHN1XKASTEX2tX4gcsw7z2jRiXey 1GPJjpfmM7C/0gtKtr94rYw0CZw8FguhKVYTrdYS7S3+aFElm8ayoVqasodxnw2RuN4p Wxmyx8JIBzdUDuk8E+9v2X6lIrJJ1qNAuiV/kdVdwkcd7Z6XiKLbYCfFzsdUmbSnhmmC Vgdkt8VuNhAC3/p+Yh2iWv26lDgDNMON1RGz7kBo9J++6f0aSq1Bh9INpc19xNQX273a X3Aw== MIME-Version: 1.0 Received: by 10.68.241.228 with SMTP id wl4mr10973651pbc.51.1340375049242; Fri, 22 Jun 2012 07:24:09 -0700 (PDT) Received: by 10.68.237.130 with HTTP; Fri, 22 Jun 2012 07:24:09 -0700 (PDT) In-Reply-To: References: <003c01cd4b29$97d7b150$c78713f0$@ndzh.com> <985EF8D2-DA8A-4BE7-94D3-F4BE2B74D768@castlepoint.net> <4FE07A24.7050804@raszuk.net> <1C1F2B2E-2EB7-42F0-8CFF-57965443C074@castlepoint.net> <7A614998-8FB1-4A51-9937-DE501FF31EB6@juniper.net> <4FE0D1F4.9070208@cisco.com> <4FE0E074.3070905@raszuk.net> <17490_1340180565_4FE18855_17490_15423_1_53C29892C857584299CBF5D05346208A0928AA@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FE18A61.8000405@raszuk.net> Date: Fri, 22 Jun 2012 10:24:09 -0400 Message-ID: From: "Senad .Palislamovic" To: idr@ietf.org Content-Type: multipart/alternative; boundary=047d7b3395a7ad088b04c31062cb Cc: shares@ndzh.com Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2012 14:24:10 -0000 --047d7b3395a7ad088b04c31062cb Content-Type: text/plain; charset=ISO-8859-1 > > IETF mail server glitch; resending: Note: Robert already commented back > > Apologize for the delay on comments, Robert, After going through all the emails, I admit, you've made a lot of valuable comments that 'seriously' MUST be considered in the new version of the draft. However, putting that aside, I would really expect this to be saved for WG discussions. I would think that at this stage, we are more less agreeing to take a look at this problem and its solution space. Robert, Randy, Shane, The main question I have for you is why object something that might not even affect you. Draft's primary purpose is for the protection of the control plane for non-internet services (vpls, l2vpn, or infrustructure routes, i.e. BGP-3107), which in all cases does not affect you or me in any shape or form. For folks to chose to extend this to l3vpn or even to IPv4/IPv6 space, they are doing it consciously knowing the nature of their network and its dynamics. If you do see a route with the STALE community, and do not desire to use this path due its "unreliable" nature, you can request your provider to withdraw the routes with STALE community effectively making them DO_NOT_PERSIST at the source which effectively mimics the standard GR behavior; as Bruno stated, at eBGP, people are talking and negotiating. So given all that, help me understand how could this impact anyone who chooses not to use it. Am I missing anything? On the side note, Susan, I do support this draft as WG document. Senad > On Wed, Jun 20, 2012 at 4:31 AM, Robert Raszuk wrote: > >> >> Yet, IMHO building a good (reliable, performant) BGP implementation is >>> hard. >>> >> >> True. And changing it's fundamental behaviour every few months does not >> help to make it reliable/ performant either ;) >> >> >> I don't think operators would do a better job on the BGP implementation >>> side. >>> >> >> I am not asking for that at all. I am asking to simply use multiple >> implementations in the backend. Not two .. but 4 or 5. Probability that all >> fail/melt with the same bug I think is very very low. >> >> Of course I admit that if you one uses service which only single vendor >> supports in BGP then one get's a bit stuck with the risk. And that seems to >> be one of the silent "problem statement" here. >> >> Rgs, >> >> R. >> >> ______________________________**_________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/**listinfo/idr >> > > --047d7b3395a7ad088b04c31062cb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

IETF mail server glitch; =A0resending:=A0Note: Robert a= lready commented back


Apologize for the delay on comments= ,

Robert,

After going through all the emails, I admit, you've mad= e a lot of valuable comments that 'seriously' MUST be considered in= the new version of the draft.=A0 However, putting that aside, I would real= ly expect this to be saved for WG discussions.=A0 I would think that at thi= s stage, we are more less agreeing to take a look at this problem and its s= olution space.=A0

Robert, Randy, Shane,

The main question I have for you is why object something th= at might not even affect you.=A0 Draft's=A0primary purpose is for the p= rotection of the control plane for non-internet services (vpls, l2vpn, or i= nfrustructure routes, i.e. BGP-3107), which in all cases does not affect yo= u or me in any shape or form.=A0 For folks to chose to extend this to l3vpn= or even to IPv4/IPv6 space, they are doing it consciously knowing the natu= re of their network and its dynamics.=A0 If you do see a route with the STA= LE community, and do not desire to use this path due its "unreliable&q= uot; nature, you can request your provider to withdraw the routes with STAL= E community effectively making them DO_NOT_PERSIST at the source which effe= ctively mimics the standard GR behavior; as Bruno stated, at eBGP, people a= re talking and negotiating.

So given all that, help me understand how could this impact= anyone who chooses not to use it. =A0Am I missing anything?

On the side note, Susan, I do support this draft as WG docu= ment.


Senad





On Wed, Jun 20, 2012 at 4:31 AM, Robert = Raszuk <robert@raszuk.net> wrote:

Yet, IMHO building a good (reliable, performant) BGP implementation is hard= .

True. And changing it's fundamental behaviour every few months does not= help to make it reliable/ performant either ;)


I don't think operators would do a better job on the BGP implementation= side.

I am not asking for that at all. I am asking to simply use multiple impleme= ntations in the backend. Not two .. but 4 or 5. Probability that all fail/m= elt with the same bug I think is very very low.

Of course I admit that if you one uses service which only single vendor sup= ports in BGP then one get's a bit stuck with the risk. And that seems t= o be one of the silent "problem statement" here.

Rgs,

R.

_______________________________________________
Idr mailing list
Idr@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/idr


--047d7b3395a7ad088b04c31062cb-- From ju1738@att.com Fri Jun 22 07:57:42 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F3EC21F8659; Fri, 22 Jun 2012 07:57:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.713 X-Spam-Level: X-Spam-Status: No, score=-105.713 tagged_above=-999 required=5 tests=[AWL=-0.581, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vfV-CPQNwdpp; Fri, 22 Jun 2012 07:57:36 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id 404F221F861A; Fri, 22 Jun 2012 07:57:35 -0700 (PDT) Received: from unknown [144.160.128.153] (EHLO flpi408.enaf.ffdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.11.0-10) over TLS secured channel with ESMTP id ed784ef4.0.1435278.00-334.3971610.nbfkord-smmo06.seg.att.com (envelope-from ); Fri, 22 Jun 2012 14:57:35 +0000 (UTC) X-MXL-Hash: 4fe487df62241740-2fce62ac18bc957c89826abe17b79858cf73f2cb Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q5MEvY37024483; Fri, 22 Jun 2012 07:57:34 -0700 Received: from fflint04.pst.cso.att.com (fflint04.pst.cso.att.com [150.234.39.64]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q5MEvPo7024265 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Jun 2012 07:57:32 -0700 Received: from MISOUT7MSGHUB9F.ITServices.sbc.com (misout7msghub9f.itservices.sbc.com [144.151.223.71]) by fflint04.pst.cso.att.com (RSA Interceptor); Fri, 22 Jun 2012 07:56:50 -0700 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9F.ITServices.sbc.com ([144.151.223.71]) with mapi id 14.02.0298.004; Fri, 22 Jun 2012 10:56:50 -0400 From: "UTTARO, JAMES" To: Rob Shakir Thread-Topic: draft-ietf-grow-ops-reqs-for-bgp-error-handling-04 Thread-Index: Ac1Qh0AwzuLH5xBMSu2rz3aHemLX7w== Date: Fri, 22 Jun 2012 14:56:49 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.151.80] Content-Type: multipart/alternative; boundary="_000_B17A6910EEDD1F45980687268941550FB1F5C0MISOUT7MSGUSR9IIT_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.128.153] X-AnalysisOut: [v=1.0 c=1 a=dXkvp1zHZaMA:10 a=eKrM44SyMe0A:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=w2_UvhHieS8A:10 a=BLceEmwcHowA:10 a=xwOvzTHDVLE4u4] X-AnalysisOut: [nGvK72ag==:17 a=ZGluOzbleR_Xk4LxkFIA:9 a=CjuIK1q_8ugA:10 a] X-AnalysisOut: [=3RyeW6pd_oEGcECB:21 a=poMvd1pBHBSRxmgq:21 a=yMhMjlubAAAA:] X-AnalysisOut: [8 a=SSmOFEACAAAA:8 a=XXGzvcpgyve4yIA-16sA:9 a=gKO2Hq4RSVkA] X-AnalysisOut: [:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10] Cc: 'idr wg' , "'grow@ietf.org'" Subject: [Idr] draft-ietf-grow-ops-reqs-for-bgp-error-handling-04 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2012 14:57:42 -0000 --_000_B17A6910EEDD1F45980687268941550FB1F5C0MISOUT7MSGUSR9IIT_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Rob, Following find my comments.. Thanks, Jim Uttaro General Comment, >From a philosophical perspective I agree with the goals of this draft but I= do not agree with an approach that maintains a session in the face of a fa= ilure in the machinery. This is a bottom up approach which will always be a= day late and a dollar short as we continue to patch what it means to be a = viable session.. I believe the proper approach to meet your reqs ( and mine= too!!! ) is a top down which does not change the BGP behavior but changes = the response to that behavior.. The reality of today's BGP fields of use wh= ich are many and varied is that the control and the forwarding paths are or= thogonal, the state being carried is not always paths as we usually conside= r them. Examples include RT-C, Flowspec which are used to create PWs and si= mulate an IGP etc... I do not believe changing the behavior of BGP session = viability machinery to accomplish maintaining valid forwarding in the face = of a control plane failure is the correct approach The draft addresses a very important error condition but ( Update Error )..= This should be expanded to other areas where the failure of a session does= not indicate that a subset or all of the routing state learned over said s= ession is invalid.. I think the draft should address this directly.. Are th= e changes here configurable? Can I turn this off if I do not want this beha= vior for certain topologies, AFs? Abstract Can the scope be expanded? There are other failure modes, i.e Timer Expiry = which today is not considered a failure mode. In reality what I have seen i= s that timer expiry occurs due to the fact that BGP threads cannot be servi= ced in a timely manner. I think it would be best if we could put it all on= the table.. I do think that this draft should bound the solution space. At the minimum = the solutions proposed should meet a minimum set of the operators criteria = in terms of managing the network, convergence, persistence, churn, forwardi= ng impact etc... Section 1.1 The following paragraph is based on the premise that the session being "dow= n" results in a large impact.. This is certainly true for today's implement= ations which use the session ( Control Plane Construct ) to determine the v= iability of the forwarding state learned over said session. There are cases= where this is the session and forwarding are parallel, but in many more ca= ses control and forwarding planes are orthogonal.. I think we need to re-co= nsider this assumption for many of the services BGP is being used for and b= ase the response to error conditions on this reality.. " Both within Internet and multi-service routing architectures, a number of BGP sessions propagate a large proportion of the required routing information for network operation. For Internet routing, these are typically BGP sessions which propagate the global routing table to an AS - failure of these sessions may have a large impact on network service, based on a single erroneous update. In an multi- service environment, typical deployments utilise a small number of core-facing BGP sessions, typically towards route reflector devices. Failure of these sessions may also result in a large impact to network operation. Clearly, the avoidance of conditions requiring these sessions to fail is of great utility to any network operator, and provides further motivation for the revision of the existing behaviour. " Section 1.2 Bullet 1.. This is a very interesting point.. As you stated " Traditional network architectures would deploy an Interior Gateway Protocol (IGP) to carry infrastructure and customer prefixes, with an Exterior Gateway Protocol (EGP) such as BGP being utilised to propagate these prefixes to other Autonomous Systems. " In this environment where BGP was predominantly used to advertised state be= tween AS domains over dedicated peering points it would makes sense that a = malformed update learned from a peer is a fairly good indication that the p= eer which is originating the update is suspect.. As there are other NHs ava= ilable it would be prudent to not use the suspect session/forwarding path w= hich in these cases were in parallel.. Maybe "treat as withdraw" is appropr= iate not sure, although the SP should be able to decide the course of actio= n . I would ask you to consider that there are two cases here.. The first is wh= en a speaker learns an update from a peer where the NH for the paths in tha= t update is the direct peer ( ASBR, PE ), and the second whereby the update= is from a peer where the NH for the paths in the update is not the peer ( = RR ). In the former case is there still a case that the original premise ho= lds..The offending egress router should be disconnected from the topology. = I don't think this is black and white and operators may want the flexibilit= y of determining the behavior.. Bullet 2 Totally agree.. This is the one of the major requirements driving the BG Pe= rsistence Draft.. Bullet 3 Not sure exactly what the intent here is.. I am all for more robust NM and = visibility... Section 2 I think understand where you are coming from for the first set of errors.. = Do we have a feel as to why there would be erroneous data? It would seem th= at whichever speaker created/modified etc.. the attr is experiencing some f= undamental issue with the BGP machinery as it is not validating the context= ?? "Since in this case, the message received from the remote peer is syntactically valid, it is considered that such an UPDATE is indicative of erroneous data within a path attribute." Section 2.1, 2.1.1, 2.1.2 Hmmm. Too be honest this make me a bit nervous.. This introduces classes of= failure modes.. Downstream NM, Ops etc... will have to learn how to suppor= t these nuanced messages and intended meanings.. There is one thing certain= , when a BGP Session goes down in today's world it merits the immediate att= n of operations to figure out what went wrong and to fix it.. Solutions lik= e GR or BGP Persistence do not change the trigger for Operations response.. Section 3 The premise is to modify when a NOTIFICATION message is sent thus mitigatin= g the possibility that the session becomes invalid or to use a "treat as wi= thdraw" for those paths sharing this common attribute.. The issue in mind i= s the notion of the session as the be all to end all.. We could as easily w= ithout any change to BGP use BGP Persistence to maintain the paths except f= or the ones that have the invalid attribute.. This is the simpler method, h= as the benefit of not changing BGP, or educating the world on the nuances o= f the changes etc... I also do not fully understand "treat as withdraw" does this meant that the= peer who has received an update with P1-PN with malformed attr then initia= te a withdrawal to all of its peers? Or simply assume that the paths have = been received as a message? Some sample topologies as to how this works wo= uld be a good addition to this section.. Section 4 I made some comments on a solution "Re: [Idr] I-D Action: draft-ietf-idr-er= ror-handling-02.txt" which I think is intended to address some aspects of t= his reqs doc. It seems that there is a possibility of forwarding loops that= can be created and the inability of BGP to recover without operator interv= ention. " There are therefore risks of traffic blackholing, due to missing routing information, or forwarding loops. Whilst this is deemed an acceptable compromise in the short term, clearly, it is suboptimal. Therefore, a requirement exists to provide mechanisms by which a BGP speaker is able to recover the consistency of the Adj- RIB-In for a particular neighbour." I do not think that the above draft which does not recover addresses this r= eq.. I am not in support of solutions which create a scenario where BGP cannot r= ecover without human intervention. "It is of particular note for both means of recovering RIB consistency described that these are effective only when considering transitive errors within an implementation - for instance, should an RFC interpretation error within an implementation be present, regardless of the number of times a specific UPDATE is generated, it is likely that this error condition will persist (as it may with the existing behaviour defined by [RFC4271])." I think the difference is that the operator knows that a serious situation = is occurring by virtue of the session failing and can take appropriate acti= on to correct. Forwarding can be maintained using Persistence or GR.. So IM= O I can know a serious issue exists using existing BGP Machinery and well k= nown procedures and at the same time maintain my forwarding.. Section 5 Why wouldn't we simply let the session fail and then use BGP Persistence or= GR ;) Section 6 Nothing is going to get people's attention like a failed BGP Session.. I ca= n only speak for my org but this is what is actively monitored as the bases= for the health of BGP.. Diagnostic, log etc... messages are of high volume= and does not get folks attn.. IMO this is a major disadvantage to this app= roach.. We do not know how convey that something bad has happened to the BG= P Machinery.. Section 7 Although I understand the distinction between the different classes of Upda= te Errors, I am not sure that I understand how that translates into how the= BGP Machinery is actually being impacted. The increased complexity of "und= erstanding" the type of update error message, it's cause, possible remediat= ion etc.. makes this approach really difficult to wrap ones arms around.. --_000_B17A6910EEDD1F45980687268941550FB1F5C0MISOUT7MSGUSR9IIT_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Rob,

 

Following find my comments..

 

Thanks,

        &nbs= p;       Jim Uttaro

 

General Comment,

 

From a philosophical perspective I agree with the go= als of this draft but I do not agree with an approach that maintains a sess= ion in the face of a failure in the machinery. This is a bottom up approach= which will always be a day late and a dollar short as we continue to patch what it means to be a viable sessio= n.. I believe the proper approach to meet your reqs ( and mine too!!! ) is = a top down which does not change the BGP behavior but changes the response = to that behavior.. The reality of today’s BGP fields of use which are many and varied is that the cont= rol and the forwarding paths are orthogonal, the state being carried is not= always paths as we usually consider them. Examples include RT-C, Flowspec = which are used to create PWs and simulate an IGP etc… I do not believe changing the behavior of BGP session vi= ability machinery to accomplish maintaining valid forwarding in the face of= a control plane failure is the correct approach

 

The draft addresses a very important error condition= but ( Update Error ).. This should be expanded to other areas where the fa= ilure of a session does not indicate that a subset or all of the routing st= ate learned over said session is invalid.. I think the draft should address this directly.. Are the changes here conf= igurable? Can I turn this off if I do not want this behavior for certain to= pologies, AFs?

 

Abstract

 

Can the scope be expanded? There are other failure m= odes, i.e Timer Expiry which today is not considered a failure mode. In rea= lity what I have seen is that timer expiry occurs due to the fact that BGP = threads cannot be serviced in a timely manner.  I think it would be best if we could put it all on the table= ..

 

I do think that this draft should bound the solution= space. At the minimum the solutions proposed should meet a minimum set of = the operators criteria in terms of managing the network, convergence, persi= stence, churn, forwarding impact etc…  

 

Section 1.1

 

The following paragraph is based on the premise that= the session being “down” results in a large impact.. This is c= ertainly true for today’s implementations which use the session ( Con= trol Plane Construct ) to determine the viability of the forwarding state learned over said session. There are cases where this= is the session and forwarding are parallel, but in many more cases control= and forwarding planes are orthogonal.. I think we need to re-consider this= assumption for many of the services BGP is being used for and base the response to error conditions on this re= ality..

 

“ Both within Internet and multi-service routing arc= hitectures, a

   number of BGP sessions propagate a large prop= ortion of the required

   routing information for network operation.&nb= sp; For Internet routing,

   these are typically BGP sessions which propag= ate the global routing

   table to an AS - failure of these sessions ma= y have a large impact on

   network service, based on a single erroneous = update.  In an multi-

   service environment, typical deployments util= ise a small number of

   core-facing BGP sessions, typically towards r= oute reflector devices.

   Failure of these sessions may also result in = a large impact to

   network operation.  Clearly, the avoidan= ce of conditions requiring

   these sessions to fail is of great utility to= any network operator,

  and provides further motivation for the revisi= on of the existing

   behaviour. “

 

Section 1.2

 

Bullet 1..

 

This is a very interesting point.. As you stated 
 
“  Traditional network architectures would deploy an Interi=
or Gateway
   Protocol (IGP) to carry infrastructure and customer prefi=
xes, with an
   Exterior Gateway Protocol (EGP) such as BGP being utilise=
d to
   propagate these prefixes to other Autonomous Systems. =
220;
 
In this environment where BGP was predominantly used to advertised sta=
te between AS domains over dedicated peering points it would makes sense th=
at a malformed update learned from a peer is a fairly good indication that =
the peer which is originating the update is suspect.. As there are other NH=
s available it would be prudent to not use the suspect session/forwarding p=
ath which in these cases were in parallel.. Maybe “treat as withdraw&=
#8221; is appropriate not sure, although the SP should be able to decide th=
e course of action .
 
I would ask you to consider that there are two cases here.. The first =
is when a speaker learns an update from a peer where the NH for the paths i=
n that update is the direct peer ( ASBR, PE ), and the second whereby the u=
pdate is from a peer where the NH for the paths in the update is not the pe=
er ( RR ). In the former case is there still a case that the original premi=
se holds..The offending egress router should be disconnected from the topol=
ogy. I don’t think this is black and white and operators may want the=
 flexibility of determining the behavior..
 
Bullet 2
 
Totally agree.. This is the one of the major requirements driving the =
BG Persistence Draft..
 
Bullet 3
 
Not sure exactly what the intent here is.. I am all for more robust NM=
 and visibility…
 
Section 2
 
I think understand where you are coming from for the first set of erro=
rs.. Do we have a feel as to why there would be erroneous data? It would se=
em that whichever speaker created/modified etc.. the attr is experiencing s=
ome fundamental issue with the BGP machinery as it is not validating the co=
ntext??
 
“Since in this case, the message
   received from the remote peer is syntactically valid, it =
is
   considered that such an UPDATE is indicative of erroneous=
 data within
   a path attribute.”
 
Section 2.1, 2.1.1, 2.1.2
 
Hmmm. Too be honest this make me a bit nervous.. This introduces class=
es of failure modes.. Downstream NM, Ops etc… will have to learn how =
to support these nuanced messages and intended meanings.. There is one thin=
g certain, when a BGP Session goes down in today’s world it merits th=
e immediate attn of operations to figure out what went wrong and to fix it.=
. Solutions like GR or BGP Persistence do not change the trigger for Operat=
ions response..
 
Section 3
 
The premise is to modify when a NOTIFICATION message is sent thus miti=
gating the possibility that the session becomes invalid or to use a “=
treat as withdraw” for those paths sharing this common attribute.. Th=
e issue in mind is the notion of the session as the be all to end all.. We =
could as easily without any change to BGP use BGP Persistence to maintain t=
he paths except for the ones that have the invalid attribute.. This is the =
simpler method, has the benefit of not changing BGP, or educating the world=
 on the nuances of the changes etc… 
 
I also do not fully understand “treat as withdraw” does th=
is meant that the peer who has received an update with P1-PN with malformed=
 attr then initiate a withdrawal to all of its peers?  Or simply assum=
e that the paths have been received as a message?  Some sample topolog=
ies as to how this works would be a good addition to this section..
 
Section 4
 
I made some comments on a solution “Re: [Idr] I-D Action: draft-=
ietf-idr-error-handling-02.txt” which I think is intended to address =
some aspects of this reqs doc. It seems that there is a possibility of forw=
arding loops that can be created and the inability of BGP to recover withou=
t operator intervention. 
 
“ There are therefore risks of traffic blackholing, due to<=
/o:p>
   missing routing information, or forwarding loops.  W=
hilst this is
   deemed an acceptable compromise in the short term, clearl=
y, it is
   suboptimal.  Therefore, a requirement exists to prov=
ide mechanisms by
   which a BGP speaker is able to recover the consistency of=
 the Adj-
   RIB-In for a particular neighbour.”

 


I do not think that the above draft which does not recover addresses t=
his req..


 


 


I am not in support of solutions which create a scenario where BGP can=
not recover without human intervention.


 


“It is of particular note for both means of recovering RIB consi=
stency


   described that these are effective only when considering =
transitive


   errors within an implementation - for instance, should an=
 RFC


   interpretation error within an implementation be present,=
 regardless


   of the number of times a specific UPDATE is generated, it=
 is likely


   that this error condition will persist (as it may with th=
e existing


   behaviour defined by [RFC4271]).”


 


I think the difference is that the operator knows that a serious situa=
tion is occurring by virtue of the session failing and can take appropriate=
 action to correct. Forwarding can be maintained using Persistence or GR.. =
So IMO I can know a serious issue exists using existing BGP Machinery and w=
ell known procedures and at the same time maintain my forwarding..


 


Section 5


 


Why wouldn’t we simply let the session fail and then use BGP Per=
sistence or GR ;)  


 


Section 6


 


Nothing is going to get people’s attention like a failed BGP Ses=
sion.. I can only speak for my org but this is what is actively monitored a=
s the bases for the health of BGP.. Diagnostic, log etc… messages are=
 of high volume and does not get folks attn.. IMO this is a major disadvant=
age to this approach.. We do not know how convey that something bad has hap=
pened to the BGP Machinery..


 


Section 7


 


Although I understand the distinction between the different classes of=
 Update Errors, I am not sure that I understand how that translates into ho=
w the BGP Machinery is actually being impacted. The increased complexity of=
 “understanding” the type of update error message, it’s c=
ause, possible remediation etc.. makes this approach really difficult to wr=
ap ones arms around..


 


 


 


 
--_000_B17A6910EEDD1F45980687268941550FB1F5C0MISOUT7MSGUSR9IIT_-- From robert@raszuk.net Fri Jun 22 08:57:07 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B95621F85F8 for ; Fri, 22 Jun 2012 08:57:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=-0.076, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18fAAzinvwja for ; Fri, 22 Jun 2012 08:57:04 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id E2B2F21F8595 for ; Fri, 22 Jun 2012 08:57:03 -0700 (PDT) Received: (qmail 22950 invoked by uid 399); 22 Jun 2012 15:57:02 -0000 Received: from unknown (HELO ?192.168.1.91?) (pbs:robert@raszuk.net@83.31.147.254) by mail1310.opentransfer.com with ESMTPM; 22 Jun 2012 15:57:02 -0000 X-Originating-IP: 83.31.147.254 Message-ID: <4FE495CD.7080604@raszuk.net> Date: Fri, 22 Jun 2012 17:57:01 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: "idr@ietf.org List" , "grow@ietf.org" References: In-Reply-To: X-Forwarded-Message-Id: Content-Type: multipart/mixed; boundary="------------020302020806020607080304" Cc: "UTTARO, JAMES \(ATTLABS\)" Subject: [Idr] Fwd: [GROW] draft-ietf-grow-ops-reqs-for-bgp-error-handling-04 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2012 15:57:07 -0000 This is a multi-part message in MIME format. --------------020302020806020607080304 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Jim, > We could as easily without any change to BGP use BGP Persistence to > maintain the paths except for the ones that have the invalid > attribute.. This is the simpler method, has the benefit of not > changing BGP, or educating the world on the nuances of the changes > etc… + > Why wouldn’t we simply let the session fail and then use BGP Persistence > or GR ;) Please observe that when the session is down you are not receiving withdraws or new best paths for those "good" prefixes (maybe 99% of them) which did not have any errors in their respective update messages. Equating it with persistence proposal is therefor highly incorrect. > I also do not fully understand “treat as withdraw” does this meant that > the peer who has received an update with P1-PN with malformed attr then > initiate a withdrawal to all of its peers? Or simply assume that the > paths have been received as a message? Some sample topologies as to how > this works would be a good addition to this section.. The speaker reacting on an error which can be addressed by "treat-as-withdraw" invalidates locally those prefixes received in the update message, runs local best path and as result if no other path is found withdraws those prefixes from all peers it has previously sent them to. > I am not in support of solutions which create a scenario where BGP > cannot recover without human intervention. I think no one is. But we are - I think - not there yet for the routers to automatically fix their bugs, but only automatically signalling them the requested action ;(. > Nothing is going to get people’s attention like a failed BGP > Session.. True statement. But the entire assumption behind treat-as-withdraw is that your ops scripts parse the syslog messages indicating the issue to NOC with the same red color and buzz as bgp session down. Of course you need to rework your ops scripts/alarms for that to happen. Rgs, R. PS. Note that if the main BGP session is down (like in the persistence case) BGP Operational Messages can not any longer be exchanged between peers as TCP connection could have been reset (if no multisession is used and if we are talking about single SAFI). That just makes the issue worse especially when you do not like to have humans intervention. --------------020302020806020607080304 Content-Type: text/plain; charset=windows-1252; name="Attached Message Part" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Attached Message Part" _______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow --------------020302020806020607080304-- From sairay@cisco.com Fri Jun 22 09:34:36 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8980321F8773 for ; Fri, 22 Jun 2012 09:34:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.998 X-Spam-Level: X-Spam-Status: No, score=-9.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R2-97c7y+zEL for ; Fri, 22 Jun 2012 09:34:34 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id BF29021F8621 for ; Fri, 22 Jun 2012 09:34:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sairay@cisco.com; l=12453; q=dns/txt; s=iport; t=1340382873; x=1341592473; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=Np51aH2Py74qdj0cu1NQK1cOrOC1hYdkaq4L7DI6bzs=; b=Oj8vMumK4Odxa4H8Q8jB0Qw6ruodnVbgpie+BAgYa0pZan7Zjh82UCzp h1EZI9JTckOzw56k3kh084uwUjhyNYucXjAEExe+1vx5SLevYwDmUejvu C5fX5yxfPNmzbjuLJhSrAScWMV3UP22Sch3puVcY/DudeHYQ5wgbFOtYT w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAGyd5E+tJXG8/2dsb2JhbABFgkWzH4EHghgBAQEEAQEBDwEaQQYVAgEIEQQBAQsdBycLFAkIAgQTCAwHB4dpC5oZoAYEiy4ahQhgA6NHgWaCX4Ff X-IronPort-AV: E=Sophos;i="4.77,459,1336348800"; d="scan'208,217";a="95035203" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-8.cisco.com with ESMTP; 22 Jun 2012 16:34:33 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q5MGYXkd003468 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 22 Jun 2012 16:34:33 GMT Received: from xmb-rcd-x13.cisco.com ([169.254.3.37]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0298.004; Fri, 22 Jun 2012 11:34:32 -0500 From: "Saikat Ray (sairay)" To: "idr@ietf.org" Thread-Topic: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks Thread-Index: AQHNUIK5992oODS5z0GaMDFvi/PwiZcGhN0g Date: Fri, 22 Jun 2012 16:34:31 +0000 Message-ID: <8ED5B0B0F5B4854A912480C1521F973AD95B@xmb-rcd-x13.cisco.com> References: <003c01cd4b29$97d7b150$c78713f0$@ndzh.com> <985EF8D2-DA8A-4BE7-94D3-F4BE2B74D768@castlepoint.net> <4FE07A24.7050804@raszuk.net> <1C1F2B2E-2EB7-42F0-8CFF-57965443C074@castlepoint.net> <7A614998-8FB1-4A51-9937-DE501FF31EB6@juniper.net> <4FE0D1F4.9070208@cisco.com> <4FE0E074.3070905@raszuk.net> <17490_1340180565_4FE18855_17490_15423_1_53C29892C857584299CBF5D05346208A0928AA@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FE18A61.8000405@raszuk.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.119.214] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-18988.006 x-tm-as-result: No--59.354300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_8ED5B0B0F5B4854A912480C1521F973AD95Bxmbrcdx13ciscocom_" MIME-Version: 1.0 Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2012 16:34:36 -0000 --_000_8ED5B0B0F5B4854A912480C1521F973AD95Bxmbrcdx13ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Without being involved in the discussion whether it is the right problem to= tackle or not, I would like to make the observation that at the very least= , the draft needs to define a new BGP capability for the willingness to acc= ept STALE routes. Peers that has not negotiated this capability MUST receiv= e paths "as if" the STALE paths did not exist. This includes that STALE pat= hs and any non-STALE paths whose nexthops resolve over a STALE paths MUST a= lso not be sent to a such a peer. This way, negotiation of this capability = by consenting adults will define an island where stale routes would roam fr= ee without affecting others. From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Senad= .Palislamovic Sent: Friday, June 22, 2012 7:24 AM To: idr@ietf.org Cc: shares@ndzh.com Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document -= 3 more weeks IETF mail server glitch; resending: Note: Robert already commented back Apologize for the delay on comments, Robert, After going through all the emails, I admit, you've made a lot of valuable = comments that 'seriously' MUST be considered in the new version of the draf= t. However, putting that aside, I would really expect this to be saved for= WG discussions. I would think that at this stage, we are more less agreei= ng to take a look at this problem and its solution space. Robert, Randy, Shane, The main question I have for you is why object something that might not eve= n affect you. Draft's primary purpose is for the protection of the control= plane for non-internet services (vpls, l2vpn, or infrustructure routes, i.= e. BGP-3107), which in all cases does not affect you or me in any shape or = form. For folks to chose to extend this to l3vpn or even to IPv4/IPv6 spac= e, they are doing it consciously knowing the nature of their network and it= s dynamics. If you do see a route with the STALE community, and do not des= ire to use this path due its "unreliable" nature, you can request your prov= ider to withdraw the routes with STALE community effectively making them DO= _NOT_PERSIST at the source which effectively mimics the standard GR behavio= r; as Bruno stated, at eBGP, people are talking and negotiating. So given all that, help me understand how could this impact anyone who choo= ses not to use it. Am I missing anything? On the side note, Susan, I do support this draft as WG document. Senad On Wed, Jun 20, 2012 at 4:31 AM, Robert Raszuk > wrote: Yet, IMHO building a good (reliable, performant) BGP implementation is hard= . True. And changing it's fundamental behaviour every few months does not hel= p to make it reliable/ performant either ;) I don't think operators would do a better job on the BGP implementation sid= e. I am not asking for that at all. I am asking to simply use multiple impleme= ntations in the backend. Not two .. but 4 or 5. Probability that all fail/m= elt with the same bug I think is very very low. Of course I admit that if you one uses service which only single vendor sup= ports in BGP then one get's a bit stuck with the risk. And that seems to be= one of the silent "problem statement" here. Rgs, R. _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr --_000_8ED5B0B0F5B4854A912480C1521F973AD95Bxmbrcdx13ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Without being involved in= the discussion whether it is the right problem to tackle or not, I would l= ike to make the observation that at the very least, the draft needs to define a new BGP capability for the willingness to accept S= TALE routes. Peers that has not negotiated this capability MUST receive pat= hs “as if” the STALE paths did not exist. This includes that ST= ALE paths and any non-STALE paths whose nexthops resolve over a STALE paths MUST also not be sent to a such a peer. This wa= y, negotiation of this capability by consenting adults will define an islan= d where stale routes would roam free without affecting others.

 <= /p>

From: idr-boun= ces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Senad .Palislamovic
Sent: Friday, June 22, 2012 7:24 AM
To: idr@ietf.org
Cc: shares@ndzh.com
Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG doc= ument - 3 more weeks

 

IETF mail server glitch;  resending: Note: Robert= already commented back

 

Apologize for the delay on comments,

Robert,

After going through all the emails, I admit, you've made a = lot of valuable comments that 'seriously' MUST be considered in the new ver= sion of the draft.  However, putting that aside, I would really expect= this to be saved for WG discussions.  I would think that at this stage, we are more less agreeing to take a look= at this problem and its solution space. 

Robert, Randy, Shane,

The main question I have for you is why object something th= at might not even affect you.  Draft's primary purpose is for the= protection of the control plane for non-internet services (vpls, l2vpn, or= infrustructure routes, i.e. BGP-3107), which in all cases does not affect you or me in any shape or form.  For fol= ks to chose to extend this to l3vpn or even to IPv4/IPv6 space, they are do= ing it consciously knowing the nature of their network and its dynamics.&nb= sp; If you do see a route with the STALE community, and do not desire to use this path due its "unreliable" nature, = you can request your provider to withdraw the routes with STALE community e= ffectively making them DO_NOT_PERSIST at the source which effectively mimic= s the standard GR behavior; as Bruno stated, at eBGP, people are talking and negotiating.

So given all that, help me understand how could this impact= anyone who chooses not to use it.  Am I missing anything?<= /p>

On the side note, Susan, I do support this draft as WG docu= ment.

 

Senad

 

 

 

 

 

On Wed, Jun 20, 2012 at 4:31 AM, Robert Raszuk <<= a href=3D"mailto:robert@raszuk.net" target=3D"_blank">robert@raszuk.net= > wrote:

 

Yet, IMHO building a good (reliable, performant) BGP= implementation is hard.

 

True. And changing it's fundamental behaviour every = few months does not help to make it reliable/ performant either ;)

 

I don't think operators would do a better job on the= BGP implementation side.

 

I am not asking for that at all. I am asking to simp= ly use multiple implementations in the backend. Not two .. but 4 or 5. Prob= ability that all fail/melt with the same bug I think is very very low.

Of course I admit that if you one uses service which only single vendor sup= ports in BGP then one get's a bit stuck with the risk. And that seems to be= one of the silent "problem statement" here.

Rgs,


R.

_______________________________________________
Idr mailing list
Idr@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/idr

 

 

--_000_8ED5B0B0F5B4854A912480C1521F973AD95Bxmbrcdx13ciscocom_-- From ju1738@att.com Fri Jun 22 10:10:43 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96FCA21F8723 for ; Fri, 22 Jun 2012 10:10:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.382 X-Spam-Level: X-Spam-Status: No, score=-106.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jTX9gZsy0ygD for ; Fri, 22 Jun 2012 10:10:40 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id A511A21F877B for ; Fri, 22 Jun 2012 10:10:39 -0700 (PDT) Received: from unknown [144.160.128.153] (EHLO flpi408.enaf.ffdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.11.0-10) over TLS secured channel with ESMTP id f07a4ef4.0.1478786.00-334.4096084.nbfkord-smmo06.seg.att.com (envelope-from ); Fri, 22 Jun 2012 17:10:39 +0000 (UTC) X-MXL-Hash: 4fe4a70f4d4cccfb-e82208370ad5e9bc2cca50732d7b13349ec9882a Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q5MHAaxU015832; Fri, 22 Jun 2012 10:10:38 -0700 Received: from fflint03.pst.cso.att.com (fflint03.pst.cso.att.com [150.234.39.63]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q5MHA3sA015204 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Jun 2012 10:10:29 -0700 Received: from MISOUT7MSGHUB9D.ITServices.sbc.com (misout7msghub9d.itservices.sbc.com [144.151.223.93]) by fflint03.pst.cso.att.com (RSA Interceptor); Fri, 22 Jun 2012 10:09:13 -0700 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9D.ITServices.sbc.com ([144.151.223.93]) with mapi id 14.02.0298.004; Fri, 22 Jun 2012 13:09:13 -0400 From: "UTTARO, JAMES" To: "'John G. Scudder'" Thread-Topic: [Idr] I-D Action: draft-ietf-idr-error-handling-02.txt Thread-Index: AQHNTMoO3AC4WgUFwEeXslewDoqMZpb/MenAgAGOTwD//8NEcIADk6OAgAJ9+mA= Date: Fri, 22 Jun 2012 17:09:12 +0000 Message-ID: References: <20120617204451.26844.76025.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.151.80] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.128.153] X-AnalysisOut: [v=1.0 c=1 a=dXkvp1zHZaMA:10 a=Crak0S_X7RUA:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=xwOvzTHDVLE4u4] X-AnalysisOut: [nGvK72ag==:17 a=OUXY8nFuAAAA:8 a=48vgC7mUAAAA:8 a=zQP7CpKO] X-AnalysisOut: [AAAA:8 a=N3yQjV_H-RGZRS77NsMA:9 a=CjuIK1q_8ugA:10 a=peF9eE] X-AnalysisOut: [_zjQwA:10 a=lZB815dzVvQA:10 a=Hz7IrDYlS0cA:10 a=tYRuDmN78j] X-AnalysisOut: [Ty5WBe:21 a=xg57oLriNokyBSFG:21] Cc: "idr@ietf.org" Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2012 17:10:43 -0000 John, Comments In-Line Thanks, Jim Uttaro -----Original Message----- From: John G. Scudder [mailto:jgs@juniper.net]=20 Sent: Wednesday, June 20, 2012 6:49 PM To: UTTARO, JAMES Cc: John Scudder; idr@ietf.org Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-02.txt [trimmed cc] Jim, On Jun 18, 2012, at 5:13 PM, "UTTARO, JAMES" wrote: > John, >=20 > The notion of this draft is to change the actual behavior of the p= rotocol in terms of the resultant action due to a update error malformed at= tr.. Currently the session is torn down.. Another behavior would be timer e= xpiry, in that case the actual NH of the update is correct, but a timer exp= iry between a RR and the egress PE also tears down the session. Should we c= hange the specification to deal with a bug where a RR cannot maintain sessi= ons? Are there addl bugs in the protocol implementation that are being cons= idered ? No. If you or another WG member would like to propose such, feel free to br= ing it up. =20 [Jim U>] I commented on Rob's draft in GROW and I feel that this is a great= opportunity to consider a number of session failures beyond the Update var= iety.. I will pursue with Rob > The BGP persistence draft and GR to a lesser extent as it does not= survive as many error conditions accepts the base specification but simply= allows paths to persist without changing the fundamental nature of the pro= tocol.. Why do we need this solution also? If the egress PE used BGP Persis= tence or GR ( Assume modified to persist through mal-formed attr ), then th= e current specification continues unchanged, and valid paths persist. There are several answers to this but the most fundamental is that if you'v= e got a poison route in the system then when you restart your session (whet= her with GR, persistence, or what-have-you) you'll eventually get the poiso= n route again, reset the session again, repeat forever. In the mean time yo= ur routing will be badly degraded and anything that would arrive after the = poison route in the initial convergence will be completely stuck since you'= ll always reset before seeing it. =20 [Jim U>] I think two cases here. The first is if the speaker is initially c= oming up, then all paths up to the one with the mal-formed would be retaine= d and valid, the poison path would cause a failure of the session, all subs= equent paths are not received..The second is a speaker getting updates in r= esponse to normal behavior or a soft refresh.. In either of these cases the= paths already learned are programmed and not affected or better said stale= ... IMO it is best to consider these cases independently, in the former I d= o not want the session established s there is something fundamentally wrong= with the machinery, in the latter I have all paths learned already and am = in steady state.. By ignoring the poison route you allow the rest of your routes to continue = getting service. You may even be able to use an alternate path toward the p= refixes in the poison route.=20 [Jim U>] See Above > Another observation is that the draft attempts to provide a finer level o= f granularity in terms of specification for some errors. The resultant acti= on is no longer at a session but at a path level. >=20 > If one path has a mal-formed update I believe that all of the paths in th= at update are treated as withdrawn . If so, then this fix discards possibly= different sets of good paths at different egress PEs? I guess? Though if you're distributing a consistent set of routes within yo= ur AS I think you'll normally end up discarding them consistently too becau= se they'll arrive with the same (presumed to be malformed) attributes, whet= her packed into one update or spread across several. OTOH if you're not dis= tributing a consistent set of routes within your AS then yes, you are hoist= on your own petard.=20 [Jim U>] Have to think about this some more... Anything can happen of course if you posit just the right (wrong) set of bu= gs, but that way lies madness. I think in reasonably foreseeable circumstan= ces things will tend to go as I've described above. Even in the case where = inconsistency ensues, well, this is already broadly speaking a known side-e= ffect of the proposal and the notion is it's acceptable if the other altern= ative is session reset.=20 [Jim U>] Do not agree. Session reset is fine if forwarding is retained.. Th= at is the end goal not maintain a session and thus forwarding is retained. = As I commented on Rob's draft, we need to maintain forwarding through this = and other failure modes of a session, we cannot have different bottom up so= lutions for different errors.. > This may create inconsistent routing topologies as different "good paths"= may be discarded based on update packing at the ingress PE. So not an inco= nsistency for the path with the mal-formed attr but possibly all the others= packed in.. By definition all the prefixes packed in the same update share the same (pr= esumed to be malformed) attributes, so there is zero chance of an "innocent= " route catching a drive-by bullet as you describe.=20 [Jim U>] Ok. I thought the packing paradigm did not require all the exact s= ame attributes..=20 > Comments In-Line.. Ditto.=20 > Thanks, > Jim Uttaro >=20 >=20 > -----Original Message----- > From: John G. Scudder [mailto:jgs@juniper.net] > Sent: Monday, June 18, 2012 3:49 PM > To: UTTARO, JAMES > Cc: 'internet-drafts@ietf.org'; i-d-announce@ietf.org; idr@ietf.org > Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-02.txt >=20 > Hi Jim, >=20 > On Jun 17, 2012, at 8:29 PM, UTTARO, JAMES wrote: >=20 >> I took a read on this ( I will read more thoroughly) but one section jum= ped out at me. "Operational Considerations". >>=20 >>=20 >> Although the "treat-as-withdraw" error-handling behavior defined in >> Section 2 makes every effort to preserve BGP's correctness, we note >> that if an UPDATE received on an IBGP session is subjected to this >> treatment, inconsistent routing within the affected Autonomous System >> may result. The consequences of inconsistent routing can include >> long-lived forwarding loops and black holes. While lamentable, this >> issue is expected to be rare in practice, and more importantly is >> seen as less problematic than the session-reset behavior it replaces. >>=20 >> " When a malformed attribute is indeed detected over an IBGP session, >> we RECOMMEND that routes with the malformed attribute be identified >> and traced back to the ingress router in the network where the routes >> were sourced or received externally, and then a filter be applied on >> the ingress router to prevent the routes from being sourced or >> received. This will help maintain routing consistency in the >> network." >>=20 >>=20 >> I don't think the terminology "lamentable" to describe Long lived forwar= ding loops and black holes is appropriate as it would probably be more than= regrettable. >=20 > My dictionary says "(of circumstances or conditions) deplorably bad or un= satisfactory" which seems about right to me. We could have said "it really = sucks a lot" but the style seems wrong. :-) But this sentence could be rewr= itten as needed, it's not a big deal. > [Jim U>] Agreed it is bad/unsatisfactory. I guess I was addressing the pr= emise. >=20 >> Could you expand on the conditions >=20 > One very simple case: >=20 > A--B--C--D >=20 > The four routers depicted form an IBGP full mesh (sessions not shown). Th= e links shown are the physical topology. Standard IP forwarding is used. Ro= uters A and D are ASBRs and both advertise a path for prefix X into IBGP. R= outer C prefers the path from A, for example due to a shorter AS Path. Howe= ver, router B decides that the path from A is malformed, so it selects the = path from D. Now we have C's next hop to reach X as B, and B's next hop to = reach X as C. This is a stable forwarding loop. (Why do B and C have differ= ent conclusions about whether the update is malformed? Different code bases= with different assumptions, as we have seen more than once in the field.) > [Jim U>] Ouch. We could get some big flows going back and forth in our to= pology based upon the path in question... would this be trading forwarding = loops within a network for routing churn amongst networks and/or traffic re= -direction.. It sort of feels that way to me.. Potentially, yes. Devil, deep blue sea. One thing to observe is that a flap= ping bgp session in the middle of your network is the other alternative in = this scenario. Does that sound better to you? Most reviewers have thought i= t sounded worse.=20 >> and how BGP would eventually recover. >=20 > It wouldn't :-( without operator intervention. > [Jim U>] Ouch +1.. >=20 >> That would be a good addition. I am a bit confused, how does this type o= f error handling which restarts GR ( As of my last read ) and which BGP per= sistence lives through change the paradigm of these solutions? >=20 > I don't understand this question. > [Jim U>] Assume BGP current behavior.. The sessions would be torn down, B= GP Persist/GR ( Assume GR is modified to persist through a mal-formed attr = ) would become active.. See discussion above.=20 > In this model for a subset of failure modes the session would not be torn= down. I guess the issue is that for different error conditions we see diff= erent solutions/behaviors.. If malformed then no session tear down, treat a= s withdrawn, If timer expiry than if GR tear session down flush paths, BGP = Persistence session tear down maintain paths. I am war of the lack of consi= stency.. I think this is a legitimate case of different diseases having different cu= res, although as Enke (I think) mentioned in a different context, if we can= come up with a single, simpler, unified solution to these problems then th= at's great. Big "if", though.=20 >> There is a notion of treat as withdraw for some attrs, but don't tear do= wn session?? >=20 > Yes. You're right to find this shocking. I find it shocking, but have bee= n browbeaten :-)/2 into agreeing that the cure may be a little less bad tha= n the disease. However, the floor is still definitely open for debate! > [Jim U>] Ouch.. I don't like the notion of changing the fundamental natur= e of the protocol.. >=20 >> How many malformed updates before the session is torn down? Ever? >=20 > This was discussed a while ago, inconclusively. To date, I don't recall h= aving seen any suggestions I really liked for how to decide a session shoul= d be torn down. It actually seems to make things more complicated (to imple= ment, to debug in operation) to have two error-handling modes you flip betw= een according to some heuristic. The floor is still open for more discussio= n. > [Jim U>] Maybe determine the exposure to inconsistency.. >=20 >> According to the next paragraph ( See below ) there is an expectation th= at the offending ingress router should be identified, and then a filter sho= uld be applied for those paths in a given updated with the malformed attrs = :) What is the recommendation for doing this? >=20 > The router should log (and possibly trap, alarm, etc) the offending updat= e(s). The operator should examine the logs and by so doing, figure it out f= rom there. Sorry this seems glib but that's what it comes down to. Remember= that the alternate (present-day) scenario is that the BGP session to the a= ffected router is going to flap, which is likely even worse operationally, = possibly much worse. > [Jim U>] If we could persist the state than the damage from the flap shou= ld be mitigated.. Again, see above.=20 > Of course this is different based on application i.e internet, VPNV4, vPN= V2 etc... We would need to think about how to automate this.. >=20 >> Will there be a draft whereby the detecting router somehow figures out t= he offending ingress router, builds routing policy and then sends it there = to dynamically create the filter. >=20 > I sincerely hope not and have spoken against this idea in the past. > [Jim U>] LOL >=20 >> This seems non-trivial, >=20 > That's why. When you start building machinery to automatically patch arou= nd bugs in your primary routing machinery, IMO you have officially Jumped T= he Shark and started building a Rube Goldberg router. > [Jim U>] Yes. If there is a bug that should be fixed.. There are solution= that allow state to persist.. I would prefer this as opposed to modifying = the specification to deal with this one type of bug? BTW Is it extensible t= o other Update Message Errors?? The idea is to cover pretty much every message error, as long as the prefix= es still can be extracted and the update boundaries determined, yes.=20 Thanks, =20 --John >> I guess Flowspec like technology may be used not sure.. Is the ingress r= outer assumed to be in the same AS domain as the detecting router? >=20 > Since the paragraph is talking about IBGP, yes. Of course this doesn't me= an the offending update was sourced within the same AS, but the paragraph y= ou're picking on is just talking about what happens within IBGP. > [Jim U>] Yup. Assuming same AS then like flowspec there may be a way but = again it is patching a bug in the machinery.. >=20 > Note that draft-ietf-grow-ops-reqs-for-bgp-error-handling-04.txt is very = applicable to this discussion and is currently in WGLC in GROW. Since you h= ave opinions about this topic I strongly suggest you review it and comment = on the GROW WGLC. It runs until June 25.[Jim U>] I will.. Thx... >=20 > --John >=20 >> Administrative domain may span multiple AS domains.. >>=20 >> Jim Uttaro >>=20 >>=20 >>=20 >>=20 >> -----Original Message----- >> From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of in= ternet-drafts@ietf.org >> Sent: Sunday, June 17, 2012 4:45 PM >> To: i-d-announce@ietf.org >> Cc: idr@ietf.org >> Subject: [Idr] I-D Action: draft-ietf-idr-error-handling-02.txt >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts direc= tories. >> This draft is a work item of the Inter-Domain Routing Working Group of t= he IETF. >>=20 >> Title : Revised Error Handling for BGP UPDATE Messages >> Author(s) : John G. Scudder >> Enke Chen >> Pradosh Mohapatra >> Keyur Patel >> Filename : draft-ietf-idr-error-handling-02.txt >> Pages : 10 >> Date : 2012-06-17 >>=20 >> Abstract: >> According to the base BGP specification, a BGP speaker that receives >> an UPDATE message containing a malformed attribute is required to >> reset the session over which the offending attribute was received. >> This behavior is undesirable as a session reset would impact not only >> routes with the offending attribute, but also other valid routes >> exchanged over the session. This document partially revises the >> error handling for UPDATE messages, and provides guidelines for the >> authors of documents defining new attributes. Finally, it revises >> the error handling procedures for several existing attributes. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-idr-error-handling >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-idr-error-handling-02 >>=20 >> A diff from previous version is available at: >> http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-error-handling-02 >>=20 >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> 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 From enkechen@cisco.com Fri Jun 22 10:17:24 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6EA111E80A4 for ; Fri, 22 Jun 2012 10:17:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.301, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3s4Thz7H-wnF for ; Fri, 22 Jun 2012 10:17:18 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 5BBCB11E8087 for ; Fri, 22 Jun 2012 10:17:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=enkechen@cisco.com; l=17145; q=dns/txt; s=iport; t=1340385438; x=1341595038; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=ZzEH0Z1VhGFrqGVVJFI/Q86VB3IpCdOd52OXqebM7+Y=; b=hQpgkoP/eAjMH4WGjyW1G139mBBv/EU8/hcfkgMcd7MZpa2Y9jxmo7Yh ybzJ8KpVzmlBHRleT02QHj5umNb/ZB74Nlx31NUtWv0SGbLKDb5Ieg2Um /ccKF2yYIxVGuDS2XN3WMkDlU/8/E8WhyDEwExEQq9nKxEMD3PH92aMVI 0=; X-IronPort-AV: E=Sophos;i="4.77,459,1336348800"; d="scan'208,217";a="47328844" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 22 Jun 2012 17:17:18 +0000 Received: from sjc-vpn4-1382.cisco.com (sjc-vpn4-1382.cisco.com [10.21.85.101]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q5MHHHRl027873; Fri, 22 Jun 2012 17:17:17 GMT Message-ID: <4FE4A8F3.20809@cisco.com> Date: Fri, 22 Jun 2012 10:18:43 -0700 From: Enke Chen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Saikat Ray (sairay)" References: <003c01cd4b29$97d7b150$c78713f0$@ndzh.com> <985EF8D2-DA8A-4BE7-94D3-F4BE2B74D768@castlepoint.net> <4FE07A24.7050804@raszuk.net> <1C1F2B2E-2EB7-42F0-8CFF-57965443C074@castlepoint.net> <7A614998-8FB1-4A51-9937-DE501FF31EB6@juniper.net> <4FE0D1F4.9070208@cisco.com> <4FE0E074.3070905@raszuk.net> <17490_1340180565_4FE18855_17490_15423_1_53C29892C857584299CBF5D05346208A0928AA@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FE18A61.8000405@raszuk.net> <8ED5B0B0F5B4854A912480C1521F973AD95B@xmb-rcd-x13.cisco.com> In-Reply-To: <8ED5B0B0F5B4854A912480C1521F973AD95B@xmb-rcd-x13.cisco.com> Content-Type: multipart/alternative; boundary="------------010004050007080300000003" Cc: "idr@ietf.org" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2012 17:17:24 -0000 This is a multi-part message in MIME format. --------------010004050007080300000003 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, Saikat: A new capability would certainly help. It seems necessary, but may not be sufficient to limit the scope of the STALE path to "consenting adults". For example, inside a network (i.e., AS), if there are routers that do not recognize the STALE community, a STALE path may still be advertised to external peers without the capability. This means that all the routers in a network must recognize the community before enabling the capability on any of them. It will be difficult to satisfy the condition universally. In addition, to limit its scope the STALE community, once set, MUST not be removed by any receiver. -- Enke On 6/22/12 9:34 AM, Saikat Ray (sairay) wrote: > > Without being involved in the discussion whether it is the right > problem to tackle or not, I would like to make the observation that at > the very least, the draft needs to define a new BGP capability for the > willingness to accept STALE routes. Peers that has not negotiated this > capability MUST receive paths "as if" the STALE paths did not exist. > This includes that STALE paths and any non-STALE paths whose nexthops > resolve over a STALE paths MUST also not be sent to a such a peer. > This way, negotiation of this capability by consenting adults will > define an island where stale routes would roam free without affecting > others. > > *From:*idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] *On Behalf > Of *Senad .Palislamovic > *Sent:* Friday, June 22, 2012 7:24 AM > *To:* idr@ietf.org > *Cc:* shares@ndzh.com > *Subject:* Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG > document - 3 more weeks > > IETF mail server glitch; resending: Note: Robert already > commented back > > Apologize for the delay on comments, > > Robert, > > After going through all the emails, I admit, you've made a lot of > valuable comments that 'seriously' MUST be considered in the new > version of the draft. However, putting that aside, I would really > expect this to be saved for WG discussions. I would think that at > this stage, we are more less agreeing to take a look at this problem > and its solution space. > > Robert, Randy, Shane, > > The main question I have for you is why object something that might > not even affect you. Draft's primary purpose is for the protection of > the control plane for non-internet services (vpls, l2vpn, or > infrustructure routes, i.e. BGP-3107), which in all cases does not > affect you or me in any shape or form. For folks to chose to extend > this to l3vpn or even to IPv4/IPv6 space, they are doing it > consciously knowing the nature of their network and its dynamics. If > you do see a route with the STALE community, and do not desire to use > this path due its "unreliable" nature, you can request your provider > to withdraw the routes with STALE community effectively making them > DO_NOT_PERSIST at the source which effectively mimics the standard GR > behavior; as Bruno stated, at eBGP, people are talking and negotiating. > > So given all that, help me understand how could this impact anyone who > chooses not to use it. Am I missing anything? > > On the side note, Susan, I do support this draft as WG document. > > Senad > > On Wed, Jun 20, 2012 at 4:31 AM, Robert Raszuk > wrote: > > Yet, IMHO building a good (reliable, performant) BGP > implementation is hard. > > True. And changing it's fundamental behaviour every few months > does not help to make it reliable/ performant either ;) > > I don't think operators would do a better job on the BGP > implementation side. > > I am not asking for that at all. I am asking to simply use > multiple implementations in the backend. Not two .. but 4 or 5. > Probability that all fail/melt with the same bug I think is very > very low. > > Of course I admit that if you one uses service which only single > vendor supports in BGP then one get's a bit stuck with the risk. > And that seems to be one of the silent "problem statement" here. > > Rgs, > > > R. > > _______________________________________________ > 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 --------------010004050007080300000003 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, Saikat:

A new capability would certainly help.  It seems necessary, but may not be sufficient to limit the scope of the STALE path to "consenting adults".   For example, inside a network (i.e., AS), if there are routers that do not recognize the STALE community, a STALE path may still be advertised to external peers without the capability.   This means that all the routers in a network must recognize the community before enabling the capability on any of them.  It will be difficult to satisfy the condition universally.

In addition, to limit its scope the STALE community, once set, MUST not be removed by any receiver.

-- Enke

On 6/22/12 9:34 AM, Saikat Ray (sairay) wrote:

Without being involved in the discussion whether it is the right problem to tackle or not, I would like to make the observation that at the very least, the draft needs to define a new BGP capability for the willingness to accept STALE routes. Peers that has not negotiated this capability MUST receive paths “as if” the STALE paths did not exist. This includes that STALE paths and any non-STALE paths whose nexthops resolve over a STALE paths MUST also not be sent to a such a peer. This way, negotiation of this capability by consenting adults will define an island where stale routes would roam free without affecting others.

 

From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Senad .Palislamovic
Sent: Friday, June 22, 2012 7:24 AM
To: idr@ietf.org
Cc: shares@ndzh.com
Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks

 

IETF mail server glitch;  resending: Note: Robert already commented back

 

Apologize for the delay on comments,

Robert,

After going through all the emails, I admit, you've made a lot of valuable comments that 'seriously' MUST be considered in the new version of the draft.  However, putting that aside, I would really expect this to be saved for WG discussions.  I would think that at this stage, we are more less agreeing to take a look at this problem and its solution space. 

Robert, Randy, Shane,

The main question I have for you is why object something that might not even affect you.  Draft's primary purpose is for the protection of the control plane for non-internet services (vpls, l2vpn, or infrustructure routes, i.e. BGP-3107), which in all cases does not affect you or me in any shape or form.  For folks to chose to extend this to l3vpn or even to IPv4/IPv6 space, they are doing it consciously knowing the nature of their network and its dynamics.  If you do see a route with the STALE community, and do not desire to use this path due its "unreliable" nature, you can request your provider to withdraw the routes with STALE community effectively making them DO_NOT_PERSIST at the source which effectively mimics the standard GR behavior; as Bruno stated, at eBGP, people are talking and negotiating.

So given all that, help me understand how could this impact anyone who chooses not to use it.  Am I missing anything?

On the side note, Susan, I do support this draft as WG document.

 

Senad

 

 

 

 

 

On Wed, Jun 20, 2012 at 4:31 AM, Robert Raszuk <robert@raszuk.net> wrote:

 

Yet, IMHO building a good (reliable, performant) BGP implementation is hard.

 

True. And changing it's fundamental behaviour every few months does not help to make it reliable/ performant either ;)

 

I don't think operators would do a better job on the BGP implementation side.

 

I am not asking for that at all. I am asking to simply use multiple implementations in the backend. Not two .. but 4 or 5. Probability that all fail/melt with the same bug I think is very very low.

Of course I admit that if you one uses service which only single vendor supports in BGP then one get's a bit stuck with the risk. And that seems to be one of the silent "problem statement" here.

Rgs,


R.

_______________________________________________
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

--------------010004050007080300000003-- From ju1738@att.com Fri Jun 22 10:28:17 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5965821F8797 for ; Fri, 22 Jun 2012 10:28:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.103 X-Spam-Level: X-Spam-Status: No, score=-106.103 tagged_above=-999 required=5 tests=[AWL=-0.105, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UA1q0EOI-cUG for ; Fri, 22 Jun 2012 10:28:12 -0700 (PDT) Received: from nbfkord-smmo04.seg.att.com (nbfkord-smmo04.seg.att.com [209.65.160.86]) by ietfa.amsl.com (Postfix) with ESMTP id 4A0FC21F8792 for ; Fri, 22 Jun 2012 10:28:11 -0700 (PDT) Received: from unknown [144.160.128.153] (EHLO nbfkord-smmo04.seg.att.com) by nbfkord-smmo04.seg.att.com(mxl_mta-6.11.0-10) with ESMTP id b2ba4ef4.63802940.1482986.00-556.4106081.nbfkord-smmo04.seg.att.com (envelope-from ); Fri, 22 Jun 2012 17:28:11 +0000 (UTC) X-MXL-Hash: 4fe4ab2b2ae2249c-36bdfd07dd49a10a8c4ccd235e5aea49a1cc94f9 Received: from unknown [144.160.128.153] (EHLO flpi408.enaf.ffdc.sbc.com) by nbfkord-smmo04.seg.att.com(mxl_mta-6.11.0-10) over TLS secured channel with ESMTP id 62ba4ef4.0.1482971.00-266.4106033.nbfkord-smmo04.seg.att.com (envelope-from ); Fri, 22 Jun 2012 17:28:06 +0000 (UTC) X-MXL-Hash: 4fe4ab266b345925-15be9029a3e70683226bd184448738e6a529daf8 Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q5MHS4oD002965; Fri, 22 Jun 2012 10:28:05 -0700 Received: from fflint04.pst.cso.att.com (fflint04.pst.cso.att.com [150.234.39.64]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q5MHRxZG002881 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Jun 2012 10:28:02 -0700 Received: from MISOUT7MSGHUB9F.ITServices.sbc.com (misout7msghub9f.itservices.sbc.com [144.151.223.71]) by fflint04.pst.cso.att.com (RSA Interceptor); Fri, 22 Jun 2012 10:27:29 -0700 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9F.ITServices.sbc.com ([144.151.223.71]) with mapi id 14.02.0298.004; Fri, 22 Jun 2012 13:27:28 -0400 From: "UTTARO, JAMES" To: "'Enke Chen'" , "Saikat Ray (sairay)" Thread-Topic: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks Thread-Index: AQHNUIKv4gES0WzL/kWO4I5ojxcnRZcGy9WAgAAMWYD//70toA== Date: Fri, 22 Jun 2012 17:27:28 +0000 Message-ID: References: <003c01cd4b29$97d7b150$c78713f0$@ndzh.com> <985EF8D2-DA8A-4BE7-94D3-F4BE2B74D768@castlepoint.net> <4FE07A24.7050804@raszuk.net> <1C1F2B2E-2EB7-42F0-8CFF-57965443C074@castlepoint.net> <7A614998-8FB1-4A51-9937-DE501FF31EB6@juniper.net> <4FE0D1F4.9070208@cisco.com> <4FE0E074.3070905@raszuk.net> <17490_1340180565_4FE18855_17490_15423_1_53C29892C857584299CBF5D05346208A0928AA@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FE18A61.8000405@raszuk.net> <8ED5B0B0F5B4854A912480C1521F973AD95B@xmb-rcd-x13.cisco.com> <4FE4A8F3.20809@cisco.com> In-Reply-To: <4FE4A8F3.20809@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.151.80] Content-Type: multipart/alternative; boundary="_000_B17A6910EEDD1F45980687268941550FB1F8B9MISOUT7MSGUSR9IIT_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.128.153] X-AnalysisOut: [v=1.0 c=1 a=dXkvp1zHZaMA:10 a=ZQD3OTTxKqYA:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=xwOvzTHDVLE4u4nGvK72ag==:17 a=48] X-AnalysisOut: [vgC7mUAAAA:8 a=1sjgXBK7AAAA:8 a=2clOPd4PAAAA:8 a=Wh0hONagF] X-AnalysisOut: [D2dy5SoJG8A:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=kZwP4K] X-AnalysisOut: [TQBigA:10 a=bDUki_mJ7DgA:10 a=995eJDShJvKLgiDa:21 a=v7GFg8] X-AnalysisOut: [5FKOR12OMS:21 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=gKO2Hq4R] X-AnalysisOut: [SVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=tXsnliwV7b4A] X-AnalysisOut: [:10 a=hdcCwMUJwMTZS9ud:21 a=FQ56WgYtKeaTjcnR:21] Cc: "idr@ietf.org" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2012 17:28:17 -0000 --_000_B17A6910EEDD1F45980687268941550FB1F8B9MISOUT7MSGUSR9IIT_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Enke, The idea behind the setting of STALE is to inform speakers = in other AS domains that the path is suspect as the session it was learned = over is down.. IMO this is required to inform others about the viability of= a path.. The other approach is to simply not mark these paths as STALE.. Simply de-p= ref in the local AS and business as usual when advertised outside the AS wh= ere all transitive attrs are reset.. This is exactly the semantic you are using in the GR draft. You do not de-p= ref the state locally and do not inform other AS domains that the paths lea= rned over the session that GR is active on are suspect. If the STALE CV is not honored across the AS border than the behavior defau= lts to what is specified in the GR draft. This should meet your requirement= s. Jim Uttaro From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Enke = Chen Sent: Friday, June 22, 2012 1:19 PM To: Saikat Ray (sairay) Cc: idr@ietf.org Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document -= 3 more weeks Hi, Saikat: A new capability would certainly help. It seems necessary, but may not be = sufficient to limit the scope of the STALE path to "consenting adults". F= or example, inside a network (i.e., AS), if there are routers that do not r= ecognize the STALE community, a STALE path may still be advertised to exter= nal peers without the capability. This means that all the routers in a ne= twork must recognize the community before enabling the capability on any of= them. It will be difficult to satisfy the condition universally. In addition, to limit its scope the STALE community, once set, MUST not be = removed by any receiver. -- Enke On 6/22/12 9:34 AM, Saikat Ray (sairay) wrote: Without being involved in the discussion whether it is the right problem to= tackle or not, I would like to make the observation that at the very least= , the draft needs to define a new BGP capability for the willingness to acc= ept STALE routes. Peers that has not negotiated this capability MUST receiv= e paths "as if" the STALE paths did not exist. This includes that STALE pat= hs and any non-STALE paths whose nexthops resolve over a STALE paths MUST a= lso not be sent to a such a peer. This way, negotiation of this capability = by consenting adults will define an island where stale routes would roam fr= ee without affecting others. From: idr-bounces@ietf.org [mailto:idr-bounces= @ietf.org] On Behalf Of Senad .Palislamovic Sent: Friday, June 22, 2012 7:24 AM To: idr@ietf.org Cc: shares@ndzh.com Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document -= 3 more weeks IETF mail server glitch; resending: Note: Robert already commented back Apologize for the delay on comments, Robert, After going through all the emails, I admit, you've made a lot of valuable = comments that 'seriously' MUST be considered in the new version of the draf= t. However, putting that aside, I would really expect this to be saved for= WG discussions. I would think that at this stage, we are more less agreei= ng to take a look at this problem and its solution space. Robert, Randy, Shane, The main question I have for you is why object something that might not eve= n affect you. Draft's primary purpose is for the protection of the control= plane for non-internet services (vpls, l2vpn, or infrustructure routes, i.= e. BGP-3107), which in all cases does not affect you or me in any shape or = form. For folks to chose to extend this to l3vpn or even to IPv4/IPv6 spac= e, they are doing it consciously knowing the nature of their network and it= s dynamics. If you do see a route with the STALE community, and do not des= ire to use this path due its "unreliable" nature, you can request your prov= ider to withdraw the routes with STALE community effectively making them DO= _NOT_PERSIST at the source which effectively mimics the standard GR behavio= r; as Bruno stated, at eBGP, people are talking and negotiating. So given all that, help me understand how could this impact anyone who choo= ses not to use it. Am I missing anything? On the side note, Susan, I do support this draft as WG document. Senad On Wed, Jun 20, 2012 at 4:31 AM, Robert Raszuk > wrote: Yet, IMHO building a good (reliable, performant) BGP implementation is hard= . True. And changing it's fundamental behaviour every few months does not hel= p to make it reliable/ performant either ;) I don't think operators would do a better job on the BGP implementation sid= e. I am not asking for that at all. I am asking to simply use multiple impleme= ntations in the backend. Not two .. but 4 or 5. Probability that all fail/m= elt with the same bug I think is very very low. Of course I admit that if you one uses service which only single vendor sup= ports in BGP then one get's a bit stuck with the risk. And that seems to be= one of the silent "problem statement" here. Rgs, R. _______________________________________________ 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 --_000_B17A6910EEDD1F45980687268941550FB1F8B9MISOUT7MSGUSR9IIT_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Enke,

 <= /p>

    &= nbsp;           The idea = behind the setting of STALE is to inform speakers in other AS domains that = the path is suspect as the session it was learned over is down.. IMO this is required to inform others about the viability of a path= ..

 <= /p>

The other approach is to = simply not mark these paths as STALE.. Simply de-pref in the local AS and b= usiness as usual when advertised outside the AS where all transitive attrs are reset..

 <= /p>

This is exactly the seman= tic you are using in the GR draft. You do not de-pref the state locally and= do not inform other AS domains that the paths learned over the session that GR is active on are suspect.

 <= /p>

If the STALE CV is not ho= nored across the AS border than the behavior defaults to what is specified = in the GR draft. This should meet your requirements.

 <= /p>

Jim Uttaro

 <= /p>

From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org= ] On Behalf Of Enke Chen
Sent: Friday, June 22, 2012 1:19 PM
To: Saikat Ray (sairay)
Cc: idr@ietf.org
Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG doc= ument - 3 more weeks

 

Hi, Saikat:

A new capability would certainly help.  It seems necessary, but may no= t be sufficient to limit the scope of the STALE path to "consenting ad= ults".   For example, inside a network (i.e., AS), if there = are routers that do not recognize the STALE community, a STALE path may still be advertised to external peers without the capabilit= y.   This means that all the routers in a network must recognize = the community before enabling the capability on any of them.  It will = be difficult to satisfy the condition universally.

In addition, to limit its scope the STALE community, once set, MUST not be = removed by any receiver.

-- Enke

On 6/22/12 9:34 AM, Saikat Ray (sairay) wrote:

Without being involved in= the discussion whether it is the right problem to tackle or not, I would l= ike to make the observation that at the very least, the draft needs to define a new BGP capability for the willingness to accept S= TALE routes. Peers that has not negotiated this capability MUST receive pat= hs “as if” the STALE paths did not exist. This includes that ST= ALE paths and any non-STALE paths whose nexthops resolve over a STALE paths MUST also not be sent to a such a peer. This wa= y, negotiation of this capability by consenting adults will define an islan= d where stale routes would roam free without affecting others.<= /o:p>

 <= /p>

From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Senad .Palislamovic
Sent: Friday, June 22, 2012 7:24 AM
To: idr@ietf.org
Cc: shares@ndzh.com
Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG doc= ument - 3 more weeks

 

IETF mail server glitch;  resending: Note: Robert= already commented back

 

Apologize for the delay on comments,

Robert,

After going through all the emails, I admit, you've made a = lot of valuable comments that 'seriously' MUST be considered in the new ver= sion of the draft.  However, putting that aside, I would really expect= this to be saved for WG discussions.  I would think that at this stage, we are more less agreeing to take a look= at this problem and its solution space. 

Robert, Randy, Shane,

The main question I have for you is why object something th= at might not even affect you.  Draft's primary purpose is for the= protection of the control plane for non-internet services (vpls, l2vpn, or= infrustructure routes, i.e. BGP-3107), which in all cases does not affect you or me in any shape or form.  For fol= ks to chose to extend this to l3vpn or even to IPv4/IPv6 space, they are do= ing it consciously knowing the nature of their network and its dynamics.&nb= sp; If you do see a route with the STALE community, and do not desire to use this path due its "unreliable" nature, = you can request your provider to withdraw the routes with STALE community e= ffectively making them DO_NOT_PERSIST at the source which effectively mimic= s the standard GR behavior; as Bruno stated, at eBGP, people are talking and negotiating.

So given all that, help me understand how could this impact= anyone who chooses not to use it.  Am I missing anything?<= /p>

On the side note, Susan, I do support this draft as WG docu= ment.

 

Senad

 

 

 

 

 

On Wed, Jun 20, 2012 at 4:31 AM, Robert Raszuk <<= a href=3D"mailto:robert@raszuk.net" target=3D"_blank">robert@raszuk.net= > wrote:

 

Yet, IMHO building a good (reliable, performant) BGP= implementation is hard.

 

True. And changing it's fundamental behaviour every = few months does not help to make it reliable/ performant either ;)

 

I don't think operators would do a better job on the= BGP implementation side.

 

I am not asking for that at all. I am asking to simp= ly use multiple implementations in the backend. Not two .. but 4 or 5. Prob= ability that all fail/melt with the same bug I think is very very low.

Of course I admit that if you one uses service which only single vendor sup= ports in BGP then one get's a bit stuck with the risk. And that seems to be= one of the silent "problem statement" here.

Rgs,


R.

_______________________________________________
Idr mailing list
Idr@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/idr

 

 




_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf=
.org/mailman/listinfo/idr

 

--_000_B17A6910EEDD1F45980687268941550FB1F8B9MISOUT7MSGUSR9IIT_-- From sairay@cisco.com Fri Jun 22 10:31:00 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39EC911E80AE for ; Fri, 22 Jun 2012 10:31:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.998 X-Spam-Level: X-Spam-Status: No, score=-9.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iVqmbcYCa8O2 for ; Fri, 22 Jun 2012 10:30:56 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id A126F11E80AD for ; Fri, 22 Jun 2012 10:30:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sairay@cisco.com; l=17230; q=dns/txt; s=iport; t=1340386256; x=1341595856; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=wWB7uIEqHP1QuHFWvvoxsrmmCw8/5S7oqBDCM5x3rUc=; b=mNm9EH6DLKcukXeV4H8WWs+M+d2mdJkG1oCAGeWJGaTgOTDcleewRWoS 3zGLFYorNurigC+nPqNv4ePuiK5l3wN8LPgaEZjJ5qiPYy2U7SmSGLRlY kx40msCah4QRS+5Ooe3QST/6iuSEGpbjb9hNgggUziH1F+EpJANhjVCrr U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An0FADWr5E+tJV2d/2dsb2JhbABFgkWFda0qgQeCGAEBAQQBAQEPARpBBgUQAgEIEQQBAQsdBycLFAkIAgQOBQgMBweHaQuaKqADBIsuFQWFCGADo0eBZoEtgTKBVgEEBA X-IronPort-AV: E=Sophos;i="4.77,459,1336348800"; d="scan'208,217";a="95072224" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-4.cisco.com with ESMTP; 22 Jun 2012 17:30:55 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q5MHUtmw030363 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 22 Jun 2012 17:30:55 GMT Received: from xmb-rcd-x13.cisco.com ([169.254.3.37]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0298.004; Fri, 22 Jun 2012 12:30:55 -0500 From: "Saikat Ray (sairay)" To: "Enke Chen (enkechen)" Thread-Topic: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks Thread-Index: AQHNUIK5992oODS5z0GaMDFvi/PwiZcGhN0ggABkFID//65x8A== Date: Fri, 22 Jun 2012 17:30:54 +0000 Message-ID: <8ED5B0B0F5B4854A912480C1521F973AD9C9@xmb-rcd-x13.cisco.com> References: <003c01cd4b29$97d7b150$c78713f0$@ndzh.com> <985EF8D2-DA8A-4BE7-94D3-F4BE2B74D768@castlepoint.net> <4FE07A24.7050804@raszuk.net> <1C1F2B2E-2EB7-42F0-8CFF-57965443C074@castlepoint.net> <7A614998-8FB1-4A51-9937-DE501FF31EB6@juniper.net> <4FE0D1F4.9070208@cisco.com> <4FE0E074.3070905@raszuk.net> <17490_1340180565_4FE18855_17490_15423_1_53C29892C857584299CBF5D05346208A0928AA@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FE18A61.8000405@raszuk.net> <8ED5B0B0F5B4854A912480C1521F973AD95B@xmb-rcd-x13.cisco.com> <4FE4A8F3.20809@cisco.com> In-Reply-To: <4FE4A8F3.20809@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.119.214] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-18988.006 x-tm-as-result: No--53.285600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_8ED5B0B0F5B4854A912480C1521F973AD9C9xmbrcdx13ciscocom_" MIME-Version: 1.0 Cc: "idr@ietf.org" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2012 17:31:00 -0000 --_000_8ED5B0B0F5B4854A912480C1521F973AD9C9xmbrcdx13ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Saikat: A new capability would certainly help. It seems necessary, but may not be = sufficient to limit the scope of the STALE path to "consenting adults". F= or example, inside a network (i.e., AS), if there are routers that do not r= ecognize the STALE community, [SR] That router must not negotiate the STALE capability with any peer, iBG= P or eBGP, and hence should not receive any stale path from any router. The= stale capability must be negotiated even within iBGP peers. To avoid incon= sistency of iBGP routes in an AS, you might need to add the restriction tha= t unless all iBGP peers negotiate the new capability, STALE paths should no= t be sent to any of them. a STALE path may still be advertised to external peers without the capabili= ty. This means that all the routers in a network must recognize the commu= nity before enabling the capability on any of them. It will be difficult t= o satisfy the condition universally. In addition, to limit its scope the STALE community, once set, MUST not be = removed by any receiver. -- Enke On 6/22/12 9:34 AM, Saikat Ray (sairay) wrote: Without being involved in the discussion whether it is the right problem to= tackle or not, I would like to make the observation that at the very least= , the draft needs to define a new BGP capability for the willingness to acc= ept STALE routes. Peers that has not negotiated this capability MUST receiv= e paths "as if" the STALE paths did not exist. This includes that STALE pat= hs and any non-STALE paths whose nexthops resolve over a STALE paths MUST a= lso not be sent to a such a peer. This way, negotiation of this capability = by consenting adults will define an island where stale routes would roam fr= ee without affecting others. From: idr-bounces@ietf.org [mailto:idr-bounces= @ietf.org] On Behalf Of Senad .Palislamovic Sent: Friday, June 22, 2012 7:24 AM To: idr@ietf.org Cc: shares@ndzh.com Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document -= 3 more weeks IETF mail server glitch; resending: Note: Robert already commented back Apologize for the delay on comments, Robert, After going through all the emails, I admit, you've made a lot of valuable = comments that 'seriously' MUST be considered in the new version of the draf= t. However, putting that aside, I would really expect this to be saved for= WG discussions. I would think that at this stage, we are more less agreei= ng to take a look at this problem and its solution space. Robert, Randy, Shane, The main question I have for you is why object something that might not eve= n affect you. Draft's primary purpose is for the protection of the control= plane for non-internet services (vpls, l2vpn, or infrustructure routes, i.= e. BGP-3107), which in all cases does not affect you or me in any shape or = form. For folks to chose to extend this to l3vpn or even to IPv4/IPv6 spac= e, they are doing it consciously knowing the nature of their network and it= s dynamics. If you do see a route with the STALE community, and do not des= ire to use this path due its "unreliable" nature, you can request your prov= ider to withdraw the routes with STALE community effectively making them DO= _NOT_PERSIST at the source which effectively mimics the standard GR behavio= r; as Bruno stated, at eBGP, people are talking and negotiating. So given all that, help me understand how could this impact anyone who choo= ses not to use it. Am I missing anything? On the side note, Susan, I do support this draft as WG document. Senad On Wed, Jun 20, 2012 at 4:31 AM, Robert Raszuk > wrote: Yet, IMHO building a good (reliable, performant) BGP implementation is hard= . True. And changing it's fundamental behaviour every few months does not hel= p to make it reliable/ performant either ;) I don't think operators would do a better job on the BGP implementation sid= e. I am not asking for that at all. I am asking to simply use multiple impleme= ntations in the backend. Not two .. but 4 or 5. Probability that all fail/m= elt with the same bug I think is very very low. Of course I admit that if you one uses service which only single vendor sup= ports in BGP then one get's a bit stuck with the risk. And that seems to be= one of the silent "problem statement" here. Rgs, R. _______________________________________________ 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 --_000_8ED5B0B0F5B4854A912480C1521F973AD9C9xmbrcdx13ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, Saikat:

A new capability would certainly help.  It seems necessary, but may no= t be sufficient to limit the scope of the STALE path to "consenting ad= ults".   For example, inside a network (i.e., AS), if there = are routers that do not recognize the STALE community,

[SR] That router must not= negotiate the STALE capability with any peer, iBGP or eBGP, and hence shou= ld not receive any stale path from any router. The stale capability must be negotiated even within iBGP peers. To avoid inconsisten= cy of iBGP routes in an AS, you might need to add the restriction that unle= ss all iBGP peers negotiate the new capability, STALE paths should not be s= ent to any of them.

 <= /p>

a STALE path may still be advertised to external pee= rs without the capability.   This means that all the routers in a= network must recognize the community before enabling the capability on any= of them.  It will be difficult to satisfy the condition universally.

In addition, to limit its scope the STALE community, once set, MUST not be = removed by any receiver.

-- Enke

On 6/22/12 9:34 AM, Saikat Ray (sairay) wrote:

Without being involved in= the discussion whether it is the right problem to tackle or not, I would l= ike to make the observation that at the very least, the draft needs to define a new BGP capability for the willingness to accept S= TALE routes. Peers that has not negotiated this capability MUST receive pat= hs “as if” the STALE paths did not exist. This includes that ST= ALE paths and any non-STALE paths whose nexthops resolve over a STALE paths MUST also not be sent to a such a peer. This wa= y, negotiation of this capability by consenting adults will define an islan= d where stale routes would roam free without affecting others.<= /o:p>

 <= /p>

From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Senad .Palislamovic
Sent: Friday, June 22, 2012 7:24 AM
To: idr@ietf.org
Cc: shares@ndzh.com
Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG doc= ument - 3 more weeks

 

IETF mail server glitch;  resending: Note: Robert= already commented back

 

Apologize for the delay on comments,

Robert,

After going through all the emails, I admit, you've made a = lot of valuable comments that 'seriously' MUST be considered in the new ver= sion of the draft.  However, putting that aside, I would really expect= this to be saved for WG discussions.  I would think that at this stage, we are more less agreeing to take a look= at this problem and its solution space. 

Robert, Randy, Shane,

The main question I have for you is why object something th= at might not even affect you.  Draft's primary purpose is for the= protection of the control plane for non-internet services (vpls, l2vpn, or= infrustructure routes, i.e. BGP-3107), which in all cases does not affect you or me in any shape or form.  For fol= ks to chose to extend this to l3vpn or even to IPv4/IPv6 space, they are do= ing it consciously knowing the nature of their network and its dynamics.&nb= sp; If you do see a route with the STALE community, and do not desire to use this path due its "unreliable" nature, = you can request your provider to withdraw the routes with STALE community e= ffectively making them DO_NOT_PERSIST at the source which effectively mimic= s the standard GR behavior; as Bruno stated, at eBGP, people are talking and negotiating.

So given all that, help me understand how could this impact= anyone who chooses not to use it.  Am I missing anything?<= /p>

On the side note, Susan, I do support this draft as WG docu= ment.

 

Senad

 

 

 

 

 

On Wed, Jun 20, 2012 at 4:31 AM, Robert Raszuk <<= a href=3D"mailto:robert@raszuk.net" target=3D"_blank">robert@raszuk.net= > wrote:

 

Yet, IMHO building a good (reliable, performant) BGP= implementation is hard.

 

True. And changing it's fundamental behaviour every = few months does not help to make it reliable/ performant either ;)

 

I don't think operators would do a better job on the= BGP implementation side.

 

I am not asking for that at all. I am asking to simp= ly use multiple implementations in the backend. Not two .. but 4 or 5. Prob= ability that all fail/melt with the same bug I think is very very low.

Of course I admit that if you one uses service which only single vendor sup= ports in BGP then one get's a bit stuck with the risk. And that seems to be= one of the silent "problem statement" here.

Rgs,


R.

_______________________________________________
Idr mailing list
Idr@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/idr

 

 




_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf=
.org/mailman/listinfo/idr

 

--_000_8ED5B0B0F5B4854A912480C1521F973AD9C9xmbrcdx13ciscocom_-- From jakob.heitz@ericsson.com Fri Jun 22 10:36:37 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0329211E80AE for ; Fri, 22 Jun 2012 10:36:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.33 X-Spam-Level: X-Spam-Status: No, score=-6.33 tagged_above=-999 required=5 tests=[AWL=0.268, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ECnsawVhIR4N for ; Fri, 22 Jun 2012 10:36:36 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id A2BAF11E80D1 for ; Fri, 22 Jun 2012 10:36:27 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q5MHaOeQ012827 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 Jun 2012 12:36:24 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.64]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Fri, 22 Jun 2012 13:36:24 -0400 From: Jakob Heitz To: "Saikat Ray (sairay)" , "Enke Chen (enkechen)" Date: Fri, 22 Jun 2012 13:36:23 -0400 Thread-Topic: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks Thread-Index: AQHNUIK5992oODS5z0GaMDFvi/PwiZcGhN0ggABkFID//65x8IAAAddQ Message-ID: <7309FCBCAE981B43ABBE69B31C8D213921C23CA13C@EUSAACMS0701.eamcs.ericsson.se> References: <003c01cd4b29$97d7b150$c78713f0$@ndzh.com> <985EF8D2-DA8A-4BE7-94D3-F4BE2B74D768@castlepoint.net> <4FE07A24.7050804@raszuk.net> <1C1F2B2E-2EB7-42F0-8CFF-57965443C074@castlepoint.net> <7A614998-8FB1-4A51-9937-DE501FF31EB6@juniper.net> <4FE0D1F4.9070208@cisco.com> <4FE0E074.3070905@raszuk.net> <17490_1340180565_4FE18855_17490_15423_1_53C29892C857584299CBF5D05346208A0928AA@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FE18A61.8000405@raszuk.net> <8ED5B0B0F5B4854A912480C1521F973AD95B@xmb-rcd-x13.cisco.com> <4FE4A8F3.20809@cisco.com> <8ED5B0B0F5B4854A912480C1521F973AD9C9@xmb-rcd-x13.cisco.com> In-Reply-To: <8ED5B0B0F5B4854A912480C1521F973AD9C9@xmb-rcd-x13.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7309FCBCAE981B43ABBE69B31C8D213921C23CA13CEUSAACMS0701e_" MIME-Version: 1.0 Cc: "idr@ietf.org" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2012 17:36:37 -0000 --_000_7309FCBCAE981B43ABBE69B31C8D213921C23CA13CEUSAACMS0701e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ________________________________ From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Saika= t Ray (sairay) Sent: Friday, June 22, 2012 10:31 AM To: Enke Chen (enkechen) Cc: idr@ietf.org Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document -= 3 more weeks Hi, Saikat: A new capability would certainly help. It seems necessary, but may not be = sufficient to limit the scope of the STALE path to "consenting adults". F= or example, inside a network (i.e., AS), if there are routers that do not r= ecognize the STALE community, [SR] That router must not negotiate the STALE capability with any peer, iBG= P or eBGP, and hence should not receive any stale path from any router. The= stale capability must be negotiated even within iBGP peers. To avoid incon= sistency of iBGP routes in an AS, you might need to add the restriction tha= t unless all iBGP peers negotiate the new capability, STALE paths should no= t be sent to any of them. [Jakob Heitz] What if a Route Reflector acquires a client without the capab= ility? --_000_7309FCBCAE981B43ABBE69B31C8D213921C23CA13CEUSAACMS0701e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
From: idr-bounces@ietf.org=20 [mailto:idr-bounces@ietf.org] On Behalf Of Saikat Ray=20 (sairay)
Sent: Friday, June 22, 2012 10:31 AM
To: Enke = Chen=20 (enkechen)
Cc: idr@ietf.org
Subject: Re: [Idr]=20 draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more=20 weeks

Hi, Saikat:

A new capability would certainly=20 help.  It seems necessary, but may not be sufficient to limit the scop= e of=20 the STALE path to "consenting adults".   For example, inside a ne= twork=20 (i.e., AS), if there are routers that do not recognize the STALE community,= =20

[SR]=20 That router must not negotiate the STALE capability with any peer, iBGP or = eBGP,=20 and hence should not receive any stale path from any router. The stale=20 capability must be negotiated even within iBGP peers. To avoid inconsistenc= y of=20 iBGP routes in an AS, you might need to add the restriction that unless all= iBGP=20 peers negotiate the new capability, STALE paths should not be sent to any o= f=20 them.

[Jakob=20 Heitz] What if a Route Reflector acquires a client without the=20 capability?

 

= --_000_7309FCBCAE981B43ABBE69B31C8D213921C23CA13CEUSAACMS0701e_-- From jakob.heitz@ericsson.com Fri Jun 22 10:46:11 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E54111E80DF for ; Fri, 22 Jun 2012 10:46:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.368 X-Spam-Level: X-Spam-Status: No, score=-6.368 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fGGzomp8tAei for ; Fri, 22 Jun 2012 10:46:10 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 7127411E8099 for ; Fri, 22 Jun 2012 10:46:10 -0700 (PDT) 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 q5MHk7YP026990; Fri, 22 Jun 2012 12:46:08 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.64]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Fri, 22 Jun 2012 13:46:04 -0400 From: Jakob Heitz To: "UTTARO, JAMES" , "'Enke Chen'" , "Saikat Ray (sairay)" Date: Fri, 22 Jun 2012 13:46:03 -0400 Thread-Topic: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks Thread-Index: AQHNUIKv4gES0WzL/kWO4I5ojxcnRZcGy9WAgAAMWYD//70toIAABL1g Message-ID: <7309FCBCAE981B43ABBE69B31C8D213921C23CA154@EUSAACMS0701.eamcs.ericsson.se> References: <003c01cd4b29$97d7b150$c78713f0$@ndzh.com> <985EF8D2-DA8A-4BE7-94D3-F4BE2B74D768@castlepoint.net> <4FE07A24.7050804@raszuk.net> <1C1F2B2E-2EB7-42F0-8CFF-57965443C074@castlepoint.net> <7A614998-8FB1-4A51-9937-DE501FF31EB6@juniper.net> <4FE0D1F4.9070208@cisco.com> <4FE0E074.3070905@raszuk.net> <17490_1340180565_4FE18855_17490_15423_1_53C29892C857584299CBF5D05346208A0928AA@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FE18A61.8000405@raszuk.net> <8ED5B0B0F5B4854A912480C1521F973AD95B@xmb-rcd-x13.cisco.com> <4FE4A8F3.20809@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7309FCBCAE981B43ABBE69B31C8D213921C23CA154EUSAACMS0701e_" MIME-Version: 1.0 Cc: "idr@ietf.org" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2012 17:46:11 -0000 --_000_7309FCBCAE981B43ABBE69B31C8D213921C23CA154EUSAACMS0701e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ________________________________ From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of UTTAR= O, JAMES Sent: Friday, June 22, 2012 10:27 AM To: 'Enke Chen'; Saikat Ray (sairay) Cc: idr@ietf.org Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document -= 3 more weeks Enke, The idea behind the setting of STALE is to inform speakers = in other AS domains that the path is suspect as the session it was learned = over is down.. IMO this is required to inform others about the viability of= a path.. [Jakob Heitz] Then call them SUSPECT instead of STALE. The other approach is to simply not mark these paths as STALE.. Simply de-p= ref in the local AS and business as usual when advertised outside the AS wh= ere all transitive attrs are reset.. [Jakob Heitz] SUSPECT is entirely different to low preference. A low preference path exists. A SUSPECT path may not exist. A less specific path (shorter netmask) exists and will forward packets, unless it is the default route or also SUSPECT. This puts a SUSPECT route at an equal or lower preference than a default ro= ute. Therefore a SUSPECT path should be de-preferred among the set of ALL available paths, including the less specific ones. --_000_7309FCBCAE981B43ABBE69B31C8D213921C23CA154EUSAACMS0701e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
From: idr-bounces@ietf.org=20 [mailto:idr-bounces@ietf.org] On Behalf Of UTTARO, JAMES
Sent:= =20 Friday, June 22, 2012 10:27 AM
To: 'Enke Chen'; Saikat Ray=20 (sairay)
Cc: idr@ietf.org
Subject: Re: [Idr]=20 draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more=20 weeks

Enke,

 

            = ;   =20 The idea behind the setting of STALE is to inform speakers in other AS doma= ins=20 that the path is suspect as the session it was learned over is down.. IMO t= his=20 is required to inform others about the viability of a path..

[Jakob=20 Heitz]  Then call them SUSPECT instead of=20 STALE.

 

The=20 other approach is to simply not mark these paths as STALE.. Simply de-pref = in=20 the local AS and business as usual when advertised outside the AS where all= =20 transitive attrs are reset..

[Jakob=20 Heitz]  SUSPECT is entirely different to low=20 preference.

A low preference path exis= ts. A=20 SUSPECT path may not exist.

 

A less=20 specific path (shorter netmask) exists and will forward=20 packets,

unless=20 it is the default route or also SUSPECT.

This=20 puts a SUSPECT route at an equal or lower preference than a default=20 route.

 

Therefore a SUSPECT path should be de-preferred among=20 the

set of=20 ALL available paths, including the less specific=20 ones.

 

 

--_000_7309FCBCAE981B43ABBE69B31C8D213921C23CA154EUSAACMS0701e_-- From enkechen@cisco.com Fri Jun 22 10:47:10 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C38F11E808C for ; Fri, 22 Jun 2012 10:47:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.223 X-Spam-Level: X-Spam-Status: No, score=-10.223 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HPq+i5JSvZqU for ; Fri, 22 Jun 2012 10:47:07 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 7AF8321F8534 for ; Fri, 22 Jun 2012 10:47:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=enkechen@cisco.com; l=24918; q=dns/txt; s=iport; t=1340387227; x=1341596827; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=v6X3XrBnuVnbE1ZC802ZJaIKq2JXUZuwQ675l8lGMIc=; b=i7GUk/C9nwsZwXV94Q7PayBouN44fKD3az+Rwyp0LVXs1WWJybbC7hIN iMax2MjSI0NsJQk3DDZ9wn2B8zhWV86bYSiXLdU3zLfc6shzVI0E9BTtc QFXB2RehCETZmLggGAmvijTg/C8nx2vB0CUboH3i7xgxHIyzOhIwLisBS E=; X-IronPort-AV: E=Sophos;i="4.77,459,1336348800"; d="scan'208,217";a="49903200" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 22 Jun 2012 17:46:52 +0000 Received: from sjc-vpn4-1382.cisco.com (sjc-vpn4-1382.cisco.com [10.21.85.101]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q5MHkplv030779; Fri, 22 Jun 2012 17:46:51 GMT Message-ID: <4FE4AFE2.3030107@cisco.com> Date: Fri, 22 Jun 2012 10:48:18 -0700 From: Enke Chen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "UTTARO, JAMES" References: <003c01cd4b29$97d7b150$c78713f0$@ndzh.com> <985EF8D2-DA8A-4BE7-94D3-F4BE2B74D768@castlepoint.net> <4FE07A24.7050804@raszuk.net> <1C1F2B2E-2EB7-42F0-8CFF-57965443C074@castlepoint.net> <7A614998-8FB1-4A51-9937-DE501FF31EB6@juniper.net> <4FE0D1F4.9070208@cisco.com> <4FE0E074.3070905@raszuk.net> <17490_1340180565_4FE18855_17490_15423_1_53C29892C857584299CBF5D05346208A0928AA@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FE18A61.8000405@raszuk.net> <8ED5B0B0F5B4854A912480C1521F973AD95B@xmb-rcd-x13.cisco.com> <4FE4A8F3.20809@cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010809000804010301030701" Cc: "idr@ietf.org" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2012 17:47:10 -0000 This is a multi-part message in MIME format. --------------010809000804010301030701 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Jim, With GR, as you correctly pointed out, a path would not stale for many hours or days. That is why it may not be as critical to limit the scope of the stale path. If we were to have long-lived stale paths (which I think is a bad idea), I agree that they should be limited to "consenting adults", and there must be some mechanisms (such as capability) in place. -- Enke On 6/22/12 10:27 AM, UTTARO, JAMES wrote: > > Enke, > > The idea behind the setting of STALE is to inform > speakers in other AS domains that the path is suspect as the session > it was learned over is down.. IMO this is required to inform others > about the viability of a path.. > > The other approach is to simply not mark these paths as STALE.. Simply > de-pref in the local AS and business as usual when advertised outside > the AS where all transitive attrs are reset.. > > This is exactly the semantic you are using in the GR draft. You do not > de-pref the state locally and do not inform other AS domains that the > paths learned over the session that GR is active on are suspect. > > If the STALE CV is not honored across the AS border than the behavior > defaults to what is specified in the GR draft. This should meet your > requirements. > > Jim Uttaro > > *From:*idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] *On Behalf > Of *Enke Chen > *Sent:* Friday, June 22, 2012 1:19 PM > *To:* Saikat Ray (sairay) > *Cc:* idr@ietf.org > *Subject:* Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG > document - 3 more weeks > > Hi, Saikat: > > A new capability would certainly help. It seems necessary, but may > not be sufficient to limit the scope of the STALE path to "consenting > adults". For example, inside a network (i.e., AS), if there are > routers that do not recognize the STALE community, a STALE path may > still be advertised to external peers without the capability. This > means that all the routers in a network must recognize the community > before enabling the capability on any of them. It will be difficult > to satisfy the condition universally. > > In addition, to limit its scope the STALE community, once set, MUST > not be removed by any receiver. > > -- Enke > > On 6/22/12 9:34 AM, Saikat Ray (sairay) wrote: > > Without being involved in the discussion whether it is the right > problem to tackle or not, I would like to make the observation that at > the very least, the draft needs to define a new BGP capability for the > willingness to accept STALE routes. Peers that has not negotiated this > capability MUST receive paths "as if" the STALE paths did not exist. > This includes that STALE paths and any non-STALE paths whose nexthops > resolve over a STALE paths MUST also not be sent to a such a peer. > This way, negotiation of this capability by consenting adults will > define an island where stale routes would roam free without affecting > others. > > *From:*idr-bounces@ietf.org > [mailto:idr-bounces@ietf.org] *On Behalf Of *Senad .Palislamovic > *Sent:* Friday, June 22, 2012 7:24 AM > *To:* idr@ietf.org > *Cc:* shares@ndzh.com > *Subject:* Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG > document - 3 more weeks > > IETF mail server glitch; resending: Note: Robert already > commented back > > Apologize for the delay on comments, > > Robert, > > After going through all the emails, I admit, you've made a lot of > valuable comments that 'seriously' MUST be considered in the new > version of the draft. However, putting that aside, I would really > expect this to be saved for WG discussions. I would think that at > this stage, we are more less agreeing to take a look at this problem > and its solution space. > > Robert, Randy, Shane, > > The main question I have for you is why object something that might > not even affect you. Draft's primary purpose is for the protection of > the control plane for non-internet services (vpls, l2vpn, or > infrustructure routes, i.e. BGP-3107), which in all cases does not > affect you or me in any shape or form. For folks to chose to extend > this to l3vpn or even to IPv4/IPv6 space, they are doing it > consciously knowing the nature of their network and its dynamics. If > you do see a route with the STALE community, and do not desire to use > this path due its "unreliable" nature, you can request your provider > to withdraw the routes with STALE community effectively making them > DO_NOT_PERSIST at the source which effectively mimics the standard GR > behavior; as Bruno stated, at eBGP, people are talking and negotiating. > > So given all that, help me understand how could this impact anyone who > chooses not to use it. Am I missing anything? > > On the side note, Susan, I do support this draft as WG document. > > Senad > > On Wed, Jun 20, 2012 at 4:31 AM, Robert Raszuk > wrote: > > Yet, IMHO building a good (reliable, performant) BGP > implementation is hard. > > True. And changing it's fundamental behaviour every few months > does not help to make it reliable/ performant either ;) > > I don't think operators would do a better job on the BGP > implementation side. > > I am not asking for that at all. I am asking to simply use > multiple implementations in the backend. Not two .. but 4 or 5. > Probability that all fail/melt with the same bug I think is very > very low. > > Of course I admit that if you one uses service which only single > vendor supports in BGP then one get's a bit stuck with the risk. > And that seems to be one of the silent "problem statement" here. > > Rgs, > > > R. > > _______________________________________________ > 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 > --------------010809000804010301030701 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Jim,

With GR, as you correctly pointed out, a path would not stale for many hours or days. That is why it may not be as critical to limit the scope of the stale path.

If we were to have long-lived stale paths (which I think is a bad idea), I agree that they should be limited to "consenting adults", and there must be some mechanisms (such as capability) in place.

-- Enke

On 6/22/12 10:27 AM, UTTARO, JAMES wrote:

Enke,

 

                The idea behind the setting of STALE is to inform speakers in other AS domains that the path is suspect as the session it was learned over is down.. IMO this is required to inform others about the viability of a path..

 

The other approach is to simply not mark these paths as STALE.. Simply de-pref in the local AS and business as usual when advertised outside the AS where all transitive attrs are reset..

 

This is exactly the semantic you are using in the GR draft. You do not de-pref the state locally and do not inform other AS domains that the paths learned over the session that GR is active on are suspect.

 

If the STALE CV is not honored across the AS border than the behavior defaults to what is specified in the GR draft. This should meet your requirements.

 

Jim Uttaro

 

From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Enke Chen
Sent: Friday, June 22, 2012 1:19 PM
To: Saikat Ray (sairay)
Cc: idr@ietf.org
Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks

 

Hi, Saikat:

A new capability would certainly help.  It seems necessary, but may not be sufficient to limit the scope of the STALE path to "consenting adults".   For example, inside a network (i.e., AS), if there are routers that do not recognize the STALE community, a STALE path may still be advertised to external peers without the capability.   This means that all the routers in a network must recognize the community before enabling the capability on any of them.  It will be difficult to satisfy the condition universally.

In addition, to limit its scope the STALE community, once set, MUST not be removed by any receiver.

-- Enke

On 6/22/12 9:34 AM, Saikat Ray (sairay) wrote:

Without being involved in the discussion whether it is the right problem to tackle or not, I would like to make the observation that at the very least, the draft needs to define a new BGP capability for the willingness to accept STALE routes. Peers that has not negotiated this capability MUST receive paths “as if” the STALE paths did not exist. This includes that STALE paths and any non-STALE paths whose nexthops resolve over a STALE paths MUST also not be sent to a such a peer. This way, negotiation of this capability by consenting adults will define an island where stale routes would roam free without affecting others.

 

From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Senad .Palislamovic
Sent: Friday, June 22, 2012 7:24 AM
To: idr@ietf.org
Cc: shares@ndzh.com
Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks

 

IETF mail server glitch;  resending: Note: Robert already commented back

 

Apologize for the delay on comments,

Robert,

After going through all the emails, I admit, you've made a lot of valuable comments that 'seriously' MUST be considered in the new version of the draft.  However, putting that aside, I would really expect this to be saved for WG discussions.  I would think that at this stage, we are more less agreeing to take a look at this problem and its solution space. 

Robert, Randy, Shane,

The main question I have for you is why object something that might not even affect you.  Draft's primary purpose is for the protection of the control plane for non-internet services (vpls, l2vpn, or infrustructure routes, i.e. BGP-3107), which in all cases does not affect you or me in any shape or form.  For folks to chose to extend this to l3vpn or even to IPv4/IPv6 space, they are doing it consciously knowing the nature of their network and its dynamics.  If you do see a route with the STALE community, and do not desire to use this path due its "unreliable" nature, you can request your provider to withdraw the routes with STALE community effectively making them DO_NOT_PERSIST at the source which effectively mimics the standard GR behavior; as Bruno stated, at eBGP, people are talking and negotiating.

So given all that, help me understand how could this impact anyone who chooses not to use it.  Am I missing anything?

On the side note, Susan, I do support this draft as WG document.

 

Senad

 

 

 

 

 

On Wed, Jun 20, 2012 at 4:31 AM, Robert Raszuk <robert@raszuk.net> wrote:

 

Yet, IMHO building a good (reliable, performant) BGP implementation is hard.

 

True. And changing it's fundamental behaviour every few months does not help to make it reliable/ performant either ;)

 

I don't think operators would do a better job on the BGP implementation side.

 

I am not asking for that at all. I am asking to simply use multiple implementations in the backend. Not two .. but 4 or 5. Probability that all fail/melt with the same bug I think is very very low.

Of course I admit that if you one uses service which only single vendor supports in BGP then one get's a bit stuck with the risk. And that seems to be one of the silent "problem statement" here.

Rgs,


R.

_______________________________________________
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

 


--------------010809000804010301030701-- From enkechen@cisco.com Fri Jun 22 10:58:49 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57C5B21F86CF; Fri, 22 Jun 2012 10:58:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.365 X-Spam-Level: X-Spam-Status: No, score=-10.365 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E8SSyliXgwhL; Fri, 22 Jun 2012 10:58:47 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 5E41821F86C9; Fri, 22 Jun 2012 10:58:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=enkechen@cisco.com; l=8075; q=dns/txt; s=iport; t=1340387927; x=1341597527; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=fmkzcRJgmtVEVP51hgY465sncHca9jTxZh/6z/nYmvI=; b=T+VHiPxzx5RUPik3/6kNOkARh2rPJ0L4fWCRq0MssYYOOd+BkO0raivR 2brlu9OPJzRyfRPK/FoaQN5ucU2stDGPFGfPtL9NTfjH/zbrc22lkP9n6 uiXJG+1sLe04gmVX6DdfVPtn2PErQI0IKg5m+ekN0kU0d2YVSfHKaEjZl 8=; X-IronPort-AV: E=Sophos;i="4.77,459,1336348800"; d="scan'208,217";a="46791415" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 22 Jun 2012 17:58:47 +0000 Received: from sjc-vpn4-1382.cisco.com (sjc-vpn4-1382.cisco.com [10.21.85.101]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q5MHwkbL019597; Fri, 22 Jun 2012 17:58:46 GMT Message-ID: <4FE4B2AD.9050704@cisco.com> Date: Fri, 22 Jun 2012 11:00:13 -0700 From: Enke Chen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: robert@raszuk.net References: <4FE495CD.7080604@raszuk.net> In-Reply-To: <4FE495CD.7080604@raszuk.net> Content-Type: multipart/alternative; boundary="------------070506060203000902020309" Cc: "idr@ietf.org List" , "grow@ietf.org" , "UTTARO, JAMES \(ATTLABS\)" Subject: Re: [Idr] Fwd: [GROW] draft-ietf-grow-ops-reqs-for-bgp-error-handling-04 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2012 17:58:49 -0000 This is a multi-part message in MIME format. --------------070506060203000902020309 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, folks: It might help the discussion to refresh ourselves about several large outages in the last few years that prompted the work on the error handling requirements and solutions: o issue with AS4_PATH that resulted in session resets multiple hops away (two separate incidents) o session reset triggered by a single route with a new attribute I remember that Rob had a presentation at the NANOG on the topic. -- Enke On 6/22/12 8:57 AM, Robert Raszuk wrote: > Jim, > >> We could as easily without any change to BGP use BGP Persistence to >> maintain the paths except for the ones that have the invalid >> attribute.. This is the simpler method, has the benefit of not >> changing BGP, or educating the world on the nuances of the changes >> etc... > + >> Why wouldn't we simply let the session fail and then use BGP Persistence >> or GR ;) > > Please observe that when the session is down you are not receiving > withdraws or new best paths for those "good" prefixes (maybe 99% of > them) which did not have any errors in their respective update messages. > > Equating it with persistence proposal is therefor highly incorrect. > >> I also do not fully understand "treat as withdraw" does this meant that >> the peer who has received an update with P1-PN with malformed attr then >> initiate a withdrawal to all of its peers? Or simply assume that the >> paths have been received as a message? Some sample topologies as to how >> this works would be a good addition to this section.. > > The speaker reacting on an error which can be addressed by > "treat-as-withdraw" invalidates locally those prefixes received in the > update message, runs local best path and as result if no other path is > found withdraws those prefixes from all peers it has previously sent > them to. > >> I am not in support of solutions which create a scenario where BGP >> cannot recover without human intervention. > > I think no one is. But we are - I think - not there yet for the > routers to automatically fix their bugs, but only automatically > signalling them the requested action ;(. > > > Nothing is going to get people's attention like a failed BGP > > Session.. > > True statement. But the entire assumption behind treat-as-withdraw is > that your ops scripts parse the syslog messages indicating the issue > to NOC with the same red color and buzz as bgp session down. Of course > you need to rework your ops scripts/alarms for that to happen. > > Rgs, > R. > > PS. > > Note that if the main BGP session is down (like in the persistence > case) BGP Operational Messages can not any longer be exchanged between > peers as TCP connection could have been reset (if no multisession is > used and if we are talking about single SAFI). That just makes the > issue worse especially when you do not like to have humans intervention. > > > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr --------------070506060203000902020309 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, folks:

It might help the discussion to refresh ourselves about several large outages in the last few years that prompted the work on the error handling requirements and solutions:

   o issue with AS4_PATH that resulted in session resets multiple hops away (two separate incidents)
   o session reset triggered by a single route with a new attribute

I remember that Rob had a presentation at the NANOG on the topic.

-- Enke

On 6/22/12 8:57 AM, Robert Raszuk wrote:
Jim,

We could as easily without any change to BGP use BGP Persistence to
maintain the paths except for the ones that have the invalid
attribute.. This is the simpler method, has the benefit of not
changing BGP, or educating the world on the nuances of the changes
etc…
+
Why wouldn’t we simply let the session fail and then use BGP Persistence
or GR ;)

Please observe that when the session is down you are not receiving withdraws or new best paths for those "good" prefixes (maybe 99% of them) which did not have any errors in their respective update messages.

Equating it with persistence proposal is therefor highly incorrect.

I also do not fully understand “treat as withdraw” does this meant that
the peer who has received an update with P1-PN with malformed attr then
initiate a withdrawal to all of its peers?  Or simply assume that the
paths have been received as a message?  Some sample topologies as to how
this works would be a good addition to this section..

The speaker reacting on an error which can be addressed by "treat-as-withdraw" invalidates locally those prefixes received in the update message, runs local best path and as result if no other path is found withdraws those prefixes from all peers it has previously sent them to.

I am not in support of solutions which create a scenario where BGP
cannot recover without human intervention.

I think no one is. But we are - I think - not there yet for the routers to automatically fix their bugs, but only automatically signalling them the requested action ;(.

> Nothing is going to get people’s attention like a failed BGP
> Session..

True statement. But the entire assumption behind treat-as-withdraw is that your ops scripts parse the syslog messages indicating the issue to NOC with the same red color and buzz as bgp session down. Of course you need to rework your ops scripts/alarms for that to happen.

Rgs,
R.

PS.

Note that if the main BGP session is down (like in the persistence case) BGP Operational Messages can not any longer be exchanged between peers as TCP connection could have been reset (if no multisession is used and if we are talking about single SAFI). That just makes the issue worse especially when you do not like to have humans intervention. 




_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr

--------------070506060203000902020309-- From ju1738@att.com Fri Jun 22 11:04:31 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1850E11E808C for ; Fri, 22 Jun 2012 11:04:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.094 X-Spam-Level: X-Spam-Status: No, score=-106.094 tagged_above=-999 required=5 tests=[AWL=-0.096, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2CZChirUe0if for ; Fri, 22 Jun 2012 11:04:26 -0700 (PDT) Received: from nbfkord-smmo03.seg.att.com (nbfkord-smmo03.seg.att.com [209.65.160.84]) by ietfa.amsl.com (Postfix) with ESMTP id 686FB11E8087 for ; Fri, 22 Jun 2012 11:04:26 -0700 (PDT) Received: from unknown [144.160.128.153] (EHLO nbfkord-smmo03.seg.att.com) by nbfkord-smmo03.seg.att.com(mxl_mta-6.11.0-10) with ESMTP id aa3b4ef4.4ac1c940.792007.00-583.2202114.nbfkord-smmo03.seg.att.com (envelope-from ); Fri, 22 Jun 2012 18:04:26 +0000 (UTC) X-MXL-Hash: 4fe4b3aa44d23052-537e5edd1d5b9d1ff6292ceb913c55f34eb67fa7 Received: from unknown [144.160.128.153] (EHLO flpi408.enaf.ffdc.sbc.com) by nbfkord-smmo03.seg.att.com(mxl_mta-6.11.0-10) over TLS secured channel with ESMTP id 6a3b4ef4.0.791985.00-467.2202050.nbfkord-smmo03.seg.att.com (envelope-from ); Fri, 22 Jun 2012 18:04:22 +0000 (UTC) X-MXL-Hash: 4fe4b3a62f18c008-12a748302a9a7837e0cbb922a94bb3b7b78b4170 Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q5MI4KoV016016; Fri, 22 Jun 2012 11:04:21 -0700 Received: from fflint04.pst.cso.att.com (fflint04.pst.cso.att.com [150.234.39.64]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q5MI4Gat015963 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Jun 2012 11:04:18 -0700 Received: from MISOUT7MSGHUB9A.ITServices.sbc.com (misout7msghub9a.itservices.sbc.com [144.151.223.62]) by fflint04.pst.cso.att.com (RSA Interceptor); Fri, 22 Jun 2012 11:03:34 -0700 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9A.ITServices.sbc.com ([144.151.223.62]) with mapi id 14.02.0298.004; Fri, 22 Jun 2012 14:03:33 -0400 From: "UTTARO, JAMES" To: "'Enke Chen'" Thread-Topic: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks Thread-Index: AQHNUIKv4gES0WzL/kWO4I5ojxcnRZcGy9WAgAAMWYD//70toIAASxcA//+9G7A= Date: Fri, 22 Jun 2012 18:03:33 +0000 Message-ID: References: <003c01cd4b29$97d7b150$c78713f0$@ndzh.com> <985EF8D2-DA8A-4BE7-94D3-F4BE2B74D768@castlepoint.net> <4FE07A24.7050804@raszuk.net> <1C1F2B2E-2EB7-42F0-8CFF-57965443C074@castlepoint.net> <7A614998-8FB1-4A51-9937-DE501FF31EB6@juniper.net> <4FE0D1F4.9070208@cisco.com> <4FE0E074.3070905@raszuk.net> <17490_1340180565_4FE18855_17490_15423_1_53C29892C857584299CBF5D05346208A0928AA@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FE18A61.8000405@raszuk.net> <8ED5B0B0F5B4854A912480C1521F973AD95B@xmb-rcd-x13.cisco.com> <4FE4A8F3.20809@cisco.com> <4FE4AFE2.3030107@cisco.com> In-Reply-To: <4FE4AFE2.3030107@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.151.80] Content-Type: multipart/alternative; boundary="_000_B17A6910EEDD1F45980687268941550FB1F925MISOUT7MSGUSR9IIT_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.128.153] X-AnalysisOut: [v=1.0 c=1 a=dXkvp1zHZaMA:10 a=ZQD3OTTxKqYA:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=xwOvzTHDVLE4u4nGvK72ag==:17 a=AU] X-AnalysisOut: [d_NHdVAAAA:8 a=48vgC7mUAAAA:8 a=1sjgXBK7AAAA:8 a=2clOPd4PA] X-AnalysisOut: [AAA:8 a=CyNGAW4Q4wjPTXIACT0A:9 a=CjuIK1q_8ugA:10 a=JfD0Fch] X-AnalysisOut: [1gWkA:10 a=lZB815dzVvQA:10 a=kZwP4KTQBigA:10 a=bDUki_mJ7Dg] X-AnalysisOut: [A:10 a=Uw_qXOgRm5Sz60tI:21 a=h52N7trhAfFsU_iV:21 a=yMhMjlu] X-AnalysisOut: [bAAAA:8 a=SSmOFEACAAAA:8 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:] X-AnalysisOut: [10 a=hTZeC7Yk6K0A:10 a=tXsnliwV7b4A:10 a=hCKPPO3n9wP_K4Nr:] X-AnalysisOut: [21 a=R3X2Sn3jaJfW9BId:21] Cc: "idr@ietf.org" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2012 18:04:31 -0000 --_000_B17A6910EEDD1F45980687268941550FB1F925MISOUT7MSGUSR9IIT_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Enke, I think we have got to have a consistent approach to these = solutions.. I am not comfortable with the fact that it is "ok" for GR but n= ot "ok" for Persistence based on a IMO subjective interpretation of the amo= unt of time a STALE path is active in local and adjacent topologies. An hou= r is a long time, and as GR is used primarily used n IPV4 which is dynamic = it would seem that a) these paths should be de-pref after some amount of ti= me b) GR should inform other AS topologies of the staleness by using the ST= ALE CV.. I would be interested in hearing from operators as to if this behavior is u= nderstood and if limiting of the time to ~1hr makes the inconsistency withi= n and across AS domains acceptable.. In your opinion what is the maximum a= cceptable amount of time that we could use Persistence. Jim Uttaro From: Enke Chen [mailto:enkechen@cisco.com] Sent: Friday, June 22, 2012 1:48 PM To: UTTARO, JAMES Cc: Saikat Ray (sairay); idr@ietf.org; Enke Chen Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document -= 3 more weeks Jim, With GR, as you correctly pointed out, a path would not stale for many hour= s or days. That is why it may not be as critical to limit the scope of the = stale path. If we were to have long-lived stale paths (which I think is a bad idea), I = agree that they should be limited to "consenting adults", and there must be= some mechanisms (such as capability) in place. -- Enke On 6/22/12 10:27 AM, UTTARO, JAMES wrote: Enke, The idea behind the setting of STALE is to inform speakers = in other AS domains that the path is suspect as the session it was learned = over is down.. IMO this is required to inform others about the viability of= a path.. The other approach is to simply not mark these paths as STALE.. Simply de-p= ref in the local AS and business as usual when advertised outside the AS wh= ere all transitive attrs are reset.. This is exactly the semantic you are using in the GR draft. You do not de-p= ref the state locally and do not inform other AS domains that the paths lea= rned over the session that GR is active on are suspect. If the STALE CV is not honored across the AS border than the behavior defau= lts to what is specified in the GR draft. This should meet your requirement= s. Jim Uttaro From: idr-bounces@ietf.org [mailto:idr-bounces= @ietf.org] On Behalf Of Enke Chen Sent: Friday, June 22, 2012 1:19 PM To: Saikat Ray (sairay) Cc: idr@ietf.org Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document -= 3 more weeks Hi, Saikat: A new capability would certainly help. It seems necessary, but may not be = sufficient to limit the scope of the STALE path to "consenting adults". F= or example, inside a network (i.e., AS), if there are routers that do not r= ecognize the STALE community, a STALE path may still be advertised to exter= nal peers without the capability. This means that all the routers in a ne= twork must recognize the community before enabling the capability on any of= them. It will be difficult to satisfy the condition universally. In addition, to limit its scope the STALE community, once set, MUST not be = removed by any receiver. -- Enke On 6/22/12 9:34 AM, Saikat Ray (sairay) wrote: Without being involved in the discussion whether it is the right problem to= tackle or not, I would like to make the observation that at the very least= , the draft needs to define a new BGP capability for the willingness to acc= ept STALE routes. Peers that has not negotiated this capability MUST receiv= e paths "as if" the STALE paths did not exist. This includes that STALE pat= hs and any non-STALE paths whose nexthops resolve over a STALE paths MUST a= lso not be sent to a such a peer. This way, negotiation of this capability = by consenting adults will define an island where stale routes would roam fr= ee without affecting others. From: idr-bounces@ietf.org [mailto:idr-bounces= @ietf.org] On Behalf Of Senad .Palislamovic Sent: Friday, June 22, 2012 7:24 AM To: idr@ietf.org Cc: shares@ndzh.com Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document -= 3 more weeks IETF mail server glitch; resending: Note: Robert already commented back Apologize for the delay on comments, Robert, After going through all the emails, I admit, you've made a lot of valuable = comments that 'seriously' MUST be considered in the new version of the draf= t. However, putting that aside, I would really expect this to be saved for= WG discussions. I would think that at this stage, we are more less agreei= ng to take a look at this problem and its solution space. Robert, Randy, Shane, The main question I have for you is why object something that might not eve= n affect you. Draft's primary purpose is for the protection of the control= plane for non-internet services (vpls, l2vpn, or infrustructure routes, i.= e. BGP-3107), which in all cases does not affect you or me in any shape or = form. For folks to chose to extend this to l3vpn or even to IPv4/IPv6 spac= e, they are doing it consciously knowing the nature of their network and it= s dynamics. If you do see a route with the STALE community, and do not des= ire to use this path due its "unreliable" nature, you can request your prov= ider to withdraw the routes with STALE community effectively making them DO= _NOT_PERSIST at the source which effectively mimics the standard GR behavio= r; as Bruno stated, at eBGP, people are talking and negotiating. So given all that, help me understand how could this impact anyone who choo= ses not to use it. Am I missing anything? On the side note, Susan, I do support this draft as WG document. Senad On Wed, Jun 20, 2012 at 4:31 AM, Robert Raszuk > wrote: Yet, IMHO building a good (reliable, performant) BGP implementation is hard= . True. And changing it's fundamental behaviour every few months does not hel= p to make it reliable/ performant either ;) I don't think operators would do a better job on the BGP implementation sid= e. I am not asking for that at all. I am asking to simply use multiple impleme= ntations in the backend. Not two .. but 4 or 5. Probability that all fail/m= elt with the same bug I think is very very low. Of course I admit that if you one uses service which only single vendor sup= ports in BGP then one get's a bit stuck with the risk. And that seems to be= one of the silent "problem statement" here. Rgs, R. _______________________________________________ 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 --_000_B17A6910EEDD1F45980687268941550FB1F925MISOUT7MSGUSR9IIT_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Enke,

 <= /p>

    &= nbsp;           I think w= e have got to have a consistent approach to these solutions.. I am not comf= ortable with the fact that it is “ok” for GR but not “ok&= #8221; for Persistence based on a IMO subjective interpretation of the amount of = time a STALE path is active in local and adjacent topologies. An hour is a = long time, and as GR is used primarily used n IPV4 which is dynamic it woul= d seem that a) these paths should be de-pref after some amount of time b) GR should inform other AS topologi= es of the staleness by using the STALE CV..

 <= /p>

I would be interested in = hearing from operators as to if this behavior is understood and if limiting= of the time to ~1hr makes the inconsistency within and across AS domains acceptable..  In your opinion what is the maximum a= cceptable amount of time that we could use Persistence. 

 <= /p>

Jim Uttaro

 <= /p>

 <= /p>

 <= /p>

 <= /p>

From: Enke Chen [mailto:enkechen@cisco.com]
Sent: Friday, June 22, 2012 1:48 PM
To: UTTARO, JAMES
Cc: Saikat Ray (sairay); idr@ietf.org; Enke Chen
Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG doc= ument - 3 more weeks

 

Jim,

With GR, as you correctly pointed out, a path would not stale for many hour= s or days. That is why it may not be as critical to limit the scope of the = stale path.

If we were to have long-lived stale paths (which I think is a bad idea), I = agree that they should be limited to "consenting adults", and the= re must be some mechanisms (such as capability) in place.

-- Enke

On 6/22/12 10:27 AM, UTTARO, JAMES wrote:

Enke,

 <= /p>

    &= nbsp;           The idea = behind the setting of STALE is to inform speakers in other AS domains that = the path is suspect as the session it was learned over is down.. IMO this is required to inform others about the viability of a path= ..

 <= /p>

The other approach is to = simply not mark these paths as STALE.. Simply de-pref in the local AS and b= usiness as usual when advertised outside the AS where all transitive attrs are reset..

 <= /p>

This is exactly the seman= tic you are using in the GR draft. You do not de-pref the state locally and= do not inform other AS domains that the paths learned over the session that GR is active on are suspect.

 <= /p>

If the STALE CV is not ho= nored across the AS border than the behavior defaults to what is specified = in the GR draft. This should meet your requirements.

 <= /p>

Jim Uttaro

 <= /p>

From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Enke Chen
Sent: Friday, June 22, 2012 1:19 PM
To: Saikat Ray (sairay)
Cc: idr@ietf.org
Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG doc= ument - 3 more weeks

 

Hi, Saikat:

A new capability would certainly help.  It seems necessary, but may no= t be sufficient to limit the scope of the STALE path to "consenting ad= ults".   For example, inside a network (i.e., AS), if there = are routers that do not recognize the STALE community, a STALE path may still be advertised to external peers without the capabilit= y.   This means that all the routers in a network must recognize = the community before enabling the capability on any of them.  It will = be difficult to satisfy the condition universally.

In addition, to limit its scope the STALE community, once set, MUST not be = removed by any receiver.

-- Enke

On 6/22/12 9:34 AM, Saikat Ray (sairay) wrote:

Without being involved in= the discussion whether it is the right problem to tackle or not, I would l= ike to make the observation that at the very least, the draft needs to define a new BGP capability for the willingness to accept S= TALE routes. Peers that has not negotiated this capability MUST receive pat= hs “as if” the STALE paths did not exist. This includes that ST= ALE paths and any non-STALE paths whose nexthops resolve over a STALE paths MUST also not be sent to a such a peer. This wa= y, negotiation of this capability by consenting adults will define an islan= d where stale routes would roam free without affecting others.<= /o:p>

 <= /p>

From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Senad .Palislamovic
Sent: Friday, June 22, 2012 7:24 AM
To: idr@ietf.org
Cc: shares@ndzh.com
Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG doc= ument - 3 more weeks

 

IETF mail server glitch;  resending: Note: Robert= already commented back

 

Apologize for the delay on comments,

Robert,

After going through all the emails, I admit, you've made a = lot of valuable comments that 'seriously' MUST be considered in the new ver= sion of the draft.  However, putting that aside, I would really expect= this to be saved for WG discussions.  I would think that at this stage, we are more less agreeing to take a look= at this problem and its solution space. 

Robert, Randy, Shane,

The main question I have for you is why object something th= at might not even affect you.  Draft's primary purpose is for the= protection of the control plane for non-internet services (vpls, l2vpn, or= infrustructure routes, i.e. BGP-3107), which in all cases does not affect you or me in any shape or form.  For fol= ks to chose to extend this to l3vpn or even to IPv4/IPv6 space, they are do= ing it consciously knowing the nature of their network and its dynamics.&nb= sp; If you do see a route with the STALE community, and do not desire to use this path due its "unreliable" nature, = you can request your provider to withdraw the routes with STALE community e= ffectively making them DO_NOT_PERSIST at the source which effectively mimic= s the standard GR behavior; as Bruno stated, at eBGP, people are talking and negotiating.

So given all that, help me understand how could this impact= anyone who chooses not to use it.  Am I missing anything?<= /p>

On the side note, Susan, I do support this draft as WG docu= ment.

 

Senad

 

 

 

 

 

On Wed, Jun 20, 2012 at 4:31 AM, Robert Raszuk <<= a href=3D"mailto:robert@raszuk.net" target=3D"_blank">robert@raszuk.net= > wrote:

 

Yet, IMHO building a good (reliable, performant) BGP= implementation is hard.

 

True. And changing it's fundamental behaviour every = few months does not help to make it reliable/ performant either ;)

 

I don't think operators would do a better job on the= BGP implementation side.

 

I am not asking for that at all. I am asking to simp= ly use multiple implementations in the backend. Not two .. but 4 or 5. Prob= ability that all fail/melt with the same bug I think is very very low.

Of course I admit that if you one uses service which only single vendor sup= ports in BGP then one get's a bit stuck with the risk. And that seems to be= one of the silent "problem statement" here.

Rgs,


R.

_______________________________________________
Idr mailing list
Idr@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/idr

 

 





_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf=
.org/mailman/listinfo/idr

 

 

--_000_B17A6910EEDD1F45980687268941550FB1F925MISOUT7MSGUSR9IIT_-- From ju1738@att.com Fri Jun 22 11:22:37 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F349611E80AD; Fri, 22 Jun 2012 11:22:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.272 X-Spam-Level: X-Spam-Status: No, score=-106.272 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AcdokfpL03vj; Fri, 22 Jun 2012 11:22:34 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id 37F6411E808C; Fri, 22 Jun 2012 11:22:34 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO nbfkord-smmo05.seg.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.11.0-10) with ESMTP id ae7b4ef4.4dc14940.1038928.00-581.2893482.nbfkord-smmo05.seg.att.com (envelope-from ); Fri, 22 Jun 2012 18:22:34 +0000 (UTC) X-MXL-Hash: 4fe4b7ea79e9af12-47e0413d48eefc472a51a820a15fdb092c0d2378 Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.11.0-10) over TLS secured channel with ESMTP id 6e7b4ef4.0.1038911.00-468.2893422.nbfkord-smmo05.seg.att.com (envelope-from ); Fri, 22 Jun 2012 18:22:30 +0000 (UTC) X-MXL-Hash: 4fe4b7e64943767e-c6f0041d8af840b2cfbab54ef5095598790e372b Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q5MIMUtC012241; Fri, 22 Jun 2012 14:22:30 -0400 Received: from sflint02.pst.cso.att.com (sflint02.pst.cso.att.com [144.154.234.229]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q5MIMMes012190 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Jun 2012 14:22:25 -0400 Received: from MISOUT7MSGHUB9B.ITServices.sbc.com (misout7msghub9b.itservices.sbc.com [144.151.223.72]) by sflint02.pst.cso.att.com (RSA Interceptor); Fri, 22 Jun 2012 14:22:11 -0400 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9B.ITServices.sbc.com ([144.151.223.72]) with mapi id 14.02.0298.004; Fri, 22 Jun 2012 14:22:10 -0400 From: "UTTARO, JAMES" To: "'Enke Chen'" , "robert@raszuk.net" Thread-Topic: [Idr] Fwd: [GROW] draft-ietf-grow-ops-reqs-for-bgp-error-handling-04 Thread-Index: Ac1Qh0AwzuLH5xBMSu2rz3aHemLX7wAGW8kZAADOS0A= Date: Fri, 22 Jun 2012 18:22:10 +0000 Message-ID: References: <4FE495CD.7080604@raszuk.net> <4FE4B2AD.9050704@cisco.com> In-Reply-To: <4FE4B2AD.9050704@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.151.80] Content-Type: multipart/alternative; boundary="_000_B17A6910EEDD1F45980687268941550FB1F97FMISOUT7MSGUSR9IIT_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=1.0 c=1 a=dXkvp1zHZaMA:10 a=ofMgfj31e3cA:10 a=BLceEmwcHo] X-AnalysisOut: [wA:10 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a=AUd_NHdVAAAA:8 a=2cl] X-AnalysisOut: [OPd4PAAAA:8 a=48vgC7mUAAAA:8 a=COAiZOjdOaZY4NTSpp4A:9 a=Cj] X-AnalysisOut: [uIK1q_8ugA:10 a=JfD0Fch1gWkA:10 a=bDUki_mJ7DgA:10 a=lZB815] X-AnalysisOut: [dzVvQA:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=_82lQTgo2F5v] X-AnalysisOut: [O93CtvAA:9 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6] X-AnalysisOut: [K0A:10] Cc: "idr@ietf.org List" , "grow@ietf.org" Subject: Re: [Idr] Fwd: [GROW] draft-ietf-grow-ops-reqs-for-bgp-error-handling-04 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2012 18:22:37 -0000 --_000_B17A6910EEDD1F45980687268941550FB1F97FMISOUT7MSGUSR9IIT_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1.. Jim Uttaro From: Enke Chen [mailto:enkechen@cisco.com] Sent: Friday, June 22, 2012 2:00 PM To: robert@raszuk.net Cc: idr@ietf.org List; grow@ietf.org; UTTARO, JAMES; Enke Chen Subject: Re: [Idr] Fwd: [GROW] draft-ietf-grow-ops-reqs-for-bgp-error-handl= ing-04 Hi, folks: It might help the discussion to refresh ourselves about several large outag= es in the last few years that prompted the work on the error handling requi= rements and solutions: o issue with AS4_PATH that resulted in session resets multiple hops away= (two separate incidents) o session reset triggered by a single route with a new attribute I remember that Rob had a presentation at the NANOG on the topic. -- Enke On 6/22/12 8:57 AM, Robert Raszuk wrote: Jim, We could as easily without any change to BGP use BGP Persistence to maintain the paths except for the ones that have the invalid attribute.. This is the simpler method, has the benefit of not changing BGP, or educating the world on the nuances of the changes etc... + Why wouldn't we simply let the session fail and then use BGP Persistence or GR ;) Please observe that when the session is down you are not receiving withdraw= s or new best paths for those "good" prefixes (maybe 99% of them) which did= not have any errors in their respective update messages. Equating it with persistence proposal is therefor highly incorrect. I also do not fully understand "treat as withdraw" does this meant that the peer who has received an update with P1-PN with malformed attr then initiate a withdrawal to all of its peers? Or simply assume that the paths have been received as a message? Some sample topologies as to how this works would be a good addition to this section.. The speaker reacting on an error which can be addressed by "treat-as-withdr= aw" invalidates locally those prefixes received in the update message, runs= local best path and as result if no other path is found withdraws those pr= efixes from all peers it has previously sent them to. I am not in support of solutions which create a scenario where BGP cannot recover without human intervention. I think no one is. But we are - I think - not there yet for the routers to = automatically fix their bugs, but only automatically signalling them the re= quested action ;(. > Nothing is going to get people's attention like a failed BGP > Session.. True statement. But the entire assumption behind treat-as-withdraw is that = your ops scripts parse the syslog messages indicating the issue to NOC with= the same red color and buzz as bgp session down. Of course you need to rew= ork your ops scripts/alarms for that to happen. Rgs, R. PS. Note that if the main BGP session is down (like in the persistence case) BG= P Operational Messages can not any longer be exchanged between peers as TCP= connection could have been reset (if no multisession is used and if we are= talking about single SAFI). That just makes the issue worse especially whe= n you do not like to have humans intervention. _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr --_000_B17A6910EEDD1F45980687268941550FB1F97FMISOUT7MSGUSR9IIT_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1..

 <= /p>

Jim Uttaro

 <= /p>

From: Enke Chen [mailto:enkechen@cisco.com]
Sent: Friday, June 22, 2012 2:00 PM
To: robert@raszuk.net
Cc: idr@ietf.org List; grow@ietf.org; UTTARO, JAMES; Enke Chen
Subject: Re: [Idr] Fwd: [GROW] draft-ietf-grow-ops-reqs-for-bgp-erro= r-handling-04

 

Hi, folks:

It might help the discussion to refresh ourselves about several large outag= es in the last few years that prompted the work on the error handling requi= rements and solutions:

   o issue with AS4_PATH that resulted in session resets multiple= hops away (two separate incidents)
   o session reset triggered by a single route with a new attribu= te

I remember that Rob had a presentation at the NANOG on the topic.

-- Enke

On 6/22/12 8:57 AM, Robert Raszuk wrote:

Jim,


We could as easily without any change to BGP use BGP= Persistence to
maintain the paths except for the ones that have the invalid
attribute.. This is the simpler method, has the benefit of not
changing BGP, or educating the world on the nuances of the changes
etc…

+

Why wouldn’t we simply let the session fail an= d then use BGP Persistence
or GR ;)


Please observe that when the session is down you are not receiving withdraw= s or new best paths for those "good" prefixes (maybe 99% of them)= which did not have any errors in their respective update messages.

Equating it with persistence proposal is therefor highly incorrect.


I also do not fully understand “treat as withd= raw” does this meant that
the peer who has received an update with P1-PN with malformed attr then initiate a withdrawal to all of its peers?  Or simply assume that the =
paths have been received as a message?  Some sample topologies as to h= ow
this works would be a good addition to this section..


The speaker reacting on an error which can be addressed by "treat-as-w= ithdraw" invalidates locally those prefixes received in the update mes= sage, runs local best path and as result if no other path is found withdraw= s those prefixes from all peers it has previously sent them to.


I am not in support of solutions which create a scen= ario where BGP
cannot recover without human intervention.


I think no one is. But we are - I think - not there yet for the routers to = automatically fix their bugs, but only automatically signalling them the re= quested action ;(.

> Nothing is going to get people’s attention like a failed BGP > Session..

True statement. But the entire assumption behind treat-as-withdraw is that = your ops scripts parse the syslog messages indicating the issue to NOC with= the same red color and buzz as bgp session down. Of course you need to rew= ork your ops scripts/alarms for that to happen.

Rgs,
R.

PS.

Note that if the main BGP session is down (like in the persistence case) BG= P Operational Messages can not any longer be exchanged between peers as TCP= connection could have been reset (if no multisession is used and if we are= talking about single SAFI). That just makes the issue worse especially when you do not like to have humans = intervention. 





_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf=
.org/mailman/listinfo/idr

 

--_000_B17A6910EEDD1F45980687268941550FB1F97FMISOUT7MSGUSR9IIT_-- From internet-drafts@ietf.org Fri Jun 22 12:10:46 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40F0921F853B; Fri, 22 Jun 2012 12:10:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.48 X-Spam-Level: X-Spam-Status: No, score=-102.48 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wWMAVJDHAQsq; Fri, 22 Jun 2012 12:10:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B8E521F853A; Fri, 22 Jun 2012 12:10:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.21 Message-ID: <20120622191027.2782.31128.idtracker@ietfa.amsl.com> Date: Fri, 22 Jun 2012 12:10:27 -0700 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-rfc4893bis-07.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2012 19:10:46 -0000 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 : BGP Support for Four-octet AS Number Space Author(s) : Quaizar Vohra Enke Chen Filename : draft-ietf-idr-rfc4893bis-07.txt Pages : 12 Date : 2012-06-22 Abstract: The Autonomous System number is encoded as a two-octet entity in the base BGP specification. This document describes extensions to BGP to carry the Autonomous System numbers as four-octet entities. This document obsoletes RFC 4893. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-rfc4893bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-rfc4893bis-07 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-rfc4893bis-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From enkechen@cisco.com Fri Jun 22 12:13:51 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FECE21F8597 for ; Fri, 22 Jun 2012 12:13:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.48 X-Spam-Level: X-Spam-Status: No, score=-10.48 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7zMovCU+bElt for ; Fri, 22 Jun 2012 12:13:50 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id CB38C21F857F for ; Fri, 22 Jun 2012 12:13:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=enkechen@cisco.com; l=2024; q=dns/txt; s=iport; t=1340392430; x=1341602030; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=YMb+Nw+YknMBAn42DSwe3m/h1d3X01vKuEsDEnC8Z8A=; b=PQcm9gYGmfSzZxpjK1Wlqm0eOrD6A3uVzG8hEU0XlxWoEQvICpOmRKZn lu/Ew5xn0qxCLvHcpWFxuXqHiUvP0DXvWeqEuj5zthuGLgTpLfC8hJzAG +bawnLwB86UwHIq+r4n/Jvhpi+Nav7dfyo/FAIUiGL1hVAEi9DdWVWFGs o=; X-IronPort-AV: E=Sophos;i="4.77,459,1336348800"; d="scan'208";a="47337654" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 22 Jun 2012 19:13:50 +0000 Received: from sjc-vpn4-1382.cisco.com (sjc-vpn4-1382.cisco.com [10.21.85.101]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q5MJDotW014362; Fri, 22 Jun 2012 19:13:50 GMT Message-ID: <4FE4C445.1040005@cisco.com> Date: Fri, 22 Jun 2012 12:15:17 -0700 From: Enke Chen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: idr@ietf.org References: <20120622191027.2782.31128.idtracker@ietfa.amsl.com> In-Reply-To: <20120622191027.2782.31128.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Idr] I-D Action: draft-ietf-idr-rfc4893bis-07.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2012 19:13:51 -0000 Hi, folks: The revised version addresses comments received during the IETF Last Call. The diff is larger due to several terminology related changes: > Q_GEN-1: Sometimes the text says "AS number", and sometimes "Autonomous System number". Please use consistant terminology. > Q_GEN-2: Sometimes the text says "2-octet", and sometimes "two-octet". Please use consistant terminology. > Q_GEN-3: Sometimes the text says "4-octet", and sometimes "four-octet". Please use consistant terminology. Thanks. -- Enke On 6/22/12 12:10 PM, internet-drafts@ietf.org wrote: > 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 : BGP Support for Four-octet AS Number Space > Author(s) : Quaizar Vohra > Enke Chen > Filename : draft-ietf-idr-rfc4893bis-07.txt > Pages : 12 > Date : 2012-06-22 > > Abstract: > The Autonomous System number is encoded as a two-octet entity in the > base BGP specification. This document describes extensions to BGP to > carry the Autonomous System numbers as four-octet entities. This > document obsoletes RFC 4893. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-idr-rfc4893bis > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-idr-rfc4893bis-07 > > A diff from previous version is available at: > http://tools.ietf.org/rfcdiff?url2=draft-ietf-idr-rfc4893bis-07 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From jgs@juniper.net Fri Jun 22 12:19:22 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0AC021F84D9 for ; Fri, 22 Jun 2012 12:19:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.467 X-Spam-Level: X-Spam-Status: No, score=-6.467 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DB0xdOTJFg4H for ; Fri, 22 Jun 2012 12:19:22 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by ietfa.amsl.com (Postfix) with ESMTP id 3134521F84D6 for ; Fri, 22 Jun 2012 12:19:22 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKT+TFOXfjB9MrUN19KnvNMPxQ7DafiAe9@postini.com; Fri, 22 Jun 2012 12:19:22 PDT Received: from [172.16.13.202] (172.16.13.202) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server id 8.3.213.0; Fri, 22 Jun 2012 12:18:27 -0700 MIME-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset="us-ascii" From: "John G. Scudder" In-Reply-To: <4FE4C445.1040005@cisco.com> Date: Fri, 22 Jun 2012 15:18:30 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <2C98F87E-9248-4A4D-8083-BB2189937983@juniper.net> References: <20120622191027.2782.31128.idtracker@ietfa.amsl.com> <4FE4C445.1040005@cisco.com> To: "idr@ietf.org wg" X-Mailer: Apple Mail (2.1278) Subject: Re: [Idr] I-D Action: draft-ietf-idr-rfc4893bis-07.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2012 19:19:23 -0000 Thanks, Enke. To add to this, there is (I believe) just one normative = change.=20 -06 says: The AS4_PATH attribute in an UPDATE message SHALL be considered malformed under the following conditions: - the attribute length is not a multiple of two, or is too small (i.e., less than 6) for the attribute to carry at least one AS number, or - the path segment length in the attribute is either zero, or is inconsistent with the attribute length, or - the path segment type in the attribute is not one of the types defined: AS_SEQUENCE, AS_SET. -07 changes the final bullet: The AS4_PATH attribute in an UPDATE message SHALL be considered malformed under the following conditions: - the attribute length is not a multiple of two, or is too small (i.e., less than 6) for the attribute to carry at least one AS number, or - the path segment length in the attribute is either zero, or is inconsistent with the attribute length, or - the path segment type in the attribute is not one of the types defined: AS_SEQUENCE, AS_SET, AS_CONFED_SEQUENCE and AS_CONFED_SET. Regards, --John On Jun 22, 2012, at 3:15 PM, Enke Chen wrote: > Hi, folks: >=20 > The revised version addresses comments received during the IETF Last=20= > Call. The diff is larger due to several terminology related changes: >=20 >> Q_GEN-1: Sometimes the text says "AS number", and sometimes=20 > "Autonomous System number". Please use consistant terminology. >> Q_GEN-2: Sometimes the text says "2-octet", and sometimes=20 > "two-octet". Please use consistant terminology. >> Q_GEN-3: Sometimes the text says "4-octet", and sometimes=20 > "four-octet". Please use consistant terminology. >=20 > Thanks. -- Enke >=20 > On 6/22/12 12:10 PM, internet-drafts@ietf.org wrote: >> 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. >>=20 >> Title : BGP Support for Four-octet AS Number Space >> Author(s) : Quaizar Vohra >> Enke Chen >> Filename : draft-ietf-idr-rfc4893bis-07.txt >> Pages : 12 >> Date : 2012-06-22 >>=20 >> Abstract: >> The Autonomous System number is encoded as a two-octet entity in = the >> base BGP specification. This document describes extensions to BGP = to >> carry the Autonomous System numbers as four-octet entities. This >> document obsoletes RFC 4893. >>=20 >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-idr-rfc4893bis >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-idr-rfc4893bis-07 >>=20 >> A diff from previous version is available at: >> http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-rfc4893bis-07 >>=20 >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From enkechen@cisco.com Fri Jun 22 12:34:22 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2455621F8687 for ; Fri, 22 Jun 2012 12:34:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.497 X-Spam-Level: X-Spam-Status: No, score=-10.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MLd1eju+kp-d for ; Fri, 22 Jun 2012 12:34:21 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 433C421F85A8 for ; Fri, 22 Jun 2012 12:34:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=enkechen@cisco.com; l=3755; q=dns/txt; s=iport; t=1340393661; x=1341603261; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=5PpBXYB6XyEJLfu/sXOdv6gJmX1Yfy3oKpcA5qMGXOU=; b=dKmoucQeWremAJLiEnXo1Uy3dVR1m8aQt+amUmVW6h4S0xUmeMBEYAGo C6aA8TPoJaSxzgsOa3DwYTxrFUcG7MCJjCI9f7LOfNqLHdIsl5MnYg0Kt JP740GzAyFezwYEAuj2OhJ8wI+BvnsYwBI7Wtp1vuPhz/npSnx/CKKxgQ 0=; X-IronPort-AV: E=Sophos;i="4.77,460,1336348800"; d="scan'208";a="47339433" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 22 Jun 2012 19:34:16 +0000 Received: from sjc-vpn4-1382.cisco.com (sjc-vpn4-1382.cisco.com [10.21.85.101]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q5MJYGQP023193; Fri, 22 Jun 2012 19:34:16 GMT Message-ID: <4FE4C90E.7090109@cisco.com> Date: Fri, 22 Jun 2012 12:35:42 -0700 From: Enke Chen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "John G. Scudder" References: <20120622191027.2782.31128.idtracker@ietfa.amsl.com> <4FE4C445.1040005@cisco.com> <2C98F87E-9248-4A4D-8083-BB2189937983@juniper.net> In-Reply-To: <2C98F87E-9248-4A4D-8083-BB2189937983@juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org wg" Subject: Re: [Idr] I-D Action: draft-ietf-idr-rfc4893bis-07.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2012 19:34:22 -0000 Thanks, John. The bug was introduced during editing in -06. -- Enke On 6/22/12 12:18 PM, John G. Scudder wrote: > Thanks, Enke. To add to this, there is (I believe) just one normative change. > > -06 says: > > The AS4_PATH attribute in an UPDATE message SHALL be considered > malformed under the following conditions: > > - the attribute length is not a multiple of two, or is too small > (i.e., less than 6) for the attribute to carry at least one > AS number, or > > - the path segment length in the attribute is either zero, or > is inconsistent with the attribute length, or > > - the path segment type in the attribute is not one of the > types defined: AS_SEQUENCE, AS_SET. > > -07 changes the final bullet: > > The AS4_PATH attribute in an UPDATE message SHALL be considered > malformed under the following conditions: > > - the attribute length is not a multiple of two, or is too small > (i.e., less than 6) for the attribute to carry at least one > AS number, or > > - the path segment length in the attribute is either zero, or > is inconsistent with the attribute length, or > > - the path segment type in the attribute is not one of the > types defined: AS_SEQUENCE, AS_SET, AS_CONFED_SEQUENCE > and AS_CONFED_SET. > > Regards, > > --John > > On Jun 22, 2012, at 3:15 PM, Enke Chen wrote: > >> Hi, folks: >> >> The revised version addresses comments received during the IETF Last >> Call. The diff is larger due to several terminology related changes: >> >>> Q_GEN-1: Sometimes the text says "AS number", and sometimes >> "Autonomous System number". Please use consistant terminology. >>> Q_GEN-2: Sometimes the text says "2-octet", and sometimes >> "two-octet". Please use consistant terminology. >>> Q_GEN-3: Sometimes the text says "4-octet", and sometimes >> "four-octet". Please use consistant terminology. >> >> Thanks. -- Enke >> >> On 6/22/12 12:10 PM, internet-drafts@ietf.org wrote: >>> 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 : BGP Support for Four-octet AS Number Space >>> Author(s) : Quaizar Vohra >>> Enke Chen >>> Filename : draft-ietf-idr-rfc4893bis-07.txt >>> Pages : 12 >>> Date : 2012-06-22 >>> >>> Abstract: >>> The Autonomous System number is encoded as a two-octet entity in the >>> base BGP specification. This document describes extensions to BGP to >>> carry the Autonomous System numbers as four-octet entities. This >>> document obsoletes RFC 4893. >>> >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-idr-rfc4893bis >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-idr-rfc4893bis-07 >>> >>> A diff from previous version is available at: >>> http://tools.ietf.org/rfcdiff?url2=draft-ietf-idr-rfc4893bis-07 >>> >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> I-D-Announce mailing list >>> I-D-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/i-d-announce >>> Internet-Draft directories: http://www.ietf.org/shadow.html >>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr From sairay@cisco.com Fri Jun 22 15:38:16 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 701FC21F8597 for ; Fri, 22 Jun 2012 15:38:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.298 X-Spam-Level: X-Spam-Status: No, score=-10.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Q2M76+ai-9i for ; Fri, 22 Jun 2012 15:38:15 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id B651921F8596 for ; Fri, 22 Jun 2012 15:38:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sairay@cisco.com; l=6207; q=dns/txt; s=iport; t=1340404695; x=1341614295; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ygJJFcgTOHvI9sW0LdxSsIXugd/flhOFyugtPy8z7gk=; b=XLrqNhZ2Pjsr8DZzoIAI5yNv8zdvpo0qO+kfEOEQHSDQDsLMRCSpEapB jOHCKE1hT/0HQCWCEEdQjP4DyOsJAzpkSIQkQj4GP1JtJe8KMg75zymt5 YV3sTVrH+iD8z5R49AdNpmLSv14zazKQDQcYs0W8z508A6QhIRWnE1QaY U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAErz5E+tJXG+/2dsb2JhbABFgkWzIoEHghkBAQQSARpMEAIBCCIkMiUCBA4NDA6HaZozn2uLQ4UNYAOjR4Fmgl+BVgEE X-IronPort-AV: E=Sophos;i="4.77,460,1336348800"; d="scan'208,217";a="95131555" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-8.cisco.com with ESMTP; 22 Jun 2012 22:38:15 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q5MMcFXr010381 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 Jun 2012 22:38:15 GMT Received: from xmb-rcd-x13.cisco.com ([169.254.3.37]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0298.004; Fri, 22 Jun 2012 17:38:14 -0500 From: "Saikat Ray (sairay)" To: Jakob Heitz Thread-Topic: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks Thread-Index: AQHNUIK5992oODS5z0GaMDFvi/PwiZcGhN0ggABkFID//65x8IAAAddQgABQZcA= Date: Fri, 22 Jun 2012 22:38:14 +0000 Message-ID: <8ED5B0B0F5B4854A912480C1521F973ADC87@xmb-rcd-x13.cisco.com> References: <003c01cd4b29$97d7b150$c78713f0$@ndzh.com> <985EF8D2-DA8A-4BE7-94D3-F4BE2B74D768@castlepoint.net> <4FE07A24.7050804@raszuk.net> <1C1F2B2E-2EB7-42F0-8CFF-57965443C074@castlepoint.net> <7A614998-8FB1-4A51-9937-DE501FF31EB6@juniper.net> <4FE0D1F4.9070208@cisco.com> <4FE0E074.3070905@raszuk.net> <17490_1340180565_4FE18855_17490_15423_1_53C29892C857584299CBF5D05346208A0928AA@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FE18A61.8000405@raszuk.net> <8ED5B0B0F5B4854A912480C1521F973AD95B@xmb-rcd-x13.cisco.com> <4FE4A8F3.20809@cisco.com> <8ED5B0B0F5B4854A912480C1521F973AD9C9@xmb-rcd-x13.cisco.com> <7309FCBCAE981B43ABBE69B31C8D213921C23CA13C@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D213921C23CA13C@EUSAACMS0701.eamcs.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.155.34.15] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-18990.001 x-tm-as-result: No--30.133100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_8ED5B0B0F5B4854A912480C1521F973ADC87xmbrcdx13ciscocom_" MIME-Version: 1.0 Cc: "idr@ietf.org" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2012 22:38:16 -0000 --_000_8ED5B0B0F5B4854A912480C1521F973ADC87xmbrcdx13ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable A new capability would certainly help. It seems necessary, but may not be = sufficient to limit the scope of the STALE path to "consenting adults". F= or example, inside a network (i.e., AS), if there are routers that do not r= ecognize the STALE community, [SR] That router must not negotiate the STALE capability with any peer, iBG= P or eBGP, and hence should not receive any stale path from any router. The= stale capability must be negotiated even within iBGP peers. To avoid incon= sistency of iBGP routes in an AS, you might need to add the restriction tha= t unless all iBGP peers negotiate the new capability, STALE paths should no= t be sent to any of them. [Jakob Heitz] What if a Route Reflector acquires a client without the capab= ility? That client will not get any STALE route ;) --_000_8ED5B0B0F5B4854A912480C1521F973ADC87xmbrcdx13ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

A new capability would certainly help.  It seem= s necessary, but may not be sufficient to limit the scope of the STALE path= to "consenting adults".   For example, inside a networ= k (i.e., AS), if there are routers that do not recognize the STALE community,

[SR] That router must not= negotiate the STALE capability with any peer, iBGP or eBGP, and hence shou= ld not receive any stale path from any router. The stale capability must be negotiated even within iBGP peers. To avoid inconsisten= cy of iBGP routes in an AS, you might need to add the restriction that unle= ss all iBGP peers negotiate the new capability, STALE paths should not be s= ent to any of them.

[Jakob Heitz] What if a Route Reflect= or acquires a client without the capability?

 <= /p>

That client will not get = any STALE route ;)

--_000_8ED5B0B0F5B4854A912480C1521F973ADC87xmbrcdx13ciscocom_-- From ju1738@att.com Fri Jun 22 15:59:54 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 037B421F85F1 for ; Fri, 22 Jun 2012 15:59:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.394 X-Spam-Level: X-Spam-Status: No, score=-106.394 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZP0DTny+hAnZ for ; Fri, 22 Jun 2012 15:59:52 -0700 (PDT) Received: from nbfkord-smmo03.seg.att.com (nbfkord-smmo03.seg.att.com [209.65.160.84]) by ietfa.amsl.com (Postfix) with ESMTP id C7EFE21F85F2 for ; Fri, 22 Jun 2012 15:59:51 -0700 (PDT) Received: from unknown [144.160.128.153] (EHLO flpi408.enaf.ffdc.sbc.com) by nbfkord-smmo03.seg.att.com(mxl_mta-6.11.0-10) over TLS secured channel with ESMTP id 7e8f4ef4.0.880063.00-364.2446997.nbfkord-smmo03.seg.att.com (envelope-from ); Fri, 22 Jun 2012 22:59:51 +0000 (UTC) X-MXL-Hash: 4fe4f8e700f49d2c-897be918ab857c29b4bc8d768088116e8a21693e Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q5MMxma2025756; Fri, 22 Jun 2012 15:59:50 -0700 Received: from fflint03.pst.cso.att.com (fflint03.pst.cso.att.com [150.234.39.63]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q5MMxbc6025310 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Jun 2012 15:59:44 -0700 Received: from MISOUT7MSGHUB9B.ITServices.sbc.com (misout7msghub9b.itservices.sbc.com [144.151.223.72]) by fflint03.pst.cso.att.com (RSA Interceptor); Fri, 22 Jun 2012 15:59:11 -0700 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9B.ITServices.sbc.com ([144.151.223.72]) with mapi id 14.02.0298.004; Fri, 22 Jun 2012 18:58:53 -0400 From: "UTTARO, JAMES" To: "UTTARO, JAMES" , "'John G. Scudder'" Thread-Topic: [Idr] I-D Action: draft-ietf-idr-error-handling-02.txt Thread-Index: AQHNTMoO3AC4WgUFwEeXslewDoqMZpb/MenAgAGOTwD//8NEcIADk6OAgAJ9+mCAAGNbgA== Date: Fri, 22 Jun 2012 22:58:53 +0000 Message-ID: References: <20120617204451.26844.76025.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.216.167] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.128.153] X-AnalysisOut: [v=1.0 c=1 a=xH7KjXpsev8A:10 a=Crak0S_X7RUA:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=xwOvzTHDVLE4u4] X-AnalysisOut: [nGvK72ag==:17 a=48vgC7mUAAAA:8 a=zQP7CpKOAAAA:8 a=OUXY8nFu] X-AnalysisOut: [AAAA:8 a=Jb35nYh24C7XuWfE2xsA:9 a=CjuIK1q_8ugA:10 a=2TSDkf] X-AnalysisOut: [qdCjIA:10 a=lZB815dzVvQA:10 a=peF9eE_zjQwA:10 a=Hz7IrDYlS0] X-AnalysisOut: [cA:10 a=1mNqbZnSjcHmuunV:21 a=VUaQM5nUj4iqFJIG:21] Cc: "idr@ietf.org" Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2012 22:59:54 -0000 John, Apologies, I missed the section below. Comments In-line Jim Uttaro -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of UTTAR= O, JAMES Sent: Friday, June 22, 2012 1:09 PM To: 'John G. Scudder' Cc: idr@ietf.org Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-02.txt *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. John, Comments In-Line Thanks, Jim Uttaro -----Original Message----- From: John G. Scudder [mailto:jgs@juniper.net]=20 Sent: Wednesday, June 20, 2012 6:49 PM To: UTTARO, JAMES Cc: John Scudder; idr@ietf.org Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-02.txt [trimmed cc] Jim, On Jun 18, 2012, at 5:13 PM, "UTTARO, JAMES" wrote: > John, >=20 > The notion of this draft is to change the actual behavior of the p= rotocol in terms of the resultant action due to a update error malformed at= tr.. Currently the session is torn down.. Another behavior would be timer e= xpiry, in that case the actual NH of the update is correct, but a timer exp= iry between a RR and the egress PE also tears down the session. Should we c= hange the specification to deal with a bug where a RR cannot maintain sessi= ons? Are there addl bugs in the protocol implementation that are being cons= idered ? No. If you or another WG member would like to propose such, feel free to br= ing it up. =20 [Jim U>] I commented on Rob's draft in GROW and I feel that this is a great= opportunity to consider a number of session failures beyond the Update var= iety.. I will pursue with Rob > The BGP persistence draft and GR to a lesser extent as it does not= survive as many error conditions accepts the base specification but simply= allows paths to persist without changing the fundamental nature of the pro= tocol.. Why do we need this solution also? If the egress PE used BGP Persis= tence or GR ( Assume modified to persist through mal-formed attr ), then th= e current specification continues unchanged, and valid paths persist. There are several answers to this but the most fundamental is that if you'v= e got a poison route in the system then when you restart your session (whet= her with GR, persistence, or what-have-you) you'll eventually get the poiso= n route again, reset the session again, repeat forever. In the mean time yo= ur routing will be badly degraded and anything that would arrive after the = poison route in the initial convergence will be completely stuck since you'= ll always reset before seeing it. =20 [Jim U>] I think two cases here. The first is if the speaker is initially c= oming up, then all paths up to the one with the mal-formed would be retaine= d and valid, the poison path would cause a failure of the session, all subs= equent paths are not received..The second is a speaker getting updates in r= esponse to normal behavior or a soft refresh.. In either of these cases the= paths already learned are programmed and not affected or better said stale= ... IMO it is best to consider these cases independently, in the former I d= o not want the session established s there is something fundamentally wrong= with the machinery, in the latter I have all paths learned already and am = in steady state.. By ignoring the poison route you allow the rest of your routes to continue = getting service. You may even be able to use an alternate path toward the p= refixes in the poison route.=20 [Jim U>] See Above > Another observation is that the draft attempts to provide a finer level o= f granularity in terms of specification for some errors. The resultant acti= on is no longer at a session but at a path level. >=20 > If one path has a mal-formed update I believe that all of the paths in th= at update are treated as withdrawn . If so, then this fix discards possibly= different sets of good paths at different egress PEs? I guess? Though if you're distributing a consistent set of routes within yo= ur AS I think you'll normally end up discarding them consistently too becau= se they'll arrive with the same (presumed to be malformed) attributes, whet= her packed into one update or spread across several. OTOH if you're not dis= tributing a consistent set of routes within your AS then yes, you are hoist= on your own petard.=20 [Jim U>] Have to think about this some more... Anything can happen of course if you posit just the right (wrong) set of bu= gs, but that way lies madness. I think in reasonably foreseeable circumstan= ces things will tend to go as I've described above. Even in the case where = inconsistency ensues, well, this is already broadly speaking a known side-e= ffect of the proposal and the notion is it's acceptable if the other altern= ative is session reset.=20 [Jim U>] Do not agree. Session reset is fine if forwarding is retained.. Th= at is the end goal not maintain a session and thus forwarding is retained. = As I commented on Rob's draft, we need to maintain forwarding through this = and other failure modes of a session, we cannot have different bottom up so= lutions for different errors.. > This may create inconsistent routing topologies as different "good paths"= may be discarded based on update packing at the ingress PE. So not an inco= nsistency for the path with the mal-formed attr but possibly all the others= packed in.. By definition all the prefixes packed in the same update share the same (pr= esumed to be malformed) attributes, so there is zero chance of an "innocent= " route catching a drive-by bullet as you describe.=20 [Jim U>] Ok. I thought the packing paradigm did not require all the exact s= ame attributes..=20 > Comments In-Line.. Ditto.=20 > Thanks, > Jim Uttaro >=20 >=20 > -----Original Message----- > From: John G. Scudder [mailto:jgs@juniper.net] > Sent: Monday, June 18, 2012 3:49 PM > To: UTTARO, JAMES > Cc: 'internet-drafts@ietf.org'; i-d-announce@ietf.org; idr@ietf.org > Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-02.txt >=20 > Hi Jim, >=20 > On Jun 17, 2012, at 8:29 PM, UTTARO, JAMES wrote: >=20 >> I took a read on this ( I will read more thoroughly) but one section jum= ped out at me. "Operational Considerations". >>=20 >>=20 >> Although the "treat-as-withdraw" error-handling behavior defined in >> Section 2 makes every effort to preserve BGP's correctness, we note >> that if an UPDATE received on an IBGP session is subjected to this >> treatment, inconsistent routing within the affected Autonomous System >> may result. The consequences of inconsistent routing can include >> long-lived forwarding loops and black holes. While lamentable, this >> issue is expected to be rare in practice, and more importantly is >> seen as less problematic than the session-reset behavior it replaces. >>=20 >> " When a malformed attribute is indeed detected over an IBGP session, >> we RECOMMEND that routes with the malformed attribute be identified >> and traced back to the ingress router in the network where the routes >> were sourced or received externally, and then a filter be applied on >> the ingress router to prevent the routes from being sourced or >> received. This will help maintain routing consistency in the >> network." >>=20 >>=20 >> I don't think the terminology "lamentable" to describe Long lived forwar= ding loops and black holes is appropriate as it would probably be more than= regrettable. >=20 > My dictionary says "(of circumstances or conditions) deplorably bad or un= satisfactory" which seems about right to me. We could have said "it really = sucks a lot" but the style seems wrong. :-) But this sentence could be rewr= itten as needed, it's not a big deal. > [Jim U>] Agreed it is bad/unsatisfactory. I guess I was addressing the pr= emise. >=20 >> Could you expand on the conditions >=20 > One very simple case: >=20 > A--B--C--D >=20 > The four routers depicted form an IBGP full mesh (sessions not shown). Th= e links shown are the physical topology. Standard IP forwarding is used. Ro= uters A and D are ASBRs and both advertise a path for prefix X into IBGP. R= outer C prefers the path from A, for example due to a shorter AS Path. Howe= ver, router B decides that the path from A is malformed, so it selects the = path from D. Now we have C's next hop to reach X as B, and B's next hop to = reach X as C. This is a stable forwarding loop. (Why do B and C have differ= ent conclusions about whether the update is malformed? Different code bases= with different assumptions, as we have seen more than once in the field.) > [Jim U>] Ouch. We could get some big flows going back and forth in our to= pology based upon the path in question... would this be trading forwarding = loops within a network for routing churn amongst networks and/or traffic re= -direction.. It sort of feels that way to me.. Potentially, yes. Devil, deep blue sea. One thing to observe is that a flap= ping bgp session in the middle of your network is the other alternative in = this scenario. Does that sound better to you? Most reviewers have thought i= t sounded worse.=20 >>[Jim U>] If my forwarding remained stable ( GR, Persistence ) I would pre= fer the session flap to the network flows as the network is still stable in= both the forwarding and control planes ( Control Plane is Working ).. The = traffic flow size, QOS etc is not deterministic this is of concern to me as= classes of service may be prioritized along certain paths in the network..= . Too be honest again this may service specific.. >> and how BGP would eventually recover. >=20 > It wouldn't :-( without operator intervention. > [Jim U>] Ouch +1.. >=20 >> That would be a good addition. I am a bit confused, how does this type o= f error handling which restarts GR ( As of my last read ) and which BGP per= sistence lives through change the paradigm of these solutions? >=20 > I don't understand this question. > [Jim U>] Assume BGP current behavior.. The sessions would be torn down, B= GP Persist/GR ( Assume GR is modified to persist through a mal-formed attr = ) would become active.. See discussion above.=20 > In this model for a subset of failure modes the session would not be torn= down. I guess the issue is that for different error conditions we see diff= erent solutions/behaviors.. If malformed then no session tear down, treat a= s withdrawn, If timer expiry than if GR tear session down flush paths, BGP = Persistence session tear down maintain paths. I am war of the lack of consi= stency.. I think this is a legitimate case of different diseases having different cu= res, although as Enke (I think) mentioned in a different context, if we can= come up with a single, simpler, unified solution to these problems then th= at's great. Big "if", though.=20 >>[Jim U>] Yes agreed. But philosophically I think there is a big change wi= th this draft. It takes the position that a subset of error codes should be= addressed at a path vs session level.. This leads to big complexity in und= erstanding what is happening in the network, and notifying/correcting/fixin= g part of the equation. >> There is a notion of treat as withdraw for some attrs, but don't tear do= wn session?? >=20 > Yes. You're right to find this shocking. I find it shocking, but have bee= n browbeaten :-)/2 into agreeing that the cure may be a little less bad tha= n the disease. However, the floor is still definitely open for debate! > [Jim U>] Ouch.. I don't like the notion of changing the fundamental natur= e of the protocol.. >=20 >> How many malformed updates before the session is torn down? Ever? >=20 > This was discussed a while ago, inconclusively. To date, I don't recall h= aving seen any suggestions I really liked for how to decide a session shoul= d be torn down. It actually seems to make things more complicated (to imple= ment, to debug in operation) to have two error-handling modes you flip betw= een according to some heuristic. The floor is still open for more discussio= n. > [Jim U>] Maybe determine the exposure to inconsistency.. >=20 >> According to the next paragraph ( See below ) there is an expectation th= at the offending ingress router should be identified, and then a filter sho= uld be applied for those paths in a given updated with the malformed attrs = :) What is the recommendation for doing this? >=20 > The router should log (and possibly trap, alarm, etc) the offending updat= e(s). The operator should examine the logs and by so doing, figure it out f= rom there. Sorry this seems glib but that's what it comes down to. Remember= that the alternate (present-day) scenario is that the BGP session to the a= ffected router is going to flap, which is likely even worse operationally, = possibly much worse. > [Jim U>] If we could persist the state than the damage from the flap shou= ld be mitigated.. Again, see above.=20 > Of course this is different based on application i.e internet, VPNV4, vPN= V2 etc... We would need to think about how to automate this.. >=20 >> Will there be a draft whereby the detecting router somehow figures out t= he offending ingress router, builds routing policy and then sends it there = to dynamically create the filter. >=20 > I sincerely hope not and have spoken against this idea in the past. > [Jim U>] LOL >=20 >> This seems non-trivial, >=20 > That's why. When you start building machinery to automatically patch arou= nd bugs in your primary routing machinery, IMO you have officially Jumped T= he Shark and started building a Rube Goldberg router. > [Jim U>] Yes. If there is a bug that should be fixed.. There are solution= that allow state to persist.. I would prefer this as opposed to modifying = the specification to deal with this one type of bug? BTW Is it extensible t= o other Update Message Errors?? The idea is to cover pretty much every message error, as long as the prefix= es still can be extracted and the update boundaries determined, yes.=20 >>[Jim U>] Ok.. Thanks, =20 --John >> I guess Flowspec like technology may be used not sure.. Is the ingress r= outer assumed to be in the same AS domain as the detecting router? >=20 > Since the paragraph is talking about IBGP, yes. Of course this doesn't me= an the offending update was sourced within the same AS, but the paragraph y= ou're picking on is just talking about what happens within IBGP. > [Jim U>] Yup. Assuming same AS then like flowspec there may be a way but = again it is patching a bug in the machinery.. >=20 > Note that draft-ietf-grow-ops-reqs-for-bgp-error-handling-04.txt is very = applicable to this discussion and is currently in WGLC in GROW. Since you h= ave opinions about this topic I strongly suggest you review it and comment = on the GROW WGLC. It runs until June 25.[Jim U>] I will.. Thx... >=20 > --John >=20 >> Administrative domain may span multiple AS domains.. >>=20 >> Jim Uttaro >>=20 >>=20 >>=20 >>=20 >> -----Original Message----- >> From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of in= ternet-drafts@ietf.org >> Sent: Sunday, June 17, 2012 4:45 PM >> To: i-d-announce@ietf.org >> Cc: idr@ietf.org >> Subject: [Idr] I-D Action: draft-ietf-idr-error-handling-02.txt >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts direc= tories. >> This draft is a work item of the Inter-Domain Routing Working Group of t= he IETF. >>=20 >> Title : Revised Error Handling for BGP UPDATE Messages >> Author(s) : John G. Scudder >> Enke Chen >> Pradosh Mohapatra >> Keyur Patel >> Filename : draft-ietf-idr-error-handling-02.txt >> Pages : 10 >> Date : 2012-06-17 >>=20 >> Abstract: >> According to the base BGP specification, a BGP speaker that receives >> an UPDATE message containing a malformed attribute is required to >> reset the session over which the offending attribute was received. >> This behavior is undesirable as a session reset would impact not only >> routes with the offending attribute, but also other valid routes >> exchanged over the session. This document partially revises the >> error handling for UPDATE messages, and provides guidelines for the >> authors of documents defining new attributes. Finally, it revises >> the error handling procedures for several existing attributes. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-idr-error-handling >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-idr-error-handling-02 >>=20 >> A diff from previous version is available at: >> http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-error-handling-02 >>=20 >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> 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 _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From shane@castlepoint.net Fri Jun 22 19:00:00 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B063711E808C for ; Fri, 22 Jun 2012 19:00:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_41=0.6, J_CHICKENPOX_63=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6yb9abRfLrxN for ; Fri, 22 Jun 2012 18:59:59 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id 21A6F11E8088 for ; Fri, 22 Jun 2012 18:59:58 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id 9336E368199; Fri, 22 Jun 2012 19:59:57 -0600 (MDT) Received: from mbpw.castlepoint.net (174-29-213-45.hlrn.qwest.net [174.29.213.45]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Fri, 22 Jun 2012 19:59:57 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=174.29.213.45; client-port=52248; syn-fingerprint=65535:54:1:64:M1452,N,W1,N,N,T,S; data-bytes=0 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_9D22839D-CE8D-4821-B763-85D299CD7E9E" From: Shane Amante In-Reply-To: Date: Fri, 22 Jun 2012 19:59:39 -0600 Message-Id: References: <003c01cd4b29$97d7b150$c78713f0$@ndzh.com> <985EF8D2-DA8A-4BE7-94D3-F4BE2B74D768@castlepoint.net> <4FE07A24.7050804@raszuk.net> <1C1F2B2E-2EB7-42F0-8CFF-57965443C074@castlepoint.net> <7A614998-8FB1-4A51-9937-DE501FF31EB6@juniper.net> <4FE0D1F4.9070208@cisco.com> <4FE0E074.3070905@raszuk.net> <17490_1340180565_4FE18855_17490_15423_1_53C29892C857584299CBF5D05346208A0928AA@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FE18A61.8000405@raszuk.net> <8ED5B0B0F5B4854A912480C1521F973AD95B@xmb-rcd-x13.cisco.com> <4FE4A8F3.20809@cisco.com> <4FE4AFE2.3030107@cisco.com> To: "UTTARO, JAMES" X-Mailer: Apple Mail (2.1278) Cc: "idr@ietf.org" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jun 2012 02:00:00 -0000 --Apple-Mail=_9D22839D-CE8D-4821-B763-85D299CD7E9E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jun 22, 2012, at 12:03 PM, UTTARO, JAMES wrote: > Enke, > =20 > I think we have got to have a consistent approach to = these solutions.. I am not comfortable with the fact that it is =93ok=94 = for GR but not =93ok=94 for Persistence based on a IMO subjective = interpretation of the amount of time a STALE path is active in local and = adjacent topologies. An hour is a long time, and as GR is used primarily = used n IPV4 which is dynamic it would seem that a) these paths should be = de-pref after some amount of time b) GR should inform other AS = topologies of the staleness by using the STALE CV.. > =20 > I would be interested in hearing from operators as to if this behavior = is understood and if limiting of the time to ~1hr makes the = inconsistency within and across AS domains acceptable.. In your opinion = what is the maximum acceptable amount of time that we could use = Persistence.=20 As an operator I believe even 1 hour is too long. In fact, I'd rather = (and, I do) trust Non-Stop Routing (NSR) on PE's in the network, because = I know that CE's will not understand GR capability and will not be able = to benefit from continuing to forward packets even while the PE is = restarting. Granted, this is an environment where there are many = "unmanaged CE's", where I have no control/say over what SW or the = capabilities are on those CE's. Furthermore, with control plane redundancy for iBGP sessions from one PE = across multiple RR's serving that cluster, it is possible to conduct = maintenance on one half of the RR-pair serving a cluster while still = preserving control and/or forwarding plane behavior. Ultimately, as I've said before, I'd much rather not see any type of = "stale" routes 'sticking around' in the control plane, since that is a = vast change in behavior from today's deployment of BGP where = reachability information is only carried while there are active BGP = sessions. (Yes, I get your point that I don't have to use persistence = if I don't want to, but if developers are in there monkey'ing around = with code to add this feature, inevitably I pay a price in addt'l = complexity for this "feature" even if I don't turn it on, i.e.: there = are potentially 'latent' bugs caused by this "feature", which is not = acceptable). As Enke has stated previously, I believe this class of problem is a rare = one, (given a proper network architecture), and thus we should not be = creating AFI-specific solutions that add substantial complexity to an = already complex protocol.=20 -shane > Jim Uttaro > =20 > =20 > =20 > =20 > From: Enke Chen [mailto:enkechen@cisco.com]=20 > Sent: Friday, June 22, 2012 1:48 PM > To: UTTARO, JAMES > Cc: Saikat Ray (sairay); idr@ietf.org; Enke Chen > Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG = document - 3 more weeks > =20 > Jim, >=20 > With GR, as you correctly pointed out, a path would not stale for many = hours or days. That is why it may not be as critical to limit the scope = of the stale path. >=20 > If we were to have long-lived stale paths (which I think is a bad = idea), I agree that they should be limited to "consenting adults", and = there must be some mechanisms (such as capability) in place. >=20 > -- Enke >=20 > On 6/22/12 10:27 AM, UTTARO, JAMES wrote: > Enke, > =20 > The idea behind the setting of STALE is to inform = speakers in other AS domains that the path is suspect as the session it = was learned over is down.. IMO this is required to inform others about = the viability of a path.. > =20 > The other approach is to simply not mark these paths as STALE.. Simply = de-pref in the local AS and business as usual when advertised outside = the AS where all transitive attrs are reset.. > =20 > This is exactly the semantic you are using in the GR draft. You do not = de-pref the state locally and do not inform other AS domains that the = paths learned over the session that GR is active on are suspect. > =20 > If the STALE CV is not honored across the AS border than the behavior = defaults to what is specified in the GR draft. This should meet your = requirements. > =20 > Jim Uttaro > =20 > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of = Enke Chen > Sent: Friday, June 22, 2012 1:19 PM > To: Saikat Ray (sairay) > Cc: idr@ietf.org > Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG = document - 3 more weeks > =20 > Hi, Saikat: >=20 > A new capability would certainly help. It seems necessary, but may = not be sufficient to limit the scope of the STALE path to "consenting = adults". For example, inside a network (i.e., AS), if there are = routers that do not recognize the STALE community, a STALE path may = still be advertised to external peers without the capability. This = means that all the routers in a network must recognize the community = before enabling the capability on any of them. It will be difficult to = satisfy the condition universally. >=20 > In addition, to limit its scope the STALE community, once set, MUST = not be removed by any receiver. >=20 > -- Enke >=20 > On 6/22/12 9:34 AM, Saikat Ray (sairay) wrote: > Without being involved in the discussion whether it is the right = problem to tackle or not, I would like to make the observation that at = the very least, the draft needs to define a new BGP capability for the = willingness to accept STALE routes. Peers that has not negotiated this = capability MUST receive paths =93as if=94 the STALE paths did not exist. = This includes that STALE paths and any non-STALE paths whose nexthops = resolve over a STALE paths MUST also not be sent to a such a peer. This = way, negotiation of this capability by consenting adults will define an = island where stale routes would roam free without affecting others. > =20 > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of = Senad .Palislamovic > Sent: Friday, June 22, 2012 7:24 AM > To: idr@ietf.org > Cc: shares@ndzh.com > Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG = document - 3 more weeks > =20 > IETF mail server glitch; resending: Note: Robert already commented = back >=20 > =20 >=20 > Apologize for the delay on comments, >=20 > Robert, >=20 > After going through all the emails, I admit, you've made a lot of = valuable comments that 'seriously' MUST be considered in the new version = of the draft. However, putting that aside, I would really expect this = to be saved for WG discussions. I would think that at this stage, we = are more less agreeing to take a look at this problem and its solution = space.=20 >=20 > Robert, Randy, Shane, >=20 > The main question I have for you is why object something that might = not even affect you. Draft's primary purpose is for the protection of = the control plane for non-internet services (vpls, l2vpn, or = infrustructure routes, i.e. BGP-3107), which in all cases does not = affect you or me in any shape or form. For folks to chose to extend = this to l3vpn or even to IPv4/IPv6 space, they are doing it consciously = knowing the nature of their network and its dynamics. If you do see a = route with the STALE community, and do not desire to use this path due = its "unreliable" nature, you can request your provider to withdraw the = routes with STALE community effectively making them DO_NOT_PERSIST at = the source which effectively mimics the standard GR behavior; as Bruno = stated, at eBGP, people are talking and negotiating. >=20 > So given all that, help me understand how could this impact anyone who = chooses not to use it. Am I missing anything? >=20 > On the side note, Susan, I do support this draft as WG document. >=20 > =20 > Senad > =20 > =20 > =20 > =20 > =20 >=20 > On Wed, Jun 20, 2012 at 4:31 AM, Robert Raszuk = wrote: > =20 > Yet, IMHO building a good (reliable, performant) BGP implementation is = hard. > =20 > True. And changing it's fundamental behaviour every few months does = not help to make it reliable/ performant either ;) > =20 >=20 > I don't think operators would do a better job on the BGP = implementation side. > =20 > I am not asking for that at all. I am asking to simply use multiple = implementations in the backend. Not two .. but 4 or 5. Probability that = all fail/melt with the same bug I think is very very low. >=20 > Of course I admit that if you one uses service which only single = vendor supports in BGP then one get's a bit stuck with the risk. And = that seems to be one of the silent "problem statement" here. >=20 > Rgs, >=20 > R. >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > =20 > =20 >=20 >=20 >=20 >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > =20 > =20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr --Apple-Mail=_9D22839D-CE8D-4821-B763-85D299CD7E9E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
 
 
I would be interested in = hearing from operators as to if this behavior is understood and if = limiting of the time to ~1hr makes the inconsistency within and across = AS domains acceptable..  In your opinion what is the maximum = acceptable amount of time that we could use = Persistence. 

As an operator I believe even 1 hour is too long.  In fact, I'd = rather (and, I do) trust Non-Stop Routing (NSR) on PE's in the network, = because I know that CE's will not understand GR capability and will not = be able to benefit from continuing to forward packets even while the PE = is restarting.  Granted, this is an environment where there are = many "unmanaged CE's", where I have no control/say over what SW or the = capabilities are on those CE's.

Furthermore, = with control plane redundancy for iBGP sessions from one PE across = multiple RR's serving that cluster, it is possible to conduct = maintenance on one half of the RR-pair serving a cluster while still = preserving control and/or forwarding plane = behavior.

Ultimately, as I've said before, I'd = much rather not see any type of "stale" routes 'sticking around' in the = control plane, since that is a vast change in behavior from today's = deployment of BGP where reachability information is only carried while = there are active BGP sessions.  (Yes, I get your point that I don't = have to use persistence if I don't want to, but if developers are in = there monkey'ing around with code to add this feature, inevitably I pay = a price in addt'l complexity for this "feature" even if I don't turn it = on, i.e.: there are potentially 'latent' bugs caused by this "feature", = which is not acceptable).

As Enke has stated = previously, I believe this class of problem is a rare one, (given a = proper network architecture), and thus we should not be creating = AFI-specific solutions that add substantial complexity to an already = complex = protocol. 

-shane

<= br>

Jim Uttaro
 
 
From: Enke Chen = [mailto:enkechen@cisco.com] 
Sent: Friday, June 22, 2012 1:48 = PM
To: UTTARO,= JAMES
Cc: Saikat Ray (sairay); idr@ietf.org; Enke Chen
Subject: Re: [Idr] = draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more = weeks
Jim,

With GR, = as you correctly pointed out, a path would not stale for many hours or = days. That is why it may not be as critical to limit the scope of the = stale path.

If we were to have long-lived stale paths (which I = think is a bad idea), I agree that they should be limited to "consenting = adults", and there must be some mechanisms (such as capability) in = place.

-- Enke

On 6/22/12 10:27 AM, UTTARO, JAMES = wrote:
Enke,
The other approach is to simply not mark these paths = as STALE.. Simply de-pref in the local AS and business as usual when = advertised outside the AS where all transitive attrs are = reset..
 
This is exactly the = semantic you are using in the GR draft. You do not de-pref the state = locally and do not inform other AS domains that the paths learned over = the session that GR is active on are = suspect.
 
If the STALE CV is not = honored across the AS border than the behavior defaults to what is = specified in the GR draft. This should meet your = requirements.
 
Jim = Uttaro
 
From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Enke = Chen
Sent: Friday, June 22, 2012 1:19 = PM
To: Saikat = Ray (sairay)
Cc: idr@ietf.org
Subject: Re: [Idr] = draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more = weeks
Hi, Saikat:

A = new capability would certainly help.  It seems necessary, but may = not be sufficient to limit the scope of the STALE path to "consenting = adults".   For example, inside a network (i.e., AS), if there = are routers that do not recognize the STALE community, a STALE path may = still be advertised to external peers without the = capability.   This means that all the routers in a network = must recognize the community before enabling the capability on any of = them.  It will be difficult to satisfy the condition = universally.

In addition, to limit its scope the STALE community, = once set, MUST not be removed by any receiver.

-- Enke

On = 6/22/12 9:34 AM, Saikat Ray (sairay) wrote:
Without being involved = in the discussion whether it is the right problem to tackle or not, I = would like to make the observation that at the very least, the draft = needs to define a new BGP capability for the willingness to accept STALE = routes. Peers that has not negotiated this capability MUST receive paths = =93as if=94 the STALE paths did not exist. This includes that STALE = paths and any non-STALE paths whose nexthops resolve over a STALE paths = MUST also not be sent to a such a peer. This way, negotiation of this = capability by consenting adults will define an island where stale routes = would roam free without affecting others.
 idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Senad = .Palislamovic
Sent: Friday, June 22, 2012 7:24 = AM
To: idr@ietf.org
Cc: shares@ndzh.com
Subject: Re: [Idr] = draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more = weeks

IETF mail server glitch; =  resending: Note: Robert already commented = back

Apologize for the delay on = comments,

Robert,

After going = through all the emails, I admit, you've made a lot of valuable comments = that 'seriously' MUST be considered in the new version of the = draft.  However, putting that aside, I would really expect this to = be saved for WG discussions.  I would think that at this stage, we = are more less agreeing to take a look at this problem and its solution = space. 

Robert, Randy, Shane,

The main question = I have for you is why object something that might not even affect = you.  Draft's primary purpose is for the protection of the = control plane for non-internet services (vpls, l2vpn, or infrustructure = routes, i.e. BGP-3107), which in all cases does not affect you or me in = any shape or form.  For folks to chose to extend this to l3vpn or = even to IPv4/IPv6 space, they are doing it consciously knowing the = nature of their network and its dynamics.  If you do see a route = with the STALE community, and do not desire to use this path due its = "unreliable" nature, you can request your provider to withdraw the = routes with STALE community effectively making them DO_NOT_PERSIST at = the source which effectively mimics the standard GR behavior; as Bruno = stated, at eBGP, people are talking and negotiating.

So given = all that, help me understand how could this impact anyone who chooses = not to use it.  Am I missing anything?

On the side note, = Susan, I do support this draft as WG = document.

On Wed, = Jun 20, 2012 at 4:31 AM, Robert Raszuk <robert@raszuk.net> = wrote:

 
Yet, IMHO building a good (reliable, = performant) BGP implementation is = hard.
True. = And changing it's fundamental behaviour every few months does not help = to make it reliable/ performant either = ;)

I don't think = operators would do a better job on the BGP implementation = side.

I am = not asking for that at all. I am asking to simply use multiple = implementations in the backend. Not two .. but 4 or 5. Probability that = all fail/melt with the same bug I think is very very low.

Of = course I admit that if you one uses service which only single vendor = supports in BGP then one get's a bit stuck with the risk. And that seems = to be one of the silent "problem statement" = here.

Rgs,
 




Idr mailing list
Idr@ietf.org
 
Idr@ietf.org
Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jun 2012 04:01:05 -0000 > As Enke has stated previously, I believe this class of problem is a > rare one, (given a proper network architecture), and thus we should > not be creating AFI-specific solutions that add substantial complexity > to an already complex protocol. what he said randy From neil@domino.org Sat Jun 23 02:41:04 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B33321F853B for ; Sat, 23 Jun 2012 02:41:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AiZAFIITeAyB for ; Sat, 23 Jun 2012 02:41:03 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe005.messaging.microsoft.com [65.55.88.15]) by ietfa.amsl.com (Postfix) with ESMTP id 27D8521F8513 for ; Sat, 23 Jun 2012 02:41:02 -0700 (PDT) Received: from mail121-tx2-R.bigfish.com (10.9.14.243) by TX2EHSOBE002.bigfish.com (10.9.40.22) with Microsoft SMTP Server id 14.1.225.23; Sat, 23 Jun 2012 09:39:30 +0000 Received: from mail121-tx2 (localhost [127.0.0.1]) by mail121-tx2-R.bigfish.com (Postfix) with ESMTP id 02F6EC041A; Sat, 23 Jun 2012 09:39:30 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.252.5; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0310HT002.eurprd03.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -19 X-BigFish: PS-19(zz98dI9371Ic85ehzz1202hzz8275ch1033IL8275bh8275dhz2fh2a8h668h839he5bhf0ahbe3k) Received-SPF: pass (mail121-tx2: domain of domino.org designates 157.56.252.5 as permitted sender) client-ip=157.56.252.5; envelope-from=neil@domino.org; helo=DB3PRD0310HT002.eurprd03.prod.outlook.com ; .outlook.com ; Received: from mail121-tx2 (localhost.localdomain [127.0.0.1]) by mail121-tx2 (MessageSwitch) id 1340444367588661_19644; Sat, 23 Jun 2012 09:39:27 +0000 (UTC) Received: from TX2EHSMHS022.bigfish.com (unknown [10.9.14.249]) by mail121-tx2.bigfish.com (Postfix) with ESMTP id 8A7DD1E004E; Sat, 23 Jun 2012 09:39:27 +0000 (UTC) Received: from DB3PRD0310HT002.eurprd03.prod.outlook.com (157.56.252.5) by TX2EHSMHS022.bigfish.com (10.9.99.122) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sat, 23 Jun 2012 09:39:27 +0000 Received: from DB3PRD0310MB391.eurprd03.prod.outlook.com ([169.254.4.251]) by DB3PRD0310HT002.eurprd03.prod.outlook.com ([10.255.44.37]) with mapi id 14.16.0164.004; Sat, 23 Jun 2012 09:40:58 +0000 From: "Neil J. McRae" To: "Henderickx, Wim (Wim)" , Paul Unbehagen , "Fragassi, Roberto (Roberto)" Thread-Topic: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks Thread-Index: AQHNUSRKqxGH08J/7keObl+bgZLt/g== Date: Sat, 23 Jun 2012 09:40:57 +0000 Message-ID: In-Reply-To: <14C7F4F06DB5814AB0DE29716C4F6D6702DF7129F6@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.44.4] Content-Type: multipart/alternative; boundary="_000_CC0B4BB71F8FFneildominoorg_" MIME-Version: 1.0 X-OriginatorOrg: domino.org Cc: "idr@ietf.org" , "'John G. Scudder'" , Susan Hares Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jun 2012 09:41:04 -0000 --_000_CC0B4BB71F8FFneildominoorg_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I support this work also. We can no longer have the entire control plane ju= st give up. Some folks have labeled this as rare. In comparison with other = IDR type problems, I have seen this issue more than any other problem and g= iven the catastrophic effect (I.e. complete and total network outage) and t= he impact that has not just in Internet space but also VPN space where the = impact of a complete network loss on critical infrastructure is not accepta= ble (hospitals, law enforcement and other important services). In every cas= e where this has happened there has never been an actual reachability probl= em either. From: , "Wim (Wim)" > Date: Monday, 18 June 2012 19:15 To: Paul Unbehagen >, "Fragas= si, Roberto (Roberto)" > Cc: "idr@ietf.org" >= , Susan Hares >, "'John G. Scudder'= " > Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document -= 3 more weeks +1 From: idr-bounces@ietf.org [mailto:idr-bounces= @ietf.org] On Behalf Of Paul Unbehagen Sent: maandag 18 juni 2012 16:39 To: Fragassi, Roberto (Roberto) Cc: idr@ietf.org; 'John G. Scudder'; Susan Hares Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document -= 3 more weeks +1 -- Paul On Jun 18, 2012, at 6:49 AM, Fragassi, Roberto (Roberto) wrote: +1 Support. With the continued growth of spoke topologies in mobility backhaul, the con= tinued work on this draft as WG has its value for dealing with catastrophic= failures. From: idr-bounces@ietf.org [mailto:idr-bounces= @ietf.org] On Behalf Of Susan Hares Sent: Friday, June 15, 2012 3:04 PM To: idr@ietf.org Cc: 'John G. Scudder' Subject: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 m= ore weeks IDR WG and BGPers: While there is a strong debate on draft-uttaro-idr-bgp-persistence-01 as ID= R WG document, I do not see a clear consensus. We also did not get an over= whelming number of you to hum either way (11 total). Since some of those who voted =93no=94 have suggested alternate text to the= author, I would like to extend the time to consider this draft for 3 more = weeks. To accept the draft we need a few more of you to =93hum=94 yes or =93hum=94= no. Sue Hares _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr --_000_CC0B4BB71F8FFneildominoorg_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
I support this work also. We can no longer have the entire control pla= ne just give up. Some folks have labeled this as rare. In comparison with o= ther IDR type problems, I have seen this issue more than any other problem = and given the catastrophic effect (I.e. complete and total network outage) and the impact that has not just = in Internet space but also VPN space where the impact of a complete network= loss on critical infrastructure is not acceptable (hospitals, law enforcem= ent and other important services). In every case where this has happened there has never been an actual reach= ability problem either.

From: <Henderickx>, "Wim= (Wim)" <wim.h= enderickx@alcatel-lucent.com>
Date: Monday, 18 June 2012 19:15 To: Paul Unbehagen <paul@unbehagen.net>, "Fragassi, Rober= to (Roberto)" <roberto.fragassi@alcatel-lucent.com>
Cc: "idr@ietf.org" <idr@ietf.= org>, Susan Hares <shares@ndzh= .com>, "'John G. Scudder'" <jgs@bgp.nu>
Subject: Re: [Idr] draft-uttaro-idr= -bgp-persistence-01 as IDR WG document - 3 more weeks

+1

 

From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Paul Unbehagen
Sent: maandag 18 juni 2012 16:39
To: Fragassi, Roberto (Roberto)
Cc: idr@ietf.org; 'John G. Scudd= er'; Susan Hares
Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG doc= ument - 3 more weeks

 

+1

 

 

--

Paul

 

 

 

On Jun 18, 2012, at 6:49 AM, Fragassi, Roberto (Robe= rto) wrote:



+1 Support.=

 

With the continued growth of spoke= topologies in mobility backhaul, the continued work on this draft as WG ha= s its value for dealing with catastrophic failures.

 

From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org]<= span class=3D"apple-converted-space"> On Behalf Of Susan Hares
Sent: Friday, June= 15, 2012 3:04 PM
To: idr@ietf.org
Cc: 'John G. Scudd= er'
Subject: [Idr] dra= ft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks

 

IDR WG and BGPers:

 

While there is a strong debate on draft-uttaro-idr-bgp-persistenc= e-01 as IDR WG document, I do not see a clear consensus.  We also did = not get an overwhelming number of you to hum either way (11 total).

 

Since some of those who voted =93no=94 have suggested alternate t= ext to the author, I would like to extend the time to consider this draft f= or 3 more weeks.

 

To accept the draft we need a few more of you to =93hum=94 yes or= =93hum=94 no.

 

Sue Hares

 

 

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/= mailman/listinfo/idr

 

--_000_CC0B4BB71F8FFneildominoorg_-- From john@jlc.net Sat Jun 23 04:58:18 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7FFA21F8512 for ; Sat, 23 Jun 2012 04:58:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.574 X-Spam-Level: X-Spam-Status: No, score=-106.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6hYjVEwCr+V4 for ; Sat, 23 Jun 2012 04:58:18 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 27A6121F8510 for ; Sat, 23 Jun 2012 04:58:18 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id CF34233C21; Sat, 23 Jun 2012 07:58:17 -0400 (EDT) Date: Sat, 23 Jun 2012 07:58:17 -0400 From: John Leslie To: "Neil J. McRae" Message-ID: <20120623115817.GE84371@verdi> References: <14C7F4F06DB5814AB0DE29716C4F6D6702DF7129F6@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Cc: "idr@ietf.org" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jun 2012 11:58:18 -0000 Neil J. McRae wrote: > > I support this work also. We can no longer have the entire control plane > just give up. Some folks have labeled this as rare. In comparison with > other IDR type problems, I have seen this issue more than any other > problem and given the catastrophic effect (I.e. complete and total > network outage) and the impact that has not just in Internet space but > also VPN space where the impact of a complete network loss on critical > infrastructure is not acceptable (hospitals, law enforcement and other > important services). In every case where this has happened there has > never been an actual reachability problem either. Thank you for this level of detail as your reason to support this as a WG draft. It is much more helpful than the too-brief "I support" posts. Some of us, however, seeing the same problem look to operational fixes, not protocol changes. I, for example, like to maintain redundant BGP sessions over the same link with one kept particularly simple. This can be done in a single day, instead of waiting many months for a standards change and more months for equipment to reach the field. It also keeps everything under my control, rather than passing the buck to my competitors to ensure that stale routes actually get withdrawn. -- John Leslie From neil@domino.org Sat Jun 23 05:44:52 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF7A121F84E1 for ; Sat, 23 Jun 2012 05:44:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.098 X-Spam-Level: X-Spam-Status: No, score=-5.098 tagged_above=-999 required=5 tests=[AWL=-1.499, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mCMMBdJIuDoz for ; Sat, 23 Jun 2012 05:44:52 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe003.messaging.microsoft.com [213.199.154.206]) by ietfa.amsl.com (Postfix) with ESMTP id F304321F8463 for ; Sat, 23 Jun 2012 05:44:51 -0700 (PDT) Received: from mail98-am1-R.bigfish.com (10.3.201.230) by AM1EHSOBE006.bigfish.com (10.3.204.26) with Microsoft SMTP Server id 14.1.225.23; Sat, 23 Jun 2012 12:43:18 +0000 Received: from mail98-am1 (localhost [127.0.0.1]) by mail98-am1-R.bigfish.com (Postfix) with ESMTP id 5FD14C00C6; Sat, 23 Jun 2012 12:43:18 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.252.5; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0310HT003.eurprd03.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -3 X-BigFish: PS-3(zzbb2dI98dI1432Izz1202hzz8275chz2fh2a8h668h839h944he5bhf0ah) Received-SPF: pass (mail98-am1: domain of domino.org designates 157.56.252.5 as permitted sender) client-ip=157.56.252.5; envelope-from=neil@domino.org; helo=DB3PRD0310HT003.eurprd03.prod.outlook.com ; .outlook.com ; Received: from mail98-am1 (localhost.localdomain [127.0.0.1]) by mail98-am1 (MessageSwitch) id 1340455397375384_24261; Sat, 23 Jun 2012 12:43:17 +0000 (UTC) Received: from AM1EHSMHS012.bigfish.com (unknown [10.3.201.237]) by mail98-am1.bigfish.com (Postfix) with ESMTP id 4FDF4380046; Sat, 23 Jun 2012 12:43:17 +0000 (UTC) Received: from DB3PRD0310HT003.eurprd03.prod.outlook.com (157.56.252.5) by AM1EHSMHS012.bigfish.com (10.3.207.112) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sat, 23 Jun 2012 12:43:17 +0000 Received: from DB3PRD0310MB391.eurprd03.prod.outlook.com ([169.254.4.251]) by DB3PRD0310HT003.eurprd03.prod.outlook.com ([10.255.44.38]) with mapi id 14.16.0164.004; Sat, 23 Jun 2012 12:44:48 +0000 From: "Neil J. McRae" To: John Leslie Thread-Topic: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks Thread-Index: AQHNUSRKqxGH08J/7keObl+bgZLt/pcHzKqAgAAdu4A= Date: Sat, 23 Jun 2012 12:44:47 +0000 Message-ID: In-Reply-To: <20120623115817.GE84371@verdi> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.44.4] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: domino.org Cc: "idr@ietf.org" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jun 2012 12:44:53 -0000 John, Thanks for your feedback but in reality this work around won't help especially in large VPN networks but even in just plain old internet land With the probability of this issue occurring is increasing and not decreasing. And btw its not months the industry has been waiting for this to be resolved. Its more than fifteen years. We need to act to make the control plane more resilient, I'm not sure if this is the best solution but its something that is worthy exploration given the catastrophic result of failure. What I find somewhat incredible is that any vendor that had survivability of this nature would fly to the top of our selection process! When we do so much in other protocols to ensure reliability it seems incredible that we choose not to here, and as I said, in all cases of this scenario impacting me, and what leads me to believe is crucially a flaw in the current protocol, reachability has always been present, which is what our protocol is all about. Regards, Neil. On 23/06/2012 12:58, "John Leslie" wrote: > Thank you for this level of detail as your reason to support this as >a WG draft. It is much more helpful than the too-brief "I support" posts. > > Some of us, however, seeing the same problem look to operational fixes, >not protocol changes. I, for example, like to maintain redundant BGP >sessions over the same link with one kept particularly simple. This can >be done in a single day, instead of waiting many months for a standards >change and more months for equipment to reach the field. It also keeps >everything under my control, rather than passing the buck to my >competitors to ensure that stale routes actually get withdrawn. > >-- >John Leslie > From ju1738@att.com Sat Jun 23 12:28:58 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C7D521F84CF for ; Sat, 23 Jun 2012 12:28:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.408 X-Spam-Level: X-Spam-Status: No, score=-106.408 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GODwaijSVgge for ; Sat, 23 Jun 2012 12:28:56 -0700 (PDT) Received: from nbfkord-smmo03.seg.att.com (nbfkord-smmo03.seg.att.com [209.65.160.84]) by ietfa.amsl.com (Postfix) with ESMTP id A300B21F84BF for ; Sat, 23 Jun 2012 12:28:55 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO nbfkord-smmo03.seg.att.com) by nbfkord-smmo03.seg.att.com(mxl_mta-6.11.0-10) with ESMTP id 7f816ef4.4d420940.1055750.00-571.2909793.nbfkord-smmo03.seg.att.com (envelope-from ); Sat, 23 Jun 2012 19:28:55 +0000 (UTC) X-MXL-Hash: 4fe618f70549f226-353472fa66010735e6bd8390fcd522749dc530d2 Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo03.seg.att.com(mxl_mta-6.11.0-10) over TLS secured channel with ESMTP id 7e816ef4.0.1055711.00-476.2909703.nbfkord-smmo03.seg.att.com (envelope-from ); Sat, 23 Jun 2012 19:28:41 +0000 (UTC) X-MXL-Hash: 4fe618e92468d8f1-f4a528595d4c1015074d53adcbca132e3e99ee91 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q5NJSdIc027632; Sat, 23 Jun 2012 15:28:39 -0400 Received: from sflint01.pst.cso.att.com (sflint01.pst.cso.att.com [144.154.234.228]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q5NJSWUb027597 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 23 Jun 2012 15:28:33 -0400 Received: from MISOUT7MSGHUB9B.ITServices.sbc.com (misout7msghub9b.itservices.sbc.com [144.151.223.72]) by sflint01.pst.cso.att.com (RSA Interceptor); Sat, 23 Jun 2012 15:28:14 -0400 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9B.ITServices.sbc.com ([144.151.223.72]) with mapi id 14.02.0298.004; Sat, 23 Jun 2012 15:28:14 -0400 From: "UTTARO, JAMES" To: "'Neil J. McRae'" , "Henderickx, Wim (Wim)" , Paul Unbehagen , "Fragassi, Roberto (Roberto)" Thread-Topic: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks Thread-Index: AQHNUSRck+l8gfT21UKwm6XKZP3kKZcISIpQ Date: Sat, 23 Jun 2012 19:28:13 +0000 Message-ID: References: <14C7F4F06DB5814AB0DE29716C4F6D6702DF7129F6@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.160.140] Content-Type: multipart/alternative; boundary="_000_B17A6910EEDD1F45980687268941550FB1FE0DMISOUT7MSGUSR9IIT_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=1.0 c=1 a=UZz9RedjOpYA:10 a=ZQD3OTTxKqYA:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a=48] X-AnalysisOut: [vgC7mUAAAA:8 a=gxZvrgisAAAA:8 a=FalKEykTAAAA:8 a=1sjgXBK7A] X-AnalysisOut: [AAA:8 a=I_74Wr6wBnYBeKw-WRIA:9 a=CjuIK1q_8ugA:10 a=lZB815d] X-AnalysisOut: [zVvQA:10 a=3FZX-ydVlcEA:10 a=y-FtiA-HILUA:10 a=kZwP4KTQBig] X-AnalysisOut: [A:10 a=W1LAWe3PfSPH4RwB:21 a=nI46xVkmqyynCIFv:21 a=yMhMjlu] X-AnalysisOut: [bAAAA:8 a=SSmOFEACAAAA:8 a=6CsTBMezqc_zn6jTgkcA:9 a=gKO2Hq] X-AnalysisOut: [4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=So_zOuEetI] X-AnalysisOut: [U1U-s_:21 a=6E7w5uV44VgdBvIJ:21] Cc: "idr@ietf.org" , Susan Hares , "'John G. Scudder'" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jun 2012 19:28:58 -0000 --_000_B17A6910EEDD1F45980687268941550FB1FE0DMISOUT7MSGUSR9IIT_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1.. IMO I think that folks need to come to the realization that BGP is bei= ng used in varied use cases, using the internet application as the only fra= me of reference or lens into the requirements for reliability is simply not= appropriate or correct.. I can tell you as someone who actually runs netwo= rks that this is not rare and has been seen in multiple services.. It needs= to be fixed. As Neil points out the VPN/VPLS cases are used to support man= y services that cannot afford the luxury of being down.. Jim Uttaro From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Neil = J. McRae Sent: Saturday, June 23, 2012 5:41 AM To: Henderickx, Wim (Wim); Paul Unbehagen; Fragassi, Roberto (Roberto) Cc: idr@ietf.org; 'John G. Scudder'; Susan Hares Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document -= 3 more weeks I support this work also. We can no longer have the entire control plane ju= st give up. Some folks have labeled this as rare. In comparison with other = IDR type problems, I have seen this issue more than any other problem and g= iven the catastrophic effect (I.e. complete and total network outage) and t= he impact that has not just in Internet space but also VPN space where the = impact of a complete network loss on critical infrastructure is not accepta= ble (hospitals, law enforcement and other important services). In every cas= e where this has happened there has never been an actual reachability probl= em either. From: , "Wim (Wim)" > Date: Monday, 18 June 2012 19:15 To: Paul Unbehagen >, "Fragas= si, Roberto (Roberto)" > Cc: "idr@ietf.org" >= , Susan Hares >, "'John G. Scudder'= " > Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document -= 3 more weeks +1 From: idr-bounces@ietf.org [mailto:idr-bounces= @ietf.org] On Behalf Of Paul Unbehagen Sent: maandag 18 juni 2012 16:39 To: Fragassi, Roberto (Roberto) Cc: idr@ietf.org; 'John G. Scudder'; Susan Hares Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document -= 3 more weeks +1 -- Paul On Jun 18, 2012, at 6:49 AM, Fragassi, Roberto (Roberto) wrote: +1 Support. With the continued growth of spoke topologies in mobility backhaul, the con= tinued work on this draft as WG has its value for dealing with catastrophic= failures. From: idr-bounces@ietf.org [mailto:idr-bounces= @ietf.org] On Behalf Of Susan Hares Sent: Friday, June 15, 2012 3:04 PM To: idr@ietf.org Cc: 'John G. Scudder' Subject: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 m= ore weeks IDR WG and BGPers: While there is a strong debate on draft-uttaro-idr-bgp-persistence-01 as ID= R WG document, I do not see a clear consensus. We also did not get an over= whelming number of you to hum either way (11 total). Since some of those who voted "no" have suggested alternate text to the aut= hor, I would like to extend the time to consider this draft for 3 more week= s. To accept the draft we need a few more of you to "hum" yes or "hum" no. Sue Hares _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr --_000_B17A6910EEDD1F45980687268941550FB1FE0DMISOUT7MSGUSR9IIT_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1.. IMO I think that= folks need to come to the realization that BGP is being used in varied use= cases, using the internet application as the only frame of reference or lens into the requirements for reliability is simply not appr= opriate or correct.. I can tell you as someone who actually runs networks t= hat this is not rare and has been seen in multiple services.. It needs to b= e fixed. As Neil points out the VPN/VPLS cases are used to support many services that cannot afford the lu= xury of being down..

 <= /p>

Jim Uttaro

 <= /p>

From: idr-boun= ces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Neil J. McRae
Sent: Saturday, June 23, 2012 5:41 AM
To: Henderickx, Wim (Wim); Paul Unbehagen; Fragassi, Roberto (Robert= o)
Cc: idr@ietf.org; 'John G. Scudder'; Susan Hares
Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG doc= ument - 3 more weeks

 

I support this work also. W= e can no longer have the entire control plane just give up. Some folks have= labeled this as rare. In comparison with other IDR type problems, I have seen this issue more than any other problem and given the= catastrophic effect (I.e. complete and total network outage) and the impac= t that has not just in Internet space but also VPN space where the impact o= f a complete network loss on critical infrastructure is not acceptable (hospitals, law enforcement and other imp= ortant services). In every case where this has happened there has never bee= n an actual reachability problem either.

 

From: <Henderickx>, "Wim (Wim)&quo= t; <wim.henderickx@= alcatel-lucent.com>
Date: Monday, 18 June 2012 19:15
To: Paul Unbehagen <paul@un= behagen.net>, "Fragassi, Roberto (Roberto)" <roberto.fragassi@alcatel-lucen= t.com>
Cc: "idr@ietf.org" <= ;idr@ietf.org>, Susan Hares <shares@ndzh.com>, "'John G. Scud= der'" <jgs@bgp.nu>
Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG doc= ument - 3 more weeks

 

+1

 

From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Paul Unbehagen
Sent: maandag 18 juni 2012 16:39
To: Fragassi, Roberto (Roberto)
Cc: idr@ietf.org; 'John G. Scudd= er'; Susan Hares
Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG doc= ument - 3 more weeks

 =

+1=

 =

 =

--

Paul

 

 =

 =

On Jun 18, 2012, at 6:49= AM, Fragassi, Roberto (Roberto) wrote:




+1 Support.

 

With the continued growth= of spoke topologies in mobility backhaul, the continued work on this draft= as WG has its value for dealing with catastrophic failures.

 

From: idr-bounces@i= etf.org [mailto:idr-bounces@ietf.org]<= span class=3D"apple-converted-space"> On Behalf Of Susan Hares
Sent: Friday, June= 15, 2012 3:04 PM
To: idr@ietf.org
Cc: 'John G. Scudd= er'
Subject: [Idr] dra= ft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks

 

IDR WG and BGPers:

 =

While there is a strong debate on draft-uttaro= -idr-bgp-persistence-01 as IDR WG document, I do not see a clear consensus.=  We also did not get an overwhelming number of you to hum either way (11 total).<= /o:p>

 =

Since some of those who voted “no”= have suggested alternate text to the author, I would like to extend the ti= me to consider this draft for 3 more weeks.

 =

To accept the draft we need a few more of you = to “hum” yes or “hum” no.

 =

Sue Hares

 =

 =

_________________________= ______________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/= mailman/listinfo/idr

 =

--_000_B17A6910EEDD1F45980687268941550FB1FE0DMISOUT7MSGUSR9IIT_-- From bruno.decraene@orange.com Sat Jun 23 12:43:23 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E971621F84BF for ; Sat, 23 Jun 2012 12:43:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=-0.873, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_41=0.6, J_CHICKENPOX_63=0.6, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q7eW2GSmk2Gu for ; Sat, 23 Jun 2012 12:43:17 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id EF47A21F84CF for ; Sat, 23 Jun 2012 12:43:16 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id C50C822C3DD; Sat, 23 Jun 2012 21:43:14 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id A9D8F238055; Sat, 23 Jun 2012 21:43:14 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Sat, 23 Jun 2012 21:43:14 +0200 From: To: Shane Amante , "UTTARO, JAMES" Thread-Topic: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks Thread-Index: AQHNUOPsIfRzUt1Wzk6aNJxYH/i4BpcISKrA Date: Sat, 23 Jun 2012 19:43:13 +0000 Message-ID: <25040_1340480594_4FE61C52_25040_14838_1_53C29892C857584299CBF5D05346208A094280@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <003c01cd4b29$97d7b150$c78713f0$@ndzh.com> <985EF8D2-DA8A-4BE7-94D3-F4BE2B74D768@castlepoint.net> <4FE07A24.7050804@raszuk.net> <1C1F2B2E-2EB7-42F0-8CFF-57965443C074@castlepoint.net> <7A614998-8FB1-4A51-9937-DE501FF31EB6@juniper.net> <4FE0D1F4.9070208@cisco.com> <4FE0E074.3070905@raszuk.net> <17490_1340180565_4FE18855_17490_15423_1_53C29892C857584299CBF5D05346208A0928AA@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FE18A61.8000405@raszuk.net> <8ED5B0B0F5B4854A912480C1521F973AD95B@xmb-rcd-x13.cisco.com> <4FE4A8F3.20809@cisco.com> <4FE4AFE2.3030107@cisco.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.5] Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A094280PEXCVZYM11corpora_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.6.23.163317 Cc: "idr@ietf.org" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jun 2012 19:43:24 -0000 --_000_53C29892C857584299CBF5D05346208A094280PEXCVZYM11corpora_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Shane, all, From: Shane Amante Sent: Saturday, June 23, 2012 4:00 AM On Jun 22, 2012, at 12:03 PM, UTTARO, JAMES wrote: Enke, I think we have got to have a consistent approach to these = solutions.. I am not comfortable with the fact that it is "ok" for GR but n= ot "ok" for Persistence based on a IMO subjective interpretation of the amo= unt of time a STALE path is active in local and adjacent topologies. An hou= r is a long time, and as GR is used primarily used n IPV4 which is dynamic = it would seem that a) these paths should be de-pref after some amount of ti= me b) GR should inform other AS topologies of the staleness by using the ST= ALE CV.. I would be interested in hearing from operators as to if this behavior is u= nderstood and if limiting of the time to ~1hr makes the inconsistency withi= n and across AS domains acceptable.. In your opinion what is the maximum a= cceptable amount of time that we could use Persistence. As an operator I believe even 1 hour is too long. In fact, I'd rather (and= , I do) trust Non-Stop Routing (NSR) on PE's in the network, because I know= that CE's will not understand GR capability and will not be able to benefi= t from continuing to forward packets even while the PE is restarting. Gran= ted, this is an environment where there are many "unmanaged CE's", where I = have no control/say over what SW or the capabilities are on those CE's. Furthermore, with control plane redundancy for iBGP sessions from one PE ac= ross multiple RR's serving that cluster, it is possible to conduct maintena= nce on one half of the RR-pair serving a cluster while still preserving con= trol and/or forwarding plane behavior. Ultimately, as I've said before, I'd much rather not see any type of "stale= " routes 'sticking around' in the control plane, since that is a vast chang= e in behavior from today's deployment of BGP where reachability information= is only carried while there are active BGP sessions. (Yes, I get your poi= nt that I don't have to use persistence if I don't want to, but if develope= rs are in there monkey'ing around with code to add this feature, inevitably= I pay a price in addt'l complexity for this "feature" even if I don't turn= it on, i.e.: there are potentially 'latent' bugs caused by this "feature",= which is not acceptable). Additional complexity is a valid argument, but you would need to evaluate i= t for all features. e.g. As per your own argument, one could say that Non-S= top Routing "is not acceptable". Also, it might be useful to remember that the question is about WG adoptio= n, not implementation. In the context of this draft, this is largely indepe= ndent: - a WG doc may never be implemented - to some extent BGP persistence could be implemented without WG adoption. If one SP asked BGP persistence implementation to a vendor, then only both = of them would define BGP persistence. IDR would not have the opportunity to= comment/improve/delay/kill (pick your own) the proposal. Given the importance of the subject, I would prefer that IDR had the abilit= y to have is word on this. Bruno As Enke has stated previously, I believe this class of problem is a rare on= e, (given a proper network architecture), and thus we should not be creatin= g AFI-specific solutions that add substantial complexity to an already comp= lex protocol. -shane Jim Uttaro From: Enke Chen [mailto:enkechen@cisco.com] Sent: Friday, June 22, 2012 1:48 PM To: UTTARO, JAMES Cc: Saikat Ray (sairay); idr@ietf.org; Enke Chen Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document -= 3 more weeks Jim, With GR, as you correctly pointed out, a path would not stale for many hour= s or days. That is why it may not be as critical to limit the scope of the = stale path. If we were to have long-lived stale paths (which I think is a bad idea), I = agree that they should be limited to "consenting adults", and there must be= some mechanisms (such as capability) in place. -- Enke On 6/22/12 10:27 AM, UTTARO, JAMES wrote: Enke, The idea behind the setting of STALE is to inform speakers = in other AS domains that the path is suspect as the session it was learned = over is down.. IMO this is required to inform others about the viability of= a path.. The other approach is to simply not mark these paths as STALE.. Simply de-p= ref in the local AS and business as usual when advertised outside the AS wh= ere all transitive attrs are reset.. This is exactly the semantic you are using in the GR draft. You do not de-p= ref the state locally and do not inform other AS domains that the paths lea= rned over the session that GR is active on are suspect. If the STALE CV is not honored across the AS border than the behavior defau= lts to what is specified in the GR draft. This should meet your requirement= s. Jim Uttaro From: idr-bounces@ietf.org [mailto:idr-bounces= @ietf.org] On Behalf Of Enke Chen Sent: Friday, June 22, 2012 1:19 PM To: Saikat Ray (sairay) Cc: idr@ietf.org Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document -= 3 more weeks Hi, Saikat: A new capability would certainly help. It seems necessary, but may not be = sufficient to limit the scope of the STALE path to "consenting adults". F= or example, inside a network (i.e., AS), if there are routers that do not r= ecognize the STALE community, a STALE path may still be advertised to exter= nal peers without the capability. This means that all the routers in a ne= twork must recognize the community before enabling the capability on any of= them. It will be difficult to satisfy the condition universally. In addition, to limit its scope the STALE community, once set, MUST not be = removed by any receiver. -- Enke On 6/22/12 9:34 AM, Saikat Ray (sairay) wrote: Without being involved in the discussion whether it is the right problem to= tackle or not, I would like to make the observation that at the very least= , the draft needs to define a new BGP capability for the willingness to acc= ept STALE routes. Peers that has not negotiated this capability MUST receiv= e paths "as if" the STALE paths did not exist. This includes that STALE pat= hs and any non-STALE paths whose nexthops resolve over a STALE paths MUST a= lso not be sent to a such a peer. This way, negotiation of this capability = by consenting adults will define an island where stale routes would roam fr= ee without affecting others. From: idr-bounces@ietf.org [mailto:idr-bounces= @ietf.org] On Behalf Of Senad .Palislamovic Sent: Friday, June 22, 2012 7:24 AM To: idr@ietf.org Cc: shares@ndzh.com Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document -= 3 more weeks IETF mail server glitch; resending: Note: Robert already commented back Apologize for the delay on comments, Robert, After going through all the emails, I admit, you've made a lot of valuable = comments that 'seriously' MUST be considered in the new version of the draf= t. However, putting that aside, I would really expect this to be saved for= WG discussions. I would think that at this stage, we are more less agreei= ng to take a look at this problem and its solution space. Robert, Randy, Shane, The main question I have for you is why object something that might not eve= n affect you. Draft's primary purpose is for the protection of the control= plane for non-internet services (vpls, l2vpn, or infrustructure routes, i.= e. BGP-3107), which in all cases does not affect you or me in any shape or = form. For folks to chose to extend this to l3vpn or even to IPv4/IPv6 spac= e, they are doing it consciously knowing the nature of their network and it= s dynamics. If you do see a route with the STALE community, and do not des= ire to use this path due its "unreliable" nature, you can request your prov= ider to withdraw the routes with STALE community effectively making them DO= _NOT_PERSIST at the source which effectively mimics the standard GR behavio= r; as Bruno stated, at eBGP, people are talking and negotiating. So given all that, help me understand how could this impact anyone who choo= ses not to use it. Am I missing anything? On the side note, Susan, I do support this draft as WG document. Senad On Wed, Jun 20, 2012 at 4:31 AM, Robert Raszuk > wrote: Yet, IMHO building a good (reliable, performant) BGP implementation is hard. True. And changing it's fundamental behaviour every few months does not hel= p to make it reliable/ performant either ;) I don't think operators would do a better job on the BGP implementation sid= e. I am not asking for that at all. I am asking to simply use multiple impleme= ntations in the backend. Not two .. but 4 or 5. Probability that all fail/m= elt with the same bug I think is very very low. Of course I admit that if you one uses service which only single vendor sup= ports in BGP then one get's a bit stuck with the risk. And that seems to be= one of the silent "problem statement" here. Rgs, R. _______________________________________________ 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 _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. --_000_53C29892C857584299CBF5D05346208A094280PEXCVZYM11corpora_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Shane, all= ,

 = ;

From: Shane Amante Sent: Saturday, June 23, 2012 4:00 AM

On Jun 22, 2012, at 12:03 PM, U= TTARO, JAMES wrote:



Enke,

 

 &nbs= p;            &= nbsp; I think we have got to have a consistent approach to these solutions.= . I am not comfortable with the fact that it is “ok” for GR but not “ok” for Persistence based on a IMO subjective interpr= etation of the amount of time a STALE path is active in local and adjacent = topologies. An hour is a long time, and as GR is used primarily used n IPV4= which is dynamic it would seem that a) these paths should be de-pref after some amount of time b) GR should inform othe= r AS topologies of the staleness by using the STALE CV..

 

I would be= interested in hearing from operators as to if this behavior is understood = and if limiting of the time to ~1hr makes the inconsistency within and across AS domains acceptable..  In your opinion what is th= e maximum acceptable amount of time that we could use Persistence. 

 

As an operator I believe even 1 hour is too long. &n= bsp;In fact, I'd rather (and, I do) trust Non-Stop Routing (NSR) on PE's in= the network, because I know that CE's will not understand GR capability an= d will not be able to benefit from continuing to forward packets even while the PE is restarting.  Granted, this is= an environment where there are many "unmanaged CE's", where I ha= ve no control/say over what SW or the capabilities are on those CE's.<= /o:p>

 

Furthermore, with control plane redundancy for iBGP = sessions from one PE across multiple RR's serving that cluster, it is possi= ble to conduct maintenance on one half of the RR-pair serving a cluster whi= le still preserving control and/or forwarding plane behavior.

 

Ultimately, as I've said before, I'd much rather not= see any type of "stale" routes 'sticking around' in the control = plane, since that is a vast change in behavior from today's deployment of B= GP where reachability information is only carried while there are active BGP sessions.  (Yes, I get your point that I d= on't have to use persistence if I don't want to, but if developers are in t= here monkey'ing around with code to add this feature, inevitably I pay a pr= ice in addt'l complexity for this "feature" even if I don't turn it on, i.e.: there are potentially 'latent' bugs caus= ed by this "feature", which is not acceptable).

 

Additional= complexity is a valid argument, but you would need to evaluate it for all = features. e.g. As per your own argument, one could say that Non-Stop Routing “is not acceptable”.

 = ;

 = ;

Also, &nbs= p;it might be useful to remember that the question is about WG adoption, no= t implementation. In the context of this draft, this is largely independent:

- a WG doc= may never be implemented

- to some = extent BGP persistence could be implemented without WG adoption.=

 = ;

If one SP = asked BGP persistence implementation to a vendor, then only both of them wo= uld define BGP persistence. IDR would not have the opportunity to comment/improve/delay/kill (pick your own) the proposal.

Given the = importance of the subject, I would prefer that IDR had the ability to have = is word on this.

 = ;

Bruno=

 = ;

As Enke has stated previously, I believe this class = of problem is a rare one, (given a proper network architecture), and thus w= e should not be creating AFI-specific solutions that add substantial comple= xity to an already complex protocol. 

 

-shane

 

 



Jim Uttaro=

 

 

 

 

From: Enke Chen [mailto:enkechen@cisco.com]=  
Sent: Friday, June= 22, 2012 1:48 PM
To: UTTARO, JAMES<= br> Cc: Saikat Ray (sa= iray); idr@ietf.org; Enke Chen
Subject: Re: [Idr]= draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks

 

Jim,

With GR, as you correctly pointed out, a path would not stale for many hour= s or days. That is why it may not be as critical to limit the scope of the = stale path.

If we were to have long-lived stale paths (which I think is a bad idea), I = agree that they should be limited to "consenting adults", and the= re must be some mechanisms (such as capability) in place.

-- Enke

On 6/22/12 10:27 AM, UTTARO, JAMES wrote:

Enke,

 

 &nbs= p;            &= nbsp; The idea behind the setting of STALE is to inform speakers in other A= S domains that the path is suspect as the session it was learned over is down.. IMO this is required to inform others about the viability o= f a path..

 

The other = approach is to simply not mark these paths as STALE.. Simply de-pref in the= local AS and business as usual when advertised outside the AS where all transitive attrs are reset..

 

This is ex= actly the semantic you are using in the GR draft. You do not de-pref the st= ate locally and do not inform other AS domains that the paths learned over the session that GR is active on are suspect.

 

If the STA= LE CV is not honored across the AS border than the behavior defaults to wha= t is specified in the GR draft. This should meet your requirements.<= span lang=3D"EN-US" style=3D"color:black">

 

Jim Uttaro=

 

From: idr-= bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Enke Chen<= br> Sent: Friday, June= 22, 2012 1:19 PM
To: Saikat Ray (sa= iray)
Cc: idr@ietf.org
Subject: Re: [Idr]= draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks

 

Hi, Saika= t:

A new capability would certainly help.  It seems necessary, but may no= t be sufficient to limit the scope of the STALE path to "consenting ad= ults".   For example, inside a network (i.e., AS), if there = are routers that do not recognize the STALE community, a STALE path may still be advertised to external peers without the capabilit= y.   This means that all the routers in a network must recognize = the community before enabling the capability on any of them.  It will = be difficult to satisfy the condition universally.

In addition, to limit its scope the STALE community, once set, MUST not be = removed by any receiver.

-- Enke

On 6/22/12 9:34 AM, Saikat Ray (sairay) wrote:

Without be= ing involved in the discussion whether it is the right problem to tackle or= not, I would like to make the observation that at the very least, the draft needs to define a new BGP capability for the willingness = to accept STALE routes. Peers that has not negotiated this capability MUST = receive paths “as if” the STALE paths did not exist. This inclu= des that STALE paths and any non-STALE paths whose nexthops resolve over a STALE paths MUST also not be sent to a such = a peer. This way, negotiation of this capability by consenting adults will = define an island where stale routes would roam free without affecting other= s.

 

From: idr-bounces@ietf.org [m= ailto:idr-bounces@ietf.org] = On Behalf Of Senad .Pal= islamovic
Sent: Friday, June= 22, 2012 7:24 AM
To: idr@ietf.org
Cc: shares@ndzh.com
Subject: Re: [Idr]= draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks

 

IETF mail server= glitch;  resending: Note: Robert already commented back

 

Apologize for th= e delay on comments,

Robert,

After going thro= ugh all the emails, I admit, you've made a lot of valuable comments that 's= eriously' MUST be considered in the new version of the draft.  However= , putting that aside, I would really expect this to be saved for WG discussions.  I would think that at this stag= e, we are more less agreeing to take a look at this problem and its solutio= n space. 

Robert, Randy, S= hane,

The main questio= n I have for you is why object something that might not even affect you.&nb= sp; Draft's primary purpose is for the protection of the control plane= for non-internet services (vpls, l2vpn, or infrustructure routes, i.e. BGP-3107), which in all cases does not affect you or me in an= y shape or form.  For folks to chose to extend this to l3vpn or even t= o IPv4/IPv6 space, they are doing it consciously knowing the nature of thei= r network and its dynamics.  If you do see a route with the STALE community, and do not desire to use this path d= ue its "unreliable" nature, you can request your provider to with= draw the routes with STALE community effectively making them DO_NOT_PERSIST= at the source which effectively mimics the standard GR behavior; as Bruno stated, at eBGP, people are talking and neg= otiating.

So given all tha= t, help me understand how could this impact anyone who chooses not to use i= t.  Am I missing anything?

On the side note= , Susan, I do support this draft as WG document.

 

Senad

 

 

 

 

 

On Wed, J= un 20, 2012 at 4:31 AM, Robert Raszuk <robert@raszuk.net> wrote:

 

Yet, IMHO= building a good (reliable, performant) BGP implementation is hard.

 

True. And= changing it's fundamental behaviour every few months does not help to make= it reliable/ performant either ;)

 

I don't t= hink operators would do a better job on the BGP implementation side.

 

I am not = asking for that at all. I am asking to simply use multiple implementations = in the backend. Not two .. but 4 or 5. Probability that all fail/melt with = the same bug I think is very very low.

Of course I admit that if you one uses service which only single vendor sup= ports in BGP then one get's a bit stuck with the risk. And that seems to be= one of the silent "problem statement" here.

Rgs,


R.

_______________________________________________
Idr mailing list
Idr@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/idr

 

 






___________________________=
____________________
Idr mailing list=

Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr

 

 

_______________________________= ________________
Idr mailing list
Idr@ietf.org
https://www.ie= tf.org/mailman/listinfo/idr

 

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete al=
tere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for message=
s that have been modified, changed or falsified.
Thank you.
--_000_53C29892C857584299CBF5D05346208A094280PEXCVZYM11corpora_-- From ju1738@att.com Sat Jun 23 12:46:42 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7389F21F8530 for ; Sat, 23 Jun 2012 12:46:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.521 X-Spam-Level: X-Spam-Status: No, score=-105.521 tagged_above=-999 required=5 tests=[AWL=-0.723, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_41=0.6, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ftrgxtm6JJzz for ; Sat, 23 Jun 2012 12:46:36 -0700 (PDT) Received: from nbfkord-smmo03.seg.att.com (nbfkord-smmo03.seg.att.com [209.65.160.84]) by ietfa.amsl.com (Postfix) with ESMTP id A85FA21F8532 for ; Sat, 23 Jun 2012 12:46:35 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO nbfkord-smmo03.seg.att.com) by nbfkord-smmo03.seg.att.com(mxl_mta-6.11.0-10) with ESMTP id b1d16ef4.7185a940.1058635.00-571.2916905.nbfkord-smmo03.seg.att.com (envelope-from ); Sat, 23 Jun 2012 19:46:35 +0000 (UTC) X-MXL-Hash: 4fe61d1b608cf9c2-8105c7589ac7ff940e4d10f74ed0edf20dbbc285 Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo03.seg.att.com(mxl_mta-6.11.0-10) over TLS secured channel with ESMTP id 7fc16ef4.0.1058554.00-453.2916680.nbfkord-smmo03.seg.att.com (envelope-from ); Sat, 23 Jun 2012 19:46:16 +0000 (UTC) X-MXL-Hash: 4fe61d08366084ed-e756531f6f2b4cc0beb77bc4288bee698358cde4 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q5NJjx10031573; Sat, 23 Jun 2012 15:45:59 -0400 Received: from sflint01.pst.cso.att.com (sflint01.pst.cso.att.com [144.154.234.228]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q5NJjwfW031570 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 23 Jun 2012 15:45:58 -0400 Received: from MISOUT7MSGHUB9B.ITServices.sbc.com (misout7msghub9b.itservices.sbc.com [144.151.223.72]) by sflint01.pst.cso.att.com (RSA Interceptor); Sat, 23 Jun 2012 15:45:40 -0400 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9B.ITServices.sbc.com ([144.151.223.72]) with mapi id 14.02.0298.004; Sat, 23 Jun 2012 15:45:40 -0400 From: "UTTARO, JAMES" To: "'Shane Amante'" Thread-Topic: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks Thread-Index: AQHNUIKv4gES0WzL/kWO4I5ojxcnRZcGy9WAgAAMWYD//70toIAASxcA//+9G7CAAMwtgIAA4i1A Date: Sat, 23 Jun 2012 19:45:39 +0000 Message-ID: References: <003c01cd4b29$97d7b150$c78713f0$@ndzh.com> <985EF8D2-DA8A-4BE7-94D3-F4BE2B74D768@castlepoint.net> <4FE07A24.7050804@raszuk.net> <1C1F2B2E-2EB7-42F0-8CFF-57965443C074@castlepoint.net> <7A614998-8FB1-4A51-9937-DE501FF31EB6@juniper.net> <4FE0D1F4.9070208@cisco.com> <4FE0E074.3070905@raszuk.net> <17490_1340180565_4FE18855_17490_15423_1_53C29892C857584299CBF5D05346208A0928AA@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FE18A61.8000405@raszuk.net> <8ED5B0B0F5B4854A912480C1521F973AD95B@xmb-rcd-x13.cisco.com> <4FE4A8F3.20809@cisco.com> <4FE4AFE2.3030107@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.160.140] Content-Type: multipart/alternative; boundary="_000_B17A6910EEDD1F45980687268941550FB1FE2FMISOUT7MSGUSR9IIT_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=1.0 c=1 a=UZz9RedjOpYA:10 a=ZQD3OTTxKqYA:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a=XK] X-AnalysisOut: [fbYx4oAAAA:8 a=48vgC7mUAAAA:8 a=AUd_NHdVAAAA:8 a=1sjgXBK7A] X-AnalysisOut: [AAA:8 a=2clOPd4PAAAA:8 a=MuSM70rutRobwTFv44gA:9 a=CjuIK1q_] X-AnalysisOut: [8ugA:10 a=uI1Or78iWTcA:10 a=lZB815dzVvQA:10 a=JfD0Fch1gWkA] X-AnalysisOut: [:10 a=kZwP4KTQBigA:10 a=bDUki_mJ7DgA:10 a=1_8g_3twrHqCwmh2] X-AnalysisOut: [:21 a=q8xBpDSPHGdtZja4:21 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:] X-AnalysisOut: [8 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=] X-AnalysisOut: [tXsnliwV7b4A:10 a=brYXQkpbj9x8BE3e:21 a=V4ClKr2CJk_Hw6lI:2] X-AnalysisOut: [1] Cc: "idr@ietf.org" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jun 2012 19:46:42 -0000 --_000_B17A6910EEDD1F45980687268941550FB1FE2FMISOUT7MSGUSR9IIT_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Shane, First of all if it was as easy as redundant BGP sessions or= as you state later "proper network architecture" we would not be having th= is conversation.. Obvious network architecture like redundant sessions so I= can perform maintenance mode is pretty much the starting point of a robust= architecture across AFs/Services and I would hazard a guess that everyone = does this.. Beyond that there are methods to enhance reliability even furth= er that I have taken ( We could have a pvt conversation if you would like )= . All of this being said, there are implementation bugs, overloading of BG= P machinery etc.. that have occurred and will occur in the future.. We cann= ot simply shrug and say it is not important as it in some folks mind rare (= not accurate ) or that there is some magical network architecture that if = only everyone would use, this issue could be mitigated. IMO it is the job o= f the IETF to address real problems in the real world.. Back to this rare nonsense.. Rob Shakir wrote a draft to correct what I gue= ss is a rare condition having to do with a mal-formed attr. He is very desc= riptive in terms f syntactic and semantic bugs. Folks in IDR including E.Ch= en is an author of a solutions draft. If this is so rare why is there a req= and solutions draft.. We cannot have the argument coming out of both sides of the mouth.. Jim Uttaro From: Shane Amante [mailto:shane@castlepoint.net] Sent: Friday, June 22, 2012 10:00 PM To: UTTARO, JAMES Cc: 'Enke Chen'; idr@ietf.org Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document -= 3 more weeks On Jun 22, 2012, at 12:03 PM, UTTARO, JAMES wrote: Enke, I think we have got to have a consistent approach to these = solutions.. I am not comfortable with the fact that it is "ok" for GR but n= ot "ok" for Persistence based on a IMO subjective interpretation of the amo= unt of time a STALE path is active in local and adjacent topologies. An hou= r is a long time, and as GR is used primarily used n IPV4 which is dynamic = it would seem that a) these paths should be de-pref after some amount of ti= me b) GR should inform other AS topologies of the staleness by using the ST= ALE CV.. I would be interested in hearing from operators as to if this behavior is u= nderstood and if limiting of the time to ~1hr makes the inconsistency withi= n and across AS domains acceptable.. In your opinion what is the maximum a= cceptable amount of time that we could use Persistence. As an operator I believe even 1 hour is too long. In fact, I'd rather (and= , I do) trust Non-Stop Routing (NSR) on PE's in the network, because I know= that CE's will not understand GR capability and will not be able to benefi= t from continuing to forward packets even while the PE is restarting. Gran= ted, this is an environment where there are many "unmanaged CE's", where I = have no control/say over what SW or the capabilities are on those CE's. Furthermore, with control plane redundancy for iBGP sessions from one PE ac= ross multiple RR's serving that cluster, it is possible to conduct maintena= nce on one half of the RR-pair serving a cluster while still preserving con= trol and/or forwarding plane behavior. Ultimately, as I've said before, I'd much rather not see any type of "stale= " routes 'sticking around' in the control plane, since that is a vast chang= e in behavior from today's deployment of BGP where reachability information= is only carried while there are active BGP sessions. (Yes, I get your poi= nt that I don't have to use persistence if I don't want to, but if develope= rs are in there monkey'ing around with code to add this feature, inevitably= I pay a price in addt'l complexity for this "feature" even if I don't turn= it on, i.e.: there are potentially 'latent' bugs caused by this "feature",= which is not acceptable). As Enke has stated previously, I believe this class of problem is a rare on= e, (given a proper network architecture), and thus we should not be creatin= g AFI-specific solutions that add substantial complexity to an already comp= lex protocol. -shane Jim Uttaro From: Enke Chen [mailto:enkechen@cisco.com] Sent: Friday, June 22, 2012 1:48 PM To: UTTARO, JAMES Cc: Saikat Ray (sairay); idr@ietf.org; Enke Chen Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document -= 3 more weeks Jim, With GR, as you correctly pointed out, a path would not stale for many hour= s or days. That is why it may not be as critical to limit the scope of the = stale path. If we were to have long-lived stale paths (which I think is a bad idea), I = agree that they should be limited to "consenting adults", and there must be= some mechanisms (such as capability) in place. -- Enke On 6/22/12 10:27 AM, UTTARO, JAMES wrote: Enke, The idea behind the setting of STALE is to inform speakers = in other AS domains that the path is suspect as the session it was learned = over is down.. IMO this is required to inform others about the viability of= a path.. The other approach is to simply not mark these paths as STALE.. Simply de-p= ref in the local AS and business as usual when advertised outside the AS wh= ere all transitive attrs are reset.. This is exactly the semantic you are using in the GR draft. You do not de-p= ref the state locally and do not inform other AS domains that the paths lea= rned over the session that GR is active on are suspect. If the STALE CV is not honored across the AS border than the behavior defau= lts to what is specified in the GR draft. This should meet your requirement= s. Jim Uttaro From: idr-bounces@ietf.org [mailto:idr-bounces= @ietf.org] On Behalf Of Enke Chen Sent: Friday, June 22, 2012 1:19 PM To: Saikat Ray (sairay) Cc: idr@ietf.org Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document -= 3 more weeks Hi, Saikat: A new capability would certainly help. It seems necessary, but may not be = sufficient to limit the scope of the STALE path to "consenting adults". F= or example, inside a network (i.e., AS), if there are routers that do not r= ecognize the STALE community, a STALE path may still be advertised to exter= nal peers without the capability. This means that all the routers in a ne= twork must recognize the community before enabling the capability on any of= them. It will be difficult to satisfy the condition universally. In addition, to limit its scope the STALE community, once set, MUST not be = removed by any receiver. -- Enke On 6/22/12 9:34 AM, Saikat Ray (sairay) wrote: Without being involved in the discussion whether it is the right problem to= tackle or not, I would like to make the observation that at the very least= , the draft needs to define a new BGP capability for the willingness to acc= ept STALE routes. Peers that has not negotiated this capability MUST receiv= e paths "as if" the STALE paths did not exist. This includes that STALE pat= hs and any non-STALE paths whose nexthops resolve over a STALE paths MUST a= lso not be sent to a such a peer. This way, negotiation of this capability = by consenting adults will define an island where stale routes would roam fr= ee without affecting others. From: idr-bounces@ietf.org [mailto:idr-bounces= @ietf.org] On Behalf Of Senad .Palislamovic Sent: Friday, June 22, 2012 7:24 AM To: idr@ietf.org Cc: shares@ndzh.com Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document -= 3 more weeks IETF mail server glitch; resending: Note: Robert already commented back Apologize for the delay on comments, Robert, After going through all the emails, I admit, you've made a lot of valuable = comments that 'seriously' MUST be considered in the new version of the draf= t. However, putting that aside, I would really expect this to be saved for= WG discussions. I would think that at this stage, we are more less agreei= ng to take a look at this problem and its solution space. Robert, Randy, Shane, The main question I have for you is why object something that might not eve= n affect you. Draft's primary purpose is for the protection of the control= plane for non-internet services (vpls, l2vpn, or infrustructure routes, i.= e. BGP-3107), which in all cases does not affect you or me in any shape or = form. For folks to chose to extend this to l3vpn or even to IPv4/IPv6 spac= e, they are doing it consciously knowing the nature of their network and it= s dynamics. If you do see a route with the STALE community, and do not des= ire to use this path due its "unreliable" nature, you can request your prov= ider to withdraw the routes with STALE community effectively making them DO= _NOT_PERSIST at the source which effectively mimics the standard GR behavio= r; as Bruno stated, at eBGP, people are talking and negotiating. So given all that, help me understand how could this impact anyone who choo= ses not to use it. Am I missing anything? On the side note, Susan, I do support this draft as WG document. Senad On Wed, Jun 20, 2012 at 4:31 AM, Robert Raszuk > wrote: Yet, IMHO building a good (reliable, performant) BGP implementation is hard= . True. And changing it's fundamental behaviour every few months does not hel= p to make it reliable/ performant either ;) I don't think operators would do a better job on the BGP implementation sid= e. I am not asking for that at all. I am asking to simply use multiple impleme= ntations in the backend. Not two .. but 4 or 5. Probability that all fail/m= elt with the same bug I think is very very low. Of course I admit that if you one uses service which only single vendor sup= ports in BGP then one get's a bit stuck with the risk. And that seems to be= one of the silent "problem statement" here. Rgs, R. _______________________________________________ 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 _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr --_000_B17A6910EEDD1F45980687268941550FB1FE2FMISOUT7MSGUSR9IIT_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Shane,<= /p>

 <= /p>

    &= nbsp;           First of = all if it was as easy as redundant BGP sessions or as you state later ̶= 0;proper network architecture” we would not be having this conversati= on.. Obvious network architecture like redundant sessions so I can perform main= tenance mode is pretty much the starting point of a robust architecture acr= oss AFs/Services and I would hazard a guess that everyone does this.. Beyon= d that there are methods to enhance reliability even further that I have taken ( We could have a pvt conversat= ion if you would like ).  All of this being said, there are implementa= tion bugs, overloading of BGP machinery etc.. that have occurred and will o= ccur in the future.. We cannot simply shrug and say it is not important as it in some folks mind rare ( not accu= rate ) or that there is some magical network architecture that if only ever= yone would use, this issue could be mitigated. IMO it is the job of the IET= F to address real problems in the real world..

 <= /p>

Back to this rare nonsens= e.. Rob Shakir wrote a draft to correct what I guess is a rare condition ha= ving to do with a mal-formed attr. He is very descriptive in terms f syntactic and semantic bugs. Folks in IDR including E.Chen is a= n author of a solutions draft. If this is so rare why is there a req and so= lutions draft..

 <= /p>

We cannot have the argume= nt coming out of both sides of the mouth..

 <= /p>

Jim Uttaro

 <= /p>

From: Shane Am= ante [mailto:shane@castlepoint.net]
Sent: Friday, June 22, 2012 10:00 PM
To: UTTARO, JAMES
Cc: 'Enke Chen'; idr@ietf.org
Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG doc= ument - 3 more weeks

 

 

On Jun 22, 2012, at 12:03 PM, UTTARO, JAMES wrote:



Enke,

 

    &= nbsp;           I think w= e have got to have a consistent approach to these solutions.. I am not comf= ortable with the fact that it is “ok” for GR but not “ok&= #8221; for Persistence based on a IMO subjective interpretation of the amount of = time a STALE path is active in local and adjacent topologies. An hour is a = long time, and as GR is used primarily used n IPV4 which is dynamic it woul= d seem that a) these paths should be de-pref after some amount of time b) GR should inform other AS topologi= es of the staleness by using the STALE CV..

 

I would be interested in = hearing from operators as to if this behavior is understood and if limiting= of the time to ~1hr makes the inconsistency within and across AS domains acceptable..  In your opinion what is the maximum a= cceptable amount of time that we could use Persistence. 

 

As an operator I believe even 1 hour is too long. &n= bsp;In fact, I'd rather (and, I do) trust Non-Stop Routing (NSR) on PE's in= the network, because I know that CE's will not understand GR capability an= d will not be able to benefit from continuing to forward packets even while the PE is restarting.  Granted, this is= an environment where there are many "unmanaged CE's", where I ha= ve no control/say over what SW or the capabilities are on those CE's.<= /o:p>

 

Furthermore, with control plane redundancy for iBGP = sessions from one PE across multiple RR's serving that cluster, it is possi= ble to conduct maintenance on one half of the RR-pair serving a cluster whi= le still preserving control and/or forwarding plane behavior.

 

Ultimately, as I've said before, I'd much rather not= see any type of "stale" routes 'sticking around' in the control = plane, since that is a vast change in behavior from today's deployment of B= GP where reachability information is only carried while there are active BGP sessions.  (Yes, I get your point that I d= on't have to use persistence if I don't want to, but if developers are in t= here monkey'ing around with code to add this feature, inevitably I pay a pr= ice in addt'l complexity for this "feature" even if I don't turn it on, i.e.: there are potentially 'latent' bugs caus= ed by this "feature", which is not acceptable).

 

As Enke has stated previously, I believe this class = of problem is a rare one, (given a proper network architecture), and thus w= e should not be creating AFI-specific solutions that add substantial comple= xity to an already complex protocol. 

 

-shane

 

 



Jim Uttaro

 

 

 

 

From: Enke Chen [mailto:enkechen@cisco.com]=  
Sent: Friday, June= 22, 2012 1:48 PM
To: UTTARO, JAMES<= br> Cc: Saikat Ray (sa= iray); idr@ietf.org; Enke Chen
Subject: Re: [Idr]= draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks

 =

Jim,

With GR, as you correctly pointed out, a path would not stale for many hour= s or days. That is why it may not be as critical to limit the scope of the = stale path.

If we were to have long-lived stale paths (which I think is a bad idea), I = agree that they should be limited to "consenting adults", and the= re must be some mechanisms (such as capability) in place.

-- Enke

On 6/22/12 10:27 AM, UTTARO, JAMES wrote:

Enke,

 

    &= nbsp;           The idea = behind the setting of STALE is to inform speakers in other AS domains that = the path is suspect as the session it was learned over is down.. IMO this is required to inform others about the viability of a path= ..

 

The other approach is to = simply not mark these paths as STALE.. Simply de-pref in the local AS and b= usiness as usual when advertised outside the AS where all transitive attrs are reset..=

 

This is exactly the seman= tic you are using in the GR draft. You do not de-pref the state locally and= do not inform other AS domains that the paths learned over the session that GR is active on are suspect.

 

If the STALE CV is not ho= nored across the AS border than the behavior defaults to what is specified = in the GR draft. This should meet your requirements.

 

Jim Uttaro

 

From: idr-bounces@ietf.org [mailto:i= dr-bounces@ietf.org] = On Behalf Of Enke Chen<= br> Sent: Friday, June= 22, 2012 1:19 PM
To: Saikat Ray (sa= iray)
Cc: idr@ietf.org
Subject: Re: [Idr]= draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks

 =

Hi, Saikat:

A new capability would certainly help.  It seems necessary, but may no= t be sufficient to limit the scope of the STALE path to "consenting ad= ults".   For example, inside a network (i.e., AS), if there = are routers that do not recognize the STALE community, a STALE path may still be advertised to external peers without the capabilit= y.   This means that all the routers in a network must recognize = the community before enabling the capability on any of them.  It will = be difficult to satisfy the condition universally.

In addition, to limit its scope the STALE community, once set, MUST not be = removed by any receiver.

-- Enke

On 6/22/12 9:34 AM, Saikat Ray (sairay) wrote:

Without being involved in= the discussion whether it is the right problem to tackle or not, I would l= ike to make the observation that at the very least, the draft needs to define a new BGP capability for the willingness to accept S= TALE routes. Peers that has not negotiated this capability MUST receive pat= hs “as if” the STALE paths did not exist. This includes that ST= ALE paths and any non-STALE paths whose nexthops resolve over a STALE paths MUST also not be sent to a such a peer. This wa= y, negotiation of this capability by consenting adults will define an islan= d where stale routes would roam free without affecting others.

 

From: idr-bounces@i= etf.org [mailto:idr-bounces@ietf.org] On Behalf Of Senad .Pal= islamovic
Sent: Friday, June= 22, 2012 7:24 AM
To: idr@ietf.org
Cc: shares@ndzh.com
Subject: Re: [Idr]= draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks

 =

IETF mail server glitch;  = resending: Note: Robert already commented back

 

Apologize for the delay on comm= ents,

Robert,

After going through all the ema= ils, I admit, you've made a lot of valuable comments that 'seriously' MUST = be considered in the new version of the draft.  However, putting that = aside, I would really expect this to be saved for WG discussions.  I would think that at this stage, we are more le= ss agreeing to take a look at this problem and its solution space. 

Robert, Randy, Shane,

The main question I have for yo= u is why object something that might not even affect you.  Draft's&nbs= p;primary purpose is for the protection of the control plane for non-intern= et services (vpls, l2vpn, or infrustructure routes, i.e. BGP-3107), which in all cases does not affect you or me in any shape = or form.  For folks to chose to extend this to l3vpn or even to IPv4/I= Pv6 space, they are doing it consciously knowing the nature of their networ= k and its dynamics.  If you do see a route with the STALE community, and do not desire to use this path due its= "unreliable" nature, you can request your provider to withdraw t= he routes with STALE community effectively making them DO_NOT_PERSIST at th= e source which effectively mimics the standard GR behavior; as Bruno stated, at eBGP, people are talking and negotiating.=

So given all that, help me unde= rstand how could this impact anyone who chooses not to use it.  Am I m= issing anything?

On the side note, Susan, I do s= upport this draft as WG document.

 =

Senad<= /p>

 =

 =

 =

 =

 

On Wed, Jun 20, 2012 at = 4:31 AM, Robert Raszuk <robert@raszuk.net> wrote:

 =

Yet, IMHO building a goo= d (reliable, performant) BGP implementation is hard.

 =

True. And changing it's = fundamental behaviour every few months does not help to make it reliable/ p= erformant either ;)

 

I don't think operators = would do a better job on the BGP implementation side.

 =

I am not asking for that= at all. I am asking to simply use multiple implementations in the backend.= Not two .. but 4 or 5. Probability that all fail/melt with the same bug I = think is very very low.

Of course I admit that if you one uses service which only single vendor sup= ports in BGP then one get's a bit stuck with the risk. And that seems to be= one of the silent "problem statement" here.

Rgs,


R.

_______________________________________________
Idr mailing list
Idr@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/idr

 =

 = 






__________________________________________=
_____
Idr mailing list
Idr@ietf.o=
rg
https://www.ietf.org/mailman/listinfo/idr=

 =

 =

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ie= tf.org/mailman/listinfo/idr

 

--_000_B17A6910EEDD1F45980687268941550FB1FE2FMISOUT7MSGUSR9IIT_-- From bruno.decraene@orange.com Sat Jun 23 12:52:14 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0416A21F853E for ; Sat, 23 Jun 2012 12:52:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.197 X-Spam-Level: X-Spam-Status: No, score=-2.197 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vEonmDGnzyeS for ; Sat, 23 Jun 2012 12:52:10 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id E6A7121F8539 for ; Sat, 23 Jun 2012 12:52:09 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 58CC422C3A3; Sat, 23 Jun 2012 21:52:09 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 39BDF238048; Sat, 23 Jun 2012 21:52:09 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Sat, 23 Jun 2012 21:52:08 +0200 From: To: Enke Chen , "Saikat Ray (sairay)" Thread-Topic: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks Thread-Index: AQHNUIK5kzFtDweGF06QjEz6Tygl8ZcGhN0g///uvICAAdzM4A== Date: Sat, 23 Jun 2012 19:52:07 +0000 Message-ID: <25040_1340481129_4FE61E69_25040_15039_1_53C29892C857584299CBF5D05346208A0942C7@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <003c01cd4b29$97d7b150$c78713f0$@ndzh.com> <985EF8D2-DA8A-4BE7-94D3-F4BE2B74D768@castlepoint.net> <4FE07A24.7050804@raszuk.net> <1C1F2B2E-2EB7-42F0-8CFF-57965443C074@castlepoint.net> <7A614998-8FB1-4A51-9937-DE501FF31EB6@juniper.net> <4FE0D1F4.9070208@cisco.com> <4FE0E074.3070905@raszuk.net> <17490_1340180565_4FE18855_17490_15423_1_53C29892C857584299CBF5D05346208A0928AA@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FE18A61.8000405@raszuk.net> <8ED5B0B0F5B4854A912480C1521F973AD95B@xmb-rcd-x13.cisco.com> <4FE4A8F3.20809@cisco.com> In-Reply-To: <4FE4A8F3.20809@cisco.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.5] Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A0942C7PEXCVZYM11corpora_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.6.23.163317 Cc: "idr@ietf.org" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jun 2012 19:52:14 -0000 --_000_53C29892C857584299CBF5D05346208A0942C7PEXCVZYM11corpora_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Enke, From: Enke Chen Sent: Friday, June 22, 2012 7:19 PM Hi, Saikat: A new capability would certainly help. It seems necessary, but may not be = sufficient to limit the scope of the STALE path to "consenting adults". F= or example, inside a network (i.e., AS), if there are routers that do not r= ecognize the STALE community, a STALE path may still be advertised to exter= nal peers without the capability. This means that all the routers in a ne= twork must recognize the community before enabling the capability on any of= them. It will be difficult to satisfy the condition universally. I'm not sure to see the real difficulty. This does not require a new implem= entation but only to update a routemap. ISP already widely use communities. Alternatively, the router activating persistence and setting the STALE comm= unity could also set the NO_EXPORT community. Hence by default the STALE ro= ute would not be advertised to other ASes. Bruno In addition, to limit its scope the STALE community, once set, MUST not be = removed by any receiver. -- Enke On 6/22/12 9:34 AM, Saikat Ray (sairay) wrote: Without being involved in the discussion whether it is the right problem to= tackle or not, I would like to make the observation that at the very least= , the draft needs to define a new BGP capability for the willingness to acc= ept STALE routes. Peers that has not negotiated this capability MUST receiv= e paths "as if" the STALE paths did not exist. This includes that STALE pat= hs and any non-STALE paths whose nexthops resolve over a STALE paths MUST a= lso not be sent to a such a peer. This way, negotiation of this capability = by consenting adults will define an island where stale routes would roam fr= ee without affecting others. From: idr-bounces@ietf.org [mailto:idr-bounces= @ietf.org] On Behalf Of Senad .Palislamovic Sent: Friday, June 22, 2012 7:24 AM To: idr@ietf.org Cc: shares@ndzh.com Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document -= 3 more weeks IETF mail server glitch; resending: Note: Robert already commented back Apologize for the delay on comments, Robert, After going through all the emails, I admit, you've made a lot of valuable = comments that 'seriously' MUST be considered in the new version of the draf= t. However, putting that aside, I would really expect this to be saved for= WG discussions. I would think that at this stage, we are more less agreei= ng to take a look at this problem and its solution space. Robert, Randy, Shane, The main question I have for you is why object something that might not eve= n affect you. Draft's primary purpose is for the protection of the control= plane for non-internet services (vpls, l2vpn, or infrustructure routes, i.= e. BGP-3107), which in all cases does not affect you or me in any shape or = form. For folks to chose to extend this to l3vpn or even to IPv4/IPv6 spac= e, they are doing it consciously knowing the nature of their network and it= s dynamics. If you do see a route with the STALE community, and do not des= ire to use this path due its "unreliable" nature, you can request your prov= ider to withdraw the routes with STALE community effectively making them DO= _NOT_PERSIST at the source which effectively mimics the standard GR behavio= r; as Bruno stated, at eBGP, people are talking and negotiating. So given all that, help me understand how could this impact anyone who choo= ses not to use it. Am I missing anything? On the side note, Susan, I do support this draft as WG document. Senad On Wed, Jun 20, 2012 at 4:31 AM, Robert Raszuk > wrote: Yet, IMHO building a good (reliable, performant) BGP implementation is hard. True. And changing it's fundamental behaviour every few months does not hel= p to make it reliable/ performant either ;) I don't think operators would do a better job on the BGP implementation sid= e. I am not asking for that at all. I am asking to simply use multiple impleme= ntations in the backend. Not two .. but 4 or 5. Probability that all fail/m= elt with the same bug I think is very very low. Of course I admit that if you one uses service which only single vendor sup= ports in BGP then one get's a bit stuck with the risk. And that seems to be= one of the silent "problem statement" here. Rgs, R. _______________________________________________ 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 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. --_000_53C29892C857584299CBF5D05346208A0942C7PEXCVZYM11corpora_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Enke,

 = ;

From: Enke Chen Sent: Friday, June 22, 2012 7:19 PM

 

Hi, Saikat:

A new capability would certainly help.  It seems necessary, but may no= t be sufficient to limit the scope of the STALE path to "consenting ad= ults".   For example, inside a network (i.e., AS), if there = are routers that do not recognize the STALE community, a STALE path may still be advertised to external peers without the capabilit= y.   This means that all the routers in a network must recognize = the community before enabling the capability on any of them.  It will = be difficult to satisfy the condition universally.

I’m = not sure to see the real difficulty. This does not require a new implementa= tion but only to update a routemap. ISP already widely use communities.

 = ;

Alternativ= ely, the router activating persistence and setting the STALE community coul= d also set the NO_EXPORT community. Hence by default the STALE route would not be advertised to other ASes.

 = ;

Bruno=

 = ;


In addition, to limit its scope the STALE community, once set, MUST not be = removed by any receiver.

-- Enke

On 6/22/12 9:34 AM, Saikat Ray (sairay) wrote:

Without being involved in= the discussion whether it is the right problem to tackle or not, I would l= ike to make the observation that at the very least, the draft needs to define a new BGP capability for the willingness to accept S= TALE routes. Peers that has not negotiated this capability MUST receive pat= hs “as if” the STALE paths did not exist. This includes that ST= ALE paths and any non-STALE paths whose nexthops resolve over a STALE paths MUST also not be sent to a such a peer. This wa= y, negotiation of this capability by consenting adults will define an islan= d where stale routes would roam free without affecting others.<= /o:p>

 <= /p>

From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Senad .Palislamovic
Sent: Friday, June 22, 2012 7:24 AM
To: idr@ietf.org
Cc: shares@ndzh.com
Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG doc= ument - 3 more weeks

 

IETF mail server glitch;  resending: Note: Robert= already commented back

 

Apologize for the delay on comments,

Robert,

After going through all the emails, I admit, you've made a = lot of valuable comments that 'seriously' MUST be considered in the new ver= sion of the draft.  However, putting that aside, I would really expect= this to be saved for WG discussions.  I would think that at this stage, we are more less agreeing to take a look= at this problem and its solution space. 

Robert, Randy, Shane,

The main question I have for you is why object something th= at might not even affect you.  Draft's primary purpose is for the= protection of the control plane for non-internet services (vpls, l2vpn, or= infrustructure routes, i.e. BGP-3107), which in all cases does not affect you or me in any shape or form.  For fol= ks to chose to extend this to l3vpn or even to IPv4/IPv6 space, they are do= ing it consciously knowing the nature of their network and its dynamics.&nb= sp; If you do see a route with the STALE community, and do not desire to use this path due its "unreliable" nature, = you can request your provider to withdraw the routes with STALE community e= ffectively making them DO_NOT_PERSIST at the source which effectively mimic= s the standard GR behavior; as Bruno stated, at eBGP, people are talking and negotiating.

So given all that, help me understand how could this impact= anyone who chooses not to use it.  Am I missing anything?<= /p>

On the side note, Susan, I do support this draft as WG docu= ment.

 

Senad

 

 

 

 

 

On Wed, Jun 20, 2012 at 4:31 AM, Robert Raszuk <<= a href=3D"mailto:robert@raszuk.net" target=3D"_blank">robert@raszuk.net= > wrote:

 

Yet, IMHO building a good (reliable, performant) BGP= implementation is hard.

 

True. And changing it's fundamental behaviour every = few months does not help to make it reliable/ performant either ;)

 

I don't think operators would do a better job on the= BGP implementation side.

 

I am not asking for that at all. I am asking to simp= ly use multiple implementations in the backend. Not two .. but 4 or 5. Prob= ability that all fail/melt with the same bug I think is very very low.

Of course I admit that if you one uses service which only single vendor sup= ports in BGP then one get's a bit stuck with the risk. And that seems to be= one of the silent "problem statement" here.

Rgs,


R.

_______________________________________________
Idr mailing list
Idr@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/idr

 

 




_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf=
.org/mailman/listinfo/idr

 

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete al=
tere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for message=
s that have been modified, changed or falsified.
Thank you.
--_000_53C29892C857584299CBF5D05346208A0942C7PEXCVZYM11corpora_-- From robert@raszuk.net Sat Jun 23 13:00:09 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B682621F8532 for ; Sat, 23 Jun 2012 13:00:09 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OxFlxxHcl4Nb for ; Sat, 23 Jun 2012 13:00:09 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id EDB3921F84CF for ; Sat, 23 Jun 2012 13:00:08 -0700 (PDT) Received: (qmail 28416 invoked by uid 399); 23 Jun 2012 20:00:08 -0000 Received: from unknown (HELO ?192.168.1.58?) (pbs:robert@raszuk.net@83.9.69.20) by mail1310.opentransfer.com with ESMTPM; 23 Jun 2012 20:00:08 -0000 X-Originating-IP: 83.9.69.20 Message-ID: <4FE62048.3050303@raszuk.net> Date: Sat, 23 Jun 2012 22:00:08 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: bruno.decraene@orange.com References: <003c01cd4b29$97d7b150$c78713f0$@ndzh.com> <985EF8D2-DA8A-4BE7-94D3-F4BE2B74D768@castlepoint.net> <4FE07A24.7050804@raszuk.net> <1C1F2B2E-2EB7-42F0-8CFF-57965443C074@castlepoint.net> <7A614998-8FB1-4A51-9937-DE501FF31EB6@juniper.net> <4FE0D1F4.9070208@cisco.com> <4FE0E074.3070905@raszuk.net> <17490_1340180565_4FE18855_17490_15423_1_53C29892C857584299CBF5D05346208A0928AA@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FE18A61.8000405@raszuk.net> <8ED5B0B0F5B4854A912480C1521F973AD95B@xmb-rcd-x13.cisco.com> <4FE4A8F3.20809@cisco.com> <25040_1340481129_4FE61E69_25040_15039_1_53C29892C857584299CBF5D05346208A0942C7@PEXCVZYM11.corporate.adroot.infra.ftgroup> In-Reply-To: <25040_1340481129_4FE61E69_25040_15039_1_53C29892C857584299CBF5D05346208A0942C7@PEXCVZYM11.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jun 2012 20:00:10 -0000 > Alternatively, the router activating persistence and setting the STALE > community could also set the NO_EXPORT community. Hence by default the > STALE route would not be advertised to other ASes. That would be terribly broken I am afraid. Dropping the route at PE/ASBR (what NO_EXPORT does) does not mean generating a withdraw. So all of your EBGP peers would never get the withdraw during the persistance period which as the draft say can be infinity. The end effect would be completely broken routing. r. From robert@raszuk.net Sat Jun 23 13:14:45 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A02E21F8541 for ; Sat, 23 Jun 2012 13:14:45 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VWoYMjBVcc4L for ; Sat, 23 Jun 2012 13:14:44 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 2019421F8532 for ; Sat, 23 Jun 2012 13:14:44 -0700 (PDT) Received: (qmail 14671 invoked by uid 399); 23 Jun 2012 20:14:43 -0000 Received: from unknown (HELO ?192.168.1.58?) (pbs:robert@raszuk.net@83.9.69.20) by mail1310.opentransfer.com with ESMTPM; 23 Jun 2012 20:14:43 -0000 X-Originating-IP: 83.9.69.20 Message-ID: <4FE623B3.4060906@raszuk.net> Date: Sat, 23 Jun 2012 22:14:43 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: "idr@ietf.org List" , "UTTARO, JAMES (ATTLABS)" References: <14C7F4F06DB5814AB0DE29716C4F6D6702DF7129F6@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jun 2012 20:14:45 -0000 Jim, > IMO I think that folks need to come to the realization that BGP is > being used in varied use cases, using the internet application as the > only frame of reference or lens into the requirements for reliability is > simply not appropriate or correct.. + > All of this being said, there are implementation bugs, overloading of > BGP machinery etc.. that have occurred and will occur in the future.. I think you need to realize that the key for any application is solid IP reachability. You can realize any VPN to your customers without BGP being used as a service bus for it. It is your choice or your vendor's choice as you say to "overload BGP machinery" for everything. Putting more and more questionable requirements on the only protocol which provides such global IP reachability proves as a bad idea. It makes the protocol more and more fragile. The motivation that various flavors of VPNs carried by BGP must be up only proves that as number of people suggested in the past the same BGP protocol should not be used for everything. The point is not that protocol will not be able to cope with the requirement. The point is that it is wrong to keep changing it's core behaviour because your VPN or VPLS service goes down. Moreover you now do not want to limit the changes only to your services SAFI, but argue to "enhance" all AFI/SAFIs with it. That is something very hard to agree with. R. From rjs@rob.sh Sat Jun 23 14:33:36 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD31021F85E5; Sat, 23 Jun 2012 14:33:36 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Va7vNm2xENnO; Sat, 23 Jun 2012 14:33:36 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2001:b98:201:101::10:cafe]) by ietfa.amsl.com (Postfix) with ESMTP id CB00321F85E3; Sat, 23 Jun 2012 14:33:35 -0700 (PDT) Received: from [93.97.180.64] (helo=lait.config) by cappuccino.rob.sh with esmtpa (Exim 4.72) (envelope-from ) id 1SiXwA-0003KD-J9; Sat, 23 Jun 2012 22:32:10 +0100 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Rob Shakir In-Reply-To: <4FE4B2AD.9050704@cisco.com> Date: Sat, 23 Jun 2012 22:33:32 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4FE495CD.7080604@raszuk.net> <4FE4B2AD.9050704@cisco.com> To: Enke Chen X-Mailer: Apple Mail (2.1257) Cc: "idr@ietf.org List" , "grow@ietf.org" , "UTTARO, JAMES \(ATTLABS\)" , robert@raszuk.net Subject: Re: [Idr] [GROW] Fwd: draft-ietf-grow-ops-reqs-for-bgp-error-handling-04 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jun 2012 21:33:36 -0000 On 22 Jun 2012, at 19:00, Enke Chen wrote: > Hi, folks: >=20 > It might help the discussion to refresh ourselves about several large = outages in the last few years that prompted the work on the error = handling requirements and solutions: >=20 > o issue with AS4_PATH that resulted in session resets multiple hops = away (two separate incidents) > o session reset triggered by a single route with a new attribute >=20 > I remember that Rob had a presentation at the NANOG on the topic. Hi Enke, Thanks for this message. This work is absolutely motivated by incidents = in live networks (both those that have publicly been described and those = in private network deployment that are not as public). I have talked to this work a number of times across a number of operator = forums: - NANOG51 / LINX / UKNOF: = http://www.nanog.org/meetings/nanog51/presentations/Tuesday/shakir-bgp-err= or-handling_rob-shakir-FINAL2.pdf = http://www.nanog.org/meetings/nanog51/presentations/Tuesday/bgp_err_hdling= .wmv - Netnod: = http://rob.sh/files/RJS-Reinforcing_the_Kitchen_Sink-NETNOD-Autumn2011.pdf= The motivation for this work is improving the robustness of real-world = networks, where the current error handling behaviour does not match the = situation and deployment in which the protocol is deployed.=20 As I have voiced in other posts to both the IDR and GROW mailing lists, = these requirements put forward means to be able to balance the risk of = things not being 100% correct in terms of protocol operation against the = threat of complete outages for all routing information carried via a BGP = session. If these risks are not acceptable to an operator, then the = solutions implemented in answer to these requirements do not need to be = enabled - however, at the moment, the protocol is completely constrained = in terms of its behaviour -- sessions are torn down regardless of the = impact of their failure. Kind regards, r.= From john@jlc.net Sat Jun 23 15:12:04 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0017E21F8630 for ; Sat, 23 Jun 2012 15:12:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.549 X-Spam-Level: X-Spam-Status: No, score=-106.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bJdCMR3Pwq2l for ; Sat, 23 Jun 2012 15:12:03 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 09B7921F8627 for ; Sat, 23 Jun 2012 15:12:03 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id C6B4633C22; Sat, 23 Jun 2012 18:12:02 -0400 (EDT) Date: Sat, 23 Jun 2012 18:12:02 -0400 From: John Leslie To: "Neil J. McRae" Message-ID: <20120623221202.GG84371@verdi> References: <20120623115817.GE84371@verdi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Cc: idr@ietf.org Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jun 2012 22:12:04 -0000 Neil J. McRae wrote: > > John, > Thanks for your feedback but in reality this work around won't help > especially in large VPN networks but even in just plain old internet land Obviously, my network is not the same as yours -- I didn't mean to imply that my solution would work for your network, merely that if I were facing your network problems I would be looking for an operational solution. (I'd be _quite_ surprised if there isn't one to make the routes propagated exactly what you want, but under _your_ control.) > With the probability of this issue occurring is increasing and not > decreasing. That is, alas, true. > And btw its not months the industry has been waiting for this to be > resolved. Its more than fifteen years. We need to act to make the control > plane more resilient... To do that, we must be willing to say "No" to folks who propose to introduce new bugs. Alas, the -01 version of bgp-persistence introduces entirely too many bugs for my taste. I am willing to change my opinion if an -02 version gets rid of them, but I currently don't believe this is likely. > When we do so much in other protocols to ensure reliability it seems > incredible that we choose not to here, Reliability is first a matter of leaving out the bugs we can leave out, and second a matter of gathering the operational evidence for bugs that show up. When operators aren't willing to read the logs (but prefer to wait for sessions to go down) I really don't see how to make much progress. > and as I said, in all cases of this scenario impacting me, and what > leads me to believe is crucially a flaw in the current protocol, > reachability has always been present, which is what our protocol is > all about. Alas, that's not quite true. BGP is about exchanging routing information. If it's working right, that gives us good information about reachability. Good, not perfect, alas... Reachability, in a theoretical sense, can best be deterimined by a flooding algorithm to see what works. (There are bunches of reasons why we don't do it that way.) There's nothing wrong with you remembering a stale route your peer advertised and trying it. What's wrong is to lead your other peers to believe it's still being advertised to you. BGP _could_ have been designed to make it reasonable for you to advertise routes which are neither your own nor are advertised to you; but it wasn't. When this happens in today's Internet, we call it a bug and prevail upon you to stop. I freely admit I don't understand exactly what problem you're trying to solve -- except that it involves you wanting some of your peers to use stale routes "because they work". Alas, that's not the BGP paradigm: BGP wants routes that are advertised over the same links that are being used to reach the destination, and BGP _doesn't_ want routers to have any responsibility to determine if routes "work" (whatever that means). I don't know whether the IDR WG _can_ offer you a solution. Old-timers fundamentally don't _want_ to deterimine actual reachability via routers with fried control planes but working data planes. Perhaps if we understood your needs better we could advise on how to advertise "reachability" in the absence of routing information; but right now we suspect you'll cause more problems than you solve. -- John Leslie From enkechen@cisco.com Sat Jun 23 15:31:40 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3A3421F8644 for ; Sat, 23 Jun 2012 15:31:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.009 X-Spam-Level: X-Spam-Status: No, score=-9.009 tagged_above=-999 required=5 tests=[AWL=-1.411, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_24=0.6, J_CHICKENPOX_25=0.6, J_CHICKENPOX_41=0.6, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mhEgzs61tv6A for ; Sat, 23 Jun 2012 15:31:36 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 24E2C21F862F for ; Sat, 23 Jun 2012 15:31:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=enkechen@cisco.com; l=52865; q=dns/txt; s=iport; t=1340490696; x=1341700296; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=wynDxbPlHSxpfp4TWeamR44OmTjqVLwnLsuOCSpRKxE=; b=AMk+fZe4pMZhEjFTA4ge2YuE536wIjxBjekakjDkaNLeqp9IbxXbdzYb p1wX9ENnav8g62LfuNFueCTJ/JjYuwYct6BSqogdVL1UbC1zntnXPR1fu 5DCCnkTbygrmQviCexSN8qz4889Z3xbsvwynknxSTSEjfzrIZ+9sVq1DZ I=; X-IronPort-AV: E=Sophos;i="4.77,464,1336348800"; d="scan'208,217";a="46880001" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 23 Jun 2012 22:31:35 +0000 Received: from sjc-vpn7-762.cisco.com (sjc-vpn7-762.cisco.com [10.21.146.250]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q5NMVYqT003622; Sat, 23 Jun 2012 22:31:35 GMT Message-ID: <4FE6441F.2050901@cisco.com> Date: Sat, 23 Jun 2012 15:33:03 -0700 From: Enke Chen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "UTTARO, JAMES" References: <003c01cd4b29$97d7b150$c78713f0$@ndzh.com> <7A614998-8FB1-4A51-9937-DE501FF31EB6@juniper.net> <4FE0D1F4.9070208@cisco.com> <4FE0E074.3070905@raszuk.net> <17490_1340180565_4FE18855_17490_15423_1_53C29892C857584299CBF5D05346208A0928AA@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FE18A61.8000405@raszuk.net> <8ED5B0B0F5B4854A912480C1521F973AD95B@xmb-rcd-x13.cisco.com> <4FE4A8F3.20809@cisco.com> <4FE4AFE2.3030107@cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000800060306000402050008" Cc: 'Shane Amante' , "idr@ietf.org" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jun 2012 22:31:41 -0000 This is a multi-part message in MIME format. --------------000800060306000402050008 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Jim, Let us remain civil in the discussion. If you want to use the word "nonsense", I suggest that you go back to read some of you posts. I have never said that "malform attributes" are rare. Just the contrary, the issue of session reset from malformed attributes has been with us for many years. There have been large outages from time to time. There is a major bug in the base bgp spec in that area, in particular, regarding the handling of optional transitive attribute. That is what the error handling draft is trying to address. -- Enke On 6/23/12 12:45 PM, UTTARO, JAMES wrote: > > Shane, > > First of all if it was as easy as redundant BGP > sessions or as you state later "proper network architecture" we would > not be having this conversation.. Obvious network architecture like > redundant sessions so I can perform maintenance mode is pretty much > the starting point of a robust architecture across AFs/Services and I > would hazard a guess that everyone does this.. Beyond that there are > methods to enhance reliability even further that I have taken ( We > could have a pvt conversation if you would like ). All of this being > said, there are implementation bugs, overloading of BGP machinery > etc.. that have occurred and will occur in the future.. We cannot > simply shrug and say it is not important as it in some folks mind rare > ( not accurate ) or that there is some magical network architecture > that if only everyone would use, this issue could be mitigated. IMO it > is the job of the IETF to address real problems in the real world.. > > Back to this rare nonsense.. Rob Shakir wrote a draft to correct what > I guess is a rare condition having to do with a mal-formed attr. He is > very descriptive in terms f syntactic and semantic bugs. Folks in IDR > including E.Chen is an author of a solutions draft. If this is so rare > why is there a req and solutions draft.. > > We cannot have the argument coming out of both sides of the mouth.. > > Jim Uttaro > > *From:*Shane Amante [mailto:shane@castlepoint.net] > *Sent:* Friday, June 22, 2012 10:00 PM > *To:* UTTARO, JAMES > *Cc:* 'Enke Chen'; idr@ietf.org > *Subject:* Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG > document - 3 more weeks > > On Jun 22, 2012, at 12:03 PM, UTTARO, JAMES wrote: > > > > Enke, > > I think we have got to have a consistent approach to > these solutions.. I am not comfortable with the fact that it is "ok" > for GR but not "ok" for Persistence based on a IMO subjective > interpretation of the amount of time a STALE path is active in local > and adjacent topologies. An hour is a long time, and as GR is used > primarily used n IPV4 which is dynamic it would seem that a) these > paths should be de-pref after some amount of time b) GR should inform > other AS topologies of the staleness by using the STALE CV.. > > I would be interested in hearing from operators as to if this behavior > is understood and if limiting of the time to ~1hr makes the > inconsistency within and across AS domains acceptable.. In your > opinion what is the maximum acceptable amount of time that we could > use Persistence. > > As an operator I believe even 1 hour is too long. In fact, I'd rather > (and, I do) trust Non-Stop Routing (NSR) on PE's in the network, > because I know that CE's will not understand GR capability and will > not be able to benefit from continuing to forward packets even while > the PE is restarting. Granted, this is an environment where there are > many "unmanaged CE's", where I have no control/say over what SW or the > capabilities are on those CE's. > > Furthermore, with control plane redundancy for iBGP sessions from one > PE across multiple RR's serving that cluster, it is possible to > conduct maintenance on one half of the RR-pair serving a cluster while > still preserving control and/or forwarding plane behavior. > > Ultimately, as I've said before, I'd much rather not see any type of > "stale" routes 'sticking around' in the control plane, since that is a > vast change in behavior from today's deployment of BGP where > reachability information is only carried while there are active BGP > sessions. (Yes, I get your point that I don't have to use persistence > if I don't want to, but if developers are in there monkey'ing around > with code to add this feature, inevitably I pay a price in addt'l > complexity for this "feature" even if I don't turn it on, i.e.: there > are potentially 'latent' bugs caused by this "feature", which is not > acceptable). > > As Enke has stated previously, I believe this class of problem is a > rare one, (given a proper network architecture), and thus we should > not be creating AFI-specific solutions that add substantial complexity > to an already complex protocol. > > -shane > > > > Jim Uttaro > > *From:*Enke Chen [mailto:enkechen@cisco.com] > *Sent:*Friday, June 22, 2012 1:48 PM > *To:*UTTARO, JAMES > *Cc:*Saikat Ray (sairay);idr@ietf.org ; Enke Chen > *Subject:*Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG > document - 3 more weeks > > Jim, > > With GR, as you correctly pointed out, a path would not stale for many > hours or days. That is why it may not be as critical to limit the > scope of the stale path. > > If we were to have long-lived stale paths (which I think is a bad > idea), I agree that they should be limited to "consenting adults", and > there must be some mechanisms (such as capability) in place. > > -- Enke > > On 6/22/12 10:27 AM, UTTARO, JAMES wrote: > > Enke, > > The idea behind the setting of STALE is to inform > speakers in other AS domains that the path is suspect as the session > it was learned over is down.. IMO this is required to inform others > about the viability of a path.. > > The other approach is to simply not mark these paths as STALE.. Simply > de-pref in the local AS and business as usual when advertised outside > the AS where all transitive attrs are reset.. > > This is exactly the semantic you are using in the GR draft. You do not > de-pref the state locally and do not inform other AS domains that the > paths learned over the session that GR is active on are suspect. > > If the STALE CV is not honored across the AS border than the behavior > defaults to what is specified in the GR draft. This should meet your > requirements. > > Jim Uttaro > > *From:*idr-bounces@ietf.org > [mailto:idr-bounces@ietf.org]*On Behalf > Of*Enke Chen > *Sent:*Friday, June 22, 2012 1:19 PM > *To:*Saikat Ray (sairay) > *Cc:*idr@ietf.org > *Subject:*Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG > document - 3 more weeks > > Hi, Saikat: > > A new capability would certainly help. It seems necessary, but may > not be sufficient to limit the scope of the STALE path to "consenting > adults". For example, inside a network (i.e., AS), if there are > routers that do not recognize the STALE community, a STALE path may > still be advertised to external peers without the capability. This > means that all the routers in a network must recognize the community > before enabling the capability on any of them. It will be difficult > to satisfy the condition universally. > > In addition, to limit its scope the STALE community, once set, MUST > not be removed by any receiver. > > -- Enke > > On 6/22/12 9:34 AM, Saikat Ray (sairay) wrote: > > Without being involved in the discussion whether it is the right > problem to tackle or not, I would like to make the observation that at > the very least, the draft needs to define a new BGP capability for the > willingness to accept STALE routes. Peers that has not negotiated this > capability MUST receive paths "as if" the STALE paths did not exist. > This includes that STALE paths and any non-STALE paths whose nexthops > resolve over a STALE paths MUST also not be sent to a such a peer. > This way, negotiation of this capability by consenting adults will > define an island where stale routes would roam free without affecting > others. > > *From:*idr-bounces@ietf.org > [mailto:idr-bounces@ietf.org]*On Behalf > Of*Senad .Palislamovic > *Sent:*Friday, June 22, 2012 7:24 AM > *To:*idr@ietf.org > *Cc:*shares@ndzh.com > *Subject:*Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG > document - 3 more weeks > > IETF mail server glitch; resending: Note: Robert already > commented back > > Apologize for the delay on comments, > > Robert, > > After going through all the emails, I admit, you've made a lot of > valuable comments that 'seriously' MUST be considered in the new > version of the draft. However, putting that aside, I would really > expect this to be saved for WG discussions. I would think that at > this stage, we are more less agreeing to take a look at this problem > and its solution space. > > Robert, Randy, Shane, > > The main question I have for you is why object something that might > not even affect you. Draft's primary purpose is for the protection of > the control plane for non-internet services (vpls, l2vpn, or > infrustructure routes, i.e. BGP-3107), which in all cases does not > affect you or me in any shape or form. For folks to chose to extend > this to l3vpn or even to IPv4/IPv6 space, they are doing it > consciously knowing the nature of their network and its dynamics. If > you do see a route with the STALE community, and do not desire to use > this path due its "unreliable" nature, you can request your provider > to withdraw the routes with STALE community effectively making them > DO_NOT_PERSIST at the source which effectively mimics the standard GR > behavior; as Bruno stated, at eBGP, people are talking and negotiating. > > So given all that, help me understand how could this impact anyone who > chooses not to use it. Am I missing anything? > > On the side note, Susan, I do support this draft as WG document. > > Senad > > On Wed, Jun 20, 2012 at 4:31 AM, Robert Raszuk > wrote: > > Yet, IMHO building a good (reliable, performant) BGP > implementation is hard. > > True. And changing it's fundamental behaviour every few months > does not help to make it reliable/ performant either ;) > > I don't think operators would do a better job on the BGP > implementation side. > > I am not asking for that at all. I am asking to simply use > multiple implementations in the backend. Not two .. but 4 or 5. > Probability that all fail/melt with the same bug I think is very > very low. > > Of course I admit that if you one uses service which only single > vendor supports in BGP then one get's a bit stuck with the risk. > And that seems to be one of the silent "problem statement" here. > > Rgs, > > > R. > > _______________________________________________ > 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 > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --------------000800060306000402050008 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Jim,

Let us remain civil in the discussion. If you want to use the word "nonsense", I suggest that you go back to read some of you posts.

I have never said that "malform attributes" are rare.  Just the contrary, the issue of session reset from malformed attributes has been with us for many years.  There have been large outages from time to time.  There is a major bug in the base bgp spec in that area, in particular, regarding the handling of optional transitive attribute.  That is what the error handling draft is trying to address.

-- Enke

On 6/23/12 12:45 PM, UTTARO, JAMES wrote:

Shane,

 

                First of all if it was as easy as redundant BGP sessions or as you state later “proper network architecture” we would not be having this conversation.. Obvious network architecture like redundant sessions so I can perform maintenance mode is pretty much the starting point of a robust architecture across AFs/Services and I would hazard a guess that everyone does this.. Beyond that there are methods to enhance reliability even further that I have taken ( We could have a pvt conversation if you would like ).  All of this being said, there are implementation bugs, overloading of BGP machinery etc.. that have occurred and will occur in the future.. We cannot simply shrug and say it is not important as it in some folks mind rare ( not accurate ) or that there is some magical network architecture that if only everyone would use, this issue could be mitigated. IMO it is the job of the IETF to address real problems in the real world..

 

Back to this rare nonsense.. Rob Shakir wrote a draft to correct what I guess is a rare condition having to do with a mal-formed attr. He is very descriptive in terms f syntactic and semantic bugs. Folks in IDR including E.Chen is an author of a solutions draft. If this is so rare why is there a req and solutions draft..

 

We cannot have the argument coming out of both sides of the mouth..

 

Jim Uttaro

 

From: Shane Amante [mailto:shane@castlepoint.net]
Sent: Friday, June 22, 2012 10:00 PM
To: UTTARO, JAMES
Cc: 'Enke Chen'; idr@ietf.org
Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks

 

 

On Jun 22, 2012, at 12:03 PM, UTTARO, JAMES wrote:



Enke,

 

                I think we have got to have a consistent approach to these solutions.. I am not comfortable with the fact that it is “ok” for GR but not “ok” for Persistence based on a IMO subjective interpretation of the amount of time a STALE path is active in local and adjacent topologies. An hour is a long time, and as GR is used primarily used n IPV4 which is dynamic it would seem that a) these paths should be de-pref after some amount of time b) GR should inform other AS topologies of the staleness by using the STALE CV..

 

I would be interested in hearing from operators as to if this behavior is understood and if limiting of the time to ~1hr makes the inconsistency within and across AS domains acceptable..  In your opinion what is the maximum acceptable amount of time that we could use Persistence. 

 

As an operator I believe even 1 hour is too long.  In fact, I'd rather (and, I do) trust Non-Stop Routing (NSR) on PE's in the network, because I know that CE's will not understand GR capability and will not be able to benefit from continuing to forward packets even while the PE is restarting.  Granted, this is an environment where there are many "unmanaged CE's", where I have no control/say over what SW or the capabilities are on those CE's.

 

Furthermore, with control plane redundancy for iBGP sessions from one PE across multiple RR's serving that cluster, it is possible to conduct maintenance on one half of the RR-pair serving a cluster while still preserving control and/or forwarding plane behavior.

 

Ultimately, as I've said before, I'd much rather not see any type of "stale" routes 'sticking around' in the control plane, since that is a vast change in behavior from today's deployment of BGP where reachability information is only carried while there are active BGP sessions.  (Yes, I get your point that I don't have to use persistence if I don't want to, but if developers are in there monkey'ing around with code to add this feature, inevitably I pay a price in addt'l complexity for this "feature" even if I don't turn it on, i.e.: there are potentially 'latent' bugs caused by this "feature", which is not acceptable).

 

As Enke has stated previously, I believe this class of problem is a rare one, (given a proper network architecture), and thus we should not be creating AFI-specific solutions that add substantial complexity to an already complex protocol. 

 

-shane

 

 



Jim Uttaro

 

 

 

 

From: Enke Chen [mailto:enkechen@cisco.com] 
Sent: Friday, June 22, 2012 1:48 PM
To: UTTARO, JAMES
Cc: Saikat Ray (sairay); idr@ietf.org; Enke Chen
Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks

 

Jim,

With GR, as you correctly pointed out, a path would not stale for many hours or days. That is why it may not be as critical to limit the scope of the stale path.

If we were to have long-lived stale paths (which I think is a bad idea), I agree that they should be limited to "consenting adults", and there must be some mechanisms (such as capability) in place.

-- Enke

On 6/22/12 10:27 AM, UTTARO, JAMES wrote:

Enke,

 

                The idea behind the setting of STALE is to inform speakers in other AS domains that the path is suspect as the session it was learned over is down.. IMO this is required to inform others about the viability of a path..

 

The other approach is to simply not mark these paths as STALE.. Simply de-pref in the local AS and business as usual when advertised outside the AS where all transitive attrs are reset..

 

This is exactly the semantic you are using in the GR draft. You do not de-pref the state locally and do not inform other AS domains that the paths learned over the session that GR is active on are suspect.

 

If the STALE CV is not honored across the AS border than the behavior defaults to what is specified in the GR draft. This should meet your requirements.

 

Jim Uttaro

 

From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Enke Chen
Sent: Friday, June 22, 2012 1:19 PM
To: Saikat Ray (sairay)
Cc: idr@ietf.org
Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks

 

Hi, Saikat:

A new capability would certainly help.  It seems necessary, but may not be sufficient to limit the scope of the STALE path to "consenting adults".   For example, inside a network (i.e., AS), if there are routers that do not recognize the STALE community, a STALE path may still be advertised to external peers without the capability.   This means that all the routers in a network must recognize the community before enabling the capability on any of them.  It will be difficult to satisfy the condition universally.

In addition, to limit its scope the STALE community, once set, MUST not be removed by any receiver.

-- Enke

On 6/22/12 9:34 AM, Saikat Ray (sairay) wrote:

Without being involved in the discussion whether it is the right problem to tackle or not, I would like to make the observation that at the very least, the draft needs to define a new BGP capability for the willingness to accept STALE routes. Peers that has not negotiated this capability MUST receive paths “as if” the STALE paths did not exist. This includes that STALE paths and any non-STALE paths whose nexthops resolve over a STALE paths MUST also not be sent to a such a peer. This way, negotiation of this capability by consenting adults will define an island where stale routes would roam free without affecting others.

 

From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Senad .Palislamovic
Sent: Friday, June 22, 2012 7:24 AM
To: idr@ietf.org
Cc: shares@ndzh.com
Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks

 

IETF mail server glitch;  resending: Note: Robert already commented back

 

Apologize for the delay on comments,

Robert,

After going through all the emails, I admit, you've made a lot of valuable comments that 'seriously' MUST be considered in the new version of the draft.  However, putting that aside, I would really expect this to be saved for WG discussions.  I would think that at this stage, we are more less agreeing to take a look at this problem and its solution space. 

Robert, Randy, Shane,

The main question I have for you is why object something that might not even affect you.  Draft's primary purpose is for the protection of the control plane for non-internet services (vpls, l2vpn, or infrustructure routes, i.e. BGP-3107), which in all cases does not affect you or me in any shape or form.  For folks to chose to extend this to l3vpn or even to IPv4/IPv6 space, they are doing it consciously knowing the nature of their network and its dynamics.  If you do see a route with the STALE community, and do not desire to use this path due its "unreliable" nature, you can request your provider to withdraw the routes with STALE community effectively making them DO_NOT_PERSIST at the source which effectively mimics the standard GR behavior; as Bruno stated, at eBGP, people are talking and negotiating.

So given all that, help me understand how could this impact anyone who chooses not to use it.  Am I missing anything?

On the side note, Susan, I do support this draft as WG document.

 

Senad

 

 

 

 

 

On Wed, Jun 20, 2012 at 4:31 AM, Robert Raszuk <robert@raszuk.net> wrote:

 

Yet, IMHO building a good (reliable, performant) BGP implementation is hard.

 

True. And changing it's fundamental behaviour every few months does not help to make it reliable/ performant either ;)

 

I don't think operators would do a better job on the BGP implementation side.

 

I am not asking for that at all. I am asking to simply use multiple implementations in the backend. Not two .. but 4 or 5. Probability that all fail/melt with the same bug I think is very very low.

Of course I admit that if you one uses service which only single vendor supports in BGP then one get's a bit stuck with the risk. And that seems to be one of the silent "problem statement" here.

Rgs,


R.

_______________________________________________
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

 

 

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr

 


--------------000800060306000402050008-- From robert@raszuk.net Sat Jun 23 15:32:37 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB88521F862F for ; Sat, 23 Jun 2012 15:32:37 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T-gA-nfTTkqp for ; Sat, 23 Jun 2012 15:32:37 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id E11FB21F8615 for ; Sat, 23 Jun 2012 15:32:36 -0700 (PDT) Received: (qmail 4829 invoked by uid 399); 23 Jun 2012 22:32:36 -0000 Received: from unknown (HELO ?192.168.1.58?) (pbs:robert@raszuk.net@178.43.236.71) by mail1310.opentransfer.com with ESMTPM; 23 Jun 2012 22:32:36 -0000 X-Originating-IP: 178.43.236.71 Message-ID: <4FE64404.6070606@raszuk.net> Date: Sun, 24 Jun 2012 00:32:36 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: bruno.decraene@orange.com References: <003c01cd4b29$97d7b150$c78713f0$@ndzh.com> <4FE07A24.7050804@raszuk.net> <1C1F2B2E-2EB7-42F0-8CFF-57965443C074@castlepoint.net> <7A614998-8FB1-4A51-9937-DE501FF31EB6@juniper.net> <4FE0D1F4.9070208@cisco.com> <4FE0E074.3070905@raszuk.net> <17490_1340180565_4FE18855_17490_15423_1_53C29892C857584299CBF5D05346208A0928AA@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FE18A61.8000405@raszuk.net> <8ED5B0B0F5B4854A912480C1521F973AD95B@xmb-rcd-x13.cisco.com> <4FE4A8F3.20809@cisco.com> <25040_1340481129_4FE61E69_25040_15039_1_53C29892C857584299CBF5D05346208A0942C7@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FE62048.3050303@raszuk.net> In-Reply-To: <4FE62048.3050303@raszuk.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jun 2012 22:32:37 -0000 >> Alternatively, the router activating persistence and setting the STALE >> community could also set the NO_EXPORT community. Hence by default the >> STALE route would not be advertised to other ASes. > > That would be terribly broken I am afraid. Dropping the route at PE/ASBR > (what NO_EXPORT does) does not mean generating a withdraw. I'll take it back. In order to verify I have tested this in my lab and no matter what I try the routers/ios version I am using do not let me set NO_EXPORT (or any other community) on the IBGP in or out sessions (PE or RR). If I set it on inbound EBGP sessions (route-map in) it works as it supposed to and withdraw is generated. So after all I am not sure if this is applicable to be used by the persistence as a workaround to limit the advertisement radius of STALE paths. R. From rjs@rob.sh Sat Jun 23 15:39:07 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B08221F862F; Sat, 23 Jun 2012 15:39:07 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZKuut4YW5ycK; Sat, 23 Jun 2012 15:39:06 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2001:b98:201:101::10:cafe]) by ietfa.amsl.com (Postfix) with ESMTP id 94AF721F8615; Sat, 23 Jun 2012 15:39:05 -0700 (PDT) Received: from [93.97.180.64] (helo=lait.config) by cappuccino.rob.sh with esmtpa (Exim 4.72) (envelope-from ) id 1SiYxZ-0003Yh-HM; Sat, 23 Jun 2012 23:37:41 +0100 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Rob Shakir In-Reply-To: Date: Sat, 23 Jun 2012 23:39:03 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <52CBEC1F-49E6-4656-A617-CAB7304479F0@rob.sh> References: To: "UTTARO, JAMES" X-Mailer: Apple Mail (2.1257) Cc: 'idr wg' , "'grow@ietf.org'" Subject: Re: [Idr] draft-ietf-grow-ops-reqs-for-bgp-error-handling-04 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jun 2012 22:39:07 -0000 Hi Jim, Thanks very much for the detailed review of this document. On 22 Jun 2012, at 15:56, UTTARO, JAMES wrote: > Rob, > =20 > Following find my comments.. > =20 > Thanks, > Jim Uttaro > =20 > General Comment, > =20 > =46rom a philosophical perspective I agree with the goals of this = draft but I do not agree with an approach that maintains a session in = the face of a failure in the machinery. This is a bottom up approach = which will always be a day late and a dollar short as we continue to = patch what it means to be a viable session.. I believe the proper = approach to meet your reqs ( and mine too!!! ) is a top down which does = not change the BGP behavior but changes the response to that behavior.. = The reality of today=92s BGP fields of use which are many and varied is = that the control and the forwarding paths are orthogonal, the state = being carried is not always paths as we usually consider them. Examples = include RT-C, Flowspec which are used to create PWs and simulate an IGP = etc=85 I do not believe changing the behavior of BGP session viability = machinery to accomplish maintaining valid forwarding in the face of a = control plane failure is the correct approach > =20 > The draft addresses a very important error condition but ( Update = Error ).. This should be expanded to other areas where the failure of a = session does not indicate that a subset or all of the routing state = learned over said session is invalid.. I think the draft should address = this directly.. Are the changes here configurable? Can I turn this off = if I do not want this behavior for certain topologies, AFs? The scope for this draft was particularly to handle errors that occurred = in the DFZ (and in some private networks) where UPDATE messages with = malformed contents representing a subset of NLRI carried via a session = (1 prefix in numerous cases) resulted in complete failure of these = sessions. Particularly, errors where it was a malformed optional = transitive attribute that was "tunnelled" across multiple speakers who = did not parse it were particularly destructive in the DFZ. Jonathan = Oddy, Andy Davidson and myself spent some effort analysing one of these = incidents back in 2008/2009 -- = http://mailman.nanog.org/pipermail/nanog/2009-January/006816.html.=20 One of the complexities in this problem space is that there are multiple = underlying philosophies as to how such error behaviour should be = handled: 1. Conservative -- any error in messages received from a neighbour are = indicative that it is not a viable route to any prefix it advertises. = Therefore where error conditions occur, disconnect and remove all routes = from the neighbour from the RIB. 2. Balanced risk -- some errors are not indicative of an error on the = remote speaker, or are localised to specific NLRI/prefixes that are = propagated via this speaker. Therefore take a balanced approach of = applying error handling mechanisms to those NLRI, but continue to trust = the integrity of the speaker for the remainder of routing information. Essentially, this draft's scope was to explain the requirements that = exist to manage the risk of taking the latter view. At the moment, there = is a risk to an operator presented by the first (a malformed UPDATE may = break the BGP sessions that run between their PEs and RRs, or those that = propagate their routes to the Internet DFZ, and cause a service outage), = and there is no option to balance the impact of that risk against the = impact of BGP being incorrect for a subset of prefixes propagated via = those sessions. I would expect all solutions implemented in response to these = requirements to be optional. If the risk of incorrectness is = unacceptable to you/an operator, then you should absolutely not enable = any of these mechanisms. In a number of networks that I have operated, = designed and architected, I am prepared to accept the risk of = incorrectness, as I consider it acceptable when compared to the risk of = complete service outages in terms of impact to my customers during such = incidents. At the moment, without the work described through the = requirements outlined in this draft I do not have the means to make that = call... > Abstract > =20 > Can the scope be expanded? There are other failure modes, i.e Timer = Expiry which today is not considered a failure mode. In reality what I = have seen is that timer expiry occurs due to the fact that BGP threads = cannot be serviced in a timely manner. I think it would be best if we = could put it all on the table.. > =20 > I do think that this draft should bound the solution space. At the = minimum the solutions proposed should meet a minimum set of the = operators criteria in terms of managing the network, convergence, = persistence, churn, forwarding impact etc=85 =20 I think there was clear consensus amongst operators with whom I have = spoken to work on the problem space of erroneous UPDATEs - particularly = in response to observed incidents. The very real risk of expanding the = scope of this document even further to handle any error in the BGP = protocol is that we spend another few years cataloguing such conditions, = whilst doing nothing about the ones that we have identified. > Section 1.1 > =20 > The following paragraph is based on the premise that the session being = =93down=94 results in a large impact.. This is certainly true for = today=92s implementations which use the session ( Control Plane = Construct ) to determine the viability of the forwarding state learned = over said session. There are cases where this is the session and = forwarding are parallel, but in many more cases control and forwarding = planes are orthogonal.. I think we need to re-consider this assumption = for many of the services BGP is being used for and base the response to = error conditions on this reality.. > =20 > =93 Both within Internet and multi-service routing architectures, a > number of BGP sessions propagate a large proportion of the required > routing information for network operation. For Internet routing, > these are typically BGP sessions which propagate the global routing > table to an AS - failure of these sessions may have a large impact = on > network service, based on a single erroneous update. In an multi- > service environment, typical deployments utilise a small number of > core-facing BGP sessions, typically towards route reflector = devices. > Failure of these sessions may also result in a large impact to > network operation. Clearly, the avoidance of conditions requiring > these sessions to fail is of great utility to any network operator, > and provides further motivation for the revision of the existing > behaviour. =93 I do not understand what the assertion that you are making here is. = Please could you explain it to me? The errors that are being discussed = relate to where a subset of NLRI are advertised within an erroneous = UPDATE message, and the resulting impact of the current protocol = behaviour on all other NLRI carried on that session. The cases of IP = "transit" sessions, and RR-PE sessions are only examples of cases where = there is a large amount of routing information carried over a single = session - and hence it is of utility to avoid these sessions failing = where they do not necessarily need to based on the impact to overall = network service. This point (to me anyway) seems entirely related to the control-plane -- = it points out that an operator has cases where one really wants to keep = the impact of errors down to the particular subset of routing = information that is affected. This point is entirely in the protocol, = rather than implying any behaviour about forwarding (i.e., no = implication is made that the NLRI identified as carried in the erroneous = UPDATE are installed in the FIB, but rather that all *other* NLRI = continue to be installed in the RIB). I'll work through the points that you have made in this mail -- but I'd = like to respond with a specific point here comparing more targeted = handling of errors in UPDATE messages with persistence-type approaches.=20= - Persistence/hold-up is not acceptable to all operators in all = deployments. Particularly, where no liveliness detection mechanism for = the next-hop is available (i.e., where it is not possible or practical = to determine the NH's reachability in the forwarding plane other than = with with the routing protocol itself) then one would not want to accept = the risk of running persistence. - Therefore, an operator has two options for these deployments -- stick = with the error handling behaviour that is available in BGP right now, = which gives him no flexibility in terms of focusing responses to errors = in a manner that is proportional to the actual error; or alternatively, = accept some additional complexity and risk such that particular error = handling is targeted to the NLRI that are contained in an UPDATE message = that is found to be erroneous. Given there are deployments where I cannot deploy persistence (e.g., = towards an Internet network peer on an IXP where deployment of BFD/OAM = mechanisms are very limited so BGP really tells me whether the other = peer is "there" at all) yet in these cases I do not want to affect all = NLRI when one erroneous UPDATE is received then it would seem that I = need answers to the requirements in this draft.=20 Your e-mail seems to imply that you do not have cases where you will not = be able to deploy persistence and that you are accepting of = session-level error handling in these cases. Would this be a fair = assessment? Kind regards, r. From enkechen@cisco.com Sat Jun 23 15:45:40 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE4B621F8620 for ; Sat, 23 Jun 2012 15:45:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.353 X-Spam-Level: X-Spam-Status: No, score=-10.353 tagged_above=-999 required=5 tests=[AWL=0.246, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qLLEA1v58jSS for ; Sat, 23 Jun 2012 15:45:39 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 09CEF21F861C for ; Sat, 23 Jun 2012 15:45:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=enkechen@cisco.com; l=2655; q=dns/txt; s=iport; t=1340491537; x=1341701137; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=Joegcx9eMHhEmqO9C5vg7gdE+/tvv1p0KKRWEQCH2AU=; b=dX5r0ZALafgKeDWtCRSBXo0YGj6vbEuoZbCvkNRH96I1NBL4WErur5hL WGkuUIjIoz9jnKrh8zuO3v+PC168917U0zYykAtqEs/3lBcIMsZKSp1FJ GconkU7pQl1Ct6OJIaoFuh7ruD0ZZzEofma+yVFPTJCH86nH82qqzPYJo Q=; X-IronPort-AV: E=Sophos;i="4.77,464,1336348800"; d="scan'208";a="46880444" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 23 Jun 2012 22:45:37 +0000 Received: from sjc-vpn7-762.cisco.com (sjc-vpn7-762.cisco.com [10.21.146.250]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q5NMjbY3001398; Sat, 23 Jun 2012 22:45:37 GMT Message-ID: <4FE6476A.3060405@cisco.com> Date: Sat, 23 Jun 2012 15:47:06 -0700 From: Enke Chen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Neil J. McRae" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org" , John Leslie Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jun 2012 22:45:41 -0000 Hi, Neil: Thanks for sharing your thoughts and experiences. That is certainly helpful to the discussion. Over the years I have personally experienced and witnessed a number of major network outages that were bgp related. Most of them, if not all, were caused by malformed updates. That's why the work on error handling started in both IDR and GROW WGs. It will be really valuable if you could share with us whether the revised error handling would address issues that you encountered in your network: http://datatracker.ietf.org/doc/draft-ietf-idr-error-handling/?include_text=1 Regards, -- Enke On 6/23/12 5:44 AM, Neil J. McRae wrote: > John, > Thanks for your feedback but in reality this work around won't help > especially in large VPN networks but even in just plain old internet land > With the probability of this issue occurring is increasing and not > decreasing. > > And btw its not months the industry has been waiting for this to be > resolved. Its more than fifteen years. We need to act to make the control > plane more resilient, I'm not sure if this is the best solution but its > something that is worthy exploration given the catastrophic result of > failure. What I find somewhat incredible is that any vendor that had > survivability of this nature would fly to the top of our selection process! > > When we do so much in other protocols to ensure reliability it seems > incredible that we choose not to here, and as I said, in all cases of this > scenario impacting me, and what leads me to believe is crucially a flaw in > the current protocol, reachability has always been present, which is what > our protocol is all about. > > Regards, > Neil. > > > On 23/06/2012 12:58, "John Leslie" wrote: >> Thank you for this level of detail as your reason to support this as >> a WG draft. It is much more helpful than the too-brief "I support" posts. >> >> Some of us, however, seeing the same problem look to operational fixes, >> not protocol changes. I, for example, like to maintain redundant BGP >> sessions over the same link with one kept particularly simple. This can >> be done in a single day, instead of waiting many months for a standards >> change and more months for equipment to reach the field. It also keeps >> everything under my control, rather than passing the buck to my >> competitors to ensure that stale routes actually get withdrawn. >> >> -- >> John Leslie >> > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From ju1738@att.com Sat Jun 23 19:06:52 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27E3621F8629; Sat, 23 Jun 2012 19:06:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.262 X-Spam-Level: X-Spam-Status: No, score=-106.262 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8tcJn1YHEh7m; Sat, 23 Jun 2012 19:06:48 -0700 (PDT) Received: from nbfkord-smmo04.seg.att.com (nbfkord-smmo04.seg.att.com [209.65.160.86]) by ietfa.amsl.com (Postfix) with ESMTP id 6EAA521F8530; Sat, 23 Jun 2012 19:06:46 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo04.seg.att.com(mxl_mta-6.11.0-10) over TLS secured channel with ESMTP id 53676ef4.0.1804672.00-403.4967013.nbfkord-smmo04.seg.att.com (envelope-from ); Sun, 24 Jun 2012 02:06:46 +0000 (UTC) X-MXL-Hash: 4fe67636001aba5c-89ad0036663afc8958bde267312f1609874262e4 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q5O26jPR023681; Sat, 23 Jun 2012 22:06:45 -0400 Received: from sflint02.pst.cso.att.com (sflint02.pst.cso.att.com [144.154.234.229]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q5O26ZQp023626 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 23 Jun 2012 22:06:40 -0400 Received: from MISOUT7MSGHUB9A.ITServices.sbc.com (misout7msghub9a.itservices.sbc.com [144.151.223.62]) by sflint02.pst.cso.att.com (RSA Interceptor); Sat, 23 Jun 2012 22:06:30 -0400 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9A.ITServices.sbc.com ([144.151.223.62]) with mapi id 14.02.0298.004; Sat, 23 Jun 2012 22:06:29 -0400 From: "UTTARO, JAMES" To: "'Rob Shakir'" Thread-Topic: draft-ietf-grow-ops-reqs-for-bgp-error-handling-04 Thread-Index: Ac1Qh0AwzuLH5xBMSu2rz3aHemLX7wBK0QmAAAIbFGA= Date: Sun, 24 Jun 2012 02:06:29 +0000 Message-ID: References: <52CBEC1F-49E6-4656-A617-CAB7304479F0@rob.sh> In-Reply-To: <52CBEC1F-49E6-4656-A617-CAB7304479F0@rob.sh> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.199.211] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=1.0 c=1 a=Tyf1anlMpZ0A:10 a=81eWbNQ_HDgA:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=ZRNLZ4dFUbCvG8] X-AnalysisOut: [UMqPvVAA==:17 a=48vgC7mUAAAA:8 a=Z_GzSN2XAAAA:8 a=WhWR3eUb] X-AnalysisOut: [6aCqb_apkfMA:9 a=CjuIK1q_8ugA:10 a=RnEgMHWdb3IA:10 a=lZB81] X-AnalysisOut: [5dzVvQA:10 a=YJInicgDRrRRWZgQ:21 a=J7eEVSSeIKoLk4Hk:21] Cc: 'idr wg' , "'grow@ietf.org'" Subject: Re: [Idr] draft-ietf-grow-ops-reqs-for-bgp-error-handling-04 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jun 2012 02:06:52 -0000 Rob, Comments In-Line... Thanks, Jim Uttaro -----Original Message----- From: Rob Shakir [mailto:rjs@rob.sh]=20 Sent: Saturday, June 23, 2012 6:39 PM To: UTTARO, JAMES Cc: 'grow@ietf.org'; 'idr wg' Subject: Re: draft-ietf-grow-ops-reqs-for-bgp-error-handling-04 Hi Jim, Thanks very much for the detailed review of this document. On 22 Jun 2012, at 15:56, UTTARO, JAMES wrote: > Rob, > =20 > Following find my comments.. > =20 > Thanks, > Jim Uttaro > =20 > General Comment, > =20 > From a philosophical perspective I agree with the goals of this draft but= I do not agree with an approach that maintains a session in the face of a = failure in the machinery. This is a bottom up approach which will always be= a day late and a dollar short as we continue to patch what it means to be = a viable session.. I believe the proper approach to meet your reqs ( and mi= ne too!!! ) is a top down which does not change the BGP behavior but change= s the response to that behavior.. The reality of today's BGP fields of use = which are many and varied is that the control and the forwarding paths are = orthogonal, the state being carried is not always paths as we usually consi= der them. Examples include RT-C, Flowspec which are used to create PWs and = simulate an IGP etc... I do not believe changing the behavior of BGP sessio= n viability machinery to accomplish maintaining valid forwarding in the fac= e of a control plane failure is the correct approach > =20 > The draft addresses a very important error condition but ( Update Error )= .. This should be expanded to other areas where the failure of a session do= es not indicate that a subset or all of the routing state learned over said= session is invalid.. I think the draft should address this directly.. Are = the changes here configurable? Can I turn this off if I do not want this be= havior for certain topologies, AFs? The scope for this draft was particularly to handle errors that occurred in= the DFZ (and in some private networks) where UPDATE messages with malforme= d contents representing a subset of NLRI carried via a session (1 prefix in= numerous cases) resulted in complete failure of these sessions. Particular= ly, errors where it was a malformed optional transitive attribute that was = "tunnelled" across multiple speakers who did not parse it were particularly= destructive in the DFZ. Jonathan Oddy, Andy Davidson and myself spent some= effort analysing one of these incidents back in 2008/2009 -- http://mailma= n.nanog.org/pipermail/nanog/2009-January/006816.html.=20 [Jim U>] Got it.. One of the complexities in this problem space is that there are multiple un= derlying philosophies as to how such error behaviour should be handled: 1. Conservative -- any error in messages received from a neighbour are indi= cative that it is not a viable route to any prefix it advertises. Therefore= where error conditions occur, disconnect and remove all routes from the ne= ighbour from the RIB. [Jim U>] This is based on the current behavior of BGP.. If the NH is still = viable you could allow the session to fall and persist the good state that = has already been learned.. 2. Balanced risk -- some errors are not indicative of an error on the remot= e speaker, or are localised to specific NLRI/prefixes that are propagated v= ia this speaker. Therefore take a balanced approach of applying error handl= ing mechanisms to those NLRI, but continue to trust the integrity of the sp= eaker for the remainder of routing information. Essentially, this draft's scope was to explain the requirements that exist = to manage the risk of taking the latter view. At the moment, there is a ris= k to an operator presented by the first (a malformed UPDATE may break the B= GP sessions that run between their PEs and RRs, or those that propagate the= ir routes to the Internet DFZ, and cause a service outage), and there is no= option to balance the impact of that risk against the impact of BGP being = incorrect for a subset of prefixes propagated via those sessions. [Jim U>] Yes I have seen this.. I would expect all solutions implemented in response to these requirements = to be optional. If the risk of incorrectness is unacceptable to you/an oper= ator, then you should absolutely not enable any of these mechanisms. In a n= umber of networks that I have operated, designed and architected, I am prep= ared to accept the risk of incorrectness, as I consider it acceptable when = compared to the risk of complete service outages in terms of impact to my c= ustomers during such incidents. At the moment, without the work described t= hrough the requirements outlined in this draft I do not have the means to m= ake that call... [Jim U>] I do not understand how it is possible to make this configurable o= n a per session or AS basis..I would think all speakers participating in a = routing context would have to adhere to the same rules for a consistent vie= w across domains.. In my reading of the IDR draft it seems that it would be= a MUST.. Maybe I should not be considering that IDR draft as the actual re= alization of the reqs.. > Abstract > =20 > Can the scope be expanded? There are other failure modes, i.e Timer Expir= y which today is not considered a failure mode. In reality what I have seen= is that timer expiry occurs due to the fact that BGP threads cannot be ser= viced in a timely manner. I think it would be best if we could put it all = on the table.. > =20 > I do think that this draft should bound the solution space. At the minimu= m the solutions proposed should meet a minimum set of the operators criteri= a in terms of managing the network, convergence, persistence, churn, forwar= ding impact etc... =20 I think there was clear consensus amongst operators with whom I have spoken= to work on the problem space of erroneous UPDATEs - particularly in respon= se to observed incidents. The very real risk of expanding the scope of this= document even further to handle any error in the BGP protocol is that we s= pend another few years cataloguing such conditions, whilst doing nothing ab= out the ones that we have identified. [Jim U>] No doubt.. But I have seen other errors that relate to overloadin= g BGP, topological isolation etc... that have created huge outages in my ne= twork.. So, My thinking is that we should try to consider all of the challe= nges the protocol faces in terms of erroneous error conditions.=20 > Section 1.1 > =20 > The following paragraph is based on the premise that the session being "d= own" results in a large impact.. This is certainly true for today's impleme= ntations which use the session ( Control Plane Construct ) to determine the= viability of the forwarding state learned over said session. There are cas= es where this is the session and forwarding are parallel, but in many more = cases control and forwarding planes are orthogonal.. I think we need to re-= consider this assumption for many of the services BGP is being used for and= base the response to error conditions on this reality.. > =20 > " Both within Internet and multi-service routing architectures, a > number of BGP sessions propagate a large proportion of the required > routing information for network operation. For Internet routing, > these are typically BGP sessions which propagate the global routing > table to an AS - failure of these sessions may have a large impact on > network service, based on a single erroneous update. In an multi- > service environment, typical deployments utilise a small number of > core-facing BGP sessions, typically towards route reflector devices. > Failure of these sessions may also result in a large impact to > network operation. Clearly, the avoidance of conditions requiring > these sessions to fail is of great utility to any network operator, > and provides further motivation for the revision of the existing > behaviour. " I do not understand what the assertion that you are making here is. Please = could you explain it to me? The errors that are being discussed relate to w= here a subset of NLRI are advertised within an erroneous UPDATE message, an= d the resulting impact of the current protocol behaviour on all other NLRI = carried on that session. The cases of IP "transit" sessions, and RR-PE sess= ions are only examples of cases where there is a large amount of routing in= formation carried over a single session - and hence it is of utility to avo= id these sessions failing where they do not necessarily need to based on th= e impact to overall network service. [Jim U>] The solution space here seems explicitly targeted to the internet = IPV4 AF. Not sure if there is a dependency here on the control/forwarding p= lanes being in parallel. I believe we need to consider all AFs that BGP is = used for.. As the code that would be developed would be applicable to these= AF also ( I presume ). So as an example would be RT-C, is this solution ap= plicable I don't know I am simply asking.. If we want to develop this and h= ave it specific to the internet use case lets state that clearly. If not, t= hen let's consider the other applications BGP supports.. This point (to me anyway) seems entirely related to the control-plane -- it= points out that an operator has cases where one really wants to keep the i= mpact of errors down to the particular subset of routing information that i= s affected. This point is entirely in the protocol, rather than implying an= y behaviour about forwarding (i.e., no implication is made that the NLRI id= entified as carried in the erroneous UPDATE are installed in the FIB, but r= ather that all *other* NLRI continue to be installed in the RIB). [Jim U>] See above.. My point is how can we ensure reliability across AFs..= .There is no doubt that mal-formed updates are an issue I just do not know = how they affect other AFs, in those case it may be more appropriate to tear= down and persist instead. Can we address these other use cases? I'll work through the points that you have made in this mail -- but I'd lik= e to respond with a specific point here comparing more targeted handling of= errors in UPDATE messages with persistence-type approaches.=20 - Persistence/hold-up is not acceptable to all operators in all deployments= . Particularly, where no liveliness detection mechanism for the next-hop is= available (i.e., where it is not possible or practical to determine the NH= 's reachability in the forwarding plane other than with with the routing pr= otocol itself) then one would not want to accept the risk of running persis= tence. [Jim U>] Agreed.. Persistence requires that the NH be viable.=20 - Therefore, an operator has two options for these deployments -- stick wit= h the error handling behaviour that is available in BGP right now, which gi= ves him no flexibility in terms of focusing responses to errors in a manner= that is proportional to the actual error; or alternatively, accept some ad= ditional complexity and risk such that particular error handling is targete= d to the NLRI that are contained in an UPDATE message that is found to be e= rroneous. [Jim U>] My concern here is that the entire support structure is based on s= ession viability, the expectation here is that operators need to develop ne= w approaches to understanding if there is a routing anomaly in their topolo= gy and develop tools/procedures which are different. Given there are deployments where I cannot deploy persistence (e.g., toward= s an Internet network peer on an IXP where deployment of BFD/OAM mechanisms= are very limited so BGP really tells me whether the other peer is "there" = at all) yet in these cases I do not want to affect all NLRI when one errone= ous UPDATE is received then it would seem that I need answers to the requir= ements in this draft.=20 [Jim U>] Agreed..=20 Your e-mail seems to imply that you do not have cases where you will not be= able to deploy persistence and that you are accepting of session-level err= or handling in these cases. Would this be a fair assessment? [Jim U>] My work primarily revolves around the following BGP use cases VPN = ( L2/L3 ), 3107, Multi-Cast, RT-C, Flowspec not Internet.. In these environ= ments I would prefer that the session fail, persistence is activated, and w= ell known procedures are used to correct the problem. I am in no way saying= that the use case described here for the internet application is not viabl= e or the correct approach.. But the fact remains that the code base will be= used across all AFs and this solution requires different OpS/Troubleshooti= ng knowledge and support. I would prefer consistency in the behavior..=20 Kind regards, r. From ju1738@att.com Sat Jun 23 19:30:57 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EC2621F8682 for ; Sat, 23 Jun 2012 19:30:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.482 X-Spam-Level: X-Spam-Status: No, score=-105.482 tagged_above=-999 required=5 tests=[AWL=-0.684, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_41=0.6, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ubWNkv9YjMJs for ; Sat, 23 Jun 2012 19:30:49 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id 7830721F866E for ; Sat, 23 Jun 2012 19:30:47 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO nbfkord-smmo06.seg.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.11.0-10) with ESMTP id 7db76ef4.2aaaf003f940.1806510.00-591.4975745.nbfkord-smmo06.seg.att.com (envelope-from ); Sun, 24 Jun 2012 02:30:47 +0000 (UTC) X-MXL-Hash: 4fe67bd74e11e85b-1bbb389496777d3b29d3a69f1d0025b3373e2bba Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.11.0-10) over TLS secured channel with ESMTP id 4bb76ef4.0.1806427.00-469.4975516.nbfkord-smmo06.seg.att.com (envelope-from ); Sun, 24 Jun 2012 02:30:29 +0000 (UTC) X-MXL-Hash: 4fe67bc5270094c2-13821291873dfd0c75c440517e85c1de2082c35a Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q5O2UCgC029070; Sat, 23 Jun 2012 22:30:12 -0400 Received: from sflint01.pst.cso.att.com (sflint01.pst.cso.att.com [144.154.234.228]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q5O2U8Fn029027 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 23 Jun 2012 22:30:08 -0400 Received: from MISOUT7MSGHUB9E.ITServices.sbc.com (misout7msghub9e.itservices.sbc.com [144.151.223.61]) by sflint01.pst.cso.att.com (RSA Interceptor); Sat, 23 Jun 2012 22:30:00 -0400 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9E.ITServices.sbc.com ([144.151.223.61]) with mapi id 14.02.0298.004; Sat, 23 Jun 2012 22:30:00 -0400 From: "UTTARO, JAMES" To: "'Enke Chen'" Thread-Topic: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks Thread-Index: AQHNUIKv4gES0WzL/kWO4I5ojxcnRZcGy9WAgAAMWYD//70toIAASxcA//+9G7CAAMwtgIAA4i1AgAB2b4D///itMA== Date: Sun, 24 Jun 2012 02:29:59 +0000 Message-ID: References: <003c01cd4b29$97d7b150$c78713f0$@ndzh.com> <7A614998-8FB1-4A51-9937-DE501FF31EB6@juniper.net> <4FE0D1F4.9070208@cisco.com> <4FE0E074.3070905@raszuk.net> <17490_1340180565_4FE18855_17490_15423_1_53C29892C857584299CBF5D05346208A0928AA@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FE18A61.8000405@raszuk.net> <8ED5B0B0F5B4854A912480C1521F973AD95B@xmb-rcd-x13.cisco.com> <4FE4A8F3.20809@cisco.com> <4FE4AFE2.3030107@cisco.com> <4FE6441F.2050901@cisco.com> In-Reply-To: <4FE6441F.2050901@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.199.211] Content-Type: multipart/alternative; boundary="_000_B17A6910EEDD1F45980687268941550FB20F9FMISOUT7MSGUSR9IIT_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=1.0 c=1 a=Tyf1anlMpZ0A:10 a=ZQD3OTTxKqYA:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a=AU] X-AnalysisOut: [d_NHdVAAAA:8 a=48vgC7mUAAAA:8 a=XKfbYx4oAAAA:8 a=1sjgXBK7A] X-AnalysisOut: [AAA:8 a=2clOPd4PAAAA:8 a=qikXmGUNyTq-hkjAsPEA:9 a=CjuIK1q_] X-AnalysisOut: [8ugA:10 a=JfD0Fch1gWkA:10 a=lZB815dzVvQA:10 a=uI1Or78iWTcA] X-AnalysisOut: [:10 a=kZwP4KTQBigA:10 a=bDUki_mJ7DgA:10 a=SE5-PmYRSky3KYSY] X-AnalysisOut: [:21 a=daKFzoYsnlFw-P6e:21 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:] X-AnalysisOut: [8 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=] X-AnalysisOut: [tXsnliwV7b4A:10 a=6yl_Qpqrcc7NTZwv:21 a=7xaxmBW8FQg6f2rj:2] X-AnalysisOut: [1] Cc: 'Shane Amante' , "idr@ietf.org" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jun 2012 02:30:57 -0000 --_000_B17A6910EEDD1F45980687268941550FB20F9FMISOUT7MSGUSR9IIT_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Enke, I agree lets be civil.. So civility starts with the following: I say I have a real problem and you do not dismiss it as a rare occurrence = and therefore not warranting WG adoption for the problem to be worked on.. = Do you think I am lying or lack the ability to count the number of times it= has happened and how many major/catastrophic outages it has caused.. It is= not appropriate to discuss the outages in this venue or their cause.. I say I have a real problem and it is not dismissed as Jim Uttaro does not = know how to properly architect his network for robustness, reliability, and= survivability. Gee If he could just figure that out ( It is obvious ) ther= e would be no problem. You address the very real fact that a solution GR has been adopted and code= d that has exactly the behavior your are stating is not acceptable for the = Persistence draft which BTW has the STALE CV to address this exact deficien= cy of not informing topologies of STALE paths which is the current behavior= of GR. Stating that it is an hour, therefore OK does not cut it.. Folks acknowledge that BGP is being used for other services and they merit = the same attention as the traditional internet application.. To this point = it seems that IDR may be the wrong place for this draft and it may be more = appropriate in L3VPN, L2VPN. Maybe we should consider that other AFs i.e RT= -C, or other apps flowspec etc...should be moved into L3VPN as it is probab= ly a more appropriate place.. I do want to address the Update Error condition(s).. As I responded to Rob,= I think we need an accounting of how this behavior when coded would or wou= ld not be applicable to other AFs. I would prefer a consistent BGP code bas= e across all AFs. We have to be careful that we do not have so many respon= ses to error conditions. It is difficult enough to train Ops/Support staff,= develop tools across AFs/Service and get features consistently developed.. Jim Uttaro From: Enke Chen [mailto:enkechen@cisco.com] Sent: Saturday, June 23, 2012 6:33 PM To: UTTARO, JAMES Cc: 'Shane Amante'; idr@ietf.org; Enke Chen Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document -= 3 more weeks Jim, Let us remain civil in the discussion. If you want to use the word "nonsens= e", I suggest that you go back to read some of you posts. I have never said that "malform attributes" are rare. Just the contrary, t= he issue of session reset from malformed attributes has been with us for ma= ny years. There have been large outages from time to time. There is a maj= or bug in the base bgp spec in that area, in particular, regarding the hand= ling of optional transitive attribute. That is what the error handling dra= ft is trying to address. -- Enke On 6/23/12 12:45 PM, UTTARO, JAMES wrote: Shane, First of all if it was as easy as redundant BGP sessions or= as you state later "proper network architecture" we would not be having th= is conversation.. Obvious network architecture like redundant sessions so I= can perform maintenance mode is pretty much the starting point of a robust= architecture across AFs/Services and I would hazard a guess that everyone = does this.. Beyond that there are methods to enhance reliability even furth= er that I have taken ( We could have a pvt conversation if you would like )= . All of this being said, there are implementation bugs, overloading of BG= P machinery etc.. that have occurred and will occur in the future.. We cann= ot simply shrug and say it is not important as it in some folks mind rare (= not accurate ) or that there is some magical network architecture that if = only everyone would use, this issue could be mitigated. IMO it is the job o= f the IETF to address real problems in the real world.. Back to this rare nonsense.. Rob Shakir wrote a draft to correct what I gue= ss is a rare condition having to do with a mal-formed attr. He is very desc= riptive in terms f syntactic and semantic bugs. Folks in IDR including E.Ch= en is an author of a solutions draft. If this is so rare why is there a req= and solutions draft.. We cannot have the argument coming out of both sides of the mouth.. Jim Uttaro From: Shane Amante [mailto:shane@castlepoint.net] Sent: Friday, June 22, 2012 10:00 PM To: UTTARO, JAMES Cc: 'Enke Chen'; idr@ietf.org Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document -= 3 more weeks On Jun 22, 2012, at 12:03 PM, UTTARO, JAMES wrote: Enke, I think we have got to have a consistent approach to these = solutions.. I am not comfortable with the fact that it is "ok" for GR but n= ot "ok" for Persistence based on a IMO subjective interpretation of the amo= unt of time a STALE path is active in local and adjacent topologies. An hou= r is a long time, and as GR is used primarily used n IPV4 which is dynamic = it would seem that a) these paths should be de-pref after some amount of ti= me b) GR should inform other AS topologies of the staleness by using the ST= ALE CV.. I would be interested in hearing from operators as to if this behavior is u= nderstood and if limiting of the time to ~1hr makes the inconsistency withi= n and across AS domains acceptable.. In your opinion what is the maximum a= cceptable amount of time that we could use Persistence. As an operator I believe even 1 hour is too long. In fact, I'd rather (and= , I do) trust Non-Stop Routing (NSR) on PE's in the network, because I know= that CE's will not understand GR capability and will not be able to benefi= t from continuing to forward packets even while the PE is restarting. Gran= ted, this is an environment where there are many "unmanaged CE's", where I = have no control/say over what SW or the capabilities are on those CE's. Furthermore, with control plane redundancy for iBGP sessions from one PE ac= ross multiple RR's serving that cluster, it is possible to conduct maintena= nce on one half of the RR-pair serving a cluster while still preserving con= trol and/or forwarding plane behavior. Ultimately, as I've said before, I'd much rather not see any type of "stale= " routes 'sticking around' in the control plane, since that is a vast chang= e in behavior from today's deployment of BGP where reachability information= is only carried while there are active BGP sessions. (Yes, I get your poi= nt that I don't have to use persistence if I don't want to, but if develope= rs are in there monkey'ing around with code to add this feature, inevitably= I pay a price in addt'l complexity for this "feature" even if I don't turn= it on, i.e.: there are potentially 'latent' bugs caused by this "feature",= which is not acceptable). As Enke has stated previously, I believe this class of problem is a rare on= e, (given a proper network architecture), and thus we should not be creatin= g AFI-specific solutions that add substantial complexity to an already comp= lex protocol. -shane Jim Uttaro From: Enke Chen [mailto:enkechen@cisco.com] Sent: Friday, June 22, 2012 1:48 PM To: UTTARO, JAMES Cc: Saikat Ray (sairay); idr@ietf.org; Enke Chen Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document -= 3 more weeks Jim, With GR, as you correctly pointed out, a path would not stale for many hour= s or days. That is why it may not be as critical to limit the scope of the = stale path. If we were to have long-lived stale paths (which I think is a bad idea), I = agree that they should be limited to "consenting adults", and there must be= some mechanisms (such as capability) in place. -- Enke On 6/22/12 10:27 AM, UTTARO, JAMES wrote: Enke, The idea behind the setting of STALE is to inform speakers = in other AS domains that the path is suspect as the session it was learned = over is down.. IMO this is required to inform others about the viability of= a path.. The other approach is to simply not mark these paths as STALE.. Simply de-p= ref in the local AS and business as usual when advertised outside the AS wh= ere all transitive attrs are reset.. This is exactly the semantic you are using in the GR draft. You do not de-p= ref the state locally and do not inform other AS domains that the paths lea= rned over the session that GR is active on are suspect. If the STALE CV is not honored across the AS border than the behavior defau= lts to what is specified in the GR draft. This should meet your requirement= s. Jim Uttaro From: idr-bounces@ietf.org [mailto:idr-bounces= @ietf.org] On Behalf Of Enke Chen Sent: Friday, June 22, 2012 1:19 PM To: Saikat Ray (sairay) Cc: idr@ietf.org Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document -= 3 more weeks Hi, Saikat: A new capability would certainly help. It seems necessary, but may not be = sufficient to limit the scope of the STALE path to "consenting adults". F= or example, inside a network (i.e., AS), if there are routers that do not r= ecognize the STALE community, a STALE path may still be advertised to exter= nal peers without the capability. This means that all the routers in a ne= twork must recognize the community before enabling the capability on any of= them. It will be difficult to satisfy the condition universally. In addition, to limit its scope the STALE community, once set, MUST not be = removed by any receiver. -- Enke On 6/22/12 9:34 AM, Saikat Ray (sairay) wrote: Without being involved in the discussion whether it is the right problem to= tackle or not, I would like to make the observation that at the very least= , the draft needs to define a new BGP capability for the willingness to acc= ept STALE routes. Peers that has not negotiated this capability MUST receiv= e paths "as if" the STALE paths did not exist. This includes that STALE pat= hs and any non-STALE paths whose nexthops resolve over a STALE paths MUST a= lso not be sent to a such a peer. This way, negotiation of this capability = by consenting adults will define an island where stale routes would roam fr= ee without affecting others. From: idr-bounces@ietf.org [mailto:idr-bounces= @ietf.org] On Behalf Of Senad .Palislamovic Sent: Friday, June 22, 2012 7:24 AM To: idr@ietf.org Cc: shares@ndzh.com Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document -= 3 more weeks IETF mail server glitch; resending: Note: Robert already commented back Apologize for the delay on comments, Robert, After going through all the emails, I admit, you've made a lot of valuable = comments that 'seriously' MUST be considered in the new version of the draf= t. However, putting that aside, I would really expect this to be saved for= WG discussions. I would think that at this stage, we are more less agreei= ng to take a look at this problem and its solution space. Robert, Randy, Shane, The main question I have for you is why object something that might not eve= n affect you. Draft's primary purpose is for the protection of the control= plane for non-internet services (vpls, l2vpn, or infrustructure routes, i.= e. BGP-3107), which in all cases does not affect you or me in any shape or = form. For folks to chose to extend this to l3vpn or even to IPv4/IPv6 spac= e, they are doing it consciously knowing the nature of their network and it= s dynamics. If you do see a route with the STALE community, and do not des= ire to use this path due its "unreliable" nature, you can request your prov= ider to withdraw the routes with STALE community effectively making them DO= _NOT_PERSIST at the source which effectively mimics the standard GR behavio= r; as Bruno stated, at eBGP, people are talking and negotiating. So given all that, help me understand how could this impact anyone who choo= ses not to use it. Am I missing anything? On the side note, Susan, I do support this draft as WG document. Senad On Wed, Jun 20, 2012 at 4:31 AM, Robert Raszuk > wrote: Yet, IMHO building a good (reliable, performant) BGP implementation is hard= . True. And changing it's fundamental behaviour every few months does not hel= p to make it reliable/ performant either ;) I don't think operators would do a better job on the BGP implementation sid= e. I am not asking for that at all. I am asking to simply use multiple impleme= ntations in the backend. Not two .. but 4 or 5. Probability that all fail/m= elt with the same bug I think is very very low. Of course I admit that if you one uses service which only single vendor sup= ports in BGP then one get's a bit stuck with the risk. And that seems to be= one of the silent "problem statement" here. Rgs, R. _______________________________________________ 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 _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr --_000_B17A6910EEDD1F45980687268941550FB20F9FMISOUT7MSGUSR9IIT_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Enke,

 <= /p>

    &= nbsp;           I agree l= ets be civil..

 <= /p>

So civility starts with t= he following:  

 <= /p>

I say I have a real probl= em and you do not dismiss it as a rare occurrence and therefore not warrant= ing WG adoption for the problem to be worked on.. Do you think I am lying or lack the ability to count the number of times it has h= appened and how many major/catastrophic outages it has caused.. It is not a= ppropriate to discuss the outages in this venue or their cause..=

 <= /p>

I say I have a real probl= em and it is not dismissed as Jim Uttaro does not know how to properly arch= itect his network for robustness, reliability, and survivability. Gee If he could just figure that out ( It is obvious ) there would be no p= roblem.

 <= /p>

You address the very real= fact that a solution GR has been adopted and coded that has exactly the be= havior your are stating is not acceptable for the Persistence draft which BTW has the STALE CV to address this exact deficiency of not i= nforming topologies of STALE paths which is the current behavior of GR. Sta= ting that it is an hour, therefore OK does not cut it..

 <= /p>

Folks acknowledge that BG= P is being used for other services and they merit the same attention as the= traditional internet application.. To this point it seems that IDR may be the wrong place for this draft and it may be more appropri= ate in L3VPN, L2VPN. Maybe we should consider that other AFs i.e RT-C, or o= ther apps flowspec etc…should be moved into L3VPN as it is probably a= more appropriate place..

 <= /p>

I do want to address the = Update Error condition(s).. As I responded to Rob, I think we need an accou= nting of how this behavior when coded would or would not be applicable to other AFs. I would prefer a consistent BGP code base acro= ss all AFs.  We have to be careful that we do not have so many respons= es to error conditions. It is difficult enough to train Ops/Support staff, = develop tools across AFs/Service and get features consistently developed..

 <= /p>

Jim Uttaro

 <= /p>

From: Enke Chen [mailto:enkechen@cisco.com]
Sent: Saturday, June 23, 2012 6:33 PM
To: UTTARO, JAMES
Cc: 'Shane Amante'; idr@ietf.org; Enke Chen
Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG doc= ument - 3 more weeks

 

Jim,

Let us remain civil in the discussion. If you want to use the word "no= nsense", I suggest that you go back to read some of you posts.

I have never said that "malform attributes" are rare.  Just = the contrary, the issue of session reset from malformed attributes has been= with us for many years.  There have been large outages from time to t= ime.  There is a major bug in the base bgp spec in that area, in particular, regarding the handling of optional transitive attribu= te.  That is what the error handling draft is trying to address.

-- Enke

On 6/23/12 12:45 PM, UTTARO, JAMES wrote:

Shane,<= /p>

 <= /p>

    &= nbsp;           First of = all if it was as easy as redundant BGP sessions or as you state later ̶= 0;proper network architecture” we would not be having this conversati= on.. Obvious network architecture like redundant sessions so I can perform main= tenance mode is pretty much the starting point of a robust architecture acr= oss AFs/Services and I would hazard a guess that everyone does this.. Beyon= d that there are methods to enhance reliability even further that I have taken ( We could have a pvt conversat= ion if you would like ).  All of this being said, there are implementa= tion bugs, overloading of BGP machinery etc.. that have occurred and will o= ccur in the future.. We cannot simply shrug and say it is not important as it in some folks mind rare ( not accu= rate ) or that there is some magical network architecture that if only ever= yone would use, this issue could be mitigated. IMO it is the job of the IET= F to address real problems in the real world..

 <= /p>

Back to this rare nonsens= e.. Rob Shakir wrote a draft to correct what I guess is a rare condition ha= ving to do with a mal-formed attr. He is very descriptive in terms f syntactic and semantic bugs. Folks in IDR including E.Chen is a= n author of a solutions draft. If this is so rare why is there a req and so= lutions draft..

 <= /p>

We cannot have the argume= nt coming out of both sides of the mouth..

 <= /p>

Jim Uttaro

 <= /p>

From: Shane Am= ante [mailto:shane@castlepoint.net= ]
Sent: Friday, June 22, 2012 10:00 PM
To: UTTARO, JAMES
Cc: 'Enke Chen'; idr@ietf.org Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG doc= ument - 3 more weeks

 

 

On Jun 22, 2012, at 12:03 PM, UTTARO, JAMES wrote:




Enke,

 <= /p>

    &= nbsp;           I think w= e have got to have a consistent approach to these solutions.. I am not comf= ortable with the fact that it is “ok” for GR but not “ok&= #8221; for Persistence based on a IMO subjective interpretation of the amount of = time a STALE path is active in local and adjacent topologies. An hour is a = long time, and as GR is used primarily used n IPV4 which is dynamic it woul= d seem that a) these paths should be de-pref after some amount of time b) GR should inform other AS topologi= es of the staleness by using the STALE CV..

 <= /p>

I would be interested in = hearing from operators as to if this behavior is understood and if limiting= of the time to ~1hr makes the inconsistency within and across AS domains acceptable..  In your opinion what is the maximum a= cceptable amount of time that we could use Persistence. 

 

As an operator I believe even 1 hour is too long. &n= bsp;In fact, I'd rather (and, I do) trust Non-Stop Routing (NSR) on PE's in= the network, because I know that CE's will not understand GR capability an= d will not be able to benefit from continuing to forward packets even while the PE is restarting.  Granted, this is= an environment where there are many "unmanaged CE's", where I ha= ve no control/say over what SW or the capabilities are on those CE's.<= /o:p>

 

Furthermore, with control plane redundancy for iBGP = sessions from one PE across multiple RR's serving that cluster, it is possi= ble to conduct maintenance on one half of the RR-pair serving a cluster whi= le still preserving control and/or forwarding plane behavior.

 

Ultimately, as I've said before, I'd much rather not= see any type of "stale" routes 'sticking around' in the control = plane, since that is a vast change in behavior from today's deployment of B= GP where reachability information is only carried while there are active BGP sessions.  (Yes, I get your point that I d= on't have to use persistence if I don't want to, but if developers are in t= here monkey'ing around with code to add this feature, inevitably I pay a pr= ice in addt'l complexity for this "feature" even if I don't turn it on, i.e.: there are potentially 'latent' bugs caus= ed by this "feature", which is not acceptable).

 

As Enke has stated previously, I believe this class = of problem is a rare one, (given a proper network architecture), and thus w= e should not be creating AFI-specific solutions that add substantial comple= xity to an already complex protocol. 

 

-shane

 

 




Jim Uttaro

 <= /p>

 <= /p>

 <= /p>

 <= /p>

From: Enke Chen [mailto:enkechen@cisco.com]=  
Sent: Friday, June= 22, 2012 1:48 PM
To: UTTARO, JAMES<= br> Cc: Saikat Ray (sa= iray); idr@ietf.org; Enke Chen
Subject: Re: [Idr]= draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks

 

Jim,

With GR, as you correctly pointed out, a path would not stale for many hour= s or days. That is why it may not be as critical to limit the scope of the = stale path.

If we were to have long-lived stale paths (which I think is a bad idea), I = agree that they should be limited to "consenting adults", and the= re must be some mechanisms (such as capability) in place.

-- Enke

On 6/22/12 10:27 AM, UTTARO, JAMES wrote:

Enke,

 <= /p>

    &= nbsp;           The idea = behind the setting of STALE is to inform speakers in other AS domains that = the path is suspect as the session it was learned over is down.. IMO this is required to inform others about the viability of a path= ..

 <= /p>

The other approach is to = simply not mark these paths as STALE.. Simply de-pref in the local AS and b= usiness as usual when advertised outside the AS where all transitive attrs are reset..

 <= /p>

This is exactly the seman= tic you are using in the GR draft. You do not de-pref the state locally and= do not inform other AS domains that the paths learned over the session that GR is active on are suspect.

 <= /p>

If the STALE CV is not ho= nored across the AS border than the behavior defaults to what is specified = in the GR draft. This should meet your requirements.

 <= /p>

Jim Uttaro

 <= /p>

From: idr-bounces@ietf.org [mailto:i= dr-bounces@ietf.org] = On Behalf Of Enke Chen<= br> Sent: Friday, June= 22, 2012 1:19 PM
To: Saikat Ray (sa= iray)
Cc: idr@ietf.org
Subject: Re: [Idr]= draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks

 

Hi, Saikat:

A new capability would certainly help.  It seems necessary, but may no= t be sufficient to limit the scope of the STALE path to "consenting ad= ults".   For example, inside a network (i.e., AS), if there = are routers that do not recognize the STALE community, a STALE path may still be advertised to external peers without the capabilit= y.   This means that all the routers in a network must recognize = the community before enabling the capability on any of them.  It will = be difficult to satisfy the condition universally.

In addition, to limit its scope the STALE community, once set, MUST not be = removed by any receiver.

-- Enke

On 6/22/12 9:34 AM, Saikat Ray (sairay) wrote:

Without being involved in= the discussion whether it is the right problem to tackle or not, I would l= ike to make the observation that at the very least, the draft needs to define a new BGP capability for the willingness to accept S= TALE routes. Peers that has not negotiated this capability MUST receive pat= hs “as if” the STALE paths did not exist. This includes that ST= ALE paths and any non-STALE paths whose nexthops resolve over a STALE paths MUST also not be sent to a such a peer. This wa= y, negotiation of this capability by consenting adults will define an islan= d where stale routes would roam free without affecting others.<= /o:p>

 <= /p>

From: idr-bounces@ietf.org [mailto:i= dr-bounces@ietf.org] = On Behalf Of Senad .Pal= islamovic
Sent: Friday, June= 22, 2012 7:24 AM
To: idr@ietf.org
Cc: shares@ndzh.com
Subject: Re: [Idr]= draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks

 

IETF mail server glitch;  resending: Note: Robert= already commented back

 

Apologize for the delay on comments,

Robert,

After going through all the emails, I admit, you've made a = lot of valuable comments that 'seriously' MUST be considered in the new ver= sion of the draft.  However, putting that aside, I would really expect= this to be saved for WG discussions.  I would think that at this stage, we are more less agreeing to take a look= at this problem and its solution space. 

Robert, Randy, Shane,

The main question I have for you is why object something th= at might not even affect you.  Draft's primary purpose is for the= protection of the control plane for non-internet services (vpls, l2vpn, or= infrustructure routes, i.e. BGP-3107), which in all cases does not affect you or me in any shape or form.  For fol= ks to chose to extend this to l3vpn or even to IPv4/IPv6 space, they are do= ing it consciously knowing the nature of their network and its dynamics.&nb= sp; If you do see a route with the STALE community, and do not desire to use this path due its "unreliable" nature, = you can request your provider to withdraw the routes with STALE community e= ffectively making them DO_NOT_PERSIST at the source which effectively mimic= s the standard GR behavior; as Bruno stated, at eBGP, people are talking and negotiating.

So given all that, help me understand how could this impact= anyone who chooses not to use it.  Am I missing anything?<= /p>

On the side note, Susan, I do support this draft as WG docu= ment.

 

Senad

 

 

 

 

 

On Wed, Jun 20, 2012 at 4:31 AM, Robert Raszuk <<= a href=3D"mailto:robert@raszuk.net" target=3D"_blank">robert@raszuk.net= > wrote:

 

Yet, IMHO building a good (reliable, performant) BGP= implementation is hard.

 

True. And changing it's fundamental behaviour every = few months does not help to make it reliable/ performant either ;)

 

I don't think operators would do a better job on the= BGP implementation side.

 

I am not asking for that at all. I am asking to simp= ly use multiple implementations in the backend. Not two .. but 4 or 5. Prob= ability that all fail/melt with the same bug I think is very very low.

Of course I admit that if you one uses service which only single vendor sup= ports in BGP then one get's a bit stuck with the risk. And that seems to be= one of the silent "problem statement" here.

Rgs,


R.

_______________________________________________
Idr mailing list
Idr@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/idr

 

 







_______________________________________________
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

 

 

--_000_B17A6910EEDD1F45980687268941550FB20F9FMISOUT7MSGUSR9IIT_-- From enkechen@cisco.com Sat Jun 23 19:57:27 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D04FB21F863C for ; Sat, 23 Jun 2012 19:57:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.877 X-Spam-Level: X-Spam-Status: No, score=-8.877 tagged_above=-999 required=5 tests=[AWL=-1.279, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_24=0.6, J_CHICKENPOX_25=0.6, J_CHICKENPOX_41=0.6, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cd0R7-SMpuCY for ; Sat, 23 Jun 2012 19:57:21 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 377C421F8639 for ; Sat, 23 Jun 2012 19:57:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=enkechen@cisco.com; l=61849; q=dns/txt; s=iport; t=1340506641; x=1341716241; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=ZyPdlEsE59Y3+GKPJOxo2Px3msamd3DuGx7y68a7rzQ=; b=bbvwU3IHSkR5qctxBwrZrAYdy2oBguS+e4pI1+MkVb1Qf/H3/MsHBPXA zzdlk7CoIOKIniofm0wUWKHpDJWmKDaUv7AFzLt7v4JJhv8cPw3tyYMWD fze0D8iHNOgD3PLWlEBEh3ZB8rVqS4+dyNQoeHEWX1FsyvfuotHw7mygD A=; X-IronPort-AV: E=Sophos;i="4.77,466,1336348800"; d="scan'208,217";a="46892720" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 24 Jun 2012 02:57:21 +0000 Received: from sjc-vpn7-762.cisco.com (sjc-vpn7-762.cisco.com [10.21.146.250]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q5O2vJtu028271; Sun, 24 Jun 2012 02:57:20 GMT Message-ID: <4FE68269.4070704@cisco.com> Date: Sat, 23 Jun 2012 19:58:49 -0700 From: Enke Chen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "UTTARO, JAMES" References: <003c01cd4b29$97d7b150$c78713f0$@ndzh.com> <4FE0E074.3070905@raszuk.net> <17490_1340180565_4FE18855_17490_15423_1_53C29892C857584299CBF5D05346208A0928AA@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FE18A61.8000405@raszuk.net> <8ED5B0B0F5B4854A912480C1521F973AD95B@xmb-rcd-x13.cisco.com> <4FE4A8F3.20809@cisco.com> <4FE4AFE2.3030107@cisco.com> <4FE6441F.2050901@cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070309090309080702090600" Cc: 'Shane Amante' , "idr@ietf.org" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jun 2012 02:57:28 -0000 This is a multi-part message in MIME format. --------------070309090309080702090600 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Jim: On 6/23/12 7:29 PM, UTTARO, JAMES wrote: > > Enke, > > I agree lets be civil.. > > So civility starts with the following: > > I say I have a real problem and you do not dismiss it as a rare > occurrence and therefore not warranting WG adoption for the problem to > be worked on.. Do you think I am lying or lack the ability to count > the number of times it has happened and how many major/catastrophic > outages it has caused.. It is not appropriate to discuss the outages > in this venue or their cause.. > It is not appropriate for me to talk about another person's character or ability at IDR. I speak based on my experience and judgement, not on another person's character/ability. > I say I have a real problem and it is not dismissed as Jim Uttaro does > not know how to properly architect his network for robustness, > reliability, and survivability. Gee If he could just figure that out ( > It is obvious ) there would be no problem. > > You address the very real fact that a solution GR has been adopted and > coded that has exactly the behavior your are stating is not acceptable > for the Persistence draft which BTW has the STALE CV to address this > exact deficiency of not informing topologies of STALE paths which is > the current behavior of GR. Stating that it is an hour, therefore OK > does not cut it.. > This has been hashed multiple times, hasn't it? Again, GR allows stale paths to be kept for a short duration. I do not feel comfortable to have stale paths in the routing system for hours or days. That would make BGP semi-static and semi-dynamic. The implication is non-trivial, as pointed by others. > Folks acknowledge that BGP is being used for other services and they > merit the same attention as the traditional internet application.. To > this point it seems that IDR may be the wrong place for this draft and > it may be more appropriate in L3VPN, L2VPN. Maybe we should consider > that other AFs i.e RT-C, or other apps flowspec etc...should be moved > into L3VPN as it is probably a more appropriate place.. > > I do want to address the Update Error condition(s).. As I responded to > Rob, I think we need an accounting of how this behavior when coded > would or would not be applicable to other AFs. I would prefer a > consistent BGP code base across all AFs. We have to be careful that > we do not have so many responses to error conditions. It is difficult > enough to train Ops/Support staff, develop tools across AFs/Service > and get features consistently developed.. > Based on my experience and judgement, I believe that the error handling for malformed updates is generally applicable to all the address families. I think that several folks including JGS have explained very well why GR or persistence would not be the right solution in these cases. -- Enke > Jim Uttaro > > *From:*Enke Chen [mailto:enkechen@cisco.com] > *Sent:* Saturday, June 23, 2012 6:33 PM > *To:* UTTARO, JAMES > *Cc:* 'Shane Amante'; idr@ietf.org; Enke Chen > *Subject:* Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG > document - 3 more weeks > > Jim, > > Let us remain civil in the discussion. If you want to use the word > "nonsense", I suggest that you go back to read some of you posts. > > I have never said that "malform attributes" are rare. Just the > contrary, the issue of session reset from malformed attributes has > been with us for many years. There have been large outages from time > to time. There is a major bug in the base bgp spec in that area, in > particular, regarding the handling of optional transitive attribute. > That is what the error handling draft is trying to address. > > -- Enke > > On 6/23/12 12:45 PM, UTTARO, JAMES wrote: > > Shane, > > First of all if it was as easy as redundant BGP > sessions or as you state later "proper network architecture" we would > not be having this conversation.. Obvious network architecture like > redundant sessions so I can perform maintenance mode is pretty much > the starting point of a robust architecture across AFs/Services and I > would hazard a guess that everyone does this.. Beyond that there are > methods to enhance reliability even further that I have taken ( We > could have a pvt conversation if you would like ). All of this being > said, there are implementation bugs, overloading of BGP machinery > etc.. that have occurred and will occur in the future.. We cannot > simply shrug and say it is not important as it in some folks mind rare > ( not accurate ) or that there is some magical network architecture > that if only everyone would use, this issue could be mitigated. IMO it > is the job of the IETF to address real problems in the real world.. > > Back to this rare nonsense.. Rob Shakir wrote a draft to correct what > I guess is a rare condition having to do with a mal-formed attr. He is > very descriptive in terms f syntactic and semantic bugs. Folks in IDR > including E.Chen is an author of a solutions draft. If this is so rare > why is there a req and solutions draft.. > > We cannot have the argument coming out of both sides of the mouth.. > > Jim Uttaro > > *From:*Shane Amante [mailto:shane@castlepoint.net] > *Sent:* Friday, June 22, 2012 10:00 PM > *To:* UTTARO, JAMES > *Cc:* 'Enke Chen'; idr@ietf.org > *Subject:* Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG > document - 3 more weeks > > On Jun 22, 2012, at 12:03 PM, UTTARO, JAMES wrote: > > > > > Enke, > > I think we have got to have a consistent approach to > these solutions.. I am not comfortable with the fact that it is "ok" > for GR but not "ok" for Persistence based on a IMO subjective > interpretation of the amount of time a STALE path is active in local > and adjacent topologies. An hour is a long time, and as GR is used > primarily used n IPV4 which is dynamic it would seem that a) these > paths should be de-pref after some amount of time b) GR should inform > other AS topologies of the staleness by using the STALE CV.. > > I would be interested in hearing from operators as to if this behavior > is understood and if limiting of the time to ~1hr makes the > inconsistency within and across AS domains acceptable.. In your > opinion what is the maximum acceptable amount of time that we could > use Persistence. > > As an operator I believe even 1 hour is too long. In fact, I'd rather > (and, I do) trust Non-Stop Routing (NSR) on PE's in the network, > because I know that CE's will not understand GR capability and will > not be able to benefit from continuing to forward packets even while > the PE is restarting. Granted, this is an environment where there are > many "unmanaged CE's", where I have no control/say over what SW or the > capabilities are on those CE's. > > Furthermore, with control plane redundancy for iBGP sessions from one > PE across multiple RR's serving that cluster, it is possible to > conduct maintenance on one half of the RR-pair serving a cluster while > still preserving control and/or forwarding plane behavior. > > Ultimately, as I've said before, I'd much rather not see any type of > "stale" routes 'sticking around' in the control plane, since that is a > vast change in behavior from today's deployment of BGP where > reachability information is only carried while there are active BGP > sessions. (Yes, I get your point that I don't have to use persistence > if I don't want to, but if developers are in there monkey'ing around > with code to add this feature, inevitably I pay a price in addt'l > complexity for this "feature" even if I don't turn it on, i.e.: there > are potentially 'latent' bugs caused by this "feature", which is not > acceptable). > > As Enke has stated previously, I believe this class of problem is a > rare one, (given a proper network architecture), and thus we should > not be creating AFI-specific solutions that add substantial complexity > to an already complex protocol. > > -shane > > > > > Jim Uttaro > > *From:*Enke Chen [mailto:enkechen@cisco.com] > *Sent:*Friday, June 22, 2012 1:48 PM > *To:*UTTARO, JAMES > *Cc:*Saikat Ray (sairay);idr@ietf.org ; Enke Chen > *Subject:*Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG > document - 3 more weeks > > Jim, > > With GR, as you correctly pointed out, a path would not stale for many > hours or days. That is why it may not be as critical to limit the > scope of the stale path. > > If we were to have long-lived stale paths (which I think is a bad > idea), I agree that they should be limited to "consenting adults", and > there must be some mechanisms (such as capability) in place. > > -- Enke > > On 6/22/12 10:27 AM, UTTARO, JAMES wrote: > > Enke, > > The idea behind the setting of STALE is to inform > speakers in other AS domains that the path is suspect as the session > it was learned over is down.. IMO this is required to inform others > about the viability of a path.. > > The other approach is to simply not mark these paths as STALE.. Simply > de-pref in the local AS and business as usual when advertised outside > the AS where all transitive attrs are reset.. > > This is exactly the semantic you are using in the GR draft. You do not > de-pref the state locally and do not inform other AS domains that the > paths learned over the session that GR is active on are suspect. > > If the STALE CV is not honored across the AS border than the behavior > defaults to what is specified in the GR draft. This should meet your > requirements. > > Jim Uttaro > > *From:*idr-bounces@ietf.org > [mailto:idr-bounces@ietf.org]*On Behalf > Of*Enke Chen > *Sent:*Friday, June 22, 2012 1:19 PM > *To:*Saikat Ray (sairay) > *Cc:*idr@ietf.org > *Subject:*Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG > document - 3 more weeks > > Hi, Saikat: > > A new capability would certainly help. It seems necessary, but may > not be sufficient to limit the scope of the STALE path to "consenting > adults". For example, inside a network (i.e., AS), if there are > routers that do not recognize the STALE community, a STALE path may > still be advertised to external peers without the capability. This > means that all the routers in a network must recognize the community > before enabling the capability on any of them. It will be difficult > to satisfy the condition universally. > > In addition, to limit its scope the STALE community, once set, MUST > not be removed by any receiver. > > -- Enke > > On 6/22/12 9:34 AM, Saikat Ray (sairay) wrote: > > Without being involved in the discussion whether it is the right > problem to tackle or not, I would like to make the observation that at > the very least, the draft needs to define a new BGP capability for the > willingness to accept STALE routes. Peers that has not negotiated this > capability MUST receive paths "as if" the STALE paths did not exist. > This includes that STALE paths and any non-STALE paths whose nexthops > resolve over a STALE paths MUST also not be sent to a such a peer. > This way, negotiation of this capability by consenting adults will > define an island where stale routes would roam free without affecting > others. > > *From:*idr-bounces@ietf.org > [mailto:idr-bounces@ietf.org]*On Behalf > Of*Senad .Palislamovic > *Sent:*Friday, June 22, 2012 7:24 AM > *To:*idr@ietf.org > *Cc:*shares@ndzh.com > *Subject:*Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG > document - 3 more weeks > > IETF mail server glitch; resending: Note: Robert already > commented back > > Apologize for the delay on comments, > > Robert, > > After going through all the emails, I admit, you've made a lot of > valuable comments that 'seriously' MUST be considered in the new > version of the draft. However, putting that aside, I would really > expect this to be saved for WG discussions. I would think that at > this stage, we are more less agreeing to take a look at this problem > and its solution space. > > Robert, Randy, Shane, > > The main question I have for you is why object something that might > not even affect you. Draft's primary purpose is for the protection of > the control plane for non-internet services (vpls, l2vpn, or > infrustructure routes, i.e. BGP-3107), which in all cases does not > affect you or me in any shape or form. For folks to chose to extend > this to l3vpn or even to IPv4/IPv6 space, they are doing it > consciously knowing the nature of their network and its dynamics. If > you do see a route with the STALE community, and do not desire to use > this path due its "unreliable" nature, you can request your provider > to withdraw the routes with STALE community effectively making them > DO_NOT_PERSIST at the source which effectively mimics the standard GR > behavior; as Bruno stated, at eBGP, people are talking and negotiating. > > So given all that, help me understand how could this impact anyone who > chooses not to use it. Am I missing anything? > > On the side note, Susan, I do support this draft as WG document. > > Senad > > On Wed, Jun 20, 2012 at 4:31 AM, Robert Raszuk > wrote: > > Yet, IMHO building a good (reliable, performant) BGP > implementation is hard. > > True. And changing it's fundamental behaviour every few months > does not help to make it reliable/ performant either ;) > > I don't think operators would do a better job on the BGP > implementation side. > > I am not asking for that at all. I am asking to simply use > multiple implementations in the backend. Not two .. but 4 or 5. > Probability that all fail/melt with the same bug I think is very > very low. > > Of course I admit that if you one uses service which only single > vendor supports in BGP then one get's a bit stuck with the risk. > And that seems to be one of the silent "problem statement" here. > > Rgs, > > > R. > > _______________________________________________ > 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 > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --------------070309090309080702090600 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Jim:

On 6/23/12 7:29 PM, UTTARO, JAMES wrote:

Enke,

 

                I agree lets be civil..

 

So civility starts with the following:  

 

I say I have a real problem and you do not dismiss it as a rare occurrence and therefore not warranting WG adoption for the problem to be worked on.. Do you think I am lying or lack the ability to count the number of times it has happened and how many major/catastrophic outages it has caused.. It is not appropriate to discuss the outages in this venue or their cause..


It is not appropriate for me to talk about another person's character or ability at IDR.  I speak based on my experience and judgement, not on another person's character/ability.

 

I say I have a real problem and it is not dismissed as Jim Uttaro does not know how to properly architect his network for robustness, reliability, and survivability. Gee If he could just figure that out ( It is obvious ) there would be no problem.

 

You address the very real fact that a solution GR has been adopted and coded that has exactly the behavior your are stating is not acceptable for the Persistence draft which BTW has the STALE CV to address this exact deficiency of not informing topologies of STALE paths which is the current behavior of GR. Stating that it is an hour, therefore OK does not cut it..


This has been hashed multiple times, hasn't it?

Again, GR allows stale paths to be kept for a short duration.  I do not feel comfortable to have stale paths in the routing system for hours or days.  That would make BGP semi-static and semi-dynamic.  The implication is non-trivial, as pointed by others.

 

Folks acknowledge that BGP is being used for other services and they merit the same attention as the traditional internet application.. To this point it seems that IDR may be the wrong place for this draft and it may be more appropriate in L3VPN, L2VPN. Maybe we should consider that other AFs i.e RT-C, or other apps flowspec etc…should be moved into L3VPN as it is probably a more appropriate place..

 

I do want to address the Update Error condition(s).. As I responded to Rob, I think we need an accounting of how this behavior when coded would or would not be applicable to other AFs. I would prefer a consistent BGP code base across all AFs.  We have to be careful that we do not have so many responses to error conditions. It is difficult enough to train Ops/Support staff, develop tools across AFs/Service and get features consistently developed..


Based on my experience and judgement, I believe that the error handling for malformed updates is generally applicable to all the address families.  I think that several folks including JGS have explained very well why GR or persistence would not be the right solution in these cases.

-- Enke

 

Jim Uttaro

 

From: Enke Chen [mailto:enkechen@cisco.com]
Sent: Saturday, June 23, 2012 6:33 PM
To: UTTARO, JAMES
Cc: 'Shane Amante'; idr@ietf.org; Enke Chen
Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks

 

Jim,

Let us remain civil in the discussion. If you want to use the word "nonsense", I suggest that you go back to read some of you posts.

I have never said that "malform attributes" are rare.  Just the contrary, the issue of session reset from malformed attributes has been with us for many years.  There have been large outages from time to time.  There is a major bug in the base bgp spec in that area, in particular, regarding the handling of optional transitive attribute.  That is what the error handling draft is trying to address.

-- Enke

On 6/23/12 12:45 PM, UTTARO, JAMES wrote:

Shane,

 

                First of all if it was as easy as redundant BGP sessions or as you state later “proper network architecture” we would not be having this conversation.. Obvious network architecture like redundant sessions so I can perform maintenance mode is pretty much the starting point of a robust architecture across AFs/Services and I would hazard a guess that everyone does this.. Beyond that there are methods to enhance reliability even further that I have taken ( We could have a pvt conversation if you would like ).  All of this being said, there are implementation bugs, overloading of BGP machinery etc.. that have occurred and will occur in the future.. We cannot simply shrug and say it is not important as it in some folks mind rare ( not accurate ) or that there is some magical network architecture that if only everyone would use, this issue could be mitigated. IMO it is the job of the IETF to address real problems in the real world..

 

Back to this rare nonsense.. Rob Shakir wrote a draft to correct what I guess is a rare condition having to do with a mal-formed attr. He is very descriptive in terms f syntactic and semantic bugs. Folks in IDR including E.Chen is an author of a solutions draft. If this is so rare why is there a req and solutions draft..

 

We cannot have the argument coming out of both sides of the mouth..

 

Jim Uttaro

 

From: Shane Amante [mailto:shane@castlepoint.net]
Sent: Friday, June 22, 2012 10:00 PM
To: UTTARO, JAMES
Cc: 'Enke Chen'; idr@ietf.org
Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks

 

 

On Jun 22, 2012, at 12:03 PM, UTTARO, JAMES wrote:




Enke,

 

                I think we have got to have a consistent approach to these solutions.. I am not comfortable with the fact that it is “ok” for GR but not “ok” for Persistence based on a IMO subjective interpretation of the amount of time a STALE path is active in local and adjacent topologies. An hour is a long time, and as GR is used primarily used n IPV4 which is dynamic it would seem that a) these paths should be de-pref after some amount of time b) GR should inform other AS topologies of the staleness by using the STALE CV..

 

I would be interested in hearing from operators as to if this behavior is understood and if limiting of the time to ~1hr makes the inconsistency within and across AS domains acceptable..  In your opinion what is the maximum acceptable amount of time that we could use Persistence. 

 

As an operator I believe even 1 hour is too long.  In fact, I'd rather (and, I do) trust Non-Stop Routing (NSR) on PE's in the network, because I know that CE's will not understand GR capability and will not be able to benefit from continuing to forward packets even while the PE is restarting.  Granted, this is an environment where there are many "unmanaged CE's", where I have no control/say over what SW or the capabilities are on those CE's.

 

Furthermore, with control plane redundancy for iBGP sessions from one PE across multiple RR's serving that cluster, it is possible to conduct maintenance on one half of the RR-pair serving a cluster while still preserving control and/or forwarding plane behavior.

 

Ultimately, as I've said before, I'd much rather not see any type of "stale" routes 'sticking around' in the control plane, since that is a vast change in behavior from today's deployment of BGP where reachability information is only carried while there are active BGP sessions.  (Yes, I get your point that I don't have to use persistence if I don't want to, but if developers are in there monkey'ing around with code to add this feature, inevitably I pay a price in addt'l complexity for this "feature" even if I don't turn it on, i.e.: there are potentially 'latent' bugs caused by this "feature", which is not acceptable).

 

As Enke has stated previously, I believe this class of problem is a rare one, (given a proper network architecture), and thus we should not be creating AFI-specific solutions that add substantial complexity to an already complex protocol. 

 

-shane

 

 




Jim Uttaro

 

 

 

 

From: Enke Chen [mailto:enkechen@cisco.com] 
Sent: Friday, June 22, 2012 1:48 PM
To: UTTARO, JAMES
Cc: Saikat Ray (sairay); idr@ietf.org; Enke Chen
Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks

 

Jim,

With GR, as you correctly pointed out, a path would not stale for many hours or days. That is why it may not be as critical to limit the scope of the stale path.

If we were to have long-lived stale paths (which I think is a bad idea), I agree that they should be limited to "consenting adults", and there must be some mechanisms (such as capability) in place.

-- Enke

On 6/22/12 10:27 AM, UTTARO, JAMES wrote:

Enke,

 

                The idea behind the setting of STALE is to inform speakers in other AS domains that the path is suspect as the session it was learned over is down.. IMO this is required to inform others about the viability of a path..

 

The other approach is to simply not mark these paths as STALE.. Simply de-pref in the local AS and business as usual when advertised outside the AS where all transitive attrs are reset..

 

This is exactly the semantic you are using in the GR draft. You do not de-pref the state locally and do not inform other AS domains that the paths learned over the session that GR is active on are suspect.

 

If the STALE CV is not honored across the AS border than the behavior defaults to what is specified in the GR draft. This should meet your requirements.

 

Jim Uttaro

 

From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Enke Chen
Sent: Friday, June 22, 2012 1:19 PM
To: Saikat Ray (sairay)
Cc: idr@ietf.org
Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks

 

Hi, Saikat:

A new capability would certainly help.  It seems necessary, but may not be sufficient to limit the scope of the STALE path to "consenting adults".   For example, inside a network (i.e., AS), if there are routers that do not recognize the STALE community, a STALE path may still be advertised to external peers without the capability.   This means that all the routers in a network must recognize the community before enabling the capability on any of them.  It will be difficult to satisfy the condition universally.

In addition, to limit its scope the STALE community, once set, MUST not be removed by any receiver.

-- Enke

On 6/22/12 9:34 AM, Saikat Ray (sairay) wrote:

Without being involved in the discussion whether it is the right problem to tackle or not, I would like to make the observation that at the very least, the draft needs to define a new BGP capability for the willingness to accept STALE routes. Peers that has not negotiated this capability MUST receive paths “as if” the STALE paths did not exist. This includes that STALE paths and any non-STALE paths whose nexthops resolve over a STALE paths MUST also not be sent to a such a peer. This way, negotiation of this capability by consenting adults will define an island where stale routes would roam free without affecting others.

 

From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Senad .Palislamovic
Sent: Friday, June 22, 2012 7:24 AM
To: idr@ietf.org
Cc: shares@ndzh.com
Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks

 

IETF mail server glitch;  resending: Note: Robert already commented back

 

Apologize for the delay on comments,

Robert,

After going through all the emails, I admit, you've made a lot of valuable comments that 'seriously' MUST be considered in the new version of the draft.  However, putting that aside, I would really expect this to be saved for WG discussions.  I would think that at this stage, we are more less agreeing to take a look at this problem and its solution space. 

Robert, Randy, Shane,

The main question I have for you is why object something that might not even affect you.  Draft's primary purpose is for the protection of the control plane for non-internet services (vpls, l2vpn, or infrustructure routes, i.e. BGP-3107), which in all cases does not affect you or me in any shape or form.  For folks to chose to extend this to l3vpn or even to IPv4/IPv6 space, they are doing it consciously knowing the nature of their network and its dynamics.  If you do see a route with the STALE community, and do not desire to use this path due its "unreliable" nature, you can request your provider to withdraw the routes with STALE community effectively making them DO_NOT_PERSIST at the source which effectively mimics the standard GR behavior; as Bruno stated, at eBGP, people are talking and negotiating.

So given all that, help me understand how could this impact anyone who chooses not to use it.  Am I missing anything?

On the side note, Susan, I do support this draft as WG document.

 

Senad

 

 

 

 

 

On Wed, Jun 20, 2012 at 4:31 AM, Robert Raszuk <robert@raszuk.net> wrote:

 

Yet, IMHO building a good (reliable, performant) BGP implementation is hard.

 

True. And changing it's fundamental behaviour every few months does not help to make it reliable/ performant either ;)

 

I don't think operators would do a better job on the BGP implementation side.

 

I am not asking for that at all. I am asking to simply use multiple implementations in the backend. Not two .. but 4 or 5. Probability that all fail/melt with the same bug I think is very very low.

Of course I admit that if you one uses service which only single vendor supports in BGP then one get's a bit stuck with the risk. And that seems to be one of the silent "problem statement" here.

Rgs,


R.

_______________________________________________
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

 

 

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr

 

 


--------------070309090309080702090600-- From randy@psg.com Sat Jun 23 21:49:06 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E2C321F8523 for ; Sat, 23 Jun 2012 21:49:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N1AD4iPBKJ-4 for ; Sat, 23 Jun 2012 21:49:05 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id CFE1E21F847E for ; Sat, 23 Jun 2012 21:49:05 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Siekv-000M9G-Hr; Sun, 24 Jun 2012 04:49:01 +0000 Date: Sat, 23 Jun 2012 18:49:00 -1000 Message-ID: From: Randy Bush To: "UTTARO, JAMES" In-Reply-To: References: <003c01cd4b29$97d7b150$c78713f0$@ndzh.com> <7A614998-8FB1-4A51-9937-DE501FF31EB6@juniper.net> <4FE0D1F4.9070208@cisco.com> <4FE0E074.3070905@raszuk.net> <17490_1340180565_4FE18855_17490_15423_1_53C29892C857584299CBF5D05346208A0928AA@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FE18A61.8000405@raszuk.net> <8ED5B0B0F5B4854A912480C1521F973AD95B@xmb-rcd-x13.cisco.com> <4FE4A8F3.20809@cisco.com> <4FE4AFE2.3030107@cisco.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: 'Shane Amante' , "idr@ietf.org" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jun 2012 04:49:06 -0000 > I say I have a real problem and you do not dismiss it as a rare > occurrence and therefore not warranting WG adoption for the problem to > be worked on.. Do you think I am lying or lack the ability to count > the number of times it has happened and how many major/catastrophic > outages it has caused.. It is not appropriate to discuss the outages > in this venue or their cause.. then how do we make the engineering tradeoffs to understand if this complex and somewhat dangerous hack will ameliorate them? randy From heas@shrubbery.net Sat Jun 23 23:35:21 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D19B121F8627 for ; Sat, 23 Jun 2012 23:35:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FfP5zwXmiFiS for ; Sat, 23 Jun 2012 23:35:20 -0700 (PDT) Received: from guelah.shrubbery.net (guelah.shrubbery.net [198.58.5.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6D3121F8609 for ; Sat, 23 Jun 2012 23:35:17 -0700 (PDT) Received: by guelah.shrubbery.net (Postfix, from userid 7053) id 2772F9AAE6; Sun, 24 Jun 2012 06:35:16 +0000 (UTC) Date: Sun, 24 Jun 2012 06:35:16 +0000 From: heasley To: Susan Hares Message-ID: <20120624063516.GM39548@shrubbery.net> References: <003c01cd4b29$97d7b150$c78713f0$@ndzh.com> <985EF8D2-DA8A-4BE7-94D3-F4BE2B74D768@castlepoint.net> <4FE07A24.7050804@raszuk.net> <1C1F2B2E-2EB7-42F0-8CFF-57965443C074@castlepoint.net> <7A614998-8FB1-4A51-9937-DE501FF31EB6@juniper.net> <019d01cd4ff9$081b99d0$1852cd70$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <019d01cd4ff9$081b99d0$1852cd70$@ndzh.com> X-PGPkey: http://www.shrubbery.net/~heas/public-key.asc X-note: live free, or die! X-homer: i just want to have a beer while i am caring. X-Claimation: an engineer needs a manager like a fish needs a bicycle X-reality: only YOU can put an end to the embarrassment that is Tom Cruise User-Agent: Mutt/1.5.21 (2010-09-15) Cc: 'idr wg' Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jun 2012 06:35:21 -0000 Thu, Jun 21, 2012 at 05:58:45PM -0400, Susan Hares: > Randy: > > [co-chair hat off] > Your point is well-taken. > Data planes can continue while BGP drops, but I do not understand the point > of doing heroic efforts to keep the BGP control plane up when the data plane > is down. Perhaps someone can enlighten me. > > [co-chair hat on] i think collective-your time would be better spent developing an open source test suite that all implementers can use test their crap, than this and/or grow-ops-reqs-for-bgp-error-handling. From rjs@rob.sh Sun Jun 24 02:09:55 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD00E21F8633; Sun, 24 Jun 2012 02:09:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.072 X-Spam-Level: X-Spam-Status: No, score=-2.072 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j4pTdBvJouYB; Sun, 24 Jun 2012 02:09:49 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2001:b98:201:101::10:cafe]) by ietfa.amsl.com (Postfix) with ESMTP id E8D7621F862F; Sun, 24 Jun 2012 02:09:48 -0700 (PDT) Received: from [93.97.180.64] (helo=lait.config) by cappuccino.rob.sh with esmtpa (Exim 4.72) (envelope-from ) id 1Siinw-0005pF-Gh; Sun, 24 Jun 2012 10:08:24 +0100 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Rob Shakir In-Reply-To: Date: Sun, 24 Jun 2012 10:09:46 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <52CBEC1F-49E6-4656-A617-CAB7304479F0@rob.sh> To: "UTTARO, JAMES" X-Mailer: Apple Mail (2.1257) Cc: 'idr wg' , "'grow@ietf.org'" Subject: Re: [Idr] draft-ietf-grow-ops-reqs-for-bgp-error-handling-04 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jun 2012 09:09:55 -0000 Hi Jim, Further comments in-line as [rjs]. On 24 Jun 2012, at 03:06, UTTARO, JAMES wrote: > 1. Conservative -- any error in messages received from a neighbour are = indicative that it is not a viable route to any prefix it advertises. = Therefore where error conditions occur, disconnect and remove all routes = from the neighbour from the RIB. >=20 > [Jim U>] This is based on the current behavior of BGP.. If the NH is = still viable you could allow the session to fall and persist the good = state that has already been learned.. [rjs]: Absolutely, this is the current behaviour. The problem with = taking a whole session down in this case is that you now take a risk of = inconsistency for all NLRI across that session for the duration that you = hold onto the learned NLRI. If one avoids being in the situation where = the session is down (e.g., by applying treat-as-withdraw behaviour in = cases where one can determine the NLRI) then all other NLRI on the = session continue to be updated as they need to be. It is only the NLRI = that were included in the erroneous UPDATE that may be affected for = looping/black-holing. > I would expect all solutions implemented in response to these = requirements to be optional. If the risk of incorrectness is = unacceptable to you/an operator, then you should absolutely not enable = any of these mechanisms. In a number of networks that I have operated, = designed and architected, I am prepared to accept the risk of = incorrectness, as I consider it acceptable when compared to the risk of = complete service outages in terms of impact to my customers during such = incidents. At the moment, without the work described through the = requirements outlined in this draft I do not have the means to make that = call... > [Jim U>] I do not understand how it is possible to make this = configurable on a per session or AS basis..I would think all speakers = participating in a routing context would have to adhere to the same = rules for a consistent view across domains.. In my reading of the IDR = draft it seems that it would be a MUST.. Maybe I should not be = considering that IDR draft as the actual realization of the reqs.. [rjs]: The IDR draft is the solution for some of the requirements -- = particularly those described in Section 3 of the GROW draft. [rjs]: I do not see why this behaviour needs to be consistent across = domains? [rjs]: Essentially, if I receive an invalid UPDATE message, and apply = treat-as-withdraw, if the advertising speaker did not know that this was = erroneous then I end up with a different view of what is in the RIB than = the advertising speaker does. If this was a prefix I had no other route = to, then I may black-hole, if it was one where it was a more-specific of = some larger prefix, then we end up with the potential for loops. [rjs]: If I am prepared to accept the black-holing or loops for the NLRI = in the erroneous UPDATE as a risk, in favour of keeping the remaining = NLRI working (and being updated/withdrawn if they change), then this is = a local decision and I do not need to imply any behaviour of the = neighbouring domains. >=20 >> Abstract >>=20 >> Can the scope be expanded? There are other failure modes, i.e Timer = Expiry which today is not considered a failure mode. In reality what I = have seen is that timer expiry occurs due to the fact that BGP threads = cannot be serviced in a timely manner. I think it would be best if we = could put it all on the table.. >>=20 >> I do think that this draft should bound the solution space. At the = minimum the solutions proposed should meet a minimum set of the = operators criteria in terms of managing the network, convergence, = persistence, churn, forwarding impact etc... =20 >=20 > I think there was clear consensus amongst operators with whom I have = spoken to work on the problem space of erroneous UPDATEs - particularly = in response to observed incidents. The very real risk of expanding the = scope of this document even further to handle any error in the BGP = protocol is that we spend another few years cataloguing such conditions, = whilst doing nothing about the ones that we have identified. > [Jim U>] No doubt.. But I have seen other errors that relate to = overloading BGP, topological isolation etc... that have created huge = outages in my network.. So, My thinking is that we should try to = consider all of the challenges the protocol faces in terms of erroneous = error conditions.=20 [rjs] Right, perhaps a better title for the draft would be "Operational = Requirements for Enhanced Error Handling for UPDATE Messages in BGP-4" = -- given that there were incidents that affected networks that = particularly were focused on the errors in UPDATEs, it seemed logical = that this was the place to start for this work.=20 >=20 >> Section 1.1 >>=20 >> The following paragraph is based on the premise that the session = being "down" results in a large impact.. This is certainly true for = today's implementations which use the session ( Control Plane Construct = ) to determine the viability of the forwarding state learned over said = session. There are cases where this is the session and forwarding are = parallel, but in many more cases control and forwarding planes are = orthogonal.. I think we need to re-consider this assumption for many of = the services BGP is being used for and base the response to error = conditions on this reality.. >>=20 >> " Both within Internet and multi-service routing architectures, a >> number of BGP sessions propagate a large proportion of the required >> routing information for network operation. For Internet routing, >> these are typically BGP sessions which propagate the global routing >> table to an AS - failure of these sessions may have a large impact = on >> network service, based on a single erroneous update. In an multi- >> service environment, typical deployments utilise a small number of >> core-facing BGP sessions, typically towards route reflector = devices. >> Failure of these sessions may also result in a large impact to >> network operation. Clearly, the avoidance of conditions requiring >> these sessions to fail is of great utility to any network operator, >> and provides further motivation for the revision of the existing >> behaviour. " >=20 > I do not understand what the assertion that you are making here is. = Please could you explain it to me? The errors that are being discussed = relate to where a subset of NLRI are advertised within an erroneous = UPDATE message, and the resulting impact of the current protocol = behaviour on all other NLRI carried on that session. The cases of IP = "transit" sessions, and RR-PE sessions are only examples of cases where = there is a large amount of routing information carried over a single = session - and hence it is of utility to avoid these sessions failing = where they do not necessarily need to based on the impact to overall = network service. > [Jim U>] The solution space here seems explicitly targeted to the = internet IPV4 AF. Not sure if there is a dependency here on the = control/forwarding planes being in parallel. I believe we need to = consider all AFs that BGP is used for.. As the code that would be = developed would be applicable to these AF also ( I presume ). So as an = example would be RT-C, is this solution applicable I don't know I am = simply asking.. If we want to develop this and have it specific to the = internet use case lets state that clearly. If not, then let's consider = the other applications BGP supports.. [rjs] I'd say that it's not just applicable to IPv[46] in the Internet - = but to numerous AFIs (there is a definite use-case for these solutions = in L3VPN environments for instance). I am not saying that this is = applicable or desirable to be turned on for all AFIs -- but it seems to = me that this is a per-operator, per-deployment decision, not a per-AFI = one. For instance, if we get an RTC UPDATE that is malformed, an = operator may not want to tear down a session if it also carries other = AFIs (e.g., VPNv[46] also) - in that case, the operator may want to = treat this UPDATE as withdrawing the {as, route-target} NLRI (consider = that we have no *standardised* multi-session mechanism yet, and there = are potential scaling impacts of multiple sessions). >=20 > This point (to me anyway) seems entirely related to the control-plane = -- it points out that an operator has cases where one really wants to = keep the impact of errors down to the particular subset of routing = information that is affected. This point is entirely in the protocol, = rather than implying any behaviour about forwarding (i.e., no = implication is made that the NLRI identified as carried in the erroneous = UPDATE are installed in the FIB, but rather that all *other* NLRI = continue to be installed in the RIB). > [Jim U>] See above.. My point is how can we ensure reliability across = AFs...There is no doubt that mal-formed updates are an issue I just do = not know how they affect other AFs, in those case it may be more = appropriate to tear down and persist instead. Can we address these other = use cases? [rjs]: The consideration (that I see) that is missing from the draft = w.r.t this point seems to be more "what would break if one utilises = treat-as-withdraw and this is not {IPv[46],VPNv[46]} etc. Is this what = you feel needs to be addressed? [rjs]: I think the general though process of: 1/ In some cases, we want avoid affecting all NLRI based on an = error in a subset of the received NLRI. 2/ In this case, we may need to recover from this inconsistency. 3/ In some cases, we may want to give a session a chance to = restart where we could not handle the error gracefully. 4/ When errors occur on these sessions, there is great = operational benefit of flagging them more explicitly. [rjs]: is applicable across all AFIs almost. The distinction is really = whether one considers that 1/ is a valid behaviour/risk for an AFI?=20 >=20 > I'll work through the points that you have made in this mail -- but = I'd like to respond with a specific point here comparing more targeted = handling of errors in UPDATE messages with persistence-type approaches.=20= >=20 > - Persistence/hold-up is not acceptable to all operators in all = deployments. Particularly, where no liveliness detection mechanism for = the next-hop is available (i.e., where it is not possible or practical = to determine the NH's reachability in the forwarding plane other than = with with the routing protocol itself) then one would not want to accept = the risk of running persistence. > [Jim U>] Agreed.. Persistence requires that the NH be viable.=20 >=20 > - Therefore, an operator has two options for these deployments -- = stick with the error handling behaviour that is available in BGP right = now, which gives him no flexibility in terms of focusing responses to = errors in a manner that is proportional to the actual error; or = alternatively, accept some additional complexity and risk such that = particular error handling is targeted to the NLRI that are contained in = an UPDATE message that is found to be erroneous. > [Jim U>] My concern here is that the entire support structure is based = on session viability, the expectation here is that operators need to = develop new approaches to understanding if there is a routing anomaly in = their topology and develop tools/procedures which are different. [rjs]: Yes, this is true. We introduce a more complex failure mode where = a subset of prefixes are affected. *Any* new mechanism changing the = tear-down and flush-the-RIB behaviour of BGP will need some different = approaches to be developed. The intention of =A76 and =A77 of the draft = is to highlight where things do become more complex and define = requirements for ensuring that the right toolset exists around this = behaviour. [rjs]: Simplifying networks/removing complexity should always be a goal = -- but we need to understand where simple behaviour does not provide the = levers to limit the impact of errors occurring, and balance the = complexity of introducing new mechanisms against the benefit to our = network's operation.=20 [rjs]: I would like to think that the document highlights where = complexity is being introduced -- and highlights the impact of turning = some of these knobs on. If the complexity is not acceptable within a = deployment, these mechanisms should not be deployed. However, where it = is, we don't have the knobs to do anything today! If the document = doesn't address this to your satisfaction, please let me know, and I'd = be happy to make sure that the complexity is further highlighted. > Given there are deployments where I cannot deploy persistence (e.g., = towards an Internet network peer on an IXP where deployment of BFD/OAM = mechanisms are very limited so BGP really tells me whether the other = peer is "there" at all) yet in these cases I do not want to affect all = NLRI when one erroneous UPDATE is received then it would seem that I = need answers to the requirements in this draft.=20 > [Jim U>] Agreed..=20 >=20 > Your e-mail seems to imply that you do not have cases where you will = not be able to deploy persistence and that you are accepting of = session-level error handling in these cases. Would this be a fair = assessment? > [Jim U>] My work primarily revolves around the following BGP use cases = VPN ( L2/L3 ), 3107, Multi-Cast, RT-C, Flowspec not Internet.. In these = environments I would prefer that the session fail, persistence is = activated, and well known procedures are used to correct the problem. I = am in no way saying that the use case described here for the internet = application is not viable or the correct approach.. But the fact remains = that the code base will be used across all AFs and this solution = requires different OpS/Troubleshooting knowledge and support. I would = prefer consistency in the behavior..=20 [rjs]: I am involved in multiple network deployments across the company = in which I work, both public and private. I understand that there are = different requirements across different networks, and in different = deployment cases.=20 [rjs]: The problem of any mechanism is that it *may* be available for = places where it is not applicable. We could analyse persistence and say = that for Internet deployments, it has the potential to be harmful -- a = device that has failed will continue to look like a valid path when it = might not be, where a network in the Internet DFZ is likely to have a = number of alternate paths that could be used. In my view, in this draft, = we're just taking the "lowest common denominator" approach - where we = say, "how can we build mechanisms that could be applied across all = AFIs?". I think in all the use cases you mentioned, there are = deployments where these mechanisms are applicable. In all cases, one = valid behaviour would be that we keep the subset of NLRI that were not = affected from a neighbour, but do not use those that are not necessarily = trustworthy because they were linked to an invalid message in the = protocol. Of course, operationally, you may not want to do this, based = on the risk of inconsistency and the impact of failure. The key point = here is that my network deployment may differ to yours, and its up to = both of us to decide for our networks, but we both need the tools to be = able to make these choices. The problem with a consistent approach is = that I don't see how we can have a consistent approach that isn't based = on the lowest common denominator AFI - and even then, our logic may = differ in terms of where we want to turn it on. Kind regards, r. From rjs@rob.sh Sun Jun 24 02:15:34 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6F0A21F862F for ; Sun, 24 Jun 2012 02:15:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.425 X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cv+ntVkIkekm for ; Sun, 24 Jun 2012 02:15:34 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2001:b98:201:101::10:cafe]) by ietfa.amsl.com (Postfix) with ESMTP id D319721F859E for ; Sun, 24 Jun 2012 02:15:33 -0700 (PDT) Received: from [93.97.180.64] (helo=lait.config) by cappuccino.rob.sh with esmtpa (Exim 4.72) (envelope-from ) id 1SiitP-0005qN-3N; Sun, 24 Jun 2012 10:14:03 +0100 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Rob Shakir In-Reply-To: <20120624063516.GM39548@shrubbery.net> Date: Sun, 24 Jun 2012 10:15:24 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <16060975-A223-42D9-AA18-024209DDD842@rob.sh> References: <003c01cd4b29$97d7b150$c78713f0$@ndzh.com> <985EF8D2-DA8A-4BE7-94D3-F4BE2B74D768@castlepoint.net> <4FE07A24.7050804@raszuk.net> <1C1F2B2E-2EB7-42F0-8CFF-57965443C074@castlepoint.net> <7A614998-8FB1-4A51-9937-DE501FF31EB6@juniper.net> <019d01cd4ff9$081b99d0$1852cd70$@ndzh.com> <20120624063516.GM39548@shrubbery.net> To: heasley X-Mailer: Apple Mail (2.1257) Cc: 'idr wg' , Susan Hares Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jun 2012 09:15:35 -0000 On 24 Jun 2012, at 07:35, heasley wrote: > Thu, Jun 21, 2012 at 05:58:45PM -0400, Susan Hares: >> Randy: >>=20 >> [co-chair hat off] >> Your point is well-taken. =20 >> Data planes can continue while BGP drops, but I do not understand the = point >> of doing heroic efforts to keep the BGP control plane up when the = data plane >> is down. Perhaps someone can enlighten me.=20 >>=20 >> [co-chair hat on] >=20 > i think collective-your time would be better spent developing an open = source > test suite that all implementers can use test their crap, than this = and/or > grow-ops-reqs-for-bgp-error-handling. Whilst further testing is of course useful, and likely to find some = further issues, I think that any implementor and/or network operator = will attest to fact that testing does not find every issue. Essentially, = even if it does, we just patch them on an instance-by-instance basis - = whilst significant impact is incurred in live networks in the meantime.=20= I'm absolutely for more testing, but it seems to me like where we can = look at a solution that means that we impact less when we do get errors = occurring (such as affecting only particular NLRI etc.), this is of = value. Kind regards, r.= From shane@castlepoint.net Sun Jun 24 12:05:17 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A1B821F8645 for ; Sun, 24 Jun 2012 12:05:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.248 X-Spam-Level: X-Spam-Status: No, score=-1.248 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_41=0.6, J_CHICKENPOX_63=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f1PECD7VCD8v for ; Sun, 24 Jun 2012 12:05:15 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id 5C29421F8657 for ; Sun, 24 Jun 2012 12:05:14 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id 8D566268063; Sun, 24 Jun 2012 13:05:13 -0600 (MDT) Received: from mbpw.castlepoint.net (174-29-213-45.hlrn.qwest.net [174.29.213.45]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Sun, 24 Jun 2012 13:05:12 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=174.29.213.45; client-port=49791; syn-fingerprint=65535:54:1:64:M1452,N,W1,N,N,T,S; data-bytes=0 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_613E1E2F-03BF-495B-8164-10DFC1A4F870" From: Shane Amante In-Reply-To: Date: Sun, 24 Jun 2012 13:04:56 -0600 Message-Id: <5ED0F30C-2BC9-42EB-A75D-4FE549C4B527@castlepoint.net> References: <003c01cd4b29$97d7b150$c78713f0$@ndzh.com> <985EF8D2-DA8A-4BE7-94D3-F4BE2B74D768@castlepoint.net> <4FE07A24.7050804@raszuk.net> <1C1F2B2E-2EB7-42F0-8CFF-57965443C074@castlepoint.net> <7A614998-8FB1-4A51-9937-DE501FF31EB6@juniper.net> <4FE0D1F4.9070208@cisco.com> <4FE0E074.3070905@raszuk.net> <17490_1340180565_4FE18855_17490_15423_1_53C29892C857584299CBF5D05346208A0928AA@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FE18A61.8000405@raszuk.net> <8ED5B0B0F5B4854A912480C1521F973AD95B@xmb-rcd-x13.cisco.com> <4FE4A8F3.20809@cisco.com> <4FE4AFE2.3030107@cisco.com> To: "UTTARO, JAMES" X-Mailer: Apple Mail (2.1278) Cc: "idr@ietf.org" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jun 2012 19:05:18 -0000 --Apple-Mail=_613E1E2F-03BF-495B-8164-10DFC1A4F870 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Jim, Please note that you asked for operator input. I am providing that and, = in doing so, I am not intending to cast aspersions on you or anyone = else. I am only attempting to share my knowledge and, more importantly, = my operational experience. See below. On Jun 23, 2012, at 1:45 PM, UTTARO, JAMES wrote: > Shane, > =20 > First of all if it was as easy as redundant BGP = sessions or as you state later =93proper network architecture=94 we = would not be having this conversation.. Obvious network architecture = like redundant sessions so I can perform maintenance mode is pretty much = the starting point of a robust architecture across AFs/Services and I = would hazard a guess that everyone does this.. Beyond that there are = methods to enhance reliability even further that I have taken ( We could = have a pvt conversation if you would like ). All of this being said, = there are implementation bugs, overloading of BGP machinery etc.. that = have occurred and will occur in the future.. We cannot simply shrug and = say it is not important as it in some folks mind rare ( not accurate ) = or that there is some magical network architecture that if only everyone = would use, this issue could be mitigated. IMO it is the job of the IETF = to address real problems in the real world.. Here's the problem I have with the above. =46rom the vantage point of = my __VPN__ networks (IPVPN, VPLS), I am not observing the same types of = network failures (in those networks) as you have observed. Please note = that I am not saying your claims are false, I am only stating that this = these types of outages have not occurred in my VPN networks. As such, I = also think it's important for the WG to understand this additional data = point from the vantage point of a wholly different set of VPN networks, = so that WG members can see a "balanced view". I don't know (and, likely = will never know) why we are not seeing these problem(s) and you are, but = I imagine that it's likely due to some combination of, and in no = particular order: different HW, different SW and, potentially, different = scale. Ultimately, this operational experience is why I'm stating that = this _class_ of problem, specifically related to VPN networks, is very = rare. > Back to this rare nonsense.. Rob Shakir wrote a draft to correct what = I guess is a rare condition having to do with a mal-formed attr. He is = very descriptive in terms f syntactic and semantic bugs. Folks in IDR = including E.Chen is an author of a solutions draft. If this is so rare = why is there a req and solutions draft.. I have read and do support Rob's work. However, to be perfectly clear, = I do believe that we need to solve this overall set of problems (as = defined in Rob's draft), just not as has been proposed in the BGP = persistence draft. More to the point, where I __have__ observed this = class of problem is related to the Internet side, (AFI/SAFI 1/1 to be = more precise), during a handful of occasions over the last several = years. However, most (but, certainly not all) of those failures were = clearly attributable to implementation failures (on, the receive side of = receiving an UPDATE), for which I don't believe that any solution the = IDR WG devises will ever (or, should ever) be able to fix at the end of = the day. So, this ultimately boils down to (again, on the = Internet-side) a small number of very large disruptions to the control = plane as a result of malformed attributes. Again, yes, we should solve = those. So, forgive me for being selfish here, but this is why I would = rather see the IDR WG solve this in a generic way for all AFI's, so at = least if we're going to add complexity to implementations we're _all_ = gaining the benefit from it. > We cannot have the argument coming out of both sides of the mouth.. I'm sorry if you feel that way, but again I am only stating that my = experience has been different from yours. Obviously, each WG member is = free to draw their own conclusions as to those individual data points. -shane > =20 > Jim Uttaro > =20 > From: Shane Amante [mailto:shane@castlepoint.net]=20 > Sent: Friday, June 22, 2012 10:00 PM > To: UTTARO, JAMES > Cc: 'Enke Chen'; idr@ietf.org > Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG = document - 3 more weeks > =20 > =20 > On Jun 22, 2012, at 12:03 PM, UTTARO, JAMES wrote: >=20 >=20 > Enke, > =20 > I think we have got to have a consistent approach to = these solutions.. I am not comfortable with the fact that it is =93ok=94 = for GR but not =93ok=94 for Persistence based on a IMO subjective = interpretation of the amount of time a STALE path is active in local and = adjacent topologies. An hour is a long time, and as GR is used primarily = used n IPV4 which is dynamic it would seem that a) these paths should be = de-pref after some amount of time b) GR should inform other AS = topologies of the staleness by using the STALE CV.. > =20 > I would be interested in hearing from operators as to if this behavior = is understood and if limiting of the time to ~1hr makes the = inconsistency within and across AS domains acceptable.. In your opinion = what is the maximum acceptable amount of time that we could use = Persistence.=20 > =20 > As an operator I believe even 1 hour is too long. In fact, I'd rather = (and, I do) trust Non-Stop Routing (NSR) on PE's in the network, because = I know that CE's will not understand GR capability and will not be able = to benefit from continuing to forward packets even while the PE is = restarting. Granted, this is an environment where there are many = "unmanaged CE's", where I have no control/say over what SW or the = capabilities are on those CE's. > =20 > Furthermore, with control plane redundancy for iBGP sessions from one = PE across multiple RR's serving that cluster, it is possible to conduct = maintenance on one half of the RR-pair serving a cluster while still = preserving control and/or forwarding plane behavior. > =20 > Ultimately, as I've said before, I'd much rather not see any type of = "stale" routes 'sticking around' in the control plane, since that is a = vast change in behavior from today's deployment of BGP where = reachability information is only carried while there are active BGP = sessions. (Yes, I get your point that I don't have to use persistence = if I don't want to, but if developers are in there monkey'ing around = with code to add this feature, inevitably I pay a price in addt'l = complexity for this "feature" even if I don't turn it on, i.e.: there = are potentially 'latent' bugs caused by this "feature", which is not = acceptable). > =20 > As Enke has stated previously, I believe this class of problem is a = rare one, (given a proper network architecture), and thus we should not = be creating AFI-specific solutions that add substantial complexity to an = already complex protocol.=20 > =20 > -shane > =20 > =20 >=20 >=20 > Jim Uttaro > =20 > =20 > =20 > =20 > From: Enke Chen [mailto:enkechen@cisco.com]=20 > Sent: Friday, June 22, 2012 1:48 PM > To: UTTARO, JAMES > Cc: Saikat Ray (sairay); idr@ietf.org; Enke Chen > Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG = document - 3 more weeks > =20 > Jim, >=20 > With GR, as you correctly pointed out, a path would not stale for many = hours or days. That is why it may not be as critical to limit the scope = of the stale path. >=20 > If we were to have long-lived stale paths (which I think is a bad = idea), I agree that they should be limited to "consenting adults", and = there must be some mechanisms (such as capability) in place. >=20 > -- Enke >=20 > On 6/22/12 10:27 AM, UTTARO, JAMES wrote: > Enke, > =20 > The idea behind the setting of STALE is to inform = speakers in other AS domains that the path is suspect as the session it = was learned over is down.. IMO this is required to inform others about = the viability of a path.. > =20 > The other approach is to simply not mark these paths as STALE.. Simply = de-pref in the local AS and business as usual when advertised outside = the AS where all transitive attrs are reset.. > =20 > This is exactly the semantic you are using in the GR draft. You do not = de-pref the state locally and do not inform other AS domains that the = paths learned over the session that GR is active on are suspect. > =20 > If the STALE CV is not honored across the AS border than the behavior = defaults to what is specified in the GR draft. This should meet your = requirements. > =20 > Jim Uttaro > =20 > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of = Enke Chen > Sent: Friday, June 22, 2012 1:19 PM > To: Saikat Ray (sairay) > Cc: idr@ietf.org > Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG = document - 3 more weeks > =20 > Hi, Saikat: >=20 > A new capability would certainly help. It seems necessary, but may = not be sufficient to limit the scope of the STALE path to "consenting = adults". For example, inside a network (i.e., AS), if there are = routers that do not recognize the STALE community, a STALE path may = still be advertised to external peers without the capability. This = means that all the routers in a network must recognize the community = before enabling the capability on any of them. It will be difficult to = satisfy the condition universally. >=20 > In addition, to limit its scope the STALE community, once set, MUST = not be removed by any receiver. >=20 > -- Enke >=20 > On 6/22/12 9:34 AM, Saikat Ray (sairay) wrote: > Without being involved in the discussion whether it is the right = problem to tackle or not, I would like to make the observation that at = the very least, the draft needs to define a new BGP capability for the = willingness to accept STALE routes. Peers that has not negotiated this = capability MUST receive paths =93as if=94 the STALE paths did not exist. = This includes that STALE paths and any non-STALE paths whose nexthops = resolve over a STALE paths MUST also not be sent to a such a peer. This = way, negotiation of this capability by consenting adults will define an = island where stale routes would roam free without affecting others. > =20 > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of = Senad .Palislamovic > Sent: Friday, June 22, 2012 7:24 AM > To: idr@ietf.org > Cc: shares@ndzh.com > Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG = document - 3 more weeks > =20 > IETF mail server glitch; resending: Note: Robert already commented = back >=20 > =20 >=20 > Apologize for the delay on comments, >=20 > Robert, >=20 > After going through all the emails, I admit, you've made a lot of = valuable comments that 'seriously' MUST be considered in the new version = of the draft. However, putting that aside, I would really expect this = to be saved for WG discussions. I would think that at this stage, we = are more less agreeing to take a look at this problem and its solution = space.=20 >=20 > Robert, Randy, Shane, >=20 > The main question I have for you is why object something that might = not even affect you. Draft's primary purpose is for the protection of = the control plane for non-internet services (vpls, l2vpn, or = infrustructure routes, i.e. BGP-3107), which in all cases does not = affect you or me in any shape or form. For folks to chose to extend = this to l3vpn or even to IPv4/IPv6 space, they are doing it consciously = knowing the nature of their network and its dynamics. If you do see a = route with the STALE community, and do not desire to use this path due = its "unreliable" nature, you can request your provider to withdraw the = routes with STALE community effectively making them DO_NOT_PERSIST at = the source which effectively mimics the standard GR behavior; as Bruno = stated, at eBGP, people are talking and negotiating. >=20 > So given all that, help me understand how could this impact anyone who = chooses not to use it. Am I missing anything? >=20 > On the side note, Susan, I do support this draft as WG document. >=20 > =20 > Senad > =20 > =20 > =20 > =20 > =20 >=20 > On Wed, Jun 20, 2012 at 4:31 AM, Robert Raszuk = wrote: > =20 > Yet, IMHO building a good (reliable, performant) BGP implementation is = hard. > =20 > True. And changing it's fundamental behaviour every few months does = not help to make it reliable/ performant either ;) > =20 >=20 > I don't think operators would do a better job on the BGP = implementation side. > =20 > I am not asking for that at all. I am asking to simply use multiple = implementations in the backend. Not two .. but 4 or 5. Probability that = all fail/melt with the same bug I think is very very low. >=20 > Of course I admit that if you one uses service which only single = vendor supports in BGP then one get's a bit stuck with the risk. And = that seems to be one of the silent "problem statement" here. >=20 > Rgs, >=20 > R. >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > =20 > =20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > =20 > =20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr --Apple-Mail=_613E1E2F-03BF-495B-8164-10DFC1A4F870 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Shane,


Back to = this rare nonsense.. Rob Shakir wrote a draft to correct what I guess is = a rare condition having to do with a mal-formed attr. He is very = descriptive in terms f syntactic and semantic bugs. Folks in IDR = including E.Chen is an author of a solutions draft. If this is so rare = why is there a req and solutions = draft..

I = have read and do support Rob's work.  However, to be perfectly = clear, I do believe that we need to solve this overall set of problems = (as defined in Rob's draft), just not as has been proposed in the BGP = persistence draft.  More to the point, where I __have__ observed = this class of problem is related to the Internet side, (AFI/SAFI 1/1 to = be more precise), during a handful of occasions over the last several = years.  However, most (but, certainly not all) of those failures = were clearly attributable to implementation failures (on, the receive = side of receiving an UPDATE), for which I don't believe that any = solution the IDR WG devises will ever (or, should ever) be able to fix = at the end of the day.  So, this ultimately boils down to (again, = on the Internet-side) a small number of very large disruptions to the = control plane as a result of malformed attributes.  Again, yes, we = should solve those.  So, forgive me for being selfish here, but = this is why I would rather see the IDR WG solve this in a generic way = for all AFI's, so at least if we're going to add complexity to = implementations we're _all_ gaining the benefit from = it.


We cannot have the = argument coming out of both sides of the = mouth..

I'm sorry if you feel = that way, but again I am only stating that my experience has been = different from yours.  Obviously, each WG member is free to draw = their own conclusions as to those individual data = points.

-shane


Jim Uttaro
From: Shane Amante = [mailto:shane@castlepoint.net] 
Sent: Friday, June 22, 2012 10:00 = PM
To: UTTARO,= JAMES
Cc: 'Enke Chen'; idr@ietf.org
Subject: Re: [Idr] = draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more = weeks
 
On Jun 22, 2012, at 12:03 PM, UTTARO, JAMES = wrote:
Enke, 
 
I would be interested in hearing from operators as = to if this behavior is understood and if limiting of the time to ~1hr = makes the inconsistency within and across AS domains acceptable..  = In your opinion what is the maximum acceptable amount of time that we = could use Persistence. As an operator I = believe even 1 hour is too long.  In fact, I'd rather (and, I do) = trust Non-Stop Routing (NSR) on PE's in the network, because I know that = CE's will not understand GR capability and will not be able to benefit = from continuing to forward packets even while the PE is restarting. =  Granted, this is an environment where there are many "unmanaged = CE's", where I have no control/say over what SW or the capabilities are = on those CE's.
 
Furthermore, with control plane redundancy for iBGP sessions = from one PE across multiple RR's serving that cluster, it is possible to = conduct maintenance on one half of the RR-pair serving a cluster while = still preserving control and/or forwarding plane = behavior.
 
Ultimately, as I've said before, I'd much rather not see any = type of "stale" routes 'sticking around' in the control plane, since = that is a vast change in behavior from today's deployment of BGP where = reachability information is only carried while there are active BGP = sessions.  (Yes, I get your point that I don't have to use = persistence if I don't want to, but if developers are in there = monkey'ing around with code to add this feature, inevitably I pay a = price in addt'l complexity for this "feature" even if I don't turn it = on, i.e.: there are potentially 'latent' bugs caused by this "feature", = which is not acceptable).
As Enke has stated previously, I believe this = class of problem is a rare one, (given a proper network architecture), = and thus we should not be creating AFI-specific solutions that add = substantial complexity to an already complex = protocol. 
 
-shane
 


Jim Uttaro    
From:Enke Chen [ 
Sent: Friday, June 22, 2012 1:48 = PM
To: UTTARO,= JAMES
Cc: Saikat Ray (sairay); idr@ietf.org; Enke Chen
Subject: Re: [Idr] = draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more = weeksJim,

With GR, as you correctly pointed out, a path would = not stale for many hours or days. That is why it may not be as critical = to limit the scope of the stale path.

If we were to have = long-lived stale paths (which I think is a bad idea), I agree that they = should be limited to "consenting adults", and there must be some = mechanisms (such as capability) in place.

-- Enke

On = 6/22/12 10:27 AM, UTTARO, JAMES = wrote:
Enke,  The other approach is to simply not mark these paths = as STALE.. Simply de-pref in the local AS and business as usual when = advertised outside the AS where all transitive attrs are = reset.. This is exactly the semantic you are using in the GR = draft. You do not de-pref the state locally and do not inform other AS = domains that the paths learned over the session that GR is active on are = suspect. If the STALE CV is not honored across the AS border = than the behavior defaults to what is specified in the GR draft. This = should meet your requirements. Jim Uttaro 
From: [mailto:idr-bounces@ietf.org] On Behalf Of Enke = Chen
Sent: Friday, June 22, 2012 1:19 = PM
To: Saikat = Ray (sairay)
Cc: idr@ietf.org
Subject: Re: [Idr] = draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more = weeksHi, Saikat:

A new capability would certainly help.  = It seems necessary, but may not be sufficient to limit the scope of the = STALE path to "consenting adults".   For example, inside a = network (i.e., AS), if there are routers that do not recognize the STALE = community, a STALE path may still be advertised to external peers = without the capability.   This means that all the routers in a = network must recognize the community before enabling the capability on = any of them.  It will be difficult to satisfy the condition = universally.

In addition, to limit its scope the STALE community, = once set, MUST not be removed by any receiver.

-- Enke

On = 6/22/12 9:34 AM, Saikat Ray (sairay) = wrote:
Without being involved in the discussion whether it = is the right problem to tackle or not, I would like to make the = observation that at the very least, the draft needs to define a new BGP = capability for the willingness to accept STALE routes. Peers that has = not negotiated this capability MUST receive paths =93as if=94 the STALE = paths did not exist. This includes that STALE paths and any non-STALE = paths whose nexthops resolve over a STALE paths MUST also not be sent to = a such a peer. This way, negotiation of this capability by consenting = adults will define an island where stale routes would roam free without = affecting others. idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Senad = .Palislamovic
Sent: Friday, June 22, 2012 7:24 = AM
To: idr@ietf.org
Cc: shares@ndzh.com
Subject: Re: [Idr] = draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more = weeks 

IETF mail server glitch; =  resending: Note: Robert already commented = back

Apologize for the delay on = comments,

Robert,

After going through all the emails, I admit, you've made a lot = of valuable comments that 'seriously' MUST be considered in the new = version of the draft.  However, putting that aside, I would really = expect this to be saved for WG discussions.  I would think that at = this stage, we are more less agreeing to take a look at this problem and = its solution space. 

So given all that, help me = understand how could this impact anyone who chooses not to use it. =  Am I missing anything?

 

 

Idr@ietf.org
Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Subject: [Idr] BGP's consistency model X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jun 2012 19:19:51 -0000 In light of the work to, hopefully, define a good, all-encompassing = 'error-handling solution', I think it may be useful to take a step back = (or, up) and potentially consider that, ultimately, BGP is a protocol = for synchronization of distributed databases across a collection of = routers. Perhaps a question to be asked is: what type of consistency = model does BGP have? Or, can it even be neatly classified as such? https://en.wikipedia.org/wiki/Consistency_(database_systems) Perhaps once this is or other more appropriate fundamental aspects are = better understood, we can then begin to have a discussion around what = are the "classes" and/or spectrum of solutions that could/should = "naturally" address the error handling case(s). -shane= From hannes@juniper.net Mon Jun 25 00:08:20 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF3E521F845D for ; Mon, 25 Jun 2012 00:08:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.096 X-Spam-Level: X-Spam-Status: No, score=-6.096 tagged_above=-999 required=5 tests=[AWL=0.503, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PJT-ffx71z37 for ; Mon, 25 Jun 2012 00:08:20 -0700 (PDT) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by ietfa.amsl.com (Postfix) with ESMTP id 845E921F845C for ; Mon, 25 Jun 2012 00:08:19 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKT+gOYu1i3gu/wgzIoWRpColMBZZruYk9@postini.com; Mon, 25 Jun 2012 00:08:20 PDT Received: from ubuntu (172.23.1.121) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server id 8.3.213.0; Mon, 25 Jun 2012 00:07:30 -0700 Received: by ubuntu (Postfix, from userid 1000) id 1F3DC2049E; Mon, 25 Jun 2012 09:07:30 +0200 (CEST) Date: Mon, 25 Jun 2012 09:07:30 +0200 From: Hannes Gredler To: Robert Raszuk Message-ID: <20120625070729.GC21620@juniper.net> References: <14C7F4F06DB5814AB0DE29716C4F6D6702DF7129F6@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <4FE623B3.4060906@raszuk.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <4FE623B3.4060906@raszuk.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "idr@ietf.org List" , "UTTARO, JAMES \(ATTLABS\)" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2012 07:08:20 -0000 robert, On Sat, Jun 23, 2012 at 10:14:43PM +0200, Robert Raszuk wrote: | >IMO I think that folks need to come to the realization that BGP is | >being used in varied use cases, using the internet application as the | >only frame of reference or lens into the requirements for reliability is | >simply not appropriate or correct.. | | + | | >All of this being said, there are implementation bugs, overloading of | > BGP machinery etc.. that have occurred and will occur in the future.. | | | I think you need to realize that the key for any application is | solid IP reachability. well, there are some of us who believe that there are other ways of building a service architecture and (surprise !) the transport path not necessarily has to be IP. | You can realize any VPN to your customers without BGP being used as | a service bus for it. It is your choice or your vendor's choice as | you say to "overload BGP machinery" for everything. ^^^^^^^^^^^^^^^^^^^^^^^ is is really a smart thing to question over-and-over things that: a. have been decided 10+ years ago b. have proven to be useful | Putting more and more questionable requirements on the only protocol | which provides such global IP reachability proves as a bad idea. It | makes the protocol more and more fragile. i'd consider the questionw around a. graceful control-plane restart and b. standardized handling of forwarding entries thereafter as something that should be answered for any protocol in the design phase; obviously BGP is lacking this and that's why we're getting our heads together ... | The motivation that various flavors of VPNs carried by BGP must be | up only proves that as number of people suggested in the past the | same BGP protocol should not be used for everything. | | The point is not that protocol will not be able to cope with the | requirement. The point is that it is wrong to keep changing it's | core behaviour because your VPN or VPLS service goes down. | | Moreover you now do not want to limit the changes only to your | services SAFI, but argue to "enhance" all AFI/SAFIs with it. That is | something very hard to agree with. the "core behaviour" of the protocol (kill RIB entries right after session loss) is wrong. and since BGP has outgrown its original purpose (route 1K prefixes) vs. route 100Ks of prefixes, route unicast and multicast, route VPN/non-VPN, route non-routing related functionality it is just letigimate to discuss restart and persistence behaviour on a per AFI/SAFI basis. tx, /hannes From robert@raszuk.net Mon Jun 25 01:26:09 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D74D421F8484 for ; Mon, 25 Jun 2012 01:26:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iYCd3vRKou+P for ; Mon, 25 Jun 2012 01:26:05 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 7F75121F8494 for ; Mon, 25 Jun 2012 01:26:05 -0700 (PDT) Received: (qmail 21729 invoked by uid 399); 25 Jun 2012 08:26:04 -0000 Received: from unknown (HELO ?192.168.1.58?) (pbs:robert@raszuk.net@83.31.184.18) by mail1310.opentransfer.com with ESMTPM; 25 Jun 2012 08:26:04 -0000 X-Originating-IP: 83.31.184.18 Message-ID: <4FE8209C.3050603@raszuk.net> Date: Mon, 25 Jun 2012 10:26:04 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Hannes Gredler References: <14C7F4F06DB5814AB0DE29716C4F6D6702DF7129F6@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <4FE623B3.4060906@raszuk.net> <20120625070729.GC21620@juniper.net> In-Reply-To: <20120625070729.GC21620@juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org List" , "UTTARO, JAMES \(ATTLABS\)" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2012 08:26:10 -0000 Hi Hannes, > | I think you need to realize that the key for any application is > | solid IP reachability. > > well, there are some of us who believe that there are other ways > of building a service architecture and (surprise !) the transport > path not necessarily has to be IP. Well actually above I was not intending to sound anti-MPLS. I should say IP/MPLS above .. as you very well know MPLS requires IP to work first ! > | You can realize any VPN to your customers without BGP being used as > | a service bus for it. It is your choice or your vendor's choice as > | you say to "overload BGP machinery" for everything. > ^^^^^^^^^^^^^^^^^^^^^^^ > > is is really a smart thing to question over-and-over things that: > a. have been decided 10+ years ago > b. have proven to be useful I think it is. It is not about putting services in BGP or not as the protocol. I do not have any problem with that at all. Note that "overload" term was a quote from Jim's mail no my own description. It is about running services BGP and IP BGP together which I am questioning. Keyur and I had a draft http://goo.gl/GWrIs "Transport Instance BGP" to allow for clear separation of the two instances. I do believe that if we would have this in place there would be completely no objection from anyone in IETF to add persistence to "Service BGP". Especially that Bruno mentioned the need to propagate his infrastructure routes in SAFI 1/1. Both BGP instances could operate independently and "IP/Routing instance" could serve very well the "service instance". Yes I realize that for you it means more code to maintain so there is price to that. The only question I think which should be stated if perhaps cost vs benefit of such separation is getting to right more now. > | Putting more and more questionable requirements on the only protocol > | which provides such global IP reachability proves as a bad idea. It > | makes the protocol more and more fragile. > > i'd consider the questionw around > a. graceful control-plane restart and > b. standardized handling of forwarding entries thereafter > > as something that should be answered for any protocol in the design phase; > obviously BGP is lacking this and that's why we're getting our > heads together ... Hmmmm one would think that RFC4724 addresses that. And moreover it is widely implemented. Are you now saying that BGP GR is no good and we need something better ? Moreover this something better must be both stable and solid for "IP/Routing BGP instance" and flexible and elastic to cover every possible hole for "Service BGP" ? I think if we would address each problem space separately we would be much better off with finding the right solution to both. > the "core behaviour" of the protocol (kill RIB entries right > after session loss) is wrong. IMHO the core behaviour of the protocol assumes you have more then one path in your BGP table to any important destination. And it is only better if those paths are diverse (coming from different control planes). Then even if your session goes down immediately nothing bad is happening to the system. If you design your network with a single path only (or same BGP code mirrored another one) then sorry it is likely that both sessions go down and you loose your service for some time. In GR you could allow that for 1h .. it is already too long. But to allow that for more I am of the opinion that this is not BGP but NETCONF. > and since BGP has outgrown its > original purpose (route 1K prefixes) vs. route 100Ks of prefixes, > route unicast and multicast, route VPN/non-VPN, > route non-routing related functionality it is just letigimate to discuss > restart and persistence behaviour on a per AFI/SAFI basis. Very good point. If we would start on a per AFI/SAFI basis we would perhaps already be at the last call. However authors have chosen not to go that path. They have chosen to make BGP persistance for all AFI/SAFIs in the spec moreover now they are questioning GR (not advertising routes as STALE) and error-handling proposals (which targets to keep the sessions up as perhaps malformed attribute is about one prefix out of 400K). Best, R. From hannes@juniper.net Mon Jun 25 06:32:02 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD6EC21F8483 for ; Mon, 25 Jun 2012 06:32:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.264 X-Spam-Level: X-Spam-Status: No, score=-6.264 tagged_above=-999 required=5 tests=[AWL=0.335, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eu-Eadxx31BG for ; Mon, 25 Jun 2012 06:31:58 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by ietfa.amsl.com (Postfix) with ESMTP id D538321F848A for ; Mon, 25 Jun 2012 06:31:57 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKT+hoTL2MShP/Yqj364LJT1ZalXAjURHR@postini.com; Mon, 25 Jun 2012 06:31:58 PDT Received: from hannes-sslvpn-nc.jnpr.net (172.23.1.121) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server id 8.3.213.0; Mon, 25 Jun 2012 06:31:22 -0700 MIME-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset="iso-8859-1" From: Hannes Gredler In-Reply-To: <4FE8209C.3050603@raszuk.net> Date: Mon, 25 Jun 2012 15:31:10 +0200 Content-Transfer-Encoding: quoted-printable Message-ID: References: <14C7F4F06DB5814AB0DE29716C4F6D6702DF7129F6@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <4FE623B3.4060906@raszuk.net> <20120625070729.GC21620@juniper.net> <4FE8209C.3050603@raszuk.net> To: X-Mailer: Apple Mail (2.1278) Cc: "idr@ietf.org List" , "UTTARO, JAMES \(ATTLABS\)" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2012 13:32:02 -0000 On Jun 25, 2012, at 10:26 AM, Robert Raszuk wrote: > Hi Hannes, >=20 > > | I think you need to realize that the key for any application is >> | solid IP reachability. >>=20 >> well, there are some of us who believe that there are other ways >> of building a service architecture and (surprise !) the transport >> path not necessarily has to be IP. >=20 > Well actually above I was not intending to sound anti-MPLS. I should = say IP/MPLS above .. as you very well know MPLS requires IP to work = first ! >=20 >> | You can realize any VPN to your customers without BGP being used as >> | a service bus for it. It is your choice or your vendor's choice as >> | you say to "overload BGP machinery" for everything. >> ^^^^^^^^^^^^^^^^^^^^^^^ >>=20 >> is is really a smart thing to question over-and-over things that: >> a. have been decided 10+ years ago >> b. have proven to be useful >=20 > I think it is. >=20 > It is not about putting services in BGP or not as the protocol. I do = not have any problem with that at all. Note that "overload" term was a = quote from Jim's mail no my own description. >=20 > It is about running services BGP and IP BGP together which I am = questioning. Keyur and I had a draft http://goo.gl/GWrIs "Transport = Instance BGP" to allow for clear separation of the two instances. thats a valid concern - although i have to say that the TI draft is more = about implementation and not protocol spec ;-) wrt to TI - why restrict to internet vs. non-internet - to some e.g. = the labeled-BGP infra may appear more crucial than the internet service itself. - i can certainly see the need for a *proper* = separation between BGP service instances. > I do believe that if we would have this in place there would be = completely no objection from anyone in IETF to add persistence to = "Service BGP". Especially that Bruno mentioned the need to propagate his = infrastructure routes in SAFI 1/1. Both BGP instances could operate = independently and "IP/Routing instance" could serve very well the = "service instance". >=20 > Yes I realize that for you it means more code to maintain so there is = price to that. The only question I think which should be stated if = perhaps cost vs benefit of such separation is getting to right more now. unless we have a proper fault containment within any given = implementation of BGP, we can only try to control the failure behavior of routing software, and = its garbage collection mechanisms.=20 >> | Putting more and more questionable requirements on the only = protocol >> | which provides such global IP reachability proves as a bad idea. It >> | makes the protocol more and more fragile. >>=20 >> i'd consider the questionw around >> a. graceful control-plane restart and >> b. standardized handling of forwarding entries thereafter >>=20 >> as something that should be answered for any protocol in the design = phase; >> obviously BGP is lacking this and that's why we're getting our >> heads together ... >=20 >=20 > Hmmmm one would think that RFC4724 addresses that. And moreover it is = widely implemented. Are you now saying that BGP GR is no good and we = need something better ? Moreover this something better must be both = stable and solid for "IP/Routing BGP instance" and flexible and elastic = to cover every possible hole for "Service BGP"=20 i think extended-GR plus the ability to restart a single AFI/SAFI = anytime when the TCP session already has been established would be more flexible than todays integrated approach where = addition/deletion of an AFI/SAFI always restart in a complete restart of the entire session. > I think if we would address each problem space separately we would be = much better off with finding the right solution to both i think if you fix BGP implementation and allow graceful restart of = sessions and session instances, then you do not need to worry that much about the failure behavior and how to mitigate that. >> the "core behaviour" of the protocol (kill RIB entries right >> after session loss) is wrong. >=20 > IMHO the core behaviour of the protocol assumes you have more then one = path in your BGP table to any important destination. And it is only = better if those paths are diverse (coming from different control = planes). Then even if your session goes down immediately nothing bad is = happening to the system. true - multipathing is a viable way of cheating around the problem of = control-plane failure ;-) > If you design your network with a single path only (or same BGP code = mirrored another one) then sorry it is likely that both sessions go down = and you loose your service for some time that is understood -=20 > In GR you could allow that for 1h .. it is already too long. But to = allow that for more I am of the opinion that this is not BGP but = NETCONF. garbage collection intervals of stale prefixes should entirely an = operators choice.=20 SPs know how large their RIBs are and they know when its time to clean = up stale prefixes; >> and since BGP has outgrown its >> original purpose (route 1K prefixes) vs. route 100Ks of prefixes, >> route unicast and multicast, route VPN/non-VPN, >> route non-routing related functionality it is just letigimate to = discuss >> restart and persistence behaviour on a per AFI/SAFI basis. >=20 > Very good point. If we would start on a per AFI/SAFI basis we would = perhaps already be at the last call. However authors have chosen not to = go that path. They have chosen to make BGP persistance for all AFI/SAFIs = in the spec moreover now they are questioning GR (not advertising routes = as STALE) and error-handling proposals (which targets to keep the = sessions up as perhaps malformed attribute is about one prefix out of = 400K). >=20 > Best, > R. From robert@raszuk.net Mon Jun 25 06:51:35 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DC3B21F8644 for ; Mon, 25 Jun 2012 06:51:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zYC2MFA3cIoO for ; Mon, 25 Jun 2012 06:51:31 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id C67B321F8649 for ; Mon, 25 Jun 2012 06:51:30 -0700 (PDT) Received: (qmail 17992 invoked by uid 399); 25 Jun 2012 13:51:30 -0000 Received: from unknown (HELO ?192.168.1.91?) (pbs:m42@mojaklasa.info@83.31.239.28) by mail1310.opentransfer.com with ESMTPM; 25 Jun 2012 13:51:30 -0000 X-Originating-IP: 83.31.239.28 Message-ID: <4FE86CE1.9010708@raszuk.net> Date: Mon, 25 Jun 2012 15:51:29 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Hannes Gredler References: <14C7F4F06DB5814AB0DE29716C4F6D6702DF7129F6@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <4FE623B3.4060906@raszuk.net> <20120625070729.GC21620@juniper.net> <4FE8209C.3050603@raszuk.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org List" , "UTTARO, JAMES \(ATTLABS\)" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2012 13:51:35 -0000 Hi Hannes, I am glad you fundamentally agree. Just a few follow-up comments ... >> It is about running services BGP and IP BGP together which I am >> questioning. Keyur and I had a draft http://goo.gl/GWrIs "Transport >> Instance BGP" to allow for clear separation of the two instances. > > thats a valid concern - although i have to say that the TI draft is > more about implementation and not protocol spec ;-) Not really. All it does is clear separation between two BGP instances. Sure you can separate them with multisession - what was actually John's response in next rev of multisession draft after transport instance got posted .. however we went nowhere with both as a result :( > wrt to TI - why > restrict to internet vs. non-internet - to some e.g. the labeled-BGP > infra may appear more crucial than the internet service itself. - i > can certainly see the need for a *proper* separation between BGP > service instances. 100% agree. In fact I would see labeled-BGP to belong to IP/Routing instance .. solid as it can be. That is an infrastructure for a service not a service itself. Besides the TI draft made it very clear that the choice which AFI/SAFI is served by which instance would be not be up to IETF but would be left to the operator. The problem with the latter approach of each SAFI having separate instance seems to be really difficult to handle by IETF if protocol would differ on a per SAFI basis. That's why TI took a very pragmatic approach to just allowing number of instances equal 2. But this could be up to discussion. Currently we have one or any instance served by the same very protocol hence the collisions of group who on one hand want to protect the IP/Routing and those on the other hand who careless about IP Internet, but do care about their services. And the most interesting part is that both may be actually correct in their own views. Unfortunately single BGP protocol instance causes the collision of interests. >> Yes I realize that for you it means more code to maintain so there >> is price to that. The only question I think which should be stated >> if perhaps cost vs benefit of such separation is getting to right >> more now. > > unless we have a proper fault containment within any given > implementation of BGP, we can only try to control the failure > behavior of routing software, and its garbage collection mechanisms. I do agree but that is an implementation. I am just focusing on the value of protocol delta between different uses of BGP instances. > i think extended-GR plus the ability to restart a single AFI/SAFI > anytime when the TCP session already has been established would be > more flexible than todays integrated approach where addition/deletion > of an AFI/SAFI always restart in a complete restart of the entire > session. Does not need to. Dynamic capabilities have been invented long time back and some are even implementing it :) No longer you need to restart the entire session to add or delete a new SAFI. Ability to restart single AFI/SAFI is again an implementation choice in my view. >> I think if we would address each problem space separately we would >> be much better off with finding the right solution to both > > i think if you fix BGP implementation and allow graceful restart of > sessions and session instances, then you do not need to worry that > much about the failure behavior and how to mitigate that. Maybe ... I am not convinced. Clearly persistent folks are not convinced too - otherwise they would not be pushing for it, but instead would be banging your door to get new junos version soon :-) > true - multipathing is a viable way of cheating around the problem of > control-plane failure ;-) A lot of people consider cheating as a bad thing. So I would not call it that way. For me this is rather robust network design. >> In GR you could allow that for 1h .. it is already too long. But to >> allow that for more I am of the opinion that this is not BGP but >> NETCONF. > > garbage collection intervals of stale prefixes should entirely an > operators choice. SPs know how large their RIBs are and they know > when its time to clean up stale prefixes; At this point the spec does not allow that. If STALE is stripped by someone there is no base to do any garbage collection any more. Besides when each AS would choose to do different time for such garbage collection you can imagine what would happen right ? R. From ju1738@att.com Mon Jun 25 07:38:38 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23FA621F8601 for ; Mon, 25 Jun 2012 07:38:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.699 X-Spam-Level: X-Spam-Status: No, score=-105.699 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_41=0.6, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Crzz9SBMWsFL for ; Mon, 25 Jun 2012 07:38:29 -0700 (PDT) Received: from nbfkord-smmo04.seg.att.com (nbfkord-smmo04.seg.att.com [209.65.160.86]) by ietfa.amsl.com (Postfix) with ESMTP id 335F321F8600 for ; Mon, 25 Jun 2012 07:38:29 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO nbfkord-smmo04.seg.att.com) by nbfkord-smmo04.seg.att.com(mxl_mta-6.11.0-10) with ESMTP id 5e778ef4.2aaaf604f940.195604.00-571.514883.nbfkord-smmo04.seg.att.com (envelope-from ); Mon, 25 Jun 2012 14:38:29 +0000 (UTC) X-MXL-Hash: 4fe877e50dcf7181-0db0453b1d101812522aabb6370bcef409c97267 Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo04.seg.att.com(mxl_mta-6.11.0-10) over TLS secured channel with ESMTP id fb778ef4.0.195353.00-479.514219.nbfkord-smmo04.seg.att.com (envelope-from ); Mon, 25 Jun 2012 14:38:08 +0000 (UTC) X-MXL-Hash: 4fe877d0385bcffa-a42ad3f8abd4974c8cc138bff1fc93f5db7e9654 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q5PEbo2q025566; Mon, 25 Jun 2012 10:37:51 -0400 Received: from sflint01.pst.cso.att.com (sflint01.pst.cso.att.com [144.154.234.228]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q5PEblRL025552 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Jun 2012 10:37:48 -0400 Received: from MISOUT7MSGHUB9D.ITServices.sbc.com (misout7msghub9d.itservices.sbc.com [144.151.223.93]) by sflint01.pst.cso.att.com (RSA Interceptor); Mon, 25 Jun 2012 10:37:28 -0400 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9D.ITServices.sbc.com ([144.151.223.93]) with mapi id 14.02.0298.004; Mon, 25 Jun 2012 10:37:28 -0400 From: "UTTARO, JAMES" To: "'Shane Amante'" Thread-Topic: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks Thread-Index: AQHNUIKv4gES0WzL/kWO4I5ojxcnRZcGy9WAgAAMWYD//70toIAASxcA//+9G7CAAMwtgIAA4i1AgAHOngCAAPFJYA== Date: Mon, 25 Jun 2012 14:37:27 +0000 Message-ID: References: <003c01cd4b29$97d7b150$c78713f0$@ndzh.com> <985EF8D2-DA8A-4BE7-94D3-F4BE2B74D768@castlepoint.net> <4FE07A24.7050804@raszuk.net> <1C1F2B2E-2EB7-42F0-8CFF-57965443C074@castlepoint.net> <7A614998-8FB1-4A51-9937-DE501FF31EB6@juniper.net> <4FE0D1F4.9070208@cisco.com> <4FE0E074.3070905@raszuk.net> <17490_1340180565_4FE18855_17490_15423_1_53C29892C857584299CBF5D05346208A0928AA@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FE18A61.8000405@raszuk.net> <8ED5B0B0F5B4854A912480C1521F973AD95B@xmb-rcd-x13.cisco.com> <4FE4A8F3.20809@cisco.com> <4FE4AFE2.3030107@cisco.com> <5ED0F30C-2BC9-42EB-A75D-4FE549C4B527@castlepoint.net> In-Reply-To: <5ED0F30C-2BC9-42EB-A75D-4FE549C4B527@castlepoint.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.91.76.182] Content-Type: multipart/alternative; boundary="_000_B17A6910EEDD1F45980687268941550FB2F0D7MISOUT7MSGUSR9IIT_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=1.0 c=1 a=g8Qva45Ca7EA:10 a=ZQD3OTTxKqYA:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a=XK] X-AnalysisOut: [fbYx4oAAAA:8 a=48vgC7mUAAAA:8 a=AUd_NHdVAAAA:8 a=1sjgXBK7A] X-AnalysisOut: [AAA:8 a=2clOPd4PAAAA:8 a=GHbY7c2wHqlwQ7i0gfoA:9 a=CjuIK1q_] X-AnalysisOut: [8ugA:10 a=uI1Or78iWTcA:10 a=lZB815dzVvQA:10 a=JfD0Fch1gWkA] X-AnalysisOut: [:10 a=kZwP4KTQBigA:10 a=bDUki_mJ7DgA:10 a=x31hvKrqADT4wI5R] X-AnalysisOut: [:21 a=8j3X-3vhS7QYvO97:21 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:] X-AnalysisOut: [8 a=hoVrc8g74wzmNbPlYfMA:9 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4] X-AnalysisOut: [A:10 a=hTZeC7Yk6K0A:10 a=tXsnliwV7b4A:10 a=n69SiB5KnVyrtpM] X-AnalysisOut: [U:21 a=ZBA4AITKqCVHXVtt:21] Cc: "idr@ietf.org" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2012 14:38:38 -0000 --_000_B17A6910EEDD1F45980687268941550FB2F0D7MISOUT7MSGUSR9IIT_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Shane Comments In-Line.. Jim Uttaro From: Shane Amante [mailto:shane@castlepoint.net] Sent: Sunday, June 24, 2012 3:05 PM To: UTTARO, JAMES Cc: 'Enke Chen'; idr@ietf.org Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document -= 3 more weeks Jim, Please note that you asked for operator input. I am providing that and, in= doing so, I am not intending to cast aspersions on you or anyone else. I = am only attempting to share my knowledge and, more importantly, my operatio= nal experience. See below. On Jun 23, 2012, at 1:45 PM, UTTARO, JAMES wrote: Shane, First of all if it was as easy as redundant BGP sessions or= as you state later "proper network architecture" we would not be having th= is conversation.. Obvious network architecture like redundant sessions so I= can perform maintenance mode is pretty much the starting point of a robust= architecture across AFs/Services and I would hazard a guess that everyone = does this.. Beyond that there are methods to enhance reliability even furth= er that I have taken ( We could have a pvt conversation if you would like )= . All of this being said, there are implementation bugs, overloading of BG= P machinery etc.. that have occurred and will occur in the future.. We cann= ot simply shrug and say it is not important as it in some folks mind rare (= not accurate ) or that there is some magical network architecture that if = only everyone would use, this issue could be mitigated. IMO it is the job o= f the IETF to address real problems in the real world.. Here's the problem I have with the above. From the vantage point of my __V= PN__ networks (IPVPN, VPLS), I am not observing the same types of network f= ailures (in those networks) as you have observed. Please note that I am no= t saying your claims are false, I am only stating that this these types of = outages have not occurred in my VPN networks. As such, I also think it's i= mportant for the WG to understand this additional data point from the vanta= ge point of a wholly different set of VPN networks, so that WG members can = see a "balanced view". I don't know (and, likely will never know) why we a= re not seeing these problem(s) and you are, but I imagine that it's likely = due to some combination of, and in no particular order: different HW, diffe= rent SW and, potentially, different scale. Ultimately, this operational ex= perience is why I'm stating that this _class_ of problem, specifically rela= ted to VPN networks, is very rare. [Jim U>] That is fair.. AT&T's suite of networks span the globe, We have mu= ltiple vendors, numerous releases and multiple platforms.. I cannot divulge= actual numbers but a ballpark estimate, exceeds ( 10*Internet Scale ) in = terms of control plane state. In some case there are individual contexts th= at rival the global routing table.. I am faced with the dilemma of supporti= ng extremely large networks that support critical applications that simply = cannot fail. As Neil pointed out ( Hospital, Police/Fire etc.. and of cours= e Uncle Sam ;) There are challenges that only become evident with large amo= unts of scale, topologies which are not as robust as we would prefer in dif= ferent parts of the globe, sheer volume of operations support and possibili= ty of error, different erroneous error i.e mal-formed update etc... Back to this rare nonsense.. Rob Shakir wrote a draft to correct what I gue= ss is a rare condition having to do with a mal-formed attr. He is very desc= riptive in terms f syntactic and semantic bugs. Folks in IDR including E.Ch= en is an author of a solutions draft. If this is so rare why is there a req= and solutions draft.. I have read and do support Rob's work. However, to be perfectly clear, I d= o believe that we need to solve this overall set of problems (as defined in= Rob's draft), just not as has been proposed in the BGP persistence draft. = More to the point, where I __have__ observed this class of problem is rela= ted to the Internet side, (AFI/SAFI 1/1 to be more precise), during a handf= ul of occasions over the last several years. However, most (but, certainly= not all) of those failures were clearly attributable to implementation fai= lures (on, the receive side of receiving an UPDATE), for which I don't beli= eve that any solution the IDR WG devises will ever (or, should ever) be abl= e to fix at the end of the day. So, this ultimately boils down to (again, = on the Internet-side) a small number of very large disruptions to the contr= ol plane as a result of malformed attributes. Again, yes, we should solve = those. So, forgive me for being selfish here, but this is why I would rath= er see the IDR WG solve this in a generic way for all AFI's, so at least if= we're going to add complexity to implementations we're _all_ gaining the b= enefit from it. [Jim U>] +1 on the support.. Rob's draft should be classified as solving th= at specific set of use cases identified.. I am not involved on the internet= side, but I can definitely see the benefit of solving this for that use ca= se.. I am being selfish also in that I need to solve a bigger set of issues= ( See Above ), with different requirements for the other services I am usi= ng BGP for.. We cannot have the argument coming out of both sides of the mouth.. I'm sorry if you feel that way, but again I am only stating that my experie= nce has been different from yours. Obviously, each WG member is free to dr= aw their own conclusions as to those individual data points. [Jim U>] Agreed.. My only point would be that folks do not operate from a p= erspective of it hasn't happened to me therefore it is not real.. -shane Jim Uttaro From: Shane Amante [mailto:shane@castlepoint.net] Sent: Friday, June 22, 2012 10:00 PM To: UTTARO, JAMES Cc: 'Enke Chen'; idr@ietf.org Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document -= 3 more weeks On Jun 22, 2012, at 12:03 PM, UTTARO, JAMES wrote: Enke, I think we have got to have a consistent approach to these = solutions.. I am not comfortable with the fact that it is "ok" for GR but n= ot "ok" for Persistence based on a IMO subjective interpretation of the amo= unt of time a STALE path is active in local and adjacent topologies. An hou= r is a long time, and as GR is used primarily used n IPV4 which is dynamic = it would seem that a) these paths should be de-pref after some amount of ti= me b) GR should inform other AS topologies of the staleness by using the ST= ALE CV.. I would be interested in hearing from operators as to if this behavior is u= nderstood and if limiting of the time to ~1hr makes the inconsistency withi= n and across AS domains acceptable.. In your opinion what is the maximum a= cceptable amount of time that we could use Persistence. As an operator I believe even 1 hour is too long. In fact, I'd rather (and= , I do) trust Non-Stop Routing (NSR) on PE's in the network, because I know= that CE's will not understand GR capability and will not be able to benefi= t from continuing to forward packets even while the PE is restarting. Gran= ted, this is an environment where there are many "unmanaged CE's", where I = have no control/say over what SW or the capabilities are on those CE's. Furthermore, with control plane redundancy for iBGP sessions from one PE ac= ross multiple RR's serving that cluster, it is possible to conduct maintena= nce on one half of the RR-pair serving a cluster while still preserving con= trol and/or forwarding plane behavior. Ultimately, as I've said before, I'd much rather not see any type of "stale= " routes 'sticking around' in the control plane, since that is a vast chang= e in behavior from today's deployment of BGP where reachability information= is only carried while there are active BGP sessions. (Yes, I get your poi= nt that I don't have to use persistence if I don't want to, but if develope= rs are in there monkey'ing around with code to add this feature, inevitably= I pay a price in addt'l complexity for this "feature" even if I don't turn= it on, i.e.: there are potentially 'latent' bugs caused by this "feature",= which is not acceptable). As Enke has stated previously, I believe this class of problem is a rare on= e, (given a proper network architecture), and thus we should not be creatin= g AFI-specific solutions that add substantial complexity to an already comp= lex protocol. -shane Jim Uttaro From: Enke Chen [mailto:enkechen@cisco.com] Sent: Friday, June 22, 2012 1:48 PM To: UTTARO, JAMES Cc: Saikat Ray (sairay); idr@ietf.org; Enke Chen Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document -= 3 more weeks Jim, With GR, as you correctly pointed out, a path would not stale for many hour= s or days. That is why it may not be as critical to limit the scope of the = stale path. If we were to have long-lived stale paths (which I think is a bad idea), I = agree that they should be limited to "consenting adults", and there must be= some mechanisms (such as capability) in place. -- Enke On 6/22/12 10:27 AM, UTTARO, JAMES wrote: Enke, The idea behind the setting of STALE is to inform speakers = in other AS domains that the path is suspect as the session it was learned = over is down.. IMO this is required to inform others about the viability of= a path.. The other approach is to simply not mark these paths as STALE.. Simply de-p= ref in the local AS and business as usual when advertised outside the AS wh= ere all transitive attrs are reset.. This is exactly the semantic you are using in the GR draft. You do not de-p= ref the state locally and do not inform other AS domains that the paths lea= rned over the session that GR is active on are suspect. If the STALE CV is not honored across the AS border than the behavior defau= lts to what is specified in the GR draft. This should meet your requirement= s. Jim Uttaro From: idr-bounces@ietf.org [mailto:idr-bounces= @ietf.org] On Behalf Of Enke Chen Sent: Friday, June 22, 2012 1:19 PM To: Saikat Ray (sairay) Cc: idr@ietf.org Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document -= 3 more weeks Hi, Saikat: A new capability would certainly help. It seems necessary, but may not be = sufficient to limit the scope of the STALE path to "consenting adults". F= or example, inside a network (i.e., AS), if there are routers that do not r= ecognize the STALE community, a STALE path may still be advertised to exter= nal peers without the capability. This means that all the routers in a ne= twork must recognize the community before enabling the capability on any of= them. It will be difficult to satisfy the condition universally. In addition, to limit its scope the STALE community, once set, MUST not be = removed by any receiver. -- Enke On 6/22/12 9:34 AM, Saikat Ray (sairay) wrote: Without being involved in the discussion whether it is the right problem to= tackle or not, I would like to make the observation that at the very least= , the draft needs to define a new BGP capability for the willingness to acc= ept STALE routes. Peers that has not negotiated this capability MUST receiv= e paths "as if" the STALE paths did not exist. This includes that STALE pat= hs and any non-STALE paths whose nexthops resolve over a STALE paths MUST a= lso not be sent to a such a peer. This way, negotiation of this capability = by consenting adults will define an island where stale routes would roam fr= ee without affecting others. From: idr-bounces@ietf.org [mailto:idr-bounces= @ietf.org] On Behalf Of Senad .Palislamovic Sent: Friday, June 22, 2012 7:24 AM To: idr@ietf.org Cc: shares@ndzh.com Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document -= 3 more weeks IETF mail server glitch; resending: Note: Robert already commented back Apologize for the delay on comments, Robert, After going through all the emails, I admit, you've made a lot of valuable = comments that 'seriously' MUST be considered in the new version of the draf= t. However, putting that aside, I would really expect this to be saved for= WG discussions. I would think that at this stage, we are more less agreei= ng to take a look at this problem and its solution space. Robert, Randy, Shane, The main question I have for you is why object something that might not eve= n affect you. Draft's primary purpose is for the protection of the control= plane for non-internet services (vpls, l2vpn, or infrustructure routes, i.= e. BGP-3107), which in all cases does not affect you or me in any shape or = form. For folks to chose to extend this to l3vpn or even to IPv4/IPv6 spac= e, they are doing it consciously knowing the nature of their network and it= s dynamics. If you do see a route with the STALE community, and do not des= ire to use this path due its "unreliable" nature, you can request your prov= ider to withdraw the routes with STALE community effectively making them DO= _NOT_PERSIST at the source which effectively mimics the standard GR behavio= r; as Bruno stated, at eBGP, people are talking and negotiating. So given all that, help me understand how could this impact anyone who choo= ses not to use it. Am I missing anything? On the side note, Susan, I do support this draft as WG document. Senad On Wed, Jun 20, 2012 at 4:31 AM, Robert Raszuk > wrote: Yet, IMHO building a good (reliable, performant) BGP implementation is hard= . True. And changing it's fundamental behaviour every few months does not hel= p to make it reliable/ performant either ;) I don't think operators would do a better job on the BGP implementation sid= e. I am not asking for that at all. I am asking to simply use multiple impleme= ntations in the backend. Not two .. but 4 or 5. Probability that all fail/m= elt with the same bug I think is very very low. Of course I admit that if you one uses service which only single vendor sup= ports in BGP then one get's a bit stuck with the risk. And that seems to be= one of the silent "problem statement" here. Rgs, R. _______________________________________________ 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 _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr --_000_B17A6910EEDD1F45980687268941550FB2F0D7MISOUT7MSGUSR9IIT_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Shane

 <= /p>

    &= nbsp;           Comments = In-Line..

 <= /p>

Jim Uttaro

 <= /p>

From: Shane Am= ante [mailto:shane@castlepoint.net]
Sent: Sunday, June 24, 2012 3:05 PM
To: UTTARO, JAMES
Cc: 'Enke Chen'; idr@ietf.org
Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG doc= ument - 3 more weeks

 

Jim,

 

Please note that you asked for operator input.  = ;I am providing that and, in doing so, I am not intending to cast aspersion= s on you or anyone else.  I am only attempting to share my knowledge a= nd, more importantly, my operational experience.  See below.

 

On Jun 23, 2012, at 1:45 PM, UTTARO, JAMES wrote:

Shane,<= /p>

 <= /p>

    &= nbsp;           First of = all if it was as easy as redundant BGP sessions or as you state later ̶= 0;proper network architecture” we would not be having this conversati= on.. Obvious network architecture like redundant sessions so I can perform main= tenance mode is pretty much the starting point of a robust architecture acr= oss AFs/Services and I would hazard a guess that everyone does this.. Beyon= d that there are methods to enhance reliability even further that I have taken ( We could have a pvt conversat= ion if you would like ).  All of this being said, there are implementa= tion bugs, overloading of BGP machinery etc.. that have occurred and will o= ccur in the future.. We cannot simply shrug and say it is not important as it in some folks mind rare ( not accu= rate ) or that there is some magical network architecture that if only ever= yone would use, this issue could be mitigated. IMO it is the job of the IET= F to address real problems in the real world..

 

Here's the problem I have with the above.  From= the vantage point of my __VPN__ networks (IPVPN, VPLS), I am not observing= the same types of network failures (in those networks) as you have observe= d.  Please note that I am not saying your claims are false, I am only stating that this these types of outages have = not occurred in my VPN networks.  As such, I also think it's important= for the WG to understand this additional data point from the vantage point= of a wholly different set of VPN networks, so that WG members can see a "balanced view".  I don't know= (and, likely will never know) why we are not seeing these problem(s) and y= ou are, but I imagine that it's likely due to some combination of, and in n= o particular order: different HW, different SW and, potentially, different scale.  Ultimately, this operational expe= rience is why I'm stating that this _class_ of problem, specifically relate= d to VPN networks, is very rare.

[Jim U>] That is= fair.. AT&T’s suite of networks span the globe, We have multiple= vendors, numerous releases and multiple platforms.. I cannot divulge actual numbers but a ballpark estimate, exceeds (  10*Internet Scale = ) in terms of control plane state. In some case there are individual contex= ts that rival the global routing table.. I am faced with the dilemma of sup= porting extremely large networks that support critical applications that simply cannot fail. As Neil pointed out= ( Hospital, Police/Fire etc.. and of course Uncle Sam ;) There are challen= ges that only become evident with large amounts of scale, topologies which = are not as robust as we would prefer in different parts of the globe, sheer volume of operations support and po= ssibility of error, different erroneous error i.e mal-formed update etcR= 30;

 



Back to this rare nonsens= e.. Rob Shakir wrote a draft to correct what I guess is a rare condition ha= ving to do with a mal-formed attr. He is very descriptive in terms f syntactic and semantic bugs. Folks in IDR including E.Chen is a= n author of a solutions draft. If this is so rare why is there a req and so= lutions draft..

 

I have read and do support Rob's work.  However= , to be perfectly clear, I do believe that we need to solve this overall se= t of problems (as defined in Rob's draft), just not as has been proposed in= the BGP persistence draft.  More to the point, where I __have__ observed this class of problem is related to the I= nternet side, (AFI/SAFI 1/1 to be more precise), during a handful of occasi= ons over the last several years.  However, most (but, certainly not al= l) of those failures were clearly attributable to implementation failures (on, the receive side of receiving an UPDATE), = for which I don't believe that any solution the IDR WG devises will ever (o= r, should ever) be able to fix at the end of the day.  So, this ultima= tely boils down to (again, on the Internet-side) a small number of very large disruptions to the control plane as a result = of malformed attributes.  Again, yes, we should solve those.  So,= forgive me for being selfish here, but this is why I would rather see the = IDR WG solve this in a generic way for all AFI's, so at least if we're going to add complexity to implementations we'= re _all_ gaining the benefit from it.

[Jim U>] +1 = on the support.. Rob’s draft should be classified as solving that spe= cific set of use cases identified.. I am not involved on the internet side, but I can definitely see the benefit of solving this for that use ca= se.. I am being selfish also in that I need to solve a bigger set of issues= ( See Above ), with different requirements for the other services I am usi= ng BGP for..

 



We cannot have the argument coming out of both sides of the mouth..=

 

I'm sorry if you feel that way, but again I am only = stating that my experience has been different from yours.  Obviously, = each WG member is free to draw their own conclusions as to those individual= data points.

[Jim U>] Agreed.= . My only point would be that folks do not operate from a perspective of it= hasn’t happened to me therefore it is not real..

 

-shane

 



 <= /p>

Jim Uttaro

 <= /p>

 

 

On Jun 22, 2012, at 12:03 PM, UTTARO, JAMES wrote:




Enke,

 <= /p>

    &= nbsp;           I think w= e have got to have a consistent approach to these solutions.. I am not comf= ortable with the fact that it is “ok” for GR but not “ok&= #8221; for Persistence based on a IMO subjective interpretation of the amount of = time a STALE path is active in local and adjacent topologies. An hour is a = long time, and as GR is used primarily used n IPV4 which is dynamic it woul= d seem that a) these paths should be de-pref after some amount of time b) GR should inform other AS topologi= es of the staleness by using the STALE CV..

 <= /p>

I would be interested in = hearing from operators as to if this behavior is understood and if limiting= of the time to ~1hr makes the inconsistency within and across AS domains acceptable..  In your opinion what is the maximum a= cceptable amount of time that we could use Persistence. 

 

As an operator I believe even 1 hour is too long. &n= bsp;In fact, I'd rather (and, I do) trust Non-Stop Routing (NSR) on PE's in= the network, because I know that CE's will not understand GR capability an= d will not be able to benefit from continuing to forward packets even while the PE is restarting.  Granted, this is= an environment where there are many "unmanaged CE's", where I ha= ve no control/say over what SW or the capabilities are on those CE's.<= /o:p>

 

Furthermore, with control plane redundancy for iBGP = sessions from one PE across multiple RR's serving that cluster, it is possi= ble to conduct maintenance on one half of the RR-pair serving a cluster whi= le still preserving control and/or forwarding plane behavior.

 

Ultimately, as I've said before, I'd much rather not= see any type of "stale" routes 'sticking around' in the control = plane, since that is a vast change in behavior from today's deployment of B= GP where reachability information is only carried while there are active BGP sessions.  (Yes, I get your point that I d= on't have to use persistence if I don't want to, but if developers are in t= here monkey'ing around with code to add this feature, inevitably I pay a pr= ice in addt'l complexity for this "feature" even if I don't turn it on, i.e.: there are potentially 'latent' bugs caus= ed by this "feature", which is not acceptable).

 

As Enke has stated previously, I believe this class = of problem is a rare one, (given a proper network architecture), and thus w= e should not be creating AFI-specific solutions that add substantial comple= xity to an already complex protocol. 

 

-shane

 

 




Jim Uttaro

 <= /p>

 <= /p>

 <= /p>

 <= /p>

From: Enke Chen [mailto:enkechen@cisco.com]=  
Sent: Friday, June= 22, 2012 1:48 PM
To: UTTARO, JAMES<= br> Cc: Saikat Ray (sa= iray); idr@ietf.org; Enke Chen
Subject: Re: [Idr]= draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks

 =

Jim,

With GR, as you correctly pointed out, a path would not stale for many hour= s or days. That is why it may not be as critical to limit the scope of the = stale path.

If we were to have long-lived stale paths (which I think is a bad idea), I = agree that they should be limited to "consenting adults", and the= re must be some mechanisms (such as capability) in place.

-- Enke

On 6/22/12 10:27 AM, UTTARO, JAMES wrote:

Enke,

 <= /p>

    &= nbsp;           The idea = behind the setting of STALE is to inform speakers in other AS domains that = the path is suspect as the session it was learned over is down.. IMO this is required to inform others about the viability of a path= ..

 <= /p>

The other approach is to = simply not mark these paths as STALE.. Simply de-pref in the local AS and b= usiness as usual when advertised outside the AS where all transitive attrs are reset..

 <= /p>

This is exactly the seman= tic you are using in the GR draft. You do not de-pref the state locally and= do not inform other AS domains that the paths learned over the session that GR is active on are suspect.

 <= /p>

If the STALE CV is not ho= nored across the AS border than the behavior defaults to what is specified = in the GR draft. This should meet your requirements.

 <= /p>

Jim Uttaro

 <= /p>

From: idr-bounces@ietf.org [mailto:i= dr-bounces@ietf.org] = On Behalf Of Enke Chen<= br> Sent: Friday, June= 22, 2012 1:19 PM
To: Saikat Ray (sa= iray)
Cc: idr@ietf.org
Subject: Re: [Idr]= draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks

 =

Hi, Saikat:

A new capability would certainly help.  It seems necessary, but may no= t be sufficient to limit the scope of the STALE path to "consenting ad= ults".   For example, inside a network (i.e., AS), if there = are routers that do not recognize the STALE community, a STALE path may still be advertised to external peers without the capabilit= y.   This means that all the routers in a network must recognize = the community before enabling the capability on any of them.  It will = be difficult to satisfy the condition universally.

In addition, to limit its scope the STALE community, once set, MUST not be = removed by any receiver.

-- Enke

On 6/22/12 9:34 AM, Saikat Ray (sairay) wrote:

Without being involved in= the discussion whether it is the right problem to tackle or not, I would l= ike to make the observation that at the very least, the draft needs to define a new BGP capability for the willingness to accept S= TALE routes. Peers that has not negotiated this capability MUST receive pat= hs “as if” the STALE paths did not exist. This includes that ST= ALE paths and any non-STALE paths whose nexthops resolve over a STALE paths MUST also not be sent to a such a peer. This wa= y, negotiation of this capability by consenting adults will define an islan= d where stale routes would roam free without affecting others.<= /o:p>

 <= /p>

From: idr-bounces@i= etf.org [mailto:idr-bounces@ietf.org] On Behalf Of Senad .Pal= islamovic
Sent: Friday, June= 22, 2012 7:24 AM
To: idr@ietf.org
Cc: shares@ndzh.com
Subject: Re: [Idr]= draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks

 =

IETF mail server glitch;  = resending: Note: Robert already commented back

 

Apologize for the delay on comm= ents,

Robert,

After going through all the ema= ils, I admit, you've made a lot of valuable comments that 'seriously' MUST = be considered in the new version of the draft.  However, putting that = aside, I would really expect this to be saved for WG discussions.  I would think that at this stage, we are more le= ss agreeing to take a look at this problem and its solution space. 

Robert, Randy, Shane,

The main question I have for yo= u is why object something that might not even affect you.  Draft's&nbs= p;primary purpose is for the protection of the control plane for non-intern= et services (vpls, l2vpn, or infrustructure routes, i.e. BGP-3107), which in all cases does not affect you or me in any shape = or form.  For folks to chose to extend this to l3vpn or even to IPv4/I= Pv6 space, they are doing it consciously knowing the nature of their networ= k and its dynamics.  If you do see a route with the STALE community, and do not desire to use this path due its= "unreliable" nature, you can request your provider to withdraw t= he routes with STALE community effectively making them DO_NOT_PERSIST at th= e source which effectively mimics the standard GR behavior; as Bruno stated, at eBGP, people are talking and negotiating.=

So given all that, help me unde= rstand how could this impact anyone who chooses not to use it.  Am I m= issing anything?

On the side note, Susan, I do s= upport this draft as WG document.

 =

Senad<= /p>

 =

 =

 =

 =

 

On Wed, Jun 20, 2012 at = 4:31 AM, Robert Raszuk <robert@raszuk.net> wrote:

 =

Yet, IMHO building a goo= d (reliable, performant) BGP implementation is hard.

 =

True. And changing it's = fundamental behaviour every few months does not help to make it reliable/ p= erformant either ;)

 

I don't think operators = would do a better job on the BGP implementation side.

 =

I am not asking for that= at all. I am asking to simply use multiple implementations in the backend.= Not two .. but 4 or 5. Probability that all fail/melt with the same bug I = think is very very low.

Of course I admit that if you one uses service which only single vendor sup= ports in BGP then one get's a bit stuck with the risk. And that seems to be= one of the silent "problem statement" here.

Rgs,


R.

_______________________________________________
Idr mailing list
Idr@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/idr

 =

 = 







__________________________________________=
_____
Idr mailing list
Idr@ietf.o=
rg
https://www.ietf.org/mailman/listinfo/idr=

 =

 =

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr

 

--_000_B17A6910EEDD1F45980687268941550FB2F0D7MISOUT7MSGUSR9IIT_-- From djsmith@cisco.com Mon Jun 25 07:49:24 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AFD121F864F for ; Mon, 25 Jun 2012 07:49:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hCsXlCzJNEgh for ; Mon, 25 Jun 2012 07:49:23 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 1FE9B21F8623 for ; Mon, 25 Jun 2012 07:49:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=djsmith@cisco.com; l=1056; q=dns/txt; s=iport; t=1340635763; x=1341845363; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=mkDZjYpfaGts0/lxg7Vy322uQBtdMHdaZhFZ9TDBvgc=; b=lTvWO40WoQPaa+WbLw4cNOSDGQ58a8LG8U7Ob6edTx2hLw+5FUcIkNeC jPdvUxC+T4oG0Y+kQxaQLO3cOFJB/Q8GZrrIazptvP9mo2t9+9DuOopkl jYTVFbQR2Z1lO2nJyElEPfqPyqc0q8RBsb9fvhci4B3kVB9yydIjyRp1i E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAFR56E+tJV2Y/2dsb2JhbABEtiuBB4IYAQEBAwEBAQEPAR0KNBAHBAIBCBEEAQELBhcBBgEmHwkIAQEEARIIGodkBQuYdJ9QBIszhSJgA4hImwGBZoJ9 X-IronPort-AV: E=Sophos;i="4.77,471,1336348800"; d="scan'208";a="95674985" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-6.cisco.com with ESMTP; 25 Jun 2012 14:49:22 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q5PEnMOF024674; Mon, 25 Jun 2012 14:49:22 GMT Received: from xmb-rcd-202.cisco.com ([72.163.62.209]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 25 Jun 2012 09:49:22 -0500 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: Mon, 25 Jun 2012 09:49:20 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] Adoption of draft-djsmith-bgp-flowspec-oid-01 as IDR WGdocument Thread-Index: Ac1IwkZO1uzzMnW5RbKl+0e3S9wA5AKH0VMw References: <3BBED7A5-C064-4D80-B135-CC9B678BAF4D@juniper.net> From: "David Smith (djsmith)" To: "John G. Scudder" , X-OriginalArrivalTime: 25 Jun 2012 14:49:22.0828 (UTC) FILETIME=[B568DCC0:01CD52E1] Subject: Re: [Idr] Adoption of draft-djsmith-bgp-flowspec-oid-01 as IDR WGdocument X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2012 14:49:24 -0000 >Authors, please resubmit as draft-ietf-idr-bgp-flowspec-oid. Done. Also, the version just posted includes all WG feedback to date. Regards /dave -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of John G. Scudder Sent: Tuesday, June 12, 2012 1:38 PM To: idr@ietf.org List Cc: draft-djsmith-bgp-flowspec-oid@tools.ietf.org Subject: Re: [Idr] Adoption of draft-djsmith-bgp-flowspec-oid-01 as IDR WGdocument The draft is accepted as an IDR working group document. Authors, please resubmit as draft-ietf-idr-bgp-flowspec-oid. Thanks, --John=20 On May 16, 2012, at 3:40 PM, John Scudder wrote: > Folks, >=20 > We have received a request from the authors to adopt draft-djsmith-bgp-flowspec-oid-01 as an IDR WG document. Please send your comments to the list. The deadline for comments is June 1, 2012 at noon EDT. >=20 > Thanks, >=20 > --John _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From internet-drafts@ietf.org Mon Jun 25 11:23:06 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAC2511E8096; Mon, 25 Jun 2012 11:23:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.489 X-Spam-Level: X-Spam-Status: No, score=-102.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fmAN4SHYfzfO; Mon, 25 Jun 2012 11:23:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 860DB11E8086; Mon, 25 Jun 2012 11:22:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.21 Message-ID: <20120625182240.10015.46483.idtracker@ietfa.amsl.com> Date: Mon, 25 Jun 2012 11:22:40 -0700 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-bgp-flowspec-oid-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2012 18:23:07 -0000 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 : Revised Validation Procedure for BGP Flow Specifications Author(s) : James Uttaro Clarence Filsfils Pradosh Mohapatra David J. Smith Filename : draft-ietf-idr-bgp-flowspec-oid-00.txt Pages : 9 Date : 2012-06-25 Abstract: This document describes a modification to the validation procedure defined in RFC 5575 for the dissemination of BGP flow specifications. RFC 5575 requires that the originator of the flow specification matches the originator of the best-match unicast route for the destination prefix embedded in the flow specification. This allows only BGP speakers within the data forwarding path (such as autonomous system border routers) to originate BGP flow specifications. Though it is possible to disseminate such flow specifications directly from border routers, it may be operationally cumbersome in an autonomous system with a large number of border routers having complex BGP policies. The modification proposed herein enables flow specifications to be originated from a centralized BGP route controller. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-flowspec-oid There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-bgp-flowspec-oid-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ju1738@att.com Mon Jun 25 15:48:05 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0846321F8554; Mon, 25 Jun 2012 15:48:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.931 X-Spam-Level: X-Spam-Status: No, score=-105.931 tagged_above=-999 required=5 tests=[AWL=-0.159, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OXaoo3GbXan6; Mon, 25 Jun 2012 15:48:03 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id C9E8321F8592; Mon, 25 Jun 2012 15:48:02 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.11.0-10) over TLS secured channel with ESMTP id 2aae8ef4.0.369400.00-397.1009023.nbfkord-smmo05.seg.att.com (envelope-from ); Mon, 25 Jun 2012 22:48:03 +0000 (UTC) X-MXL-Hash: 4fe8eaa35910e810-babdfe16f318b4f2487e2e7b562ba50cb1ac0f9b Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q5PMm2fg003563; Mon, 25 Jun 2012 18:48:02 -0400 Received: from sflint01.pst.cso.att.com (sflint01.pst.cso.att.com [144.154.234.228]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q5PMlpYF003489 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Jun 2012 18:47:52 -0400 Received: from MISOUT7MSGHUB9F.ITServices.sbc.com (misout7msghub9f.itservices.sbc.com [144.151.223.71]) by sflint01.pst.cso.att.com (RSA Interceptor); Mon, 25 Jun 2012 18:47:36 -0400 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9F.ITServices.sbc.com ([144.151.223.71]) with mapi id 14.02.0298.004; Mon, 25 Jun 2012 18:47:36 -0400 From: "UTTARO, JAMES" To: "'Rob Shakir'" Thread-Topic: draft-ietf-grow-ops-reqs-for-bgp-error-handling-04 Thread-Index: Ac1Qh0AwzuLH5xBMSu2rz3aHemLX7wBK0QmAAAIbFGAAE+v4AABFsGbA Date: Mon, 25 Jun 2012 22:47:35 +0000 Message-ID: References: <52CBEC1F-49E6-4656-A617-CAB7304479F0@rob.sh> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.228.209] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=1.0 c=1 a=rBRfEN-fR5wA:10 a=81eWbNQ_HDgA:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=8nJEP1OIZ-IA:10 a=ZRNLZ4dFUbCvG8] X-AnalysisOut: [UMqPvVAA==:17 a=48vgC7mUAAAA:8 a=cXm1WQD8szEI92xSkW4A:9 a=] X-AnalysisOut: [wPNLvfGTeEIA:10 a=lZB815dzVvQA:10 a=cTsA3ETV5bvCB0Qt:21 a=] X-AnalysisOut: [S8P1yWJ-FUjRJRls:21] Cc: 'idr wg' , "'grow@ietf.org'" Subject: Re: [Idr] draft-ietf-grow-ops-reqs-for-bgp-error-handling-04 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2012 22:48:05 -0000 Rob, Comments In-Line.. Thanks, Jim Uttaro -----Original Message----- From: Rob Shakir [mailto:rjs@rob.sh]=20 Sent: Sunday, June 24, 2012 5:10 AM To: UTTARO, JAMES Cc: 'grow@ietf.org'; 'idr wg' Subject: Re: draft-ietf-grow-ops-reqs-for-bgp-error-handling-04 Hi Jim, Further comments in-line as [rjs]. On 24 Jun 2012, at 03:06, UTTARO, JAMES wrote: > 1. Conservative -- any error in messages received from a neighbour are in= dicative that it is not a viable route to any prefix it advertises. Therefo= re where error conditions occur, disconnect and remove all routes from the = neighbour from the RIB. >=20 > [Jim U>] This is based on the current behavior of BGP.. If the NH is stil= l viable you could allow the session to fall and persist the good state tha= t has already been learned.. [rjs]: Absolutely, this is the current behaviour. The problem with taking a= whole session down in this case is that you now take a risk of inconsisten= cy for all NLRI across that session for the duration that you hold onto the= learned NLRI. If one avoids being in the situation where the session is do= wn (e.g., by applying treat-as-withdraw behaviour in cases where one can de= termine the NLRI) then all other NLRI on the session continue to be updated= as they need to be. It is only the NLRI that were included in the erroneou= s UPDATE that may be affected for looping/black-holing. >>[Jim U>] The assumption being that the error was caused by an upstream sp= eaker and is therefore not truly indicative of an issue over the session wh= ere the error manifests itself. This seems to make sense in the IPV4 case. = I am still a bit concerned as I do not understand how the following is addr= essed. - There is no way of knowing if the adjacent peer is the speaker that is ac= tually responsible for the malformed attr or is coming from an upstream spe= aker. I can think of no way of knowing this.. Can it be inferred from the n= otion that an error is of the syntactic or semantic variety? - There seems to be no threshold when the session is actually taking out of= service. It would seem that some number of these type of errors would indi= cate a major issue is taking place and should be addressed by severing the = speaker that is advertising paths with the malformed attr into the topology= . A large number of these error will create a large number of withdrawn mes= sages being generated from many peers. What are your thoughts on how this s= hould be addressed? >> > I would expect all solutions implemented in response to these requirement= s to be optional. If the risk of incorrectness is unacceptable to you/an op= erator, then you should absolutely not enable any of these mechanisms. In a= number of networks that I have operated, designed and architected, I am pr= epared to accept the risk of incorrectness, as I consider it acceptable whe= n compared to the risk of complete service outages in terms of impact to my= customers during such incidents. At the moment, without the work described= through the requirements outlined in this draft I do not have the means to= make that call... > [Jim U>] I do not understand how it is possible to make this configurable= on a per session or AS basis..I would think all speakers participating in = a routing context would have to adhere to the same rules for a consistent v= iew across domains.. In my reading of the IDR draft it seems that it would = be a MUST.. Maybe I should not be considering that IDR draft as the actual = realization of the reqs.. [rjs]: The IDR draft is the solution for some of the requirements -- partic= ularly those described in Section 3 of the GROW draft. >>[Jim U>] Got it.. [rjs]: I do not see why this behaviour needs to be consistent across domain= s? >>[Jim U>] Can you explain this [rjs]: Essentially, if I receive an invalid UPDATE message, and apply treat= -as-withdraw, if the advertising speaker did not know that this was erroneo= us then I end up with a different view of what is in the RIB than the adver= tising speaker does. If this was a prefix I had no other route to, then I m= ay black-hole, if it was one where it was a more-specific of some larger pr= efix, then we end up with the potential for loops. >>[Jim U>] Yes.. I am not sure I like the notion of forwarding loops especi= ally for large flows..=20 [rjs]: If I am prepared to accept the black-holing or loops for the NLRI in= the erroneous UPDATE as a risk, in favour of keeping the remaining NLRI wo= rking (and being updated/withdrawn if they change), then this is a local de= cision and I do not need to imply any behaviour of the neighbouring domains= . >>[Jim U>] I guess what I meant was the other paths that are considered goo= d would be treated differently.. So in an environment where only paths with= the mal-formed attr are affected by this error condition as opposed to an = environment where all paths are affected ( withdrawn ) would create a incon= sistent view of the "good" paths across AS domains.. So not so much the "ba= d" paths but the "good" paths and how they may be treated differently.. >=20 >> Abstract >>=20 >> Can the scope be expanded? There are other failure modes, i.e Timer Expi= ry which today is not considered a failure mode. In reality what I have see= n is that timer expiry occurs due to the fact that BGP threads cannot be se= rviced in a timely manner. I think it would be best if we could put it all= on the table.. >>=20 >> I do think that this draft should bound the solution space. At the minim= um the solutions proposed should meet a minimum set of the operators criter= ia in terms of managing the network, convergence, persistence, churn, forwa= rding impact etc... =20 >=20 > I think there was clear consensus amongst operators with whom I have spok= en to work on the problem space of erroneous UPDATEs - particularly in resp= onse to observed incidents. The very real risk of expanding the scope of th= is document even further to handle any error in the BGP protocol is that we= spend another few years cataloguing such conditions, whilst doing nothing = about the ones that we have identified. > [Jim U>] No doubt.. But I have seen other errors that relate to overload= ing BGP, topological isolation etc... that have created huge outages in my = network.. So, My thinking is that we should try to consider all of the chal= lenges the protocol faces in terms of erroneous error conditions.=20 [rjs] Right, perhaps a better title for the draft would be "Operational Req= uirements for Enhanced Error Handling for UPDATE Messages in BGP-4" -- give= n that there were incidents that affected networks that particularly were f= ocused on the errors in UPDATEs, it seemed logical that this was the place = to start for this work.=20 >>[Jim U>] Agreed >=20 >> Section 1.1 >>=20 >> The following paragraph is based on the premise that the session being "= down" results in a large impact.. This is certainly true for today's implem= entations which use the session ( Control Plane Construct ) to determine th= e viability of the forwarding state learned over said session. There are ca= ses where this is the session and forwarding are parallel, but in many more= cases control and forwarding planes are orthogonal.. I think we need to re= -consider this assumption for many of the services BGP is being used for an= d base the response to error conditions on this reality.. >>=20 >> " Both within Internet and multi-service routing architectures, a >> number of BGP sessions propagate a large proportion of the required >> routing information for network operation. For Internet routing, >> these are typically BGP sessions which propagate the global routing >> table to an AS - failure of these sessions may have a large impact on >> network service, based on a single erroneous update. In an multi- >> service environment, typical deployments utilise a small number of >> core-facing BGP sessions, typically towards route reflector devices. >> Failure of these sessions may also result in a large impact to >> network operation. Clearly, the avoidance of conditions requiring >> these sessions to fail is of great utility to any network operator, >> and provides further motivation for the revision of the existing >> behaviour. " >=20 > I do not understand what the assertion that you are making here is. Pleas= e could you explain it to me? The errors that are being discussed relate to= where a subset of NLRI are advertised within an erroneous UPDATE message, = and the resulting impact of the current protocol behaviour on all other NLR= I carried on that session. The cases of IP "transit" sessions, and RR-PE se= ssions are only examples of cases where there is a large amount of routing = information carried over a single session - and hence it is of utility to a= void these sessions failing where they do not necessarily need to based on = the impact to overall network service. > [Jim U>] The solution space here seems explicitly targeted to the interne= t IPV4 AF. Not sure if there is a dependency here on the control/forwarding= planes being in parallel. I believe we need to consider all AFs that BGP i= s used for.. As the code that would be developed would be applicable to the= se AF also ( I presume ). So as an example would be RT-C, is this solution = applicable I don't know I am simply asking.. If we want to develop this and= have it specific to the internet use case lets state that clearly. If not,= then let's consider the other applications BGP supports.. [rjs] I'd say that it's not just applicable to IPv[46] in the Internet - bu= t to numerous AFIs (there is a definite use-case for these solutions in L3V= PN environments for instance). I am not saying that this is applicable or d= esirable to be turned on for all AFIs -- but it seems to me that this is a = per-operator, per-deployment decision, not a per-AFI one. For instance, if = we get an RTC UPDATE that is malformed, an operator may not want to tear do= wn a session if it also carries other AFIs (e.g., VPNv[46] also) - in that = case, the operator may want to treat this UPDATE as withdrawing the {as, ro= ute-target} NLRI (consider that we have no *standardised* multi-session mec= hanism yet, and there are potential scaling impacts of multiple sessions). >>[Jim U>] Quite honestly AFs such as RT-C, Flowspec, etc... where the info= being propagated is more akin to "configuration" not path info should pers= ist regardless of the session.. This goes to the heart of the discussion of= BGP is used for many fields of use that require persistence. It is not onl= y paths that use BGP for dissemination.. I would prefer that this solution = is limited to AFs that disseminate reachability/path info not configuration= info.. >>=20 >=20 > This point (to me anyway) seems entirely related to the control-plane -- = it points out that an operator has cases where one really wants to keep the= impact of errors down to the particular subset of routing information that= is affected. This point is entirely in the protocol, rather than implying = any behaviour about forwarding (i.e., no implication is made that the NLRI = identified as carried in the erroneous UPDATE are installed in the FIB, but= rather that all *other* NLRI continue to be installed in the RIB). > [Jim U>] See above.. My point is how can we ensure reliability across AFs= ...There is no doubt that mal-formed updates are an issue I just do not kno= w how they affect other AFs, in those case it may be more appropriate to te= ar down and persist instead. Can we address these other use cases? [rjs]: The consideration (that I see) that is missing from the draft w.r.t = this point seems to be more "what would break if one utilises treat-as-with= draw and this is not {IPv[46],VPNv[46]} etc. Is this what you feel needs to= be addressed? [rjs]: I think the general though process of: 1/ In some cases, we want avoid affecting all NLRI based on an error in a = subset of the received NLRI. 2/ In this case, we may need to recover from this inconsistency. 3/ In some cases, we may want to give a session a chance to restart where = we could not handle the error gracefully. 4/ When errors occur on these sessions, there is great operational benefit= of flagging them more explicitly. [rjs]: is applicable across all AFIs almost. The distinction is really whet= her one considers that 1/ is a valid behaviour/risk for an AFI?=20 >>[Jim U>] We need to look at AFs and decide what is the behavior required = for the content being disseminated..=20 >=20 > I'll work through the points that you have made in this mail -- but I'd l= ike to respond with a specific point here comparing more targeted handling = of errors in UPDATE messages with persistence-type approaches.=20 >=20 > - Persistence/hold-up is not acceptable to all operators in all deploymen= ts. Particularly, where no liveliness detection mechanism for the next-hop = is available (i.e., where it is not possible or practical to determine the = NH's reachability in the forwarding plane other than with with the routing = protocol itself) then one would not want to accept the risk of running pers= istence. > [Jim U>] Agreed.. Persistence requires that the NH be viable.=20 >=20 > - Therefore, an operator has two options for these deployments -- stick w= ith the error handling behaviour that is available in BGP right now, which = gives him no flexibility in terms of focusing responses to errors in a mann= er that is proportional to the actual error; or alternatively, accept some = additional complexity and risk such that particular error handling is targe= ted to the NLRI that are contained in an UPDATE message that is found to be= erroneous. > [Jim U>] My concern here is that the entire support structure is based on= session viability, the expectation here is that operators need to develop = new approaches to understanding if there is a routing anomaly in their topo= logy and develop tools/procedures which are different. [rjs]: Yes, this is true. We introduce a more complex failure mode where a = subset of prefixes are affected. *Any* new mechanism changing the tear-down= and flush-the-RIB behaviour of BGP will need some different approaches to = be developed. The intention of =A76 and =A77 of the draft is to highlight w= here things do become more complex and define requirements for ensuring tha= t the right toolset exists around this behaviour. [rjs]: Simplifying networks/removing complexity should always be a goal -- = but we need to understand where simple behaviour does not provide the lever= s to limit the impact of errors occurring, and balance the complexity of in= troducing new mechanisms against the benefit to our network's operation.=20 [rjs]: I would like to think that the document highlights where complexity = is being introduced -- and highlights the impact of turning some of these k= nobs on. If the complexity is not acceptable within a deployment, these mec= hanisms should not be deployed. However, where it is, we don't have the kno= bs to do anything today! If the document doesn't address this to your satis= faction, please let me know, and I'd be happy to make sure that the complex= ity is further highlighted. > Given there are deployments where I cannot deploy persistence (e.g., towa= rds an Internet network peer on an IXP where deployment of BFD/OAM mechanis= ms are very limited so BGP really tells me whether the other peer is "there= " at all) yet in these cases I do not want to affect all NLRI when one erro= neous UPDATE is received then it would seem that I need answers to the requ= irements in this draft.=20 > [Jim U>] Agreed..=20 >=20 > Your e-mail seems to imply that you do not have cases where you will not = be able to deploy persistence and that you are accepting of session-level e= rror handling in these cases. Would this be a fair assessment? > [Jim U>] My work primarily revolves around the following BGP use cases VP= N ( L2/L3 ), 3107, Multi-Cast, RT-C, Flowspec not Internet.. In these envir= onments I would prefer that the session fail, persistence is activated, and= well known procedures are used to correct the problem. I am in no way sayi= ng that the use case described here for the internet application is not via= ble or the correct approach.. But the fact remains that the code base will = be used across all AFs and this solution requires different OpS/Troubleshoo= ting knowledge and support. I would prefer consistency in the behavior..=20 [rjs]: I am involved in multiple network deployments across the company in = which I work, both public and private. I understand that there are differen= t requirements across different networks, and in different deployment cases= .=20 [rjs]: The problem of any mechanism is that it *may* be available for place= s where it is not applicable. We could analyse persistence and say that for= Internet deployments, it has the potential to be harmful -- a device that = has failed will continue to look like a valid path when it might not be, wh= ere a network in the Internet DFZ is likely to have a number of alternate p= aths that could be used. In my view, in this draft, we're just taking the "= lowest common denominator" approach - where we say, "how can we build mecha= nisms that could be applied across all AFIs?". I think in all the use cases= you mentioned, there are deployments where these mechanisms are applicable= . In all cases, one valid behaviour would be that we keep the subset of NLR= I that were not affected from a neighbour, but do not use those that are no= t necessarily trustworthy because they were linked to an invalid message in= the protocol. Of course, operationally, you may not want to do this, based= on the risk of inconsistency and the impact of failure. The key point here= is that my network deployment may differ to yours, and its up to both of u= s to decide for our networks, but we both need the tools to be able to make= these choices. The problem with a consistent approach is that I don't see = how we can have a consistent approach that isn't based on the lowest common= denominator AFI - and even then, our logic may differ in terms of where we= want to turn it on. Kind regards, r. From ietfc@btconnect.com Tue Jun 26 08:18:47 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D97B21F85DF for ; Tue, 26 Jun 2012 08:18:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.888 X-Spam-Level: X-Spam-Status: No, score=-3.888 tagged_above=-999 required=5 tests=[AWL=-0.289, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ffk+26TbtjVB for ; Tue, 26 Jun 2012 08:18:46 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe001.messaging.microsoft.com [213.199.154.204]) by ietfa.amsl.com (Postfix) with ESMTP id 67AE321F857D for ; Tue, 26 Jun 2012 08:18:46 -0700 (PDT) Received: from mail32-am1-R.bigfish.com (10.3.201.233) by AM1EHSOBE002.bigfish.com (10.3.204.22) with Microsoft SMTP Server id 14.1.225.23; Tue, 26 Jun 2012 15:17:05 +0000 Received: from mail32-am1 (localhost [127.0.0.1]) by mail32-am1-R.bigfish.com (Postfix) with ESMTP id ABAEC3400A9; Tue, 26 Jun 2012 15:17:04 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.224.141; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0702HT003.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -24 X-BigFish: PS-24(zz9371I1521I542M1432Izz1202hzz1033IL8275bh8275dhz2dh2a8h5a9h668h839hd24hf0ah304l) Received: from mail32-am1 (localhost.localdomain [127.0.0.1]) by mail32-am1 (MessageSwitch) id 1340723822452247_26887; Tue, 26 Jun 2012 15:17:02 +0000 (UTC) Received: from AM1EHSMHS003.bigfish.com (unknown [10.3.201.227]) by mail32-am1.bigfish.com (Postfix) with ESMTP id 6BF2916004C; Tue, 26 Jun 2012 15:17:02 +0000 (UTC) Received: from DB3PRD0702HT003.eurprd07.prod.outlook.com (157.55.224.141) by AM1EHSMHS003.bigfish.com (10.3.207.103) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 26 Jun 2012 15:17:00 +0000 Received: from DB3PRD0610HT002.eurprd06.prod.outlook.com (157.56.252.53) by pod51017.outlook.com (10.3.4.151) with Microsoft SMTP Server (TLS) id 14.15.86.1; Tue, 26 Jun 2012 15:18:40 +0000 Message-ID: <005501cd53ae$79a3b840$4001a8c0@gateway.2wire.net> From: t.petch To: Susan Hares , References: <003c01cd4b29$97d7b150$c78713f0$@ndzh.com> Date: Tue, 26 Jun 2012 16:09:38 +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-Originating-IP: [157.56.252.53] X-OriginatorOrg: btconnect.com Cc: "'John G. Scudder'" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 15:18:47 -0000 ----- Original Message ----- From: "Susan Hares" To: Cc: "'John G. Scudder'" Sent: Friday, June 15, 2012 8:03 PM > IDR WG and BGPers: > > While there is a strong debate on draft-uttaro-idr-bgp-persistence-01 as IDR > WG document, I do not see a clear consensus. We also did not get an > overwhelming number of you to hum either way (11 total). > > Since some of those who voted "no" have suggested alternate text to the > author, I would like to extend the time to consider this draft for 3 more > weeks. > > To accept the draft we need a few more of you to "hum" yes or "hum" no. I do not think that the draft should be adopted in its present form (I would call it "hum" no but the preceding sentence suggests that that would be a vote for adoption:-( It is too broad brush for a change to such a fundamental part of the Internet as BGP. I wonder if the consequences have been fully thought through and believe that the risk is thus too high. I would support a more tightly focussed I-D, perhaps aimed at a single SAFI or classified Experimental or .... In passing, I note that MPLS-TP has a positive requirement that the forwarding plane stays up when the control plane is recycled so the underlying idea is reasonable but the consequences need to be clearly spelled out. Tom Petch > > Sue Hares > > > From ietfc@btconnect.com Tue Jun 26 08:39:24 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7675F21F84FD for ; Tue, 26 Jun 2012 08:39:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.808 X-Spam-Level: X-Spam-Status: No, score=-3.808 tagged_above=-999 required=5 tests=[AWL=-0.209, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AxfEs2Mp3Lxd for ; Tue, 26 Jun 2012 08:39:23 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe001.messaging.microsoft.com [216.32.180.184]) by ietfa.amsl.com (Postfix) with ESMTP id 8F79421F84DF for ; Tue, 26 Jun 2012 08:39:23 -0700 (PDT) Received: from mail27-co1-R.bigfish.com (10.243.78.242) by CO1EHSOBE007.bigfish.com (10.243.66.70) with Microsoft SMTP Server id 14.1.225.23; Tue, 26 Jun 2012 15:37:42 +0000 Received: from mail27-co1 (localhost [127.0.0.1]) by mail27-co1-R.bigfish.com (Postfix) with ESMTP id D0C4514010E; Tue, 26 Jun 2012 15:37:41 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.224.141; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0702HT010.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -23 X-BigFish: PS-23(zz9371I542M1432Izz1202hzz8275ch1033IL8275dhz2dh2a8h5a9h668h839hd24hf0ah304l) Received: from mail27-co1 (localhost.localdomain [127.0.0.1]) by mail27-co1 (MessageSwitch) id 1340725060988052_15779; Tue, 26 Jun 2012 15:37:40 +0000 (UTC) Received: from CO1EHSMHS002.bigfish.com (unknown [10.243.78.229]) by mail27-co1.bigfish.com (Postfix) with ESMTP id EF07258007D; Tue, 26 Jun 2012 15:37:40 +0000 (UTC) Received: from DB3PRD0702HT010.eurprd07.prod.outlook.com (157.55.224.141) by CO1EHSMHS002.bigfish.com (10.243.66.12) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 26 Jun 2012 15:37:41 +0000 Received: from DB3PRD0610HT002.eurprd06.prod.outlook.com (157.56.252.53) by pod51017.outlook.com (10.3.4.178) with Microsoft SMTP Server (TLS) id 14.15.86.1; Tue, 26 Jun 2012 15:39:15 +0000 Message-ID: <00d801cd53b1$59e35580$4001a8c0@gateway.2wire.net> From: t.petch To: Shane Amante , References: Date: Tue, 26 Jun 2012 16:35:34 +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-Originating-IP: [157.56.252.53] X-OriginatorOrg: btconnect.com Subject: Re: [Idr] BGP's consistency model X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 15:39:24 -0000 ----- Original Message ----- From: "Shane Amante" To: Sent: Sunday, June 24, 2012 8:19 PM > In light of the work to, hopefully, define a good, all-encompassing 'error-handling solution', I think it may be useful to take a step back (or, up) and potentially consider that, ultimately, BGP is a protocol for synchronization of distributed databases across a collection of routers. Perhaps a question to be asked is: what type of consistency model does BGP have? Or, can it even be neatly classified as such? > > https://en.wikipedia.org/wiki/Consistency_(database_systems) following which link me tells me that "Wikipedia does not have an article with this exact name" which is probably a very good reference, but at the moment it is too subtle for me:-( Tom Petch > > Perhaps once this is or other more appropriate fundamental aspects are better understood, we can then begin to have a discussion around what are the "classes" and/or spectrum of solutions that could/should "naturally" address the error handling case(s). > > -shane > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > From ju1738@att.com Tue Jun 26 10:32:36 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D1B521F84FD for ; Tue, 26 Jun 2012 10:32:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.549 X-Spam-Level: X-Spam-Status: No, score=-106.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6U-nHmL94+hN for ; Tue, 26 Jun 2012 10:32:35 -0700 (PDT) Received: from nbfkord-smmo03.seg.att.com (nbfkord-smmo03.seg.att.com [209.65.160.84]) by ietfa.amsl.com (Postfix) with ESMTP id 81B6221F84DD for ; Tue, 26 Jun 2012 10:32:35 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo03.seg.att.com(mxl_mta-6.11.0-10) over TLS secured channel with ESMTP id 332f9ef4.0.578068.00-301.1585580.nbfkord-smmo03.seg.att.com (envelope-from ); Tue, 26 Jun 2012 17:32:35 +0000 (UTC) X-MXL-Hash: 4fe9f2337451aeb6-8c7efe44c7a36093ce22063f400296b73e6188d0 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q5QHWYtp026775; Tue, 26 Jun 2012 13:32:34 -0400 Received: from sflint01.pst.cso.att.com (sflint01.pst.cso.att.com [144.154.234.228]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q5QHWS6w026709 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Jun 2012 13:32:29 -0400 Received: from MISOUT7MSGHUB9C.ITServices.sbc.com (misout7msghub9c.itservices.sbc.com [144.151.223.82]) by sflint01.pst.cso.att.com (RSA Interceptor); Tue, 26 Jun 2012 13:32:12 -0400 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9C.ITServices.sbc.com ([144.151.223.82]) with mapi id 14.02.0298.004; Tue, 26 Jun 2012 13:32:12 -0400 From: "UTTARO, JAMES" To: "'Hannes Gredler'" , Robert Raszuk Thread-Topic: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks Thread-Index: AQHNUSRck+l8gfT21UKwm6XKZP3kKZcISIpQgAJXzzKAAj6Q8A== Date: Tue, 26 Jun 2012 17:32:11 +0000 Message-ID: References: <14C7F4F06DB5814AB0DE29716C4F6D6702DF7129F6@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <4FE623B3.4060906@raszuk.net> <20120625070729.GC21620@juniper.net> In-Reply-To: <20120625070729.GC21620@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.42.162] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=1.0 c=1 a=8EFNBVqcxkkA:10 a=ZQD3OTTxKqYA:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=ZRNLZ4dFUbCvG8] X-AnalysisOut: [UMqPvVAA==:17 a=OUXY8nFuAAAA:8 a=48vgC7mUAAAA:8 a=nnw-Qwel] X-AnalysisOut: [rf1kEW4v29IA:9 a=CjuIK1q_8ugA:10 a=peF9eE_zjQwA:10 a=lZB81] X-AnalysisOut: [5dzVvQA:10 a=gw2iapBC6Avd2zkd:21 a=EFDpkcg9Qq7MmaoX:21] Cc: "idr@ietf.org List" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 17:32:36 -0000 Hannes, "the "core behaviour" of the protocol (kill RIB entries right after session loss) is wrong. and since BGP has outgrown its original purpose (route 1K prefixes) vs. route 100Ks of prefixes, route unicast and multicast, route VPN/non-VPN, route non-routing related functionality it is just legitimate to discuss restart and persistence behaviour on a per AFI/SAFI basis" You have exactly captured where I am coming from in re the discussion about= persistence. As a standards group we must evolve our thinking to address h= ow BGP is being used today and anticipate its future use.=20 Jim Uttaro -----Original Message----- From: Hannes Gredler [mailto:hannes@juniper.net]=20 Sent: Monday, June 25, 2012 3:08 AM To: Robert Raszuk Cc: idr@ietf.org List; UTTARO, JAMES Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document -= 3 more weeks robert, On Sat, Jun 23, 2012 at 10:14:43PM +0200, Robert Raszuk wrote: | >IMO I think that folks need to come to the realization that BGP is | >being used in varied use cases, using the internet application as the | >only frame of reference or lens into the requirements for reliability is | >simply not appropriate or correct.. |=20 | + |=20 | >All of this being said, there are implementation bugs, overloading of | > BGP machinery etc.. that have occurred and will occur in the future.. |=20 |=20 | I think you need to realize that the key for any application is | solid IP reachability. well, there are some of us who believe that there are other ways of building a service architecture and (surprise !) the transport path not necessarily has to be IP. | You can realize any VPN to your customers without BGP being used as | a service bus for it. It is your choice or your vendor's choice as | you say to "overload BGP machinery" for everything. ^^^^^^^^^^^^^^^^^^^^^^^ is is really a smart thing to question over-and-over things that: a. have been decided 10+ years ago b. have proven to be useful =20 | Putting more and more questionable requirements on the only protocol | which provides such global IP reachability proves as a bad idea. It | makes the protocol more and more fragile. i'd consider the questionw around a. graceful control-plane restart and b. standardized handling of forwarding entries thereafter as something that should be answered for any protocol in the design phase; obviously BGP is lacking this and that's why we're getting our heads together ... | The motivation that various flavors of VPNs carried by BGP must be | up only proves that as number of people suggested in the past the | same BGP protocol should not be used for everything. | | The point is not that protocol will not be able to cope with the | requirement. The point is that it is wrong to keep changing it's | core behaviour because your VPN or VPLS service goes down. | | Moreover you now do not want to limit the changes only to your | services SAFI, but argue to "enhance" all AFI/SAFIs with it. That is | something very hard to agree with. the "core behaviour" of the protocol (kill RIB entries right after session loss) is wrong. and since BGP has outgrown its original purpose (route 1K prefixes) vs. route 100Ks of prefixes, route unicast and multicast, route VPN/non-VPN, route non-routing related functionality it is just letigimate to discuss restart and persistence behaviour on a per AFI/SAFI basis. tx, /hannes From tony.li@tony.li Tue Jun 26 10:47:52 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2E8E11E8095 for ; Tue, 26 Jun 2012 10:47:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OLD9v38CDg7O for ; Tue, 26 Jun 2012 10:47:51 -0700 (PDT) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [76.96.59.228]) by ietfa.amsl.com (Postfix) with ESMTP id EAA8611E8098 for ; Tue, 26 Jun 2012 10:47:50 -0700 (PDT) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta15.westchester.pa.mail.comcast.net with comcast id Sywi1j0091ei1Bg5F5nreo; Tue, 26 Jun 2012 17:47:51 +0000 Received: from [10.10.201.222] ([24.43.229.254]) by omta24.westchester.pa.mail.comcast.net with comcast id T5nU1j01a5VyHgg3k5nbSg; Tue, 26 Jun 2012 17:47:49 +0000 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Tony Li In-Reply-To: Date: Tue, 26 Jun 2012 07:47:25 -1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <14C7F4F06DB5814AB0DE29716C4F6D6702DF7129F6@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <4FE623B3.4060906@raszuk.net> <20120625070729.GC21620@juniper.net> To: "UTTARO, JAMES" X-Mailer: Apple Mail (2.1278) Cc: Robert Raszuk , "idr@ietf.org List" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 17:47:52 -0000 On Jun 26, 2012, at 7:32 AM, UTTARO, JAMES wrote: > You have exactly captured where I am coming from in re the discussion = about persistence. As a standards group we must evolve our thinking to = address how BGP is being used today and anticipate its future use.=20 Perhaps we should consider the overall routing architecture of the = Internet, the role that BGP plays within that architecture, and how = major modifications might have implications to the architecture. Regards, Tony From brian.peter.dickson@gmail.com Tue Jun 26 10:55:03 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98B6021F84D8 for ; Tue, 26 Jun 2012 10:55:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S5rRz9Ly3PmF for ; Tue, 26 Jun 2012 10:55:02 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 4AE2121F8491 for ; Tue, 26 Jun 2012 10:55:02 -0700 (PDT) Received: by wibhr14 with SMTP id hr14so155502wib.13 for ; Tue, 26 Jun 2012 10:55:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uqWDVQECZMMNPiNl/OQJBOFmpz3CQ6SQT9iajHJs7w4=; b=FJW3whp5niOhtyL6++jUpFvdCKcZ7hbj/wrIjGe2ubWyzceX+A5YucuPKEh8YrDf0U 08cgK1Rg7EEaAcwAbqAanftDTx6W6bYSza2u8QuqiCIekPKQMRXVFLUgcuM/otL6zEHv IQpLkGFCoYPoJ0tkVbVgyYnyIBnL9GHX4YWcPhey2kkXp+hMYYAmBXje3aD7ywofcJGW a5/XNMrvFiV7luJVWHklKrZaaZc1aWZCqLwfnulIrcmVWyPX9S75+sf5AvOKyUHcb09I t0h1DI8YZaL9jisrfogur3E2+wQsILZ9sZ5NbE8f+YjaDbremo7uR1Q6vf3jt+MjIu/o vhLQ== MIME-Version: 1.0 Received: by 10.180.86.194 with SMTP id r2mr34458762wiz.15.1340733301411; Tue, 26 Jun 2012 10:55:01 -0700 (PDT) Received: by 10.223.39.19 with HTTP; Tue, 26 Jun 2012 10:55:01 -0700 (PDT) In-Reply-To: References: Date: Tue, 26 Jun 2012 13:55:01 -0400 Message-ID: From: Brian Dickson To: Shane Amante Content-Type: multipart/alternative; boundary=f46d044286dc2b4ffa04c363cc7d Cc: "idr@ietf.org List" Subject: Re: [Idr] BGP's consistency model X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 17:55:03 -0000 --f46d044286dc2b4ffa04c363cc7d Content-Type: text/plain; charset=ISO-8859-1 On Sun, Jun 24, 2012 at 3:19 PM, Shane Amante wrote: > In light of the work to, hopefully, define a good, all-encompassing > 'error-handling solution', I think it may be useful to take a step back > (or, up) and potentially consider that, ultimately, BGP is a protocol for > synchronization of distributed databases across a collection of routers. > Perhaps a question to be asked is: what type of consistency model does BGP > have? Or, can it even be neatly classified as such? > > https://en.wikipedia.org/wiki/Consistency_(database_systems) > > IMHO, the following characteristics apply: 1. The "cell" (i.e. granularity on which synchronization needs to operate) is the NLRI (aka "prefix/length" as primary key) 2. The "data" aren't universal, but rather behave much like rays of light in a 3D CGI model 3. The results require deterministic behavior, so it needs to be at least "sequential", or perhaps as strong as "serializable". Indeed, within a given BGP process, it should be treated as SS2PL (strong sequential 2-phase locking). Only correct processing of updates (without error conditions being reached) should result in change-of-state, which then atomically happens with possible propagation to appropriate neighbors. Since each NLRI is effectively orthogonal, parallel processing at the NLRI level of granularity could be done - but all RIB-IN instances need to be available for each parallel node (if there are multiple "processors" doing update handling). At a given instant in time, system-wide it might appear like "causal" consistency - but it needs to be seen as a flaw in the current BGP design, rather than truly a feature. System-wide, convergence (if/when it happens) to steady-state delivers "serialize" consistency. Brian > Perhaps once this is or other more appropriate fundamental aspects are > better understood, we can then begin to have a discussion around what are > the "classes" and/or spectrum of solutions that could/should "naturally" > address the error handling case(s). > > -shane > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --f46d044286dc2b4ffa04c363cc7d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sun, Jun 24, 2012 at 3:19 PM, Shane Amante <shane@castlepoint.net> wrote:
In light of the work to, hopefully, define a good, all-encompassing 'er= ror-handling solution', I think it may be useful to take a step back (o= r, up) and potentially consider that, ultimately, BGP is a protocol for syn= chronization of distributed databases across a collection of routers. =A0Pe= rhaps a question to be asked is: what type of consistency model does BGP ha= ve? =A0Or, can it even be neatly classified as such?

https://en.wikipedia.org/wiki/Consistency_(database_systems= )


IMHO, the following characteristics ap= ply:
  1. The "cell" (i.e. granularity on which sync= hronization needs to operate) is the NLRI (aka "prefix/length" as= primary key)
  2. The "data" aren't universal, but rather behave much like = rays of light in a 3D CGI model
  3. The results require deterministic b= ehavior, so it needs to be at least "sequential", or perhaps as s= trong as "serializable". Indeed, within a given BGP process, it s= hould be treated as SS2PL (strong sequential 2-phase locking). Only correct= processing of updates (without error conditions being reached) should resu= lt in change-of-state, which then atomically happens with possible propagat= ion to appropriate neighbors.
Since each NLRI is effectively orthogonal, parallel processing at= the NLRI level of granularity could be done - but all RIB-IN instances nee= d to be available for each parallel node (if there are multiple "proce= ssors" doing update handling).

At a given instant in time, system-wide it might = appear like "causal" consistency - but it needs to be seen as a f= law in the current BGP design, rather than truly a feature. System-wide, co= nvergence (if/when it happens) to steady-state delivers "serialize&quo= t; consistency.

Brian

=A0
Perhaps once this is or other more appropriate fundamental aspects are bett= er understood, we can then begin to have a discussion around what are the &= quot;classes" and/or spectrum of solutions that could/should "nat= urally" address the error handling case(s).

-shane
_______________________________________________
Idr mailing list
Idr@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/idr

--f46d044286dc2b4ffa04c363cc7d-- From ju1738@att.com Tue Jun 26 10:55:59 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0361811E8099 for ; Tue, 26 Jun 2012 10:55:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.556 X-Spam-Level: X-Spam-Status: No, score=-106.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wzQ8gm8iOuYn for ; Tue, 26 Jun 2012 10:55:58 -0700 (PDT) Received: from nbfkord-smmo08.seg.att.com (nbfkord-smmo08.seg.att.com [209.65.160.95]) by ietfa.amsl.com (Postfix) with ESMTP id B594B11E8097 for ; Tue, 26 Jun 2012 10:55:57 -0700 (PDT) Received: from unknown [144.160.128.153] (EHLO flpi408.enaf.ffdc.sbc.com) by nbfkord-smmo08.seg.att.com(mxl_mta-6.11.0-10) over TLS secured channel with ESMTP id da7f9ef4.0.4287686.00-221.11778780.nbfkord-smmo08.seg.att.com (envelope-from ); Tue, 26 Jun 2012 17:55:58 +0000 (UTC) X-MXL-Hash: 4fe9f7ae68a0410c-9c3335679e56b6dc91b3260bdb3b8f2b0f6a26c6 Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q5QHttqt002432; Tue, 26 Jun 2012 10:55:56 -0700 Received: from fflint03.pst.cso.att.com (fflint03.pst.cso.att.com [150.234.39.63]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q5QHthAm002232 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Jun 2012 10:55:48 -0700 Received: from MISOUT7MSGHUB9D.ITServices.sbc.com (misout7msghub9d.itservices.sbc.com [144.151.223.93]) by fflint03.pst.cso.att.com (RSA Interceptor); Tue, 26 Jun 2012 10:55:16 -0700 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9D.ITServices.sbc.com ([144.151.223.93]) with mapi id 14.02.0298.004; Tue, 26 Jun 2012 13:55:15 -0400 From: "UTTARO, JAMES" To: "'Tony Li'" Thread-Topic: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks Thread-Index: AQHNU8PVnolFlBQMoUCKeM5al70s85cM4L0w Date: Tue, 26 Jun 2012 17:55:15 +0000 Message-ID: References: <14C7F4F06DB5814AB0DE29716C4F6D6702DF7129F6@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <4FE623B3.4060906@raszuk.net> <20120625070729.GC21620@juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.42.162] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.128.153] X-AnalysisOut: [v=1.0 c=1 a=8EFNBVqcxkkA:10 a=ZQD3OTTxKqYA:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=xwOvzTHDVLE4u4] X-AnalysisOut: [nGvK72ag==:17 a=48vgC7mUAAAA:8 a=PEo-fea6D_J9Gc1WO1kA:9 a=] X-AnalysisOut: [CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=WHHgN93wCaGzIICG:21 a=] X-AnalysisOut: [QrafOzRQ9UlSUqf9:21] Cc: "idr@ietf.org List" , Robert Raszuk Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 17:55:59 -0000 Tony, I am in no way minimizing the effect of changing a base assumption in re p= ersistence as it applies to the internet although it seems that the IETF co= mmunity has accepted GR which is also creates a persistence paradigm for a = smaller amount of time.. As stated in the BGP Persistence draft IPV4 is not= a candidate use case, but there are other use cases which require it.=20 How do you think we should proceed? Should the draft explicitly state that = the internet use case is a MUST NOT? The 3107 use case is labeled IPv4 whic= h has persistence requirements also so I do not know how that could actuall= y be done.. Jim Uttaro -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Tony = Li Sent: Tuesday, June 26, 2012 1:47 PM To: UTTARO, JAMES Cc: Robert Raszuk; idr@ietf.org List Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document -= 3 more weeks On Jun 26, 2012, at 7:32 AM, UTTARO, JAMES wrote: > You have exactly captured where I am coming from in re the discussion abo= ut persistence. As a standards group we must evolve our thinking to address= how BGP is being used today and anticipate its future use.=20 Perhaps we should consider the overall routing architecture of the Internet= , the role that BGP plays within that architecture, and how major modificat= ions might have implications to the architecture. Regards, Tony _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From brian.peter.dickson@gmail.com Tue Jun 26 13:20:18 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE6E811E80C5 for ; Tue, 26 Jun 2012 13:20:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6IYmRsMxcSY7 for ; Tue, 26 Jun 2012 13:20:17 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 9716C11E809C for ; Tue, 26 Jun 2012 13:20:16 -0700 (PDT) Received: by wibhr14 with SMTP id hr14so263044wib.13 for ; Tue, 26 Jun 2012 13:20:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/a9O5RDHvay3WTLLtXS4BHkeDTNaBJhd/D8G/AqBr78=; b=OsT7wl6wIYF7XthFvfpu9LBXxRYevsNyqiDyco+hUGOR07wI5LcIsKhpK7uHG8KeoX U79kq2yXPnry7qj4tyvtAwxhCk/+nNLlgpIBV9+LHIA8Tw66sGaNpoT4CK//bmp4H+Dp iGT1I70Cp7KTPxMQnysPzrDyfpRueg4tbd+jCIOcgBHzQpTkZLkqwrusXfUgZoqXTbxY /rhcoGRh7zFcfZLg3RjjrLpWEjL4r7c9KPOgSp3Ui+vbQRrZS4l3E2xBWxwG1p2N7Qn5 WJOkxfxyxULFPuj7om+M0YgSgj4sKeDDX91Pefwq8D3cQOwliAikmJkGxt3mJNrBPTRG TM5Q== MIME-Version: 1.0 Received: by 10.180.97.135 with SMTP id ea7mr3517384wib.11.1340742015501; Tue, 26 Jun 2012 13:20:15 -0700 (PDT) Received: by 10.223.39.19 with HTTP; Tue, 26 Jun 2012 13:20:15 -0700 (PDT) In-Reply-To: References: <14C7F4F06DB5814AB0DE29716C4F6D6702DF7129F6@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <4FE623B3.4060906@raszuk.net> <20120625070729.GC21620@juniper.net> Date: Tue, 26 Jun 2012 16:20:15 -0400 Message-ID: From: Brian Dickson To: "idr@ietf.org List" Content-Type: multipart/alternative; boundary=f46d043bdb4e91c49f04c365d398 Cc: Tony Li , "UTTARO, JAMES" , Robert Raszuk Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 20:20:18 -0000 --f46d043bdb4e91c49f04c365d398 Content-Type: text/plain; charset=ISO-8859-1 I am not in favor of adoption - "hum" == no. I am sympathetic to the author(s), however. There are places where state information can be traded off for stability and performance, but this isn't it, IMHO. (Also, I hope at some point to revisit stuff from a few years ago, work on improving stability/performance/convergence, at the cost of modest amount of state, in the near future, but no promises just yet.) And Tony is, as usual, spot on. Brian (And yes, I've operated very big networks with lots of prefixes, and have a ton of deep BGP experience. Not that we're measuring anything.) (FWIW, I'd be happy to assist, Jim, in exchange for beer(s), if you're in N. VA area. Contact me off-list.) On Tue, Jun 26, 2012 at 1:47 PM, Tony Li wrote: > > On Jun 26, 2012, at 7:32 AM, UTTARO, JAMES wrote: > > > You have exactly captured where I am coming from in re the discussion > about persistence. As a standards group we must evolve our thinking to > address how BGP is being used today and anticipate its future use. > > > Perhaps we should consider the overall routing architecture of the > Internet, the role that BGP plays within that architecture, and how major > modifications might have implications to the architecture. > > Regards, > Tony > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --f46d043bdb4e91c49f04c365d398 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I am not in favor of adoption - "hum" =3D=3D no. I am sympathetic= to the author(s), however.

There are places where s= tate information can be traded off for stability and performance, but this = isn't it, IMHO.

(Also, I hope at some point to revisit stuff from a few= years ago, work on improving stability/performance/convergence,
= at the cost of modest amount of state, in the near future, but no promises = just yet.)

And Tony is, as usual, spot on.

Brian
(And yes, I've operated very big networks with lots o= f prefixes, and have a ton of deep BGP experience. Not that we're measu= ring anything.)

(FWIW, I'd be happy to assist, Jim, in exchange for= beer(s), if you're in N. VA area. Contact me off-list.)

=


On Tue, Jun 26, 2012 at 1:47 = PM, Tony Li <tony.li@tony.li> wrote:

On Jun 26, 2012, at 7:32 AM, UTTARO, JAMES wrote:

> You have exactly captured where I am coming from in re the discussion = about persistence. As a standards group we must evolve our thinking to addr= ess how BGP is being used today and anticipate its future use.


Perhaps we should consider the overall routing architecture of the In= ternet, the role that BGP plays within that architecture, and how major mod= ifications might have implications to the architecture.

Regards,
Tony

_______________________________________________
Idr mailing list
Idr@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/idr

--f46d043bdb4e91c49f04c365d398-- From adam.simpson@alcatel-lucent.com Tue Jun 26 14:10:42 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E061C11E80EC for ; Tue, 26 Jun 2012 14:10:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.488 X-Spam-Level: X-Spam-Status: No, score=-9.488 tagged_above=-999 required=5 tests=[AWL=1.110, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4sA5s35q7m1G for ; Tue, 26 Jun 2012 14:10:38 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 58C0F11E80EB for ; Tue, 26 Jun 2012 14:10:38 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id q5QLAbkU027026 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 26 Jun 2012 16:10:37 -0500 (CDT) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q5QLAae7009391 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 26 Jun 2012 16:10:37 -0500 Received: from USNAVSXCHMBSC1.ndc.alcatel-lucent.com ([135.3.39.147]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Tue, 26 Jun 2012 16:10:36 -0500 From: "Simpson, Adam (Adam)" To: "idr@ietf.org" Date: Tue, 26 Jun 2012 16:10:35 -0500 Thread-Topic: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks Thread-Index: Ac1LKKslUprHg2opQAqhsJ0zGwTtpQIpRDCg Message-ID: References: <003c01cd4b29$97d7b150$c78713f0$@ndzh.com> In-Reply-To: <003c01cd4b29$97d7b150$c78713f0$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_E0A8451817EDC4488A15B7858D43F766200C5A8B83USNAVSXCHMBSC_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 21:10:42 -0000 --_000_E0A8451817EDC4488A15B7858D43F766200C5A8B83USNAVSXCHMBSC_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have been following the debate on this draft fairly carefully, and even t= hough I am one of the authors, I have tried to be as open-minded as possibl= e to the different points of view. I can see that some of the text in draft= -01 is too loose - particularly around limiting the advertisement scope of= the Stale community and deciding what to do at the boundaries of the persi= stence domain, interaction with the approaches described in draft-ietf-idr-= error-handling, and minimizing churn when there are repeated resets of a "p= ersistence-enabled" session. But Bruno, Jim and John have already started t= o indicate how a draft-02 version could/would address these points and in m= y mind those changes would alleviate a lot of the concerns. I don't want to= enter the debate about how unlikely a catastrophic control plane failure (= decoupled from forwarding) is relative to other 'rare' events such as malfo= rmed Update packets, etc. because I know that no two networks are exactly t= he same and I know that just because something hasn't happened to me yet do= esn't mean it can't happen to me in the future. Finally - to those that hav= e argued that adding BGP persistence into router software code has the pote= ntial to introduce new bugs and other unintended consequences I won't deny = this is a possibility but from an implementer's perspective BGP persistence= appears to be a much simpler and straightforward code change (conceptually= it has shared elements with GR and graceful shutdown) than say the code ch= anges implied by draft-ietf-idr-error-handling. This is not to argue for on= e vs. the other - I think they can be complementary - but I think this pers= pective is important. -Adam From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Susan= Hares Sent: Friday, June 15, 2012 3:04 PM To: idr@ietf.org Cc: 'John G. Scudder' Subject: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 m= ore weeks IDR WG and BGPers: While there is a strong debate on draft-uttaro-idr-bgp-persistence-01 as ID= R WG document, I do not see a clear consensus. We also did not get an over= whelming number of you to hum either way (11 total). Since some of those who voted "no" have suggested alternate text to the aut= hor, I would like to extend the time to consider this draft for 3 more week= s. To accept the draft we need a few more of you to "hum" yes or "hum" no. Sue Hares --_000_E0A8451817EDC4488A15B7858D43F766200C5A8B83USNAVSXCHMBSC_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have been following the debate on this draft fairly careful= ly, and even though I am one of the authors, I have tried to be as open-min= ded as possible to the different points of view. I can see that some of the= text in draft-01 is too loose – particularly around limiting the &nb= sp;advertisement scope of the Stale community and deciding what to do at th= e boundaries of the persistence domain, interaction with the approaches des= cribed in draft-ietf-idr-error-handling, and minimizing churn when there ar= e repeated resets of a “persistence-enabled” session. But Bruno= , Jim and John have already started to indicate how a draft-02 version coul= d/would address these points and in my mind those changes would alleviate a= lot of the concerns. I don’t want to enter the debate about how unli= kely a catastrophic control plane failure (decoupled from forwarding) is re= lative to other ‘rare’ events such as malformed Update packets,= etc. because I know that no two networks are exactly the same and I know t= hat just because something hasn’t happened to me yet doesn’t me= an it can’t happen to me in the future. Finally - to those that have = argued that adding BGP persistence into router software code has the potent= ial to introduce new bugs and other unintended consequences I won’t d= eny this is a possibility but from an implementer’s perspective BGP p= ersistence appears to be a much simpler and straightforward code change (co= nceptually it has shared elements with GR and graceful shutdown) than say t= he code changes implied by draft-ietf-idr-error-handling. This is not to ar= gue for one vs. the other – I think they can be complementary –= but I think this perspective is important.

 

-Adam

<= p class=3DMsoNormal> <= /p>

 

 =

From: idr-bounces@ietf.org [mai= lto:idr-bounces@ietf.org] On Behalf Of Susan Hares
Sent: F= riday, June 15, 2012 3:04 PM
To: idr@ietf.org
Cc: 'John= G. Scudder'
Subject: [Idr] draft-uttaro-idr-bgp-persistence-01 a= s IDR WG document - 3 more weeks

 

IDR WG and BGPers:

 

While there is a strong debate o= n draft-uttaro-idr-bgp-persistence-01 as IDR WG document, I do not see a cl= ear consensus.  We also did not get an overwhelming number of you to h= um either way (11 total).

 

Since some of those who voted “no” have suggested al= ternate text to the author, I would like to extend the time to consider thi= s draft for 3 more weeks.

 

To accept the draft we need a few more of you to “hum̶= 1; yes or “hum” no.

=  

Sue Hares

 

 

= --_000_E0A8451817EDC4488A15B7858D43F766200C5A8B83USNAVSXCHMBSC_-- From jakob.heitz@ericsson.com Tue Jun 26 14:44:31 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3503621F85C2 for ; Tue, 26 Jun 2012 14:44:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.42 X-Spam-Level: X-Spam-Status: No, score=-6.42 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NkEWa8UBy3u0 for ; Tue, 26 Jun 2012 14:44:30 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 4FDEA21F85BB for ; Tue, 26 Jun 2012 14:44:30 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q5QLiOg1013542 for ; Tue, 26 Jun 2012 16:44:29 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([147.117.20.26]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Tue, 26 Jun 2012 17:44:29 -0400 From: Jakob Heitz To: "idr@ietf.org" Date: Tue, 26 Jun 2012 17:44:26 -0400 Thread-Topic: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks Thread-Index: Ac1RtRvZ9EZwefrQRMeNKB0Y/zEBywAz0HGQ Message-ID: <7309FCBCAE981B43ABBE69B31C8D21392437F56D23@EUSAACMS0701.eamcs.ericsson.se> References: <003c01cd4b29$97d7b150$c78713f0$@ndzh.com> <4FE0E074.3070905@raszuk.net> <17490_1340180565_4FE18855_17490_15423_1_53C29892C857584299CBF5D05346208A0928AA@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FE18A61.8000405@raszuk.net> <8ED5B0B0F5B4854A912480C1521F973AD95B@xmb-rcd-x13.cisco.com> <4FE4A8F3.20809@cisco.com> <4FE4AFE2.3030107@cisco.com> <4FE6441F.2050901@cisco.com> <4FE68269.4070704@cisco.com> In-Reply-To: <4FE68269.4070704@cisco.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 Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 21:44:31 -0000 To address the problem of retaining BGP routes after failure of the BGP session, I am preparing a draft that starts like this: When a BGP session terminates, the standard response is to delete all information learnt from that session. Even when a BGP session fails, the routes learnt from it may still be viable. To maintain network connectivity, it is desirable to retain routes as long as their viability can be assured. If the next-hop is reachable, then we can send it a message to ask. I can understand the desire to keep STALE routes. The objection I see is that the viability of a STALE route is not assured. If a simple enough protocol can be developed to verify route viability, it would provide extra confidence for STALE routes. Is there interest to develop this? =20 --=20 Jakob Heitz. From robert@raszuk.net Tue Jun 26 15:06:56 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC70921F85C7 for ; Tue, 26 Jun 2012 15:06:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yAcQ0OOvDjMD for ; Tue, 26 Jun 2012 15:06:56 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id B7E2E21F8599 for ; Tue, 26 Jun 2012 15:06:55 -0700 (PDT) Received: (qmail 21267 invoked by uid 399); 26 Jun 2012 22:06:55 -0000 Received: from unknown (HELO ?192.168.1.58?) (pbs:m42@mojaklasa.info@83.31.246.166) by mail1310.opentransfer.com with ESMTPM; 26 Jun 2012 22:06:55 -0000 X-Originating-IP: 83.31.246.166 Message-ID: <4FEA327F.3040208@raszuk.net> Date: Wed, 27 Jun 2012 00:06:55 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Jakob Heitz References: <003c01cd4b29$97d7b150$c78713f0$@ndzh.com> <4FE0E074.3070905@raszuk.net> <17490_1340180565_4FE18855_17490_15423_1_53C29892C857584299CBF5D05346208A0928AA@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FE18A61.8000405@raszuk.net> <8ED5B0B0F5B4854A912480C1521F973AD95B@xmb-rcd-x13.cisco.com> <4FE4A8F3.20809@cisco.com> <4FE4AFE2.3030107@cisco.com> <4FE6441F.2050901@cisco.com> <4FE68269.4070704@cisco.com> <7309FCBCAE981B43ABBE69B31C8D21392437F56D23@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21392437F56D23@EUSAACMS0701.eamcs.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr@ietf.org Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 22:06:56 -0000 Hi Jakob, I think this is a basic assumption even for the current persistence draft version that next hop is reachable in the RIB. The draft fails to discuss what happens if we are dealing with double or N-level BGP recursion though. However let me point out that next hop reachability from control plane RR point of view - which is not in the data path - does not really mean that all of it's clients would have an identical view. For that there is existing draft already proposed which allows RR to get next hop cost and reachability information from it's clients: http://goo.gl/jQfnB "Carrying next-hop cost information in BGP" Perhaps it could be reused. Thx, R. > To address the problem of retaining BGP routes after > failure of the BGP session, I am preparing a draft > that starts like this: > > When a BGP session terminates, the standard response is to delete all > information learnt from that session. Even when a BGP session fails, > the routes learnt from it may still be viable. To maintain network > connectivity, it is desirable to retain routes as long as their > viability can be assured. > > If the next-hop is reachable, then we can send it a message to ask. > > I can understand the desire to keep STALE routes. > The objection I see is that the viability of a STALE route is not assured. > If a simple enough protocol can be developed to verify route viability, > it would provide extra confidence for STALE routes. > > Is there interest to develop this? > > From jakob.heitz@ericsson.com Tue Jun 26 15:10:40 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E51521F8440 for ; Tue, 26 Jun 2012 15:10:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.438 X-Spam-Level: X-Spam-Status: No, score=-6.438 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 404gq47RwGFM for ; Tue, 26 Jun 2012 15:10:39 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 83C9021F842C for ; Tue, 26 Jun 2012 15:10:39 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q5QMAWvM018416; Tue, 26 Jun 2012 17:10:34 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.215]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Tue, 26 Jun 2012 18:10:27 -0400 From: Jakob Heitz To: "robert@raszuk.net" Date: Tue, 26 Jun 2012 18:10:23 -0400 Thread-Topic: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks Thread-Index: Ac1T6AeC9c992GXdRbuUb2wh3qdCbAAADx2A Message-ID: <7309FCBCAE981B43ABBE69B31C8D21392437F56D6A@EUSAACMS0701.eamcs.ericsson.se> References: <003c01cd4b29$97d7b150$c78713f0$@ndzh.com> <4FE0E074.3070905@raszuk.net> <17490_1340180565_4FE18855_17490_15423_1_53C29892C857584299CBF5D05346208A0928AA@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FE18A61.8000405@raszuk.net> <8ED5B0B0F5B4854A912480C1521F973AD95B@xmb-rcd-x13.cisco.com> <4FE4A8F3.20809@cisco.com> <4FE4AFE2.3030107@cisco.com> <4FE6441F.2050901@cisco.com> <4FE68269.4070704@cisco.com> <7309FCBCAE981B43ABBE69B31C8D21392437F56D23@EUSAACMS0701.eamcs.ericsson.se> <4FEA327F.3040208@raszuk.net> In-Reply-To: <4FEA327F.3040208@raszuk.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "idr@ietf.org" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 22:10:40 -0000 This is not about next-hop reachability. It is the next step. Ask the nexthop if the route is viable. Not with BGP. This is for use when BGP is dead. On Tuesday, June 26, 2012 3:07 PM, Robert Raszuk = wrote: > Hi Jakob, >=20 > I think this is a basic assumption even for the current persistence > draft version that next hop is reachable in the RIB. >=20 > The draft fails to discuss what happens if we are dealing with double > or=20 > N-level BGP recursion though. >=20 > However let me point out that next hop reachability from control plane > RR point of view - which is not in the data path - does not really > mean=20 > that all of it's clients would have an identical view. >=20 > For that there is existing draft already proposed which allows RR to > get=20 > next hop cost and reachability information from it's clients: > http://goo.gl/jQfnB "Carrying next-hop cost information in BGP" >=20 > Perhaps it could be reused. >=20 > Thx, > R. >=20 >=20 >> To address the problem of retaining BGP routes after >> failure of the BGP session, I am preparing a draft >> that starts like this: >>=20 >> When a BGP session terminates, the standard response is to >> delete all information learnt from that session. Even when a BGP >> session fails, the routes learnt from it may still be viable. To >> maintain network connectivity, it is desirable to retain routes >> as long as their viability can be assured.=20 >>=20 >> If the next-hop is reachable, then we can send it a message to >> ask.=20 >>=20 >> I can understand the desire to keep STALE routes. >> The objection I see is that the viability of a STALE route is not >> assured. If a simple enough protocol can be developed to verify >> route viability, it would provide extra confidence for STALE routes. >>=20 >> Is there interest to develop this? --=20 Jakob Heitz. x25475. 510-566-2901= From robert@raszuk.net Tue Jun 26 15:17:38 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FE6D11E809F for ; Tue, 26 Jun 2012 15:17:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7kNyMZ5tIZk0 for ; Tue, 26 Jun 2012 15:17:37 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 538AA11E8097 for ; Tue, 26 Jun 2012 15:17:37 -0700 (PDT) Received: (qmail 2930 invoked by uid 399); 26 Jun 2012 22:17:36 -0000 Received: from unknown (HELO ?192.168.1.58?) (pbs:robert@raszuk.net@83.31.246.166) by mail1310.opentransfer.com with ESMTPM; 26 Jun 2012 22:17:36 -0000 X-Originating-IP: 83.31.246.166 Message-ID: <4FEA3501.5020708@raszuk.net> Date: Wed, 27 Jun 2012 00:17:37 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Jakob Heitz References: <003c01cd4b29$97d7b150$c78713f0$@ndzh.com> <4FE18A61.8000405@raszuk.net> <8ED5B0B0F5B4854A912480C1521F973AD95B@xmb-rcd-x13.cisco.com> <4FE4A8F3.20809@cisco.com> <4FE4AFE2.3030107@cisco.com> <4FE6441F.2050901@cisco.com> <4FE68269.4070704@cisco.com> <7309FCBCAE981B43ABBE69B31C8D21392437F56D23@EUSAACMS0701.eamcs.ericsson.se> <4FEA327F.3040208@raszuk.net> <7309FCBCAE981B43ABBE69B31C8D21392437F56D6A@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21392437F56D6A@EUSAACMS0701.eamcs.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 22:17:38 -0000 > Not with BGP. This is for use when BGP is dead. You mean when BGP session(s) or process is dead you will query all next hops if all routes you have received are still their best ? Is that the plan ? R. > This is not about next-hop reachability. > It is the next step. > Ask the nexthop if the route is viable. > Not with BGP. This is for use when BGP is dead. From jakob.heitz@ericsson.com Tue Jun 26 15:23:43 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04A2911E80A4 for ; Tue, 26 Jun 2012 15:23:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.453 X-Spam-Level: X-Spam-Status: No, score=-6.453 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cuf6gNvPzO23 for ; Tue, 26 Jun 2012 15:23:42 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 7184F11E809F for ; Tue, 26 Jun 2012 15:23:42 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q5QMNfqP007823 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 26 Jun 2012 17:23:41 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.215]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Tue, 26 Jun 2012 18:23:40 -0400 From: Jakob Heitz To: "robert@raszuk.net" Date: Tue, 26 Jun 2012 18:23:36 -0400 Thread-Topic: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks Thread-Index: Ac1T6YGcdNx4Kfq2Sv6H/0HKnoLqpQAAEVzg Message-ID: <7309FCBCAE981B43ABBE69B31C8D21392437F56D7B@EUSAACMS0701.eamcs.ericsson.se> References: <003c01cd4b29$97d7b150$c78713f0$@ndzh.com> <4FE18A61.8000405@raszuk.net> <8ED5B0B0F5B4854A912480C1521F973AD95B@xmb-rcd-x13.cisco.com> <4FE4A8F3.20809@cisco.com> <4FE4AFE2.3030107@cisco.com> <4FE6441F.2050901@cisco.com> <4FE68269.4070704@cisco.com> <7309FCBCAE981B43ABBE69B31C8D21392437F56D23@EUSAACMS0701.eamcs.ericsson.se> <4FEA327F.3040208@raszuk.net> <7309FCBCAE981B43ABBE69B31C8D21392437F56D6A@EUSAACMS0701.eamcs.ericsson.se> <4FEA3501.5020708@raszuk.net> In-Reply-To: <4FEA3501.5020708@raszuk.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "idr@ietf.org" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 22:23:43 -0000 Say I have a STALE route: destination 10.0.0.0/24 with next-hop 10.1.1.666. I would send a message to 10.1.1.666 asking it if it has a route to 10.0.0.= 0/24. Of course, there are issues. If we can work through the issues, is there interest? On Tuesday, June 26, 2012 3:18 PM, Robert Raszuk = wrote: > > Not with BGP. This is for use when BGP is dead. >=20 > You mean when BGP session(s) or process is dead you will query all > next=20 > hops if all routes you have received are still their best ? >=20 > Is that the plan ? >=20 > R. >=20 >> This is not about next-hop reachability. >> It is the next step. >> Ask the nexthop if the route is viable. >> Not with BGP. This is for use when BGP is dead. --=20 Jakob Heitz.= From senad.ietf@gmail.com Tue Jun 26 15:24:49 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 650CE11E80C8 for ; Tue, 26 Jun 2012 15:24:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.465 X-Spam-Level: X-Spam-Status: No, score=-2.465 tagged_above=-999 required=5 tests=[AWL=1.133, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Ap9Vahim4Xo for ; Tue, 26 Jun 2012 15:24:48 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4564911E80A6 for ; Tue, 26 Jun 2012 15:24:48 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so676660pbc.31 for ; Tue, 26 Jun 2012 15:24:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=h3wJ71zQXcRf+FMpnVp890zAPPthXtj77FJqN+RckDw=; b=sHTybCPwTidEsDyOqzeqIo1x5tlqYkZD1r8wmMo0HYb7REQStMzvnCKUh/t23u/5sI GcNLVJnOJbcucNgXjzphseZTFUyJYntB8Y3nQKKgL0m1VOnve2vWGbLwoSdLKysuvMED +IXANIxIqi03PctsQWzAM+i0xT29L99XZ/8nv/Uo/ReyUDIpQH3EZHVKd9bxebRkZi5W BHv/Jmj1P5JbpNvVAdCp1WX0Ng/+hGOGXQ1ZJrjs/g2qfTIVuTdluuUz0Eojx5WWHl7w e79Et5/r9L0JPOoAFiswNglgd4RYL6X0tEzTolpWSYXvFLIGqxwKxvFfecngxODuVxf6 qLwg== MIME-Version: 1.0 Received: by 10.68.221.164 with SMTP id qf4mr43724834pbc.20.1340749487419; Tue, 26 Jun 2012 15:24:47 -0700 (PDT) Received: by 10.68.237.130 with HTTP; Tue, 26 Jun 2012 15:24:47 -0700 (PDT) In-Reply-To: References: <14C7F4F06DB5814AB0DE29716C4F6D6702DF7129F6@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <4FE623B3.4060906@raszuk.net> <20120625070729.GC21620@juniper.net> Date: Tue, 26 Jun 2012 18:24:47 -0400 Message-ID: From: "Senad .Palislamovic" To: Shane Amante , enkechen@cisco.com Content-Type: multipart/alternative; boundary=e89a8ff25190ee327504c367909f Cc: "UTTARO, JAMES" , Robert Raszuk , "idr@ietf.org List" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 22:24:49 -0000 --e89a8ff25190ee327504c367909f Content-Type: text/plain; charset=ISO-8859-1 Robert, Enke, Thanks for the inputs. Your concern with Internet routes is valid one. Shane, Would you agree that concern of introducing "bugs" with this change is more less the same as any feature being introduced into BGP? And yet, where there are business cases and it just makes technological sense to go down that path, we all agree and proceed. Thus we have reached the point that we have numerous new features and services in BGP showing up as some sort of route (for forwarding or topology discovery purposes) - PIM/IGMP state in BGP in MVPNs (6513/14), MAC state (evpn draft), VPLS - 4761, BGP-TE draft. My point is that we don't stop innovation because of potential bugs - it is up to the vendor to ensure bug-free (dream) code. In this case, there are several operators who do have a business case for this feature, so why stop now? Having said that, I fully understand and agree with Robert's concern of implementing this on pure v4/v6 Internet routes - having two diverse paths on my network, I might not ever want to take "STALE" route on someone else's network - 1-2 ASs down the road - so some sort of "consistency" across the entire Internet on messaging the "STALE" info is needed. It seems that both Enke and Saikat have proposed two possible solutions for Internet space - either capability advertisement OR "STALE" community to stay with the route indefinitely, ie, CANNOT be removed. With that said, apart from Internet routes, I fail to see any technological or philosophical issue in going forward with BGP persistance and having operators enable it on their services as they see it fit. Senad On Tue, Jun 26, 2012 at 1:32 PM, UTTARO, JAMES wrote: > Hannes, > > "the "core behaviour" of the protocol (kill RIB entries right > after session loss) is wrong. and since BGP has outgrown its > original purpose (route 1K prefixes) vs. route 100Ks of prefixes, > route unicast and multicast, route VPN/non-VPN, > route non-routing related functionality it is just legitimate to discuss > restart and persistence behaviour on a per AFI/SAFI basis" > > You have exactly captured where I am coming from in re the discussion > about persistence. As a standards group we must evolve our thinking to > address how BGP is being used today and anticipate its future use. > > Jim Uttaro > > -----Original Message----- > From: Hannes Gredler [mailto:hannes@juniper.net] > Sent: Monday, June 25, 2012 3:08 AM > To: Robert Raszuk > Cc: idr@ietf.org List; UTTARO, JAMES > Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document > - 3 more weeks > > robert, > > On Sat, Jun 23, 2012 at 10:14:43PM +0200, Robert Raszuk wrote: > | >IMO I think that folks need to come to the realization that BGP is > | >being used in varied use cases, using the internet application as the > | >only frame of reference or lens into the requirements for reliability is > | >simply not appropriate or correct.. > | > | + > | > | >All of this being said, there are implementation bugs, overloading of > | > BGP machinery etc.. that have occurred and will occur in the future.. > | > | > | I think you need to realize that the key for any application is > | solid IP reachability. > > well, there are some of us who believe that there are other ways > of building a service architecture and (surprise !) the transport > path not necessarily has to be IP. > > | You can realize any VPN to your customers without BGP being used as > | a service bus for it. It is your choice or your vendor's choice as > | you say to "overload BGP machinery" for everything. > ^^^^^^^^^^^^^^^^^^^^^^^ > > is is really a smart thing to question over-and-over things that: > a. have been decided 10+ years ago > b. have proven to be useful > > | Putting more and more questionable requirements on the only protocol > | which provides such global IP reachability proves as a bad idea. It > | makes the protocol more and more fragile. > > i'd consider the questionw around > a. graceful control-plane restart and > b. standardized handling of forwarding entries thereafter > > as something that should be answered for any protocol in the design phase; > obviously BGP is lacking this and that's why we're getting our > heads together ... > > | The motivation that various flavors of VPNs carried by BGP must be > | up only proves that as number of people suggested in the past the > | same BGP protocol should not be used for everything. > | > | The point is not that protocol will not be able to cope with the > | requirement. The point is that it is wrong to keep changing it's > | core behaviour because your VPN or VPLS service goes down. > | > | Moreover you now do not want to limit the changes only to your > | services SAFI, but argue to "enhance" all AFI/SAFIs with it. That is > | something very hard to agree with. > > the "core behaviour" of the protocol (kill RIB entries right > after session loss) is wrong. and since BGP has outgrown its > original purpose (route 1K prefixes) vs. route 100Ks of prefixes, > route unicast and multicast, route VPN/non-VPN, > route non-routing related functionality it is just letigimate to discuss > restart and persistence behaviour on a per AFI/SAFI basis. > > tx, > > /hannes > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --e89a8ff25190ee327504c367909f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Robert, Enke,

Thanks for the inputs. =A0Your concern wit= h Internet routes is valid one.

Shane,
<= br>
Would you agree that concern of introducing "bugs" = with this change is more less the same as any feature being introduced into= BGP?

And yet, where there are business cases and it just mak= es technological sense to go down that path, we all agree and proceed. =A0T= hus we have reached the point that we have numerous new features and servic= es in BGP showing up as some sort of route (for forwarding or topology disc= overy purposes) - PIM/IGMP state in BGP in MVPNs (6513/14), MAC state (evpn= draft), VPLS - 4761, BGP-TE draft. =A0My point is that we don't stop i= nnovation because of potential bugs - it is up to the vendor to ensure bug-= free (dream) code. =A0In this case, there are several operators who do have= a business case for this feature, so why stop now?

Having said that, I fully understand and agree with Rob= ert's concern of implementing this on pure v4/v6 Internet routes - havi= ng two diverse paths on my network, I might not ever want to take "STA= LE" route on someone else's network - 1-2 ASs down the road - so s= ome sort of "consistency" across the entire Internet on messaging= the "STALE" info is needed. =A0It seems that both Enke and Saika= t have proposed two possible solutions for Internet space - either capabili= ty advertisement OR "STALE" community to stay with the route=A0in= definitely, ie, CANNOT be removed. =A0

With that said, apart from Internet routes, I fail =A0t= o see any technological or philosophical issue in going forward with BGP pe= rsistance and having operators enable it on their services as they see it f= it.

Senad




On Tue, Jun 26, 2012 at 1:32 PM, UTTARO, JAMES <ju1738@at= t.com> wrote:
Hannes,

"the "core behaviour" of the protocol (kill RIB entries righ= t
after session loss) is wrong. and since BGP has outgrown its
original purpose (route 1K prefixes) vs. route 100Ks of prefixes,
route unicast and multicast, route VPN/non-VPN,
route non-routing related functionality it is just legitimate to disc= uss
restart and persistence behaviour on a per AFI/SAFI basis= "

You have exactly captured where I am coming from in re the discussion= about persistence. As a standards group we must evolve our thinking to add= ress how BGP is being used today and anticipate its future use.

Jim Uttaro

-----Original Message-----
From: Hannes Gredler [mailto:hannes@j= uniper.net]
Sent: Monday, June 25, 2012 3:08 AM
To: Robert Raszuk
Cc: idr@ietf.org List; UTTARO, JAMES Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document -= 3 more weeks

robert,

On Sat, Jun 23, 2012 at 10:14:43PM +0200, Robert Raszuk wrote:
| >IMO I think that folks need to come to the realization that BGP is | >being used in varied use cases, using the internet application as the=
| >only frame of reference or lens into the requirements for reliability= is
| >simply not appropriate or correct..
|
| +
|
| >All of this being said, there are implementation bugs, overloading of=
| > BGP machinery etc.. that have occurred and will occur in the future.= .
|
|
| I think you need to realize that the key for any application is
| solid IP reachability.

well, there are some of us who believe that there are other ways
of building a service architecture and (surprise !) the transport
path not necessarily has to be IP.

| You can realize any VPN to your customers without BGP being used as
| a service bus for it. It is your choice or your vendor's choice as | you say to "overload BGP machinery" for everything.
=A0 =A0 =A0 =A0 =A0 =A0 ^^^^^^^^^^^^^^^^^^^^^^^

is is really a smart thing to question over-and-over things that:
=A0a. have been decided 10+ years ago
=A0b. have proven to be useful

| Putting more and more questionable requirements on the only protocol
| which provides such global IP reachability proves as a bad idea. It
| makes the protocol more and more fragile.

i'd consider the questionw around
=A0a. graceful control-plane restart and
=A0b. standardized handling of forwarding entries thereafter

as something that should be answered for any protocol in the design phase;<= br> obviously BGP is lacking this and that's why we're getting our
heads together ...

| The motivation that various flavors of VPNs carried by BGP must be
| up only proves that as number of people suggested in the past the
| same BGP protocol should not be used for everything.
|
| The point is not that protocol will not be able to cope with the
| requirement. The point is that it is wrong to keep changing it's
| core behaviour because your VPN or VPLS service goes down.
|
| Moreover you now do not want to limit the changes only to your
| services SAFI, but argue to "enhance" all AFI/SAFIs with it. Th= at is
| something very hard to agree with.

the "core behaviour" of the protocol (kill RIB entries right
after session loss) is wrong. and since BGP has outgrown its
original purpose (route 1K prefixes) vs. route 100Ks of prefixes,
route unicast and multicast, route VPN/non-VPN,
route non-routing related functionality it is just letigimate to discuss restart and persistence behaviour on a per AFI/SAFI basis.

tx,

/hannes
_______________________________________________
Idr mailing list
Idr@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/idr

--e89a8ff25190ee327504c367909f-- From tony.li@tony.li Tue Jun 26 19:24:52 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A29AA11E80FD for ; Tue, 26 Jun 2012 19:24:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8BM4kRgE6K0p for ; Tue, 26 Jun 2012 19:24:52 -0700 (PDT) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by ietfa.amsl.com (Postfix) with ESMTP id 23F9011E80EF for ; Tue, 26 Jun 2012 19:24:51 -0700 (PDT) Received: from omta18.emeryville.ca.mail.comcast.net ([76.96.30.74]) by qmta01.emeryville.ca.mail.comcast.net with comcast id TEPb1j00B1bwxycA1EQriP; Wed, 27 Jun 2012 02:24:51 +0000 Received: from sjc-vpn5-1449.cisco.com ([128.107.239.233]) by omta18.emeryville.ca.mail.comcast.net with comcast id TEQX1j00B52qHCY8eEQeGP; Wed, 27 Jun 2012 02:24:49 +0000 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Tony Li In-Reply-To: Date: Tue, 26 Jun 2012 16:24:29 -1000 Content-Transfer-Encoding: quoted-printable Message-Id: <75EA7DFD-4FC7-4BC9-9091-2108750D591F@tony.li> References: <14C7F4F06DB5814AB0DE29716C4F6D6702DF7129F6@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <4FE623B3.4060906@raszuk.net> <20120625070729.GC21620@juniper.net> To: "UTTARO, JAMES" X-Mailer: Apple Mail (2.1278) Cc: "idr@ietf.org List" , Robert Raszuk Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 02:24:52 -0000 On Jun 26, 2012, at 7:55 AM, UTTARO, JAMES wrote: > How do you think we should proceed? Should the draft explicitly state = that the internet use case is a MUST NOT? The 3107 use case is labeled = IPv4 which has persistence requirements also so I do not know how that = could actually be done.. Aloha James, We should proceed as always. Those who believe that this problem should = be solved should work with those who are willing to solve the problem = and present a solution to the group. Preferably with running code. As always, the burden falls to those proposing the changes to convince = the rest of us that the benefits of the proposal exceed its drawbacks. Mahalo, Tony From tony.li@tony.li Tue Jun 26 19:30:09 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C7B921F8472 for ; Tue, 26 Jun 2012 19:30:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G-bNr9vkXwNm for ; Tue, 26 Jun 2012 19:30:08 -0700 (PDT) Received: from qmta03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [76.96.30.32]) by ietfa.amsl.com (Postfix) with ESMTP id CA86321F8471 for ; Tue, 26 Jun 2012 19:30:08 -0700 (PDT) Received: from omta20.emeryville.ca.mail.comcast.net ([76.96.30.87]) by qmta03.emeryville.ca.mail.comcast.net with comcast id TEMq1j0031smiN4A3EW8J0; Wed, 27 Jun 2012 02:30:08 +0000 Received: from sjc-vpn5-1449.cisco.com ([128.107.239.233]) by omta20.emeryville.ca.mail.comcast.net with comcast id TEVl1j00E52qHCY8gEVplo; Wed, 27 Jun 2012 02:30:05 +0000 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Tony Li In-Reply-To: Date: Tue, 26 Jun 2012 16:29:45 -1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <14C7F4F06DB5814AB0DE29716C4F6D6702DF7129F6@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <4FE623B3.4060906@raszuk.net> <20120625070729.GC21620@juniper.net> To: "Senad .Palislamovic" X-Mailer: Apple Mail (2.1278) Cc: Shane Amante , "UTTARO, JAMES" , Robert Raszuk , "idr@ietf.org List" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 02:30:09 -0000 Aloha, On Jun 26, 2012, at 12:24 PM, Senad .Palislamovic wrote: > Would you agree that concern of introducing "bugs" with this change is = more less the same as any feature being introduced into BGP? I would agree that that is always a concern, as with any change. I = would also agree that the risk for bugs with this proposal is high, and = that the number of applicable use cases seems to be small. > And yet, where there are business cases and it just makes = technological sense to go down that path, we all agree and proceed. =20 Sorry, but violently, no. We agreed because we had rough consensus, NOT = because there is a business case. There are many considerations beyond = a business case and 'technological sense'. This includes architectural = direction and increased complexity. These must be weighed in making a = rational decision. Hopefully all parties are trying to make a = _rational_ decision. > Thus we have reached the point that we have numerous new features and = services in BGP showing up as some sort of route (for forwarding or = topology discovery purposes) - PIM/IGMP state in BGP in MVPNs (6513/14), = MAC state (evpn draft), VPLS - 4761, BGP-TE draft. My point is that we = don't stop innovation because of potential bugs - it is up to the vendor = to ensure bug-free (dream) code. In this case, there are several = operators who do have a business case for this feature, so why stop now? Not everyone agrees that the aforementioned features should have been = included in the first place. Again, it requires rough consensus to move = forward and there are those that will dissent. Mahalo, Tony From shane@castlepoint.net Tue Jun 26 19:43:38 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 551D711E80EF for ; Tue, 26 Jun 2012 19:43:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CQba+f6mvolV for ; Tue, 26 Jun 2012 19:43:36 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id AA11211E80CD for ; Tue, 26 Jun 2012 19:43:36 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id 449A9368199; Tue, 26 Jun 2012 20:43:36 -0600 (MDT) Received: from mbpw.castlepoint.net (174-29-213-45.hlrn.qwest.net [174.29.213.45]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Tue, 26 Jun 2012 20:43:35 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=174.29.213.45; client-port=65503; syn-fingerprint=65535:54:1:64:M1452,N,W1,N,N,T,S; data-bytes=0 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_2D163D20-39B0-469C-97DB-B13AE394460B" From: Shane Amante In-Reply-To: Date: Tue, 26 Jun 2012 20:43:19 -0600 Message-Id: <94135843-5EF1-4B4A-9CA3-885A4088A762@castlepoint.net> References: <14C7F4F06DB5814AB0DE29716C4F6D6702DF7129F6@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <4FE623B3.4060906@raszuk.net> <20120625070729.GC21620@juniper.net> To: Senad .Palislamovic X-Mailer: Apple Mail (2.1278) Cc: "idr@ietf.org List" , "UTTARO, JAMES" , Robert Raszuk Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 02:43:38 -0000 --Apple-Mail=_2D163D20-39B0-469C-97DB-B13AE394460B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Senad, On Jun 26, 2012, at 4:24 PM, Senad .Palislamovic wrote: > Robert, Enke, >=20 > Thanks for the inputs. Your concern with Internet routes is valid = one. >=20 > Shane, >=20 > Would you agree that concern of introducing "bugs" with this change is = more less the same as any feature being introduced into BGP? >=20 > And yet, where there are business cases and it just makes = technological sense to go down that path, we all agree and proceed. = Thus we have reached the point that we have numerous new features and = services in BGP showing up as some sort of route (for forwarding or = topology discovery purposes) - PIM/IGMP state in BGP in MVPNs (6513/14), = MAC state (evpn draft), VPLS - 4761, BGP-TE draft. My point is that we = don't stop innovation because of potential bugs - it is up to the vendor = to ensure bug-free (dream) code. In this case, there are several = operators who do have a business case for this feature, so why stop now? I find it disingenuous, to put it politely, that "it just makes = technological sense to go down that path". Since you brought it up by = citing a wide variety of additional features that have been added, or = are still being [seriously] considered being added to BGP, where do we = draw the line? No, /seriously/, I **really** want to know. To put it = bluntly, it seems there's NOT really a feature that BGP hasn't been = adapted to support. Or, to put it more colloquially: "If BGP is a = hammer, [nearly] every problem is a nail". On the one hand, that's a marvelous testament to the original design of = BGP to be able to "easily" adapt to support new services, allowing for = moderately fast roll-out on SP networks. However, when looked at from = the context of actually operating networks that run BGP, i.e.: - draft-ietf-grow-ops-reqs-for-bgp-error-handling; - my own and others studies into the present scalability of iBGP; - lots of research papers documenting various aspects of BGP, = (Labovitz/Ahuja; Route Flap Damping; studies on CLUSTER_LIST changes, = but not their length, causing flooding of new iBGP updates inside and = outside an ASN, etc.) ... I am very concerned that if we keep /incrementally/ pouring new = features into BGP without considering the overall effects on BGP as a = _system_ then we're not doing a good enough job. By a "system" I mean = of networks consisting of not just 1 router in an ASN, but thousands of = routers in a single [VPN] network, and orders of magnitude more in the = DFZ. FWIW, that is the context by which I evaluate drafts proposed in = this, and other, WG's. Furthermore, and back to the discussion of this particular draft, I = acknowledge that BGP session survivability is a problem; however, in the = context of the networks that I operate: a) It has not occurred in my VPN networks; b) It has occurred, but only very rarely in my Internet network, (and = even then several of those events are clearly attributable to = _implementation_ errors that nothing we do in IDR will ever fix). Ultimately, I really do want the IDR WG to solve this problem, but I = hope that we will seriously raise the bar in terms of what we, as = operators, are expecting for a solution here. IMO, I think that is the = spirit (if not more) of why = draft-ietf-grow-ops-reqs-for-bgp-error-handling was written. = Personally, at this stage (and given the data I cite above wrt my own = networks), I believe we have a moderate amount of time that would allow = us to raise the bar on our expectations. And, I would rather set the = bar too high, and miss it, then only have a partial solution that is the = currently proposed persistence draft. IMHO, I would much rather see a = solution that: a) has consistent support across _ALL_ AFI/SAFI's -- that benefits = everyone. It allows for a consistent training regime for my Ops folks, = regardless of which services or networks they are working on, etc. b) takes a much more "optimistic" approach to dynamically 'fixing' the = problem in the control plane. Namely, it's my belief (and, I wish I had = hard data to back this up), that it's only an extremely small handful of = BGP routes with malformed attributes that are the problem here, (in = reality ... in only takes 1 malformed attribute to cause chaos, right?) = If that's the case, I would much rather see a solution that tries to = contain the small number "bad" routes in a type of 'penalty box' and = /NOT/ disturb the overwhelming majority of the existing "good" routes, = at all. c) IOW, there's no need for me, as an operator, to pre-color routes = with communities that so those routes can survive session failures. = (WRT to persistence, I will /always/ guess wrong which customer's routes = to enable it on and which don't care, so at the end of the day operators = are going to turn it on for ALL routes). d) In addition, when a BGP receiver gets "choked up", his neighbors = aren't required to re-flood out routes with a new community on them = indicating something 'bad' has happened. IOW, the problem should be = contained as locally as possible in the AS, w/out flooding this = throughout the whole ASN -- if possible/practical. My routers are busy = enough handling flapping PE-CE circuits and dealing with churn from all = the existing wonderful "features", that I really don't need addt'l churn = /if/ it can be avoided in the first place. At the scale of BGP that we're operating in our networks today, this is = not a time for half-measures to this problem. We should aim to fix it = once and for all. /If/ we aim to do that, then I'm all for it. My apologies if the above sounds too much like a "rant" ... but, it's = been a long day. :-) As always, just my $0.02, -shane > Having said that, I fully understand and agree with Robert's concern = of implementing this on pure v4/v6 Internet routes - having two diverse = paths on my network, I might not ever want to take "STALE" route on = someone else's network - 1-2 ASs down the road - so some sort of = "consistency" across the entire Internet on messaging the "STALE" info = is needed. It seems that both Enke and Saikat have proposed two = possible solutions for Internet space - either capability advertisement = OR "STALE" community to stay with the route indefinitely, ie, CANNOT be = removed. =20 >=20 > With that said, apart from Internet routes, I fail to see any = technological or philosophical issue in going forward with BGP = persistance and having operators enable it on their services as they see = it fit. >=20 > Senad >=20 >=20 >=20 >=20 > On Tue, Jun 26, 2012 at 1:32 PM, UTTARO, JAMES wrote: > Hannes, >=20 > "the "core behaviour" of the protocol (kill RIB entries right > after session loss) is wrong. and since BGP has outgrown its > original purpose (route 1K prefixes) vs. route 100Ks of prefixes, > route unicast and multicast, route VPN/non-VPN, > route non-routing related functionality it is just legitimate to = discuss > restart and persistence behaviour on a per AFI/SAFI basis" >=20 > You have exactly captured where I am coming from in re the discussion = about persistence. As a standards group we must evolve our thinking to = address how BGP is being used today and anticipate its future use. >=20 > Jim Uttaro >=20 > -----Original Message----- > From: Hannes Gredler [mailto:hannes@juniper.net] > Sent: Monday, June 25, 2012 3:08 AM > To: Robert Raszuk > Cc: idr@ietf.org List; UTTARO, JAMES > Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG = document - 3 more weeks >=20 > robert, >=20 > On Sat, Jun 23, 2012 at 10:14:43PM +0200, Robert Raszuk wrote: > | >IMO I think that folks need to come to the realization that BGP is > | >being used in varied use cases, using the internet application as = the > | >only frame of reference or lens into the requirements for = reliability is > | >simply not appropriate or correct.. > | > | + > | > | >All of this being said, there are implementation bugs, overloading = of > | > BGP machinery etc.. that have occurred and will occur in the = future.. > | > | > | I think you need to realize that the key for any application is > | solid IP reachability. >=20 > well, there are some of us who believe that there are other ways > of building a service architecture and (surprise !) the transport > path not necessarily has to be IP. >=20 > | You can realize any VPN to your customers without BGP being used as > | a service bus for it. It is your choice or your vendor's choice as > | you say to "overload BGP machinery" for everything. > ^^^^^^^^^^^^^^^^^^^^^^^ >=20 > is is really a smart thing to question over-and-over things that: > a. have been decided 10+ years ago > b. have proven to be useful >=20 > | Putting more and more questionable requirements on the only protocol > | which provides such global IP reachability proves as a bad idea. It > | makes the protocol more and more fragile. >=20 > i'd consider the questionw around > a. graceful control-plane restart and > b. standardized handling of forwarding entries thereafter >=20 > as something that should be answered for any protocol in the design = phase; > obviously BGP is lacking this and that's why we're getting our > heads together ... >=20 > | The motivation that various flavors of VPNs carried by BGP must be > | up only proves that as number of people suggested in the past the > | same BGP protocol should not be used for everything. > | > | The point is not that protocol will not be able to cope with the > | requirement. The point is that it is wrong to keep changing it's > | core behaviour because your VPN or VPLS service goes down. > | > | Moreover you now do not want to limit the changes only to your > | services SAFI, but argue to "enhance" all AFI/SAFIs with it. That is > | something very hard to agree with. >=20 > the "core behaviour" of the protocol (kill RIB entries right > after session loss) is wrong. and since BGP has outgrown its > original purpose (route 1K prefixes) vs. route 100Ks of prefixes, > route unicast and multicast, route VPN/non-VPN, > route non-routing related functionality it is just letigimate to = discuss > restart and persistence behaviour on a per AFI/SAFI basis. >=20 > tx, >=20 > /hannes > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr --Apple-Mail=_2D163D20-39B0-469C-97DB-B13AE394460B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Robert, = Enke,

Thanks for the inputs.  Your concern with = Internet routes is valid = one.

Shane,

Would you = agree that concern of introducing "bugs" with this change is more less = the same as any feature being introduced into BGP?

And yet, where there are business cases and it just = makes technological sense to go down that path, we all agree and = proceed.  Thus we have reached the point that we have numerous new = features and services in BGP showing up as some sort of route (for = forwarding or topology discovery purposes) - PIM/IGMP state in BGP in = MVPNs (6513/14), MAC state (evpn draft), VPLS - 4761, BGP-TE draft. =  My point is that we don't stop innovation because of potential = bugs - it is up to the vendor to ensure bug-free (dream) code.  In = this case, there are several operators who do have a business case for = this feature, so why stop now?

I = find it disingenuous, to put it politely, that "it just makes = technological sense to go down that path".  Since you brought it up = by citing a wide variety of additional features that have been added, or = are still being [seriously] considered being added to BGP, where do we = draw the line?  No, /seriously/, I **really** want to know. =  To put it bluntly, it seems there's NOT really a feature that BGP = hasn't been adapted to support.  Or, to put it more colloquially: = "If BGP is a hammer, [nearly] every problem is a = nail".

On the one hand, that's a marvelous = testament to the original design of BGP to be able to "easily" adapt to = support new services, allowing for moderately fast roll-out on SP = networks.  However, when looked at from the context of actually = operating networks that run BGP, i.e.:
- = draft-ietf-grow-ops-reqs-for-bgp-error-handling;
- my own and = others studies into the present scalability of iBGP;
- lots of = research papers documenting various aspects of BGP, (Labovitz/Ahuja; = Route Flap Damping; studies on CLUSTER_LIST changes, but not their = length, causing flooding of new iBGP updates inside and outside an ASN, = etc.)
... I am very concerned that if we keep /incrementally/ = pouring new features into BGP without considering the overall effects on = BGP as a _system_ then we're not doing a good enough job.  By = a "system" I mean of networks consisting of not just 1 router in an ASN, = but thousands of routers in a single [VPN] network, and orders of = magnitude more in the DFZ.  FWIW, that is the context by which I = evaluate drafts proposed in this, and other, = WG's.

Furthermore, and back to the discussion = of this particular draft, I acknowledge that BGP session survivability = is a problem; however, in the context of the networks that I = operate:
a)  It has not occurred in my VPN = networks;
b)  It has occurred, but only very rarely in my = Internet network, (and even then several of those events are clearly = attributable to _implementation_ errors that nothing we do in IDR will = ever fix).

Ultimately, I really do want the IDR = WG to solve this problem, but I hope that we will seriously raise the = bar in terms of what we, as operators, are expecting for a solution = here.  IMO, I think that is the spirit (if not more) of = why draft-ietf-grow-ops-reqs-for-bgp-error-handling was written. =  Personally, at this stage (and given the data I cite above wrt my = own networks), I believe we have a moderate amount of time that would = allow us to raise the bar on our expectations.  And, I would rather = set the bar too high, and miss it, then only have a partial solution = that is the currently proposed persistence draft.  IMHO, I would = much rather see a solution that:
a) has consistent support = across _ALL_ AFI/SAFI's -- that benefits everyone.  It allows for a = consistent training regime for my Ops folks, regardless of which = services or networks they are working on, etc.
b) takes a much = more "optimistic" approach to dynamically 'fixing' the problem in the = control plane.  Namely, it's my belief (and, I wish I had hard data = to back this up), that it's only an extremely small handful of BGP = routes with malformed attributes that are the problem here, (in reality = ... in only takes 1 malformed attribute to cause chaos, right?)  If = that's the case, I would much rather see a solution that tries to = contain the small number "bad" routes in a type of 'penalty box' and = /NOT/ disturb the overwhelming majority of the existing "good" routes, = at all.
  c) IOW, there's no need for me, as an operator, = to pre-color routes with communities that so those routes can survive = session failures.  (WRT to persistence, I will /always/ guess wrong = which customer's routes to enable it on and which don't care, so at the = end of the day operators are going to turn it on for ALL = routes).
  d) In addition, when a BGP receiver gets = "choked up", his neighbors aren't required to re-flood out routes with a = new community on them indicating something 'bad' has happened. =  IOW, the problem should be contained as locally as possible in the = AS, w/out flooding this throughout the whole ASN -- if = possible/practical.  My routers are busy enough handling flapping = PE-CE circuits and dealing with churn from all the existing wonderful = "features", that I really don't need addt'l churn /if/ it can be avoided = in the first place.

At the scale of BGP that = we're operating in our networks today, this is not a time for = half-measures to this problem.  We should aim to fix it once and = for all.  /If/ we aim to do that, then I'm all for = it.

My apologies if the above sounds too much = like a "rant" ... but, it's been a long day. =  :-)

As always, just my = $0.02,

-shane


=
Having said that, I fully understand and agree with Robert's = concern of implementing this on pure v4/v6 Internet routes - having two = diverse paths on my network, I might not ever want to take "STALE" route = on someone else's network - 1-2 ASs down the road - so some sort of = "consistency" across the entire Internet on messaging the "STALE" info = is needed.  It seems that both Enke and Saikat have proposed two = possible solutions for Internet space - either capability advertisement = OR "STALE" community to stay with the route indefinitely, ie, = CANNOT be removed.  

With that said, apart from Internet routes, I fail =  to see any technological or philosophical issue in going forward = with BGP persistance and having operators enable it on their services as = they see it fit.

Senad




On Tue, Jun 26, 2012 at 1:32 PM, UTTARO, JAMES = <ju1738@att.com> wrote:
Hannes,

"the "core behaviour" of the protocol (kill RIB entries right
after session loss) is wrong. and since BGP has outgrown its
original purpose (route 1K prefixes) vs. route 100Ks of prefixes,
route unicast and multicast, route VPN/non-VPN,
route non-routing related functionality it is just legitimate to = discuss
restart and persistence behaviour on a per AFI/SAFI = basis"

You have exactly captured where I am coming from in re the = discussion about persistence. As a standards group we must evolve our = thinking to address how BGP is being used today and anticipate its = future use.

Jim Uttaro

-----Original Message-----
From: Hannes Gredler [mailto:hannes@juniper.net]
Sent: Monday, June 25, 2012 3:08 AM
To: Robert Raszuk
Cc: idr@ietf.org List; UTTARO, = JAMES
Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG = document - 3 more weeks

robert,

On Sat, Jun 23, 2012 at 10:14:43PM +0200, Robert Raszuk wrote:
| >IMO I think that folks need to come to the realization that BGP = is
| >being used in varied use cases, using the internet application as = the
| >only frame of reference or lens into the requirements for = reliability is
| >simply not appropriate or correct..
|
| +
|
| >All of this being said, there are implementation bugs, overloading = of
| > BGP machinery etc.. that have occurred and will occur in the = future..
|
|
| I think you need to realize that the key for any application is
| solid IP reachability.

well, there are some of us who believe that there are other ways
of building a service architecture and (surprise !) the transport
path not necessarily has to be IP.

| You can realize any VPN to your customers without BGP being used = as
| a service bus for it. It is your choice or your vendor's choice as
| you say to "overload BGP machinery" for everything.
            ^^^^^^^^^^^^^^^^^^^^^^^

is is really a smart thing to question over-and-over things that:
 a. have been decided 10+ years ago
 b. have proven to be useful

| Putting more and more questionable requirements on the only = protocol
| which provides such global IP reachability proves as a bad idea. = It
| makes the protocol more and more fragile.

i'd consider the questionw around
 a. graceful control-plane restart and
 b. standardized handling of forwarding entries thereafter

as something that should be answered for any protocol in the design = phase;
obviously BGP is lacking this and that's why we're getting our
heads together ...

| The motivation that various flavors of VPNs carried by BGP must be
| up only proves that as number of people suggested in the past the
| same BGP protocol should not be used for everything.
|
| The point is not that protocol will not be able to cope with the
| requirement. The point is that it is wrong to keep changing it's
| core behaviour because your VPN or VPLS service goes down.
|
| Moreover you now do not want to limit the changes only to your
| services SAFI, but argue to "enhance" all AFI/SAFIs with it. That = is
| something very hard to agree with.

the "core behaviour" of the protocol (kill RIB entries right
after session loss) is wrong. and since BGP has outgrown its
original purpose (route 1K prefixes) vs. route 100Ks of prefixes,
route unicast and multicast, route VPN/non-VPN,
route non-routing related functionality it is just letigimate to = discuss
restart and persistence behaviour on a per AFI/SAFI basis.

tx,

/hannes
_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr

_______________________________________________
Idr mailing = list
Idr@ietf.org
https://www.ietf.org/mail= man/listinfo/idr

= --Apple-Mail=_2D163D20-39B0-469C-97DB-B13AE394460B-- From senad.ietf@gmail.com Tue Jun 26 22:18:32 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE4CE11E8102 for ; Tue, 26 Jun 2012 22:18:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.025 X-Spam-Level: X-Spam-Status: No, score=-3.025 tagged_above=-999 required=5 tests=[AWL=0.573, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q3ucjLWqPzu2 for ; Tue, 26 Jun 2012 22:18:31 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9375D11E80C5 for ; Tue, 26 Jun 2012 22:18:31 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so1051970pbc.31 for ; Tue, 26 Jun 2012 22:18:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2Xmv9L1U86ovocZKzNVbVpRldc6hQb364tOPjjl4zAk=; b=S1FC7FYhQeXPDCuZAU1X4KmeJPINP6zg6L+xsbmCK078LysVnKmfGe4p2o2GxEdoBT n+GEiJ2ONOLlK2J+yCH6+ukzxYE3cGQqydI4lQBctJuJR1smmVEprkFdAPDxWNopbZ61 4IQIR2B+ZG6cXUI6G0SA5TXZbMS2Whzg88y/nNTAmQLawsQs2GRVT60u5nRbxTcuz0X6 SUcjETEkoSf/EmdWkvKKyF8hndh4imG4x3F4ayYQaScSAxv64j4QNTvVZ+puS18IQAaZ 1QDPeEL85PaXI9N9wSSJf+XcMnY7WGOWAHpJseGIgGXID3soenQuKgAAG1sg6QIKozPq QUSQ== MIME-Version: 1.0 Received: by 10.68.217.3 with SMTP id ou3mr59798978pbc.117.1340774311220; Tue, 26 Jun 2012 22:18:31 -0700 (PDT) Received: by 10.68.237.130 with HTTP; Tue, 26 Jun 2012 22:18:31 -0700 (PDT) In-Reply-To: References: <14C7F4F06DB5814AB0DE29716C4F6D6702DF7129F6@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <4FE623B3.4060906@raszuk.net> <20120625070729.GC21620@juniper.net> Date: Wed, 27 Jun 2012 01:18:31 -0400 Message-ID: From: "Senad .Palislamovic" To: Tony Li Content-Type: multipart/alternative; boundary=e89a8ffbab118b547204c36d5869 Cc: Shane Amante , "UTTARO, JAMES" , Robert Raszuk , "idr@ietf.org List" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 05:18:32 -0000 --e89a8ffbab118b547204c36d5869 Content-Type: text/plain; charset=ISO-8859-1 Tony, My comments inline: On Tue, Jun 26, 2012 at 10:29 PM, Tony Li wrote: > > Aloha, > > On Jun 26, 2012, at 12:24 PM, Senad .Palislamovic wrote: > > > Would you agree that concern of introducing "bugs" with this change is > more less the same as any feature being introduced into BGP? > > > I would agree that that is always a concern, as with any change. I would > also agree that the risk for bugs with this proposal is high, and that the > number of applicable use cases seems to be small. > > I do not think that "number" is the right unit of measure here. Number is only relevant as much as the monetary system it is tied to. In this case, a significance of the use cases, IMHO outweighs the risk. > > > And yet, where there are business cases and it just makes technological > sense to go down that path, we all agree and proceed. > > > Sorry, but violently, no. We agreed because we had rough consensus, NOT > because there is a business case. Could it be that a business case drove the "rough consensus"? And didn't insertion of these services into BGP made operators realize new revenue streams - which didn't exist before - sooner. Thus the adaptation rate. There are many considerations beyond a business case and 'technological > sense'. This includes architectural direction and increased complexity. > These must be weighed in making a rational decision. Hopefully all > parties are trying to make a _rational_ decision. > > Fully agree. However, different services call for different architectural directions - thus their level of complexity will be different. I view complexity as a relative term - complex compared to what ? > > Thus we have reached the point that we have numerous new features and > services in BGP showing up as some sort of route (for forwarding or > topology discovery purposes) - PIM/IGMP state in BGP in MVPNs (6513/14), > MAC state (evpn draft), VPLS - 4761, BGP-TE draft. My point is that we > don't stop innovation because of potential bugs - it is up to the vendor to > ensure bug-free (dream) code. In this case, there are several operators > who do have a business case for this feature, so why stop now? > > > Not everyone agrees that the aforementioned features should have been > included in the first place. Again, it requires rough consensus to move > forward and there are those that will dissent. Fair enough. However, given that we have moved forward, implemented it, deployed our services, locked the customers and revenue streams in - shouldn't we seek to improve them? Regards, Senad > Mahalo, > Tony > > > --e89a8ffbab118b547204c36d5869 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Tony,

My comments inline:

On Tue, Jun 26, 2012 at 10:29 PM, Tony Li <tony.li@tony.li> wrote:

Aloha,

On Jun 26, 2012, at 12:24 PM, Senad .Palislamovic wrote:

> Would you agree that concern of introducing "bugs" with this= change is more less the same as any feature being introduced into BGP?


I would agree that that is always a concern, as with any change. =A0I= would also agree that the risk for bugs with this proposal is high, and th= at the number of applicable use cases seems to be small.

I do not think that "num= ber" is the right unit of measure here. =A0Number is only relevant as = much as the monetary system it is tied to. =A0In this case, a=A0significanc= e=A0of the use cases, IMHO=A0outweighs=A0the risk.
=A0

> And yet, where there are business cases and it just makes technologica= l sense to go down that path, we all agree and proceed.


Sorry, but violently, no. =A0We agreed because we had rough consensus= , NOT because there is a business case.

Cou= ld it be that a business case drove the "rough=A0consensus"? =A0A= nd didn't insertion of these services into BGP made operators realize n= ew revenue streams - which didn't exist before - sooner. =A0Thus the=A0= adaptation=A0rate.

=A0There are many considerat= ions beyond a business case and 'technological sense'. =A0This incl= udes architectural direction and increased complexity. =A0These must be wei= ghed in making a rational decision. =A0Hopefully all parties are trying to = make a _rational_ decision.

Fully agree. =A0However, diff= erent services call for different architectural directions - thus their lev= el of complexity will be different. =A0I view complexity as a relative term= - complex compared to what ?


> Thus we have reached the point that we have numerous new features and = services in BGP showing up as some sort of route (for forwarding or topolog= y discovery purposes) - PIM/IGMP state in BGP in MVPNs (6513/14), MAC state= (evpn draft), VPLS - 4761, BGP-TE draft. =A0My point is that we don't = stop innovation because of potential bugs - it is up to the vendor to ensur= e bug-free (dream) code. =A0In this case, there are several operators who d= o have a business case for this feature, so why stop now?


Not everyone agrees that the aforementioned features should have been= included in the first place. =A0Again, it requires rough consensus to move= forward and there are those that will dissent.=A0

Fair enough. =A0However, given that we have moved forward, implemented= it, deployed our services, locked the customers and revenue streams in - s= houldn't we seek to improve them?


Regards,

Senad


Mahalo,
Tony



--e89a8ffbab118b547204c36d5869-- From senad.ietf@gmail.com Tue Jun 26 23:12:46 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DA9211E80E1; Tue, 26 Jun 2012 23:12:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.82 X-Spam-Level: X-Spam-Status: No, score=-2.82 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x5qOyDk6xnJJ; Tue, 26 Jun 2012 23:12:41 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id B4FA511E80C5; Tue, 26 Jun 2012 23:12:41 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so1110740pbc.31 for ; Tue, 26 Jun 2012 23:12:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZI0COz9zTBVLbolPNaGco/YgyNIyXBtYkU430zEk4DI=; b=x4sSJqp/cWpncetCp1r6Hkzuqb1IjxXFRziA3K89g5H9TdZrhsEF+ym9KIafeuhGYK 8Ry3KeUZ3xWNPlsLAjkZNc90Or/OBGaWKQntJatLZHTP91vnWnThTEreFqrxX+lv5emi LKAyiSFZan5/Z2CZi6oq0r1qeia8ueN4DXwGKDWhXBfB6srBMX5gyC9a1/Us5I0EwlNR 9CG2EBt57iF+uRrOixRI1nvyxG7kRY1MRQaUfnXPbJXSVZIvaEtmHE8Pc16emZpohCIe lGJ19k13q6PjF29iCzY0/s+Vitt9LVdS7YR6djvAzbBQ4xT5BXTQIgvtaFPQ+5tORCKo JfFw== MIME-Version: 1.0 Received: by 10.68.217.3 with SMTP id ou3mr60272315pbc.117.1340777561153; Tue, 26 Jun 2012 23:12:41 -0700 (PDT) Received: by 10.68.237.130 with HTTP; Tue, 26 Jun 2012 23:12:41 -0700 (PDT) In-Reply-To: <94135843-5EF1-4B4A-9CA3-885A4088A762@castlepoint.net> References: <14C7F4F06DB5814AB0DE29716C4F6D6702DF7129F6@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <4FE623B3.4060906@raszuk.net> <20120625070729.GC21620@juniper.net> <94135843-5EF1-4B4A-9CA3-885A4088A762@castlepoint.net> Date: Wed, 27 Jun 2012 02:12:41 -0400 Message-ID: From: "Senad .Palislamovic" To: Shane Amante Content-Type: multipart/alternative; boundary=e89a8ffbab114160c304c36e1ad2 Cc: "idr@ietf.org List" , Robert Raszuk , tony.li@tony.li, "UTTARO, JAMES" , ietf-action@ietf.org Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 06:12:46 -0000 --e89a8ffbab114160c304c36e1ad2 Content-Type: text/plain; charset=ISO-8859-1 Shane, I sincerely appreciate your 2 cents. My comments inline: On Tue, Jun 26, 2012 at 10:43 PM, Shane Amante wrote: > Senad, > > On Jun 26, 2012, at 4:24 PM, Senad .Palislamovic wrote: > > Robert, Enke, > > Thanks for the inputs. Your concern with Internet routes is valid one. > > Shane, > > Would you agree that concern of introducing "bugs" with this change is > more less the same as any feature being introduced into BGP? > > And yet, where there are business cases and it just makes technological > sense to go down that path, we all agree and proceed. Thus we have reached > the point that we have numerous new features and services in BGP showing up > as some sort of route (for forwarding or topology discovery purposes) - > PIM/IGMP state in BGP in MVPNs (6513/14), MAC state (evpn draft), VPLS - > 4761, BGP-TE draft. My point is that we don't stop innovation because of > potential bugs - it is up to the vendor to ensure bug-free (dream) code. > In this case, there are several operators who do have a business case for > this feature, so why stop now? > > > I find it disingenuous, to put it politely, that "it just makes > technological sense to go down that path". Since you brought it up by > citing a wide variety of additional features that have been added, or are > still being [seriously] considered being added to BGP, where do we draw the > line? No, /seriously/, I **really** want to know. To put it bluntly, it > seems there's NOT really a feature that BGP hasn't been adapted to support. > Or, to put it more colloquially: "If BGP is a hammer, [nearly] every > problem is a nail". > The right question to ask would be why to draw the line at the first place. Doesn't leveraging and re-using something that exists and is proven to work make more sense than going down the path of reinventing the wheel - as long as the following factors are met: - it doesn't impact the original product - the original product contains the right properties to be extended Has any of the new services "broke" the original product, ie vanilla routing? Hybrid vehicles use roughly 95 % components of their non-hybrid brothers. Car industry didn't go out and build the hybrid vehicle in the vacuum, but actually re-used existing technologies as much as possible. > On the one hand, that's a marvelous testament to the original design of > BGP to be able to "easily" adapt to support new services, allowing for > moderately fast roll-out on SP networks. However, when looked at from the > context of actually operating networks that run BGP, i.e.: > - draft-ietf-grow-ops-reqs-for-bgp-error-handling; > - my own and others studies into the present scalability of iBGP; > - lots of research papers documenting various aspects of BGP, > (Labovitz/Ahuja; Route Flap Damping; studies on CLUSTER_LIST changes, but > not their length, causing flooding of new iBGP updates inside and outside > an ASN, etc.) > ... I am very concerned that if we keep /incrementally/ pouring new > features into BGP without considering the overall effects on BGP as a > _system_ then we're not doing a good enough job. By a "system" I mean of > networks consisting of not just 1 router in an ASN, but thousands of > routers in a single [VPN] network, and orders of magnitude more in the DFZ. > FWIW, that is the context by which I evaluate drafts proposed in this, and > other, WG's. > So the question is - why should it be looked as a whole system. What defines a system? Everything is fundamentally layered on something - so leverage the commons and diverge where needed. Any protocol stack is built on same fundamental layer and diverges as it moves up based on its requirements and problem statements. In this case, different NLRI's share different properties - so we re-use what is common and adapt where we diverge according to the properties of the services. I think we have moved passed vanilla IP services long time ago. > Furthermore, and back to the discussion of this particular draft, I > acknowledge that BGP session survivability is a problem; however, in the > context of the networks that I operate: > a) It has not occurred in my VPN networks; > b) It has occurred, but only very rarely in my Internet network, (and > even then several of those events are clearly attributable to > _implementation_ errors that nothing we do in IDR will ever fix). > > Ultimately, I really do want the IDR WG to solve this problem, but I hope > that we will seriously raise the bar in terms of what we, as operators, are > expecting for a solution here. IMO, I think that is the spirit (if not > more) of why draft-ietf-grow-ops-reqs-for-bgp-error-handling was written. > I do not think the draft draft-ietf-grow-ops-reqs-for-bgp-error-handling addresses this problem. Personally, at this stage (and given the data I cite above wrt my own > networks), I believe we have a moderate amount of time that would allow us > to raise the bar on our expectations. And, I would rather set the bar too > high, and miss it, then only have a partial solution that is the currently > proposed persistence draft. IMHO, I would much rather see a solution that: > a) has consistent support across _ALL_ AFI/SAFI's -- that benefits > everyone. It allows for a consistent training regime for my Ops folks, > regardless of which services or networks they are working on, etc. > Given that each AFI/SAFI set defines a service with potentially fundamentally different properties, I do not think one size fits all methodology is appropriate here. Going back to my previous comment - use and re-use on things that are common. Now let's look at very specific use case, RFC 4761. BGP (RRs) are used for auto-discovery and PW instantiation. Once that is up, all forwarding state is after-fact of dynamic MAC learning within a pseudowire. Given that provider topology is static, BGP can be removed from the picture, moreover RR can be removed from the picture. This absolutely doesn't impact customer traffic cuz destinations are based on dynamic MAC learning so any farther changes in topology will be reflected on the customer's network correctly. This is fundamentally different use case than what you are concerned with, and IMHO could leverage different set of solutions, as long as they "fundamentally" do not impact the original product (IDR). > b) takes a much more "optimistic" approach to dynamically 'fixing' the > problem in the control plane. Namely, it's my belief (and, I wish I had > hard data to back this up), that it's only an extremely small handful of > BGP routes with malformed attributes that are the problem here, (in reality > ... in only takes 1 malformed attribute to cause chaos, right?) If that's > the case, I would much rather see a solution that tries to contain the > small number "bad" routes in a type of 'penalty box' and /NOT/ disturb the > overwhelming majority of the existing "good" routes, at all. > c) IOW, there's no need for me, as an operator, to pre-color routes with > communities that so those routes can survive session failures. (WRT to > persistence, I will /always/ guess wrong which customer's routes to enable > it on and which don't care, so at the end of the day operators are going to > turn it on for ALL routes). > d) In addition, when a BGP receiver gets "choked up", his neighbors > aren't required to re-flood out routes with a new community on them > indicating something 'bad' has happened. IOW, the problem should be > contained as locally as possible in the AS, w/out flooding this throughout > the whole ASN -- if possible/practical. My routers are busy enough > handling flapping PE-CE circuits and dealing with churn from all the > existing wonderful "features", that I really don't need addt'l churn /if/ > it can be avoided in the first place. > This would only happen in v4/v6 Internet routing space - not in SP owned services or infrastructure routes. This is why I believe different NLRIs, given that they have different set of properties, could leverage different solution. > At the scale of BGP that we're operating in our networks today, this is > not a time for half-measures to this problem. We should aim to fix it once > and for all. /If/ we aim to do that, then I'm all for it. > > My apologies if the above sounds too much like a "rant" ... but, it's been > a long day. :-) > > No worries. it's only Tuesday - wait till it gets to be Thursday :) > As always, just my $0.02, > > -shane > > > Likewise, just MHO... Senad > > Having said that, I fully understand and agree with Robert's concern of > implementing this on pure v4/v6 Internet routes - having two diverse paths > on my network, I might not ever want to take "STALE" route on someone > else's network - 1-2 ASs down the road - so some sort of "consistency" > across the entire Internet on messaging the "STALE" info is needed. It > seems that both Enke and Saikat have proposed two possible solutions for > Internet space - either capability advertisement OR "STALE" community to > stay with the route indefinitely, ie, CANNOT be removed. > > With that said, apart from Internet routes, I fail to see any > technological or philosophical issue in going forward with BGP persistance > and having operators enable it on their services as they see it fit. > > Senad > > > > > On Tue, Jun 26, 2012 at 1:32 PM, UTTARO, JAMES wrote: > >> Hannes, >> >> "the "core behaviour" of the protocol (kill RIB entries right >> after session loss) is wrong. and since BGP has outgrown its >> original purpose (route 1K prefixes) vs. route 100Ks of prefixes, >> route unicast and multicast, route VPN/non-VPN, >> route non-routing related functionality it is just legitimate to discuss >> restart and persistence behaviour on a per AFI/SAFI basis" >> >> You have exactly captured where I am coming from in re the discussion >> about persistence. As a standards group we must evolve our thinking to >> address how BGP is being used today and anticipate its future use. >> >> Jim Uttaro >> >> -----Original Message----- >> From: Hannes Gredler [mailto:hannes@juniper.net] >> Sent: Monday, June 25, 2012 3:08 AM >> To: Robert Raszuk >> Cc: idr@ietf.org List; UTTARO, JAMES >> Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document >> - 3 more weeks >> >> robert, >> >> On Sat, Jun 23, 2012 at 10:14:43PM +0200, Robert Raszuk wrote: >> | >IMO I think that folks need to come to the realization that BGP is >> | >being used in varied use cases, using the internet application as the >> | >only frame of reference or lens into the requirements for reliability >> is >> | >simply not appropriate or correct.. >> | >> | + >> | >> | >All of this being said, there are implementation bugs, overloading of >> | > BGP machinery etc.. that have occurred and will occur in the future.. >> | >> | >> | I think you need to realize that the key for any application is >> | solid IP reachability. >> >> well, there are some of us who believe that there are other ways >> of building a service architecture and (surprise !) the transport >> path not necessarily has to be IP. >> >> | You can realize any VPN to your customers without BGP being used as >> | a service bus for it. It is your choice or your vendor's choice as >> | you say to "overload BGP machinery" for everything. >> ^^^^^^^^^^^^^^^^^^^^^^^ >> >> is is really a smart thing to question over-and-over things that: >> a. have been decided 10+ years ago >> b. have proven to be useful >> >> | Putting more and more questionable requirements on the only protocol >> | which provides such global IP reachability proves as a bad idea. It >> | makes the protocol more and more fragile. >> >> i'd consider the questionw around >> a. graceful control-plane restart and >> b. standardized handling of forwarding entries thereafter >> >> as something that should be answered for any protocol in the design phase; >> obviously BGP is lacking this and that's why we're getting our >> heads together ... >> >> | The motivation that various flavors of VPNs carried by BGP must be >> | up only proves that as number of people suggested in the past the >> | same BGP protocol should not be used for everything. >> | >> | The point is not that protocol will not be able to cope with the >> | requirement. The point is that it is wrong to keep changing it's >> | core behaviour because your VPN or VPLS service goes down. >> | >> | Moreover you now do not want to limit the changes only to your >> | services SAFI, but argue to "enhance" all AFI/SAFIs with it. That is >> | something very hard to agree with. >> >> the "core behaviour" of the protocol (kill RIB entries right >> after session loss) is wrong. and since BGP has outgrown its >> original purpose (route 1K prefixes) vs. route 100Ks of prefixes, >> route unicast and multicast, route VPN/non-VPN, >> route non-routing related functionality it is just letigimate to discuss >> restart and persistence behaviour on a per AFI/SAFI basis. >> >> tx, >> >> /hannes >> _______________________________________________ >> 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 > > > --e89a8ffbab114160c304c36e1ad2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Shane,

I sincerely appreciate your 2 cents. =A0My commen= ts inline:

On Tue, Jun 26, 2012 at 10:43 = PM, Shane Amante <shane@castlepoint.net> wrote:
Senad,
On Jun 26, 2012, at 4:24 PM, Senad .Palislamovic wrot= e:
Robert, Enke,

Thanks for the i= nputs. =A0Your concern with Internet routes is valid one.

Shane,

Would you agree that concern of int= roducing "bugs" with this change is more less the same as any fea= ture being introduced into BGP?

And yet, where there are business cases and it just mak= es technological sense to go down that path, we all agree and proceed. =A0T= hus we have reached the point that we have numerous new features and servic= es in BGP showing up as some sort of route (for forwarding or topology disc= overy purposes) - PIM/IGMP state in BGP in MVPNs (6513/14), MAC state (evpn= draft), VPLS - 4761, BGP-TE draft. =A0My point is that we don't stop i= nnovation because of potential bugs - it is up to the vendor to ensure bug-= free (dream) code. =A0In this case, there are several operators who do have= a business case for this feature, so why stop now?

I find it disingenuous, to put it po= litely, that "it just makes technological sense to go down that path&q= uot;. =A0Since you brought it up by citing a wide variety of additional fea= tures that have been added, or are still being [seriously] considered being= added to BGP, where do we draw the line? =A0No, /seriously/, I **really** = want to know. =A0To put it bluntly, it seems there's NOT really a featu= re that BGP hasn't been adapted to support. =A0Or, to put it more collo= quially: "If BGP is a hammer, [nearly] every problem is a nail".<= /div>

The right question to as= k would be why to draw the line at the first place. =A0Doesn't leveragi= ng and re-using something that exists and is proven to work make more sense= than going down the path of reinventing the wheel - as long as the followi= ng factors are met:

- it doesn't impact the original product
= - the original product contains the right properties to be extended

Has any of the new services "broke" the origina= l product, ie=A0vanilla=A0routing? =A0Hybrid vehicles use=A0roughly=A095 % = components of their non-hybrid brothers. =A0Car industry didn't go out = and build the hybrid vehicle in the vacuum, but actually re-used existing t= echnologies as much as possible.


On the one hand,=A0that's a marvelous testament to = the original design of BGP to be able to "easily" adapt to suppor= t new services, allowing for moderately fast roll-out on SP networks. =A0Ho= wever, when looked at from the context of actually operating networks that = run BGP, i.e.:
- draft-ietf-grow-ops-reqs-for-bgp-error-handling;
- my own = and others studies into the present scalability of iBGP;
- lots o= f research papers documenting various aspects of BGP, (Labovitz/Ahuja; Rout= e Flap Damping; studies on CLUSTER_LIST changes, but not their length, caus= ing flooding of new iBGP updates inside and outside an ASN, etc.)
... I am very concerned that if we keep /incrementally/ pouring new fe= atures into BGP without considering the overall effects on BGP as a _system= _=A0then we're not doing a good enough job.=A0 By a "system" = I mean of networks consisting of not just 1 router in an ASN, but thousands= of routers in a single [VPN] network, and orders of magnitude more in the = DFZ. =A0FWIW, that is the context by which I evaluate drafts proposed in th= is, and other, WG's.

So the question is - why= should it be looked as a whole system. =A0What defines a system? =A0Everyt= hing is fundamentally layered on something - so leverage the commons and di= verge where needed. =A0Any protocol stack is built on same fundamental laye= r and diverges as it moves up based on its requirements and problem stateme= nts. =A0In this case, different NLRI's share different=A0properties=A0-= so we re-use what is common and adapt where we diverge according to the pr= operties of the services. =A0I think we have moved passed=A0vanilla=A0IP se= rvices long time ago.


Furthermore, and back to the discussion of this particu= lar draft, I acknowledge that BGP session survivability is a problem; howev= er, in the context of the networks that I operate:
a) =A0It has n= ot occurred in my VPN networks;
b) =A0It has occurred, but only very rarely in my Internet network, (a= nd even then several of those events are clearly attributable to _implement= ation_ errors that nothing we do in IDR will ever fix).



Ultimately, I really do want the IDR WG to solve this problem, but I h= ope that we will seriously raise the bar in terms of what we, as operators,= are expecting for a solution here. =A0IMO, I think that is the spirit (if = not more) of why=A0draft-ietf-grow-ops-reqs-for-bgp-error-handling was writ= ten. =A0

I do not think the draft= =A0draft-ietf-grow-ops-reqs-for-bgp-error-handling addresses this problem.<= /div>


Personally, at this stag= e (and given the data I cite above wrt my own networks), I believe we have = a moderate amount of time that would allow us to raise the bar on our expec= tations. =A0And, I would rather set the bar too high, and miss it, then onl= y have a partial solution that is the currently proposed persistence draft.= =A0IMHO, I would much rather see a solution that:
a) has consistent support across _ALL_ AFI/SAFI's -- that benefits= everyone. =A0It allows for a consistent training regime for my Ops folks, = regardless of which services or networks they are working on, etc.

Given that each AFI/SAFI= set defines a service with potentially fundamentally different properties,= I do not think one size fits all methodology is appropriate here. =A0Going= back to my previous comment - use and re-use on things that are common.

Now let's look at very specific use case, RFC 4761.= =A0BGP (RRs) are used for auto-discovery and PW instantiation. =A0Once tha= t is up, all =A0forwarding state is=A0after-fact=A0of dynamic MAC learning = within a pseudowire. =A0Given that provider topology is static, BGP can be = removed from the picture, moreover RR can be removed from the picture. =A0T= his=A0absolutely=A0doesn't impact customer traffic cuz destinations are= based on dynamic MAC learning so any farther changes in topology will be r= eflected on the customer's network correctly.

This is fundamentally different use case than what you = are concerned with, and IMHO could=A0leverage=A0different set of solutions,= as long as they "fundamentally" do not impact the original produ= ct (IDR).
=A0
b) takes a much more "optimistic" approach to dynamically 'fi= xing' the problem in the control plane. =A0Namely, it's my belief (= and, I wish I had hard data to back this up), that it's only an extreme= ly small handful of BGP routes with malformed attributes that are the probl= em here, (in reality ... in only takes 1 malformed attribute to cause chaos= , right?) =A0If that's the case, I would much rather see a solution tha= t tries to contain the small number "bad" routes in a type of = 9;penalty box' and /NOT/ disturb the overwhelming majority of the exist= ing "good" routes, at all.
=A0 c) IOW, there's no need for me, as an operator, to pre-color r= outes with communities that so those routes can survive session failures. = =A0(WRT to persistence, I will /always/ guess wrong which customer's ro= utes to enable it on and which don't care, so at the end of the day ope= rators are going to turn it on for ALL routes).
=A0 d) In addition, when a BGP receiver gets "choked up", hi= s neighbors aren't required to re-flood out routes with a new community= on them indicating something 'bad' has happened. =A0IOW, the probl= em should be contained as locally as possible in the AS, w/out flooding thi= s throughout the whole ASN -- if possible/practical. =A0My routers are busy= enough handling flapping PE-CE circuits and dealing with churn from all th= e existing wonderful "features", that I really don't need add= t'l churn /if/ it can be avoided in the first place.

This would only happen i= n v4/v6 Internet routing space - not in SP owned services or infrastructure= routes. =A0This is why I=A0believe=A0different NLRIs, given that they have= different set of properties, could=A0leverage=A0different solution.


At the scale of BGP that we're operating in our net= works today, this is not a time for half-measures to this problem. =A0We sh= ould aim to fix it once and for all. =A0/If/ we aim to do that, then I'= m all for it.

My apologies if the above sounds too much like a "= rant" ... but, it's been a long day. =A0:-)


No worries. =A0it's on= ly Tuesday - wait till it gets to be Thursday :)

=A0
As always, just my $0.02,

-shane



Likewise, just MHO...

Senad
=A0

Having said that, I fully understand and agree with Robert's conce= rn of implementing this on pure v4/v6 Internet routes - having two diverse = paths on my network, I might not ever want to take "STALE" route = on someone else's network - 1-2 ASs down the road - so some sort of &qu= ot;consistency" across the entire Internet on messaging the "STAL= E" info is needed. =A0It seems that both Enke and Saikat have proposed= two possible solutions for Internet space - either capability advertisemen= t OR "STALE" community to stay with the route=A0indefinitely, ie,= CANNOT be removed. =A0

With that said, apart from Internet routes, I fail =A0t= o see any technological or philosophical issue in going forward with BGP pe= rsistance and having operators enable it on their services as they see it f= it.

Senad




On Tue, Jun 26, 2012 at 1:32 PM, UTTARO, JAMES <ju1738@at= t.com> wrote:
Hannes,

"the "core behaviour" of the protocol (kill RIB entries righ= t
after session loss) is wrong. and since BGP has outgrown its
original purpose (route 1K prefixes) vs. route 100Ks of prefixes,
route unicast and multicast, route VPN/non-VPN,
route non-routing related functionality it is just legitimate to disc= uss
restart and persistence behaviour on a per AFI/SAFI basis"

You have exactly captured where I am coming from in re the discussion= about persistence. As a standards group we must evolve our thinking to add= ress how BGP is being used today and anticipate its future use.

Jim Uttaro

-----Original Message-----
From: Hannes Gredler [mailto:hannes@juniper.net]
Sent: Monday, June 25, 2012 3:08 AM
To: Robert Raszuk
Cc: idr@ietf.org List= ; UTTARO, JAMES
Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document -= 3 more weeks

robert,

On Sat, Jun 23, 2012 at 10:14:43PM +0200, Robert Raszuk wrote:
| >IMO I think that folks need to come to the realization that BGP is | >being used in varied use cases, using the internet application as the=
| >only frame of reference or lens into the requirements for reliability= is
| >simply not appropriate or correct..
|
| +
|
| >All of this being said, there are implementation bugs, overloading of=
| > BGP machinery etc.. that have occurred and will occur in the future.= .
|
|
| I think you need to realize that the key for any application is
| solid IP reachability.

well, there are some of us who believe that there are other ways
of building a service architecture and (surprise !) the transport
path not necessarily has to be IP.

| You can realize any VPN to your customers without BGP being used as
| a service bus for it. It is your choice or your vendor's choice as | you say to "overload BGP machinery" for everything.
=A0 =A0 =A0 =A0 =A0 =A0 ^^^^^^^^^^^^^^^^^^^^^^^

is is really a smart thing to question over-and-over things that:
=A0a. have been decided 10+ years ago
=A0b. have proven to be useful

| Putting more and more questionable requirements on the only protocol
| which provides such global IP reachability proves as a bad idea. It
| makes the protocol more and more fragile.

i'd consider the questionw around
=A0a. graceful control-plane restart and
=A0b. standardized handling of forwarding entries thereafter

as something that should be answered for any protocol in the design phase;<= br> obviously BGP is lacking this and that's why we're getting our
heads together ...

| The motivation that various flavors of VPNs carried by BGP must be
| up only proves that as number of people suggested in the past the
| same BGP protocol should not be used for everything.
|
| The point is not that protocol will not be able to cope with the
| requirement. The point is that it is wrong to keep changing it's
| core behaviour because your VPN or VPLS service goes down.
|
| Moreover you now do not want to limit the changes only to your
| services SAFI, but argue to "enhance" all AFI/SAFIs with it. Th= at is
| something very hard to agree with.

the "core behaviour" of the protocol (kill RIB entries right
after session loss) is wrong. and since BGP has outgrown its
original purpose (route 1K prefixes) vs. route 100Ks of prefixes,
route unicast and multicast, route VPN/non-VPN,
route non-routing related functionality it is just letigimate to discuss restart and persistence behaviour on a per AFI/SAFI basis.

tx,

/hannes
_______________________________________________
Idr mailing list
Idr@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/idr

_______________________________________________
Idr mailing list
Idr@ietf.org
https://ww= w.ietf.org/mailman/listinfo/idr


--e89a8ffbab114160c304c36e1ad2-- From tony.li@tony.li Wed Jun 27 00:44:11 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF71321F8608 for ; Wed, 27 Jun 2012 00:44:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MHlqkmPjbtoC for ; Wed, 27 Jun 2012 00:44:11 -0700 (PDT) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by ietfa.amsl.com (Postfix) with ESMTP id 40A9B21F85EA for ; Wed, 27 Jun 2012 00:44:10 -0700 (PDT) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta04.westchester.pa.mail.comcast.net with comcast id TKk01j0010ldTLk54KkAZq; Wed, 27 Jun 2012 07:44:10 +0000 Received: from [10.21.77.231] ([128.107.239.233]) by omta04.westchester.pa.mail.comcast.net with comcast id TKiS1j00h52qHCY3QKj9vp; Wed, 27 Jun 2012 07:44:06 +0000 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Tony Li In-Reply-To: Date: Tue, 26 Jun 2012 21:42:16 -1000 Content-Transfer-Encoding: quoted-printable Message-Id: <45B57B96-0DFE-40EC-9D3E-D566E1B21ECB@tony.li> References: <14C7F4F06DB5814AB0DE29716C4F6D6702DF7129F6@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <4FE623B3.4060906@raszuk.net> <20120625070729.GC21620@juniper.net> To: "Senad .Palislamovic" X-Mailer: Apple Mail (2.1278) Cc: Shane Amante , "UTTARO, JAMES" , Robert Raszuk , "idr@ietf.org List" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 07:44:12 -0000 Aloha Senad, >> I would agree that that is always a concern, as with any change. I = would also agree that the risk for bugs with this proposal is high, and = that the number of applicable use cases seems to be small. >>=20 > I do not think that "number" is the right unit of measure here. = Number is only relevant as much as the monetary system it is tied to. = In this case, a significance of the use cases, IMHO outweighs the risk. Number is relevant as the group is driven by rough consensus. A = particular issue can have arbitrarily high significance to some, but if = there is no rough consensus within the group, then the proposal will not = progress. >> Sorry, but violently, no. We agreed because we had rough consensus, = NOT because there is a business case. >>=20 > Could it be that a business case drove the "rough consensus"? And = didn't insertion of these services into BGP made operators realize new = revenue streams - which didn't exist before - sooner. Thus the = adaptation rate. Perhaps. It's not clear what the motivations are from all participants. >> There are many considerations beyond a business case and = 'technological sense'. This includes architectural direction and = increased complexity. These must be weighed in making a rational = decision. Hopefully all parties are trying to make a _rational_ = decision. >>=20 > Fully agree. However, different services call for different = architectural directions - thus their level of complexity will be = different. I view complexity as a relative term - complex compared to = what ? Interesting. As a computer scientist, I view complexity as both a = quantifiable issue (i.e., computational and space complexity) and as a = pragmatic issue both for developers and operators. =20 Sure, an algorithm may run in O(1) time. All wonderful, but if the = logic involved is so tortured that the developers cannot get it right, = if the testers can't tell when it is and is not working correctly, and = when it causes more operational issues than it solves, then the proposal = has become too complex. An extremely important part of our job is to judge exactly that = complexity as part of any proposal that is put forth. > Fair enough. However, given that we have moved forward, implemented = it, deployed our services, locked the customers and revenue streams in - = shouldn't we seek to improve them? A fine goal to be sure, but improvements come with costs. Those must be = considered. Mahalo, Tony From tony.li@tony.li Wed Jun 27 01:00:21 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26E7021F8657 for ; Wed, 27 Jun 2012 01:00:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4d73Hv2bCVyR for ; Wed, 27 Jun 2012 01:00:20 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by ietfa.amsl.com (Postfix) with ESMTP id 0EEB721F8650 for ; Wed, 27 Jun 2012 01:00:19 -0700 (PDT) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta03.westchester.pa.mail.comcast.net with comcast id TKtj1j0020Fqzac53L0KFt; Wed, 27 Jun 2012 08:00:19 +0000 Received: from [10.21.77.231] ([128.107.239.233]) by omta08.westchester.pa.mail.comcast.net with comcast id TKz01j00952qHCY3UKzYFm; Wed, 27 Jun 2012 08:00:16 +0000 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Tony Li In-Reply-To: Date: Tue, 26 Jun 2012 21:58:51 -1000 Content-Transfer-Encoding: quoted-printable Message-Id: <15223577-613F-455C-ABBA-59F56F8233AE@tony.li> References: <14C7F4F06DB5814AB0DE29716C4F6D6702DF7129F6@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <4FE623B3.4060906@raszuk.net> <20120625070729.GC21620@juniper.net> <94135843-5EF1-4B4A-9CA3-885A4088A762@castlepoint.net> To: "Senad .Palislamovic" X-Mailer: Apple Mail (2.1278) Cc: "idr@ietf.org List" , Robert Raszuk , Shane Amante , JAMES UTTARO Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 08:00:21 -0000 [Removed ietf-action =85 don't know why they were on this thread=85] On Jun 26, 2012, at 8:12 PM, Senad .Palislamovic wrote: > The right question to ask would be why to draw the line at the first = place. Doesn't leveraging and re-using something that exists and is = proven to work make more sense than going down the path of reinventing = the wheel - as long as the following factors are met: >=20 > - it doesn't impact the original product > - the original product contains the right properties to be extended Fact: it impacts the original product. If you add a subsystem to an = existing system, even if the new subsystem is unused, you've had an = impact. If nothing else, you've added complexity. More likely, you've = added interactions between subsystems. These are not free. Leveraging and re-using certainly have their benefits, but they also = have their drawbacks. Sometimes it is the architect's job to step back, = throw away the original infrastructure and start afresh. You should be very happy about this, otherwise we would be having a = discussion about extending GGP or EGP instead. ;-) Sometimes, it makes sense to start wholly independent subsystems. It's = a judgement call that we must make together. > Has any of the new services "broke" the original product, ie vanilla = routing? =20 Yes, absolutely. We have seen numerous bugs introduced into vanilla = routing because of implementation issues of new functions. For example, = we had several issues around capability negotiations. > So the question is - why should it be looked as a whole system. What = defines a system?=20 Based on your LinkedIn resume, I suspect you know this answer: a system = is a set of interconnected subsystems. BGP should be looked at as a = system because when a particular network element becomes a BGP speaker, = it normally ends up with a single implementation support multiple = AFI/SAFI. Thus, it all ties into a single, global system. =20 Mahalo, Tony From warren@kumari.net Wed Jun 27 03:34:52 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADD2421F866B for ; Wed, 27 Jun 2012 03:34:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rWHEiCxXkCCR for ; Wed, 27 Jun 2012 03:34:51 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 972D021F8608 for ; Wed, 27 Jun 2012 03:34:51 -0700 (PDT) Received: from [10.196.208.139] (unknown [199.91.193.1]) by vimes.kumari.net (Postfix) with ESMTPSA id A30281B402FC; Wed, 27 Jun 2012 06:34:46 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Warren Kumari In-Reply-To: Date: Wed, 27 Jun 2012 12:34:43 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <366CF971-6A6B-41D8-BF07-27BA9C41EB95@kumari.net> References: <14C7F4F06DB5814AB0DE29716C4F6D6702DF7129F6@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <4FE623B3.4060906@raszuk.net> <20120625070729.GC21620@juniper.net> To: "Senad .Palislamovic" X-Mailer: Apple Mail (2.1278) Cc: "idr@ietf.org List" , Robert Raszuk , Tony Li , Shane Amante , "UTTARO, JAMES" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 10:34:52 -0000 On Jun 27, 2012, at 7:18 AM, Senad .Palislamovic wrote: > Tony, >=20 > My comments inline: >=20 > On Tue, Jun 26, 2012 at 10:29 PM, Tony Li wrote: >=20 > Aloha, >=20 > On Jun 26, 2012, at 12:24 PM, Senad .Palislamovic wrote: >=20 > > Would you agree that concern of introducing "bugs" with this change = is more less the same as any feature being introduced into BGP? >=20 >=20 > I would agree that that is always a concern, as with any change. I = would also agree that the risk for bugs with this proposal is high, and = that the number of applicable use cases seems to be small. >=20 > I do not think that "number" is the right unit of measure here. = Number is only relevant as much as the monetary system it is tied to. = In this case, a significance of the use cases, IMHO outweighs the risk. Wow=85 just wow=85 W > =20 >=20 > > And yet, where there are business cases and it just makes = technological sense to go down that path, we all agree and proceed. >=20 >=20 > Sorry, but violently, no. We agreed because we had rough consensus, = NOT because there is a business case. >=20 > Could it be that a business case drove the "rough consensus"? And = didn't insertion of these services into BGP made operators realize new = revenue streams - which didn't exist before - sooner. Thus the = adaptation rate. >=20 > There are many considerations beyond a business case and = 'technological sense'. This includes architectural direction and = increased complexity. These must be weighed in making a rational = decision. Hopefully all parties are trying to make a _rational_ = decision. >=20 > Fully agree. However, different services call for different = architectural directions - thus their level of complexity will be = different. I view complexity as a relative term - complex compared to = what ? >=20 >=20 > > Thus we have reached the point that we have numerous new features = and services in BGP showing up as some sort of route (for forwarding or = topology discovery purposes) - PIM/IGMP state in BGP in MVPNs (6513/14), = MAC state (evpn draft), VPLS - 4761, BGP-TE draft. My point is that we = don't stop innovation because of potential bugs - it is up to the vendor = to ensure bug-free (dream) code. In this case, there are several = operators who do have a business case for this feature, so why stop now? >=20 >=20 > Not everyone agrees that the aforementioned features should have been = included in the first place. Again, it requires rough consensus to move = forward and there are those that will dissent.=20 >=20 > Fair enough. However, given that we have moved forward, implemented = it, deployed our services, locked the customers and revenue streams in - = shouldn't we seek to improve them? >=20 >=20 > Regards, >=20 > Senad >=20 >=20 > Mahalo, > Tony >=20 >=20 >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr -- "Let's just say that if complete and utter chaos was lightning, he'd be = the sort to stand on a hilltop in a thunderstorm wearing wet copper = armour and shouting 'All gods are bastards'." -- Rincewind discussing Twoflower (Terry Pratchett, The Colour of = Magic) From ju1738@att.com Wed Jun 27 11:20:02 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 188C611E8125 for ; Wed, 27 Jun 2012 11:20:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.148 X-Spam-Level: X-Spam-Status: No, score=-106.148 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WqrL9w7tTMBG for ; Wed, 27 Jun 2012 11:19:59 -0700 (PDT) Received: from nbfkord-smmo04.seg.att.com (nbfkord-smmo04.seg.att.com [209.65.160.86]) by ietfa.amsl.com (Postfix) with ESMTP id 48C6111E8088 for ; Wed, 27 Jun 2012 11:19:59 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO nbfkord-smmo04.seg.att.com) by nbfkord-smmo04.seg.att.com(mxl_mta-6.11.0-10) with ESMTP id fce4bef4.7115e940.899305.00-584.2485411.nbfkord-smmo04.seg.att.com (envelope-from ); Wed, 27 Jun 2012 18:19:59 +0000 (UTC) X-MXL-Hash: 4feb4ecf5f4823a9-34a0cb49a0be1def1fe09de12a08d879d1404908 Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo04.seg.att.com(mxl_mta-6.11.0-10) over TLS secured channel with ESMTP id d9e4bef4.0.898933.00-461.2484326.nbfkord-smmo04.seg.att.com (envelope-from ); Wed, 27 Jun 2012 18:19:25 +0000 (UTC) X-MXL-Hash: 4feb4ead7bb2c3a9-9bf959a6489b1c5932fccaeeac0cf4757d535676 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q5RIJ8jQ003810; Wed, 27 Jun 2012 14:19:08 -0400 Received: from sflint01.pst.cso.att.com (sflint01.pst.cso.att.com [144.154.234.228]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q5RIJ5d0003797 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Jun 2012 14:19:06 -0400 Received: from MISOUT7MSGHUB9A.ITServices.sbc.com (misout7msghub9a.itservices.sbc.com [144.151.223.62]) by sflint01.pst.cso.att.com (RSA Interceptor); Wed, 27 Jun 2012 14:18:52 -0400 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9A.ITServices.sbc.com ([144.151.223.62]) with mapi id 14.02.0298.004; Wed, 27 Jun 2012 14:18:52 -0400 From: "UTTARO, JAMES" To: "'Shane Amante'" , "Senad .Palislamovic" Thread-Topic: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks Thread-Index: AQHNVA6cnolFlBQMoUCKeM5al70s85cOQxBA Date: Wed, 27 Jun 2012 18:18:51 +0000 Message-ID: References: <14C7F4F06DB5814AB0DE29716C4F6D6702DF7129F6@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <4FE623B3.4060906@raszuk.net> <20120625070729.GC21620@juniper.net> <94135843-5EF1-4B4A-9CA3-885A4088A762@castlepoint.net> In-Reply-To: <94135843-5EF1-4B4A-9CA3-885A4088A762@castlepoint.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.91.76.182] Content-Type: multipart/alternative; boundary="_000_B17A6910EEDD1F45980687268941550FB3005EMISOUT7MSGUSR9IIT_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=1.0 c=1 a=g8Qva45Ca7EA:10 a=ZQD3OTTxKqYA:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a=48] X-AnalysisOut: [vgC7mUAAAA:8 a=zQP7CpKOAAAA:8 a=OUXY8nFuAAAA:8 a=JsoOE0TsH] X-AnalysisOut: [zswpI7fZtAA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=Hz7IrD] X-AnalysisOut: [YlS0cA:10 a=peF9eE_zjQwA:10 a=K6_QxarDvOJGKk0B:21 a=Il2x1U] X-AnalysisOut: [btE1Twv6VJ:21 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=gKO2Hq4R] X-AnalysisOut: [SVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=tXsnliwV7b4A] X-AnalysisOut: [:10 a=lcbEKMv-IFdM34kl:21 a=XNchfsbcx-5lnzyh:21] Cc: "idr@ietf.org List" , Robert Raszuk Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 18:20:02 -0000 --_000_B17A6910EEDD1F45980687268941550FB3005EMISOUT7MSGUSR9IIT_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, After reviewing all of the comments in re BGP Persistence I= would categorize the opinions of the WG ( At least the ones that have chim= ed in ) in the following manner. I would like to get back to a discussion = about the facts.. a) Folks would believe that the BGP should never have been used for any oth= er services except for the one originally envisaged.. These opinions suggest that if we simply had not extended BGP to other use = cases we would not have to now deal with new/different/addl requirements th= at these services demand.. Some have stated or implied that we simply do n= ot extend BGP further, roll back BGP to only Internet application, and/or c= onvince ourselves that the requirements for these new services are not diff= erent than the original internet use case. IMO this discussion is not appropriate to BGP Persistence.. This discussion= has been settled, the WG has adopted drafts that extend BGP to other use c= ases. Implicit in this adoption is an acknowledgment that these services h= ave different requirements than the original use case and addl drafts/techn= ical specifications have to be created to meet these needs. BGP persistenc= e is an example of this.. I do think that drafts of new technical specifications may not have been co= mplete in defining the semantic or requirements.. As an ex, the authors of = flowspec envisaged a use of BGP to create what is essentially configuration= of a traffic filter.. Generally speaking, configuration is static and pers= ists through session failures. That same paradigm applies to flowspec. b) Folks who feel it is unacceptable that BGP Persistence creates STALE sta= te in domains adjacent to the persistent domain. Two points here.. The first is that this is the current behavior as defined by GR for the int= ernet use case with the fact that there is no method of GR informing that p= aths are STALE. I have repeatedly noted this and so far E. Chen is the only= person that acknowledged the behavior with a caveat that the behavior is f= or a short amount of time and therefore acceptable.. I have heard no other = opinions on this are there any? The second is BGP Persistence draft took note of the above fact in re GR an= d created the ability to inform topologies by th setting of a STALE CV.. Ad= jacent domains can easily identify the paths and decide on whether or not t= hey should be used. So the draft directly addresses this issue. So IMO (a) concerns are of the religious variety.. I cannot speak to the consensus= of the WG when addl use cases for BGP were adopted. But this is the realit= y of where we are.. If IDR is going to be the venue for these discussions t= hen we need to have a consistent view of the reality of BGP and its use cas= es today and into the future. If not, then I would respectfully submit that= the newer use cases be split off from the internet use case and handled in= a different venue. (b) This I truly do not understand.. My co-authors and I have provided a si= mple mechanism to create a persistent solution and included and ability to = inform peer topologies as this IMO seemed like a hole in the current GR dra= ft for this functionality. We have also specifically stated that internet i= s not a use case.. Jim Uttaro From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Shane= Amante Sent: Tuesday, June 26, 2012 10:43 PM To: Senad .Palislamovic Cc: idr@ietf.org List; UTTARO, JAMES; Robert Raszuk Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document -= 3 more weeks Senad, On Jun 26, 2012, at 4:24 PM, Senad .Palislamovic wrote: Robert, Enke, Thanks for the inputs. Your concern with Internet routes is valid one. Shane, Would you agree that concern of introducing "bugs" with this change is more= less the same as any feature being introduced into BGP? And yet, where there are business cases and it just makes technological sen= se to go down that path, we all agree and proceed. Thus we have reached th= e point that we have numerous new features and services in BGP showing up a= s some sort of route (for forwarding or topology discovery purposes) - PIM/= IGMP state in BGP in MVPNs (6513/14), MAC state (evpn draft), VPLS - 4761, = BGP-TE draft. My point is that we don't stop innovation because of potenti= al bugs - it is up to the vendor to ensure bug-free (dream) code. In this = case, there are several operators who do have a business case for this feat= ure, so why stop now? I find it disingenuous, to put it politely, that "it just makes technologic= al sense to go down that path". Since you brought it up by citing a wide v= ariety of additional features that have been added, or are still being [ser= iously] considered being added to BGP, where do we draw the line? No, /ser= iously/, I **really** want to know. To put it bluntly, it seems there's NO= T really a feature that BGP hasn't been adapted to support. Or, to put it = more colloquially: "If BGP is a hammer, [nearly] every problem is a nail". On the one hand, that's a marvelous testament to the original design of BGP= to be able to "easily" adapt to support new services, allowing for moderat= ely fast roll-out on SP networks. However, when looked at from the context= of actually operating networks that run BGP, i.e.: - draft-ietf-grow-ops-reqs-for-bgp-error-handling; - my own and others studies into the present scalability of iBGP; - lots of research papers documenting various aspects of BGP, (Labovitz/Ahu= ja; Route Flap Damping; studies on CLUSTER_LIST changes, but not their leng= th, causing flooding of new iBGP updates inside and outside an ASN, etc.) ... I am very concerned that if we keep /incrementally/ pouring new feature= s into BGP without considering the overall effects on BGP as a _system_ the= n we're not doing a good enough job. By a "system" I mean of networks cons= isting of not just 1 router in an ASN, but thousands of routers in a single= [VPN] network, and orders of magnitude more in the DFZ. FWIW, that is the= context by which I evaluate drafts proposed in this, and other, WG's. Furthermore, and back to the discussion of this particular draft, I acknowl= edge that BGP session survivability is a problem; however, in the context o= f the networks that I operate: a) It has not occurred in my VPN networks; b) It has occurred, but only very rarely in my Internet network, (and even= then several of those events are clearly attributable to _implementation_ = errors that nothing we do in IDR will ever fix). Ultimately, I really do want the IDR WG to solve this problem, but I hope t= hat we will seriously raise the bar in terms of what we, as operators, are = expecting for a solution here. IMO, I think that is the spirit (if not mor= e) of why draft-ietf-grow-ops-reqs-for-bgp-error-handling was written. Per= sonally, at this stage (and given the data I cite above wrt my own networks= ), I believe we have a moderate amount of time that would allow us to raise= the bar on our expectations. And, I would rather set the bar too high, an= d miss it, then only have a partial solution that is the currently proposed= persistence draft. IMHO, I would much rather see a solution that: a) has consistent support across _ALL_ AFI/SAFI's -- that benefits everyone= . It allows for a consistent training regime for my Ops folks, regardless = of which services or networks they are working on, etc. b) takes a much more "optimistic" approach to dynamically 'fixing' the prob= lem in the control plane. Namely, it's my belief (and, I wish I had hard d= ata to back this up), that it's only an extremely small handful of BGP rout= es with malformed attributes that are the problem here, (in reality ... in = only takes 1 malformed attribute to cause chaos, right?) If that's the cas= e, I would much rather see a solution that tries to contain the small numbe= r "bad" routes in a type of 'penalty box' and /NOT/ disturb the overwhelmin= g majority of the existing "good" routes, at all. c) IOW, there's no need for me, as an operator, to pre-color routes with = communities that so those routes can survive session failures. (WRT to per= sistence, I will /always/ guess wrong which customer's routes to enable it = on and which don't care, so at the end of the day operators are going to tu= rn it on for ALL routes). d) In addition, when a BGP receiver gets "choked up", his neighbors aren'= t required to re-flood out routes with a new community on them indicating s= omething 'bad' has happened. IOW, the problem should be contained as local= ly as possible in the AS, w/out flooding this throughout the whole ASN -- i= f possible/practical. My routers are busy enough handling flapping PE-CE c= ircuits and dealing with churn from all the existing wonderful "features", = that I really don't need addt'l churn /if/ it can be avoided in the first p= lace. At the scale of BGP that we're operating in our networks today, this is not= a time for half-measures to this problem. We should aim to fix it once an= d for all. /If/ we aim to do that, then I'm all for it. My apologies if the above sounds too much like a "rant" ... but, it's been = a long day. :-) As always, just my $0.02, -shane Having said that, I fully understand and agree with Robert's concern of imp= lementing this on pure v4/v6 Internet routes - having two diverse paths on = my network, I might not ever want to take "STALE" route on someone else's n= etwork - 1-2 ASs down the road - so some sort of "consistency" across the e= ntire Internet on messaging the "STALE" info is needed. It seems that both= Enke and Saikat have proposed two possible solutions for Internet space - = either capability advertisement OR "STALE" community to stay with the route= indefinitely, ie, CANNOT be removed. With that said, apart from Internet routes, I fail to see any technologica= l or philosophical issue in going forward with BGP persistance and having o= perators enable it on their services as they see it fit. Senad On Tue, Jun 26, 2012 at 1:32 PM, UTTARO, JAMES > wrote: Hannes, "the "core behaviour" of the protocol (kill RIB entries right after session loss) is wrong. and since BGP has outgrown its original purpose (route 1K prefixes) vs. route 100Ks of prefixes, route unicast and multicast, route VPN/non-VPN, route non-routing related functionality it is just legitimate to discuss restart and persistence behaviour on a per AFI/SAFI basis" You have exactly captured where I am coming from in re the discussion about= persistence. As a standards group we must evolve our thinking to address h= ow BGP is being used today and anticipate its future use. Jim Uttaro -----Original Message----- From: Hannes Gredler [mailto:hannes@juniper.net] Sent: Monday, June 25, 2012 3:08 AM To: Robert Raszuk Cc: idr@ietf.org List; UTTARO, JAMES Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document -= 3 more weeks robert, On Sat, Jun 23, 2012 at 10:14:43PM +0200, Robert Raszuk wrote: | >IMO I think that folks need to come to the realization that BGP is | >being used in varied use cases, using the internet application as the | >only frame of reference or lens into the requirements for reliability is | >simply not appropriate or correct.. | | + | | >All of this being said, there are implementation bugs, overloading of | > BGP machinery etc.. that have occurred and will occur in the future.. | | | I think you need to realize that the key for any application is | solid IP reachability. well, there are some of us who believe that there are other ways of building a service architecture and (surprise !) the transport path not necessarily has to be IP. | You can realize any VPN to your customers without BGP being used as | a service bus for it. It is your choice or your vendor's choice as | you say to "overload BGP machinery" for everything. ^^^^^^^^^^^^^^^^^^^^^^^ is is really a smart thing to question over-and-over things that: a. have been decided 10+ years ago b. have proven to be useful | Putting more and more questionable requirements on the only protocol | which provides such global IP reachability proves as a bad idea. It | makes the protocol more and more fragile. i'd consider the questionw around a. graceful control-plane restart and b. standardized handling of forwarding entries thereafter as something that should be answered for any protocol in the design phase; obviously BGP is lacking this and that's why we're getting our heads together ... | The motivation that various flavors of VPNs carried by BGP must be | up only proves that as number of people suggested in the past the | same BGP protocol should not be used for everything. | | The point is not that protocol will not be able to cope with the | requirement. The point is that it is wrong to keep changing it's | core behaviour because your VPN or VPLS service goes down. | | Moreover you now do not want to limit the changes only to your | services SAFI, but argue to "enhance" all AFI/SAFIs with it. That is | something very hard to agree with. the "core behaviour" of the protocol (kill RIB entries right after session loss) is wrong. and since BGP has outgrown its original purpose (route 1K prefixes) vs. route 100Ks of prefixes, route unicast and multicast, route VPN/non-VPN, route non-routing related functionality it is just letigimate to discuss restart and persistence behaviour on a per AFI/SAFI basis. tx, /hannes _______________________________________________ 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 --_000_B17A6910EEDD1F45980687268941550FB3005EMISOUT7MSGUSR9IIT_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

 <= /p>

    &= nbsp;           After rev= iewing all of the comments in re BGP Persistence I would categorize the opi= nions of the WG ( At least the ones that have chimed in )  in the following manner. I would like to get back to a discussion = about the facts..

 <= /p>

a) Folks would believe th= at the BGP should never have been used for any other services except for th= e one originally envisaged..

 <= /p>

These opinions suggest th= at if we simply had not extended BGP to other use cases we would not have t= o now deal with new/different/addl requirements that these services demand.. Some have stated or implied  that we simply do not = extend BGP further, roll back BGP to only Internet application, and/or conv= ince ourselves that the requirements for these new services are not differe= nt than the original internet use case.

 <= /p>

IMO this discussion is no= t appropriate to BGP Persistence.. This discussion has been settled, the WG= has adopted drafts that extend BGP to other use cases.  Implicit in this adoption is an acknowledgment that these services h= ave different requirements than the original use case and addl drafts/techn= ical specifications  have to be created to meet these needs. BGP persi= stence is an example of this..

 <= /p>

I do think that drafts of= new technical specifications may not have been complete in defining the se= mantic or requirements.. As an ex, the authors of flowspec envisaged a use of BGP to create what is essentially configuration of a tr= affic filter.. Generally speaking, configuration is static and persists thr= ough session failures. That same paradigm applies to flowspec.

 <= /p>

b) Folks who feel it is u= nacceptable that BGP Persistence creates STALE state in domains adjacent to= the persistent domain.

 <= /p>

Two points here..

 <= /p>

The first is that this is= the current behavior as defined by GR for the internet use case with the f= act that there is no method of GR informing that paths are STALE. I have repeatedly noted this and so far E. Chen is the only person = that acknowledged the behavior with a caveat that the behavior is for a sho= rt amount of time and therefore acceptable.. I have heard no other opinions= on this are there any?

 <= /p>

The second is BGP Persist= ence draft took note of the above fact in re GR and created the ability to = inform topologies by th setting of a STALE CV.. Adjacent domains can easily identify the paths and decide on whether or not they sh= ould be used. So the draft directly addresses this issue.=

 <= /p>

So IMO<= /p>

 <= /p>

(a) concerns are of the r= eligious variety.. I cannot speak to the consensus of the WG when addl use = cases for BGP were adopted. But this is the reality of where we are.. If IDR is going to be the venue for these discussions then we nee= d to have a consistent view of the reality of BGP and its use cases today a= nd into the future. If not, then I would respectfully submit that the newer= use cases be split off from the internet use case and handled in a different venue.

 <= /p>

(b) This I truly do not u= nderstand.. My co-authors and I have provided a simple mechanism to create = a persistent solution and included and ability to inform peer topologies as this IMO seemed like a hole in the current GR draft for= this functionality. We have also specifically stated that internet is not = a use case..

 <= /p>

Jim Uttaro

 <= /p>

 <= /p>

 <= /p>

 <= /p>

From: idr-boun= ces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Shane Amante
Sent: Tuesday, June 26, 2012 10:43 PM
To: Senad .Palislamovic
Cc: idr@ietf.org List; UTTARO, JAMES; Robert Raszuk
Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG doc= ument - 3 more weeks

 

Senad,

 

On Jun 26, 2012, at 4:24 PM, Senad .Palislamovic wro= te:

Robert, Enke,

 

Thanks for the inputs.  Your concern with Inter= net routes is valid one.

 

Shane,

 

Would you agree that concern of introducing "bu= gs" with this change is more less the same as any feature being introd= uced into BGP?

 

And yet, where there are business cases and it just = makes technological sense to go down that path, we all agree and proceed. &= nbsp;Thus we have reached the point that we have numerous new features and = services in BGP showing up as some sort of route (for forwarding or topology discovery purposes) - PIM/IGMP state = in BGP in MVPNs (6513/14), MAC state (evpn draft), VPLS - 4761, BGP-TE draf= t.  My point is that we don't stop innovation because of potential bug= s - it is up to the vendor to ensure bug-free (dream) code.  In this case, there are several operators who= do have a business case for this feature, so why stop now?

 

I find it disingenuous, to put it politely, that &qu= ot;it just makes technological sense to go down that path".  Sinc= e you brought it up by citing a wide variety of additional features that ha= ve been added, or are still being [seriously] considered being added to BGP, where do we draw the line?  No, /seriously/, I **= really** want to know.  To put it bluntly, it seems there's NOT really= a feature that BGP hasn't been adapted to support.  Or, to put it mor= e colloquially: "If BGP is a hammer, [nearly] every problem is a nail".

 

On the one hand, that's a marvelous testament t= o the original design of BGP to be able to "easily" adapt to supp= ort new services, allowing for moderately fast roll-out on SP networks. &nb= sp;However, when looked at from the context of actually operating networks that run BGP, i.e.:

- draft-ietf-grow-ops-reqs-for-bgp-error-handling;

- my own and others studies into the present scalabi= lity of iBGP;

- lots of research papers documenting various aspect= s of BGP, (Labovitz/Ahuja; Route Flap Damping; studies on CLUSTER_LIST chan= ges, but not their length, causing flooding of new iBGP updates inside and = outside an ASN, etc.)

... I am very concerned that if we keep /incremental= ly/ pouring new features into BGP without considering the overall effects o= n BGP as a _system_ then we're not doing a good enough job.  By a= "system" I mean of networks consisting of not just 1 router in an ASN, but thousands of routers in a single [VPN] networ= k, and orders of magnitude more in the DFZ.  FWIW, that is the context= by which I evaluate drafts proposed in this, and other, WG's.

 

Furthermore, and back to the discussion of this part= icular draft, I acknowledge that BGP session survivability is a problem; ho= wever, in the context of the networks that I operate:

a)  It has not occurred in my VPN networks;

b)  It has occurred, but only very rarely in my= Internet network, (and even then several of those events are clearly attri= butable to _implementation_ errors that nothing we do in IDR will ever fix)= .

 

Ultimately, I really do want the IDR WG to solve thi= s problem, but I hope that we will seriously raise the bar in terms of what= we, as operators, are expecting for a solution here.  IMO, I think th= at is the spirit (if not more) of why draft-ietf-grow-ops-reqs-for-bgp= -error-handling was written.  Personally, at this stage (and given the data I cite ab= ove wrt my own networks), I believe we have a moderate amount of time that = would allow us to raise the bar on our expectations.  And, I would rat= her set the bar too high, and miss it, then only have a partial solution that is the currently proposed persistence dr= aft.  IMHO, I would much rather see a solution that:

a) has consistent support across _ALL_ AFI/SAFI's --= that benefits everyone.  It allows for a consistent training regime f= or my Ops folks, regardless of which services or networks they are working = on, etc.

b) takes a much more "optimistic" approach= to dynamically 'fixing' the problem in the control plane.  Namely, it= 's my belief (and, I wish I had hard data to back this up), that it's only = an extremely small handful of BGP routes with malformed attributes that are the problem here, (in reality ... in only takes 1 malf= ormed attribute to cause chaos, right?)  If that's the case, I would m= uch rather see a solution that tries to contain the small number "bad&= quot; routes in a type of 'penalty box' and /NOT/ disturb the overwhelming majority of the existing "good" routes,= at all.

  c) IOW, there's no need for me, as an operato= r, to pre-color routes with communities that so those routes can survive se= ssion failures.  (WRT to persistence, I will /always/ guess wrong whic= h customer's routes to enable it on and which don't care, so at the end of the day operators are going to turn it on for= ALL routes).

  d) In addition, when a BGP receiver gets &quo= t;choked up", his neighbors aren't required to re-flood out routes wit= h a new community on them indicating something 'bad' has happened.  IO= W, the problem should be contained as locally as possible in the AS, w/out flooding this throughout the whole ASN -- if possible/pra= ctical.  My routers are busy enough handling flapping PE-CE circuits a= nd dealing with churn from all the existing wonderful "features",= that I really don't need addt'l churn /if/ it can be avoided in the first place.

 

At the scale of BGP that we're operating in our netw= orks today, this is not a time for half-measures to this problem.  We = should aim to fix it once and for all.  /If/ we aim to do that, then I= 'm all for it.

 

My apologies if the above sounds too much like a &qu= ot;rant" ... but, it's been a long day.  :-)

 

As always, just my $0.02,

 

-shane

 

 



Having said that, I fully understand and agree with = Robert's concern of implementing this on pure v4/v6 Internet routes - havin= g two diverse paths on my network, I might not ever want to take "STAL= E" route on someone else's network - 1-2 ASs down the road - so some sort of "consistency" across the ent= ire Internet on messaging the "STALE" info is needed.  It se= ems that both Enke and Saikat have proposed two possible solutions for Inte= rnet space - either capability advertisement OR "STALE" community to stay with the route indefinitely, ie, CANNOT be removed.  

 

With that said, apart from Internet routes, I fail &= nbsp;to see any technological or philosophical issue in going forward with = BGP persistance and having operators enable it on their services as they se= e it fit.

 

Senad

 

 

 

On Tue, Jun 26, 2012 at 1:32 PM, UTTARO, JAMES <<= a href=3D"mailto:ju1738@att.com" target=3D"_blank">ju1738@att.com> w= rote:

Hannes,


"the "core behaviour" of the protocol (kill RIB entries righ= t
after session loss) is wrong. and since BGP has outgrown its
original purpose (route 1K prefixes) vs. route 100Ks of prefixes,
route unicast and multicast, route VPN/non-VPN,

route non-routing related functionality it is just l= egitimate to discuss

restart and persisten= ce behaviour on a per AFI/SAFI basis"

You have exactly captured where I am coming from in = re the discussion about persistence. As a standards group we must evolve ou= r thinking to address how BGP is being used today and anticipate its future= use.

Jim Uttaro


-----Original Message-----
From: Hannes Gredler [mailto:hannes@j= uniper.net]
Sent: Monday, June 25, 2012 3:08 AM
To: Robert Raszuk
Cc: idr@ietf.org List; UTTARO, JAMES Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document -= 3 more weeks

robert,

On Sat, Jun 23, 2012 at 10:14:43PM +0200, Robert Raszuk wrote:
| >IMO I think that folks need to come to the realization that BGP is | >being used in varied use cases, using the internet application as the=
| >only frame of reference or lens into the requirements for reliability= is
| >simply not appropriate or correct..
|
| +
|
| >All of this being said, there are implementation bugs, overloading of=
| > BGP machinery etc.. that have occurred and will occur in the future.= .
|
|
| I think you need to realize that the key for any application is
| solid IP reachability.

well, there are some of us who believe that there are other ways
of building a service architecture and (surprise !) the transport
path not necessarily has to be IP.

| You can realize any VPN to your customers without BGP being used as
| a service bus for it. It is your choice or your vendor's choice as
| you say to "overload BGP machinery" for everything.
            ^^^^^^^^^^^^^^^^^^^^^^^

is is really a smart thing to question over-and-over things that:
 a. have been decided 10+ years ago
 b. have proven to be useful

| Putting more and more questionable requirements on the only protocol
| which provides such global IP reachability proves as a bad idea. It
| makes the protocol more and more fragile.

i'd consider the questionw around
 a. graceful control-plane restart and
 b. standardized handling of forwarding entries thereafter

as something that should be answered for any protocol in the design phase;<= br> obviously BGP is lacking this and that's why we're getting our
heads together ...

| The motivation that various flavors of VPNs carried by BGP must be
| up only proves that as number of people suggested in the past the
| same BGP protocol should not be used for everything.
|
| The point is not that protocol will not be able to cope with the
| requirement. The point is that it is wrong to keep changing it's
| core behaviour because your VPN or VPLS service goes down.
|
| Moreover you now do not want to limit the changes only to your
| services SAFI, but argue to "enhance" all AFI/SAFIs with it. Th= at is
| something very hard to agree with.

the "core behaviour" of the protocol (kill RIB entries right
after session loss) is wrong. and since BGP has outgrown its
original purpose (route 1K prefixes) vs. route 100Ks of prefixes,
route unicast and multicast, route VPN/non-VPN,
route non-routing related functionality it is just letigimate to discuss restart and persistence behaviour on a per AFI/SAFI basis.

tx,

/hannes
_______________________________________________
Idr mailing list
Idr@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/idr

 

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/= mailman/listinfo/idr

 

--_000_B17A6910EEDD1F45980687268941550FB3005EMISOUT7MSGUSR9IIT_-- From shane@castlepoint.net Wed Jun 27 12:35:48 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36A2721F86A8 for ; Wed, 27 Jun 2012 12:35:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.456 X-Spam-Level: X-Spam-Status: No, score=-2.456 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nW5V5fOB9d5x for ; Wed, 27 Jun 2012 12:35:47 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id 35C9721F85F6 for ; Wed, 27 Jun 2012 12:35:47 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id 3E9CF368199; Wed, 27 Jun 2012 13:35:46 -0600 (MDT) Received: from host2.tcb.net (64.78.235.218 [64.78.235.218]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Wed, 27 Jun 2012 13:35:46 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=64.78.235.218; client-port=54478; data-bytes=0 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_EF1B1710-0223-4308-AA96-9089DFF6D0B7" From: Shane Amante In-Reply-To: Date: Wed, 27 Jun 2012 13:35:45 -0600 Message-Id: <84158396-59E4-478B-822C-02F0F42402C3@castlepoint.net> References: <14C7F4F06DB5814AB0DE29716C4F6D6702DF7129F6@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <4FE623B3.4060906@raszuk.net> <20120625070729.GC21620@juniper.net> <94135843-5EF1-4B4A-9CA3-885A4088A762@castlepoint.net> To: "UTTARO, JAMES" X-Mailer: Apple Mail (2.1278) Cc: "idr@ietf.org List" , Robert Raszuk Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 19:35:48 -0000 --Apple-Mail=_EF1B1710-0223-4308-AA96-9089DFF6D0B7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Jim, On Jun 27, 2012, at 12:18 PM, UTTARO, JAMES wrote: > All, > =20 > After reviewing all of the comments in re BGP = Persistence I would categorize the opinions of the WG ( At least the = ones that have chimed in ) in the following manner. I would like to get = back to a discussion about the facts.. [--snip--] > b) Folks who feel it is unacceptable that BGP Persistence creates = STALE state in domains adjacent to the persistent domain.=20 > =20 > Two points here.. > =20 > The first is that this is the current behavior as defined by GR for = the internet use case with the fact that there is no method of GR = informing that paths are STALE. I have repeatedly noted this and so far = E. Chen is the only person that acknowledged the behavior with a caveat = that the behavior is for a short amount of time and therefore = acceptable.. I have heard no other opinions on this are there any? > =20 > The second is BGP Persistence draft took note of the above fact in re = GR and created the ability to inform topologies by th setting of a STALE = CV.. Adjacent domains can easily identify the paths and decide on = whether or not they should be used. So the draft directly addresses this = issue. > =20 > So IMO > =20 > (b) This I truly do not understand.. My co-authors and I have provided = a simple mechanism to create a persistent solution and included and = ability to inform peer topologies as this IMO seemed like a hole in the = current GR draft for this functionality. We have also specifically = stated that internet is not a use case.. I have significant concerns wrt (b), in particular your last sentence = above. More specifically, this is the IDR WG, where the charter = currently states: ---snip--- The main objective of the working group is to support the use of BGP-4 by IP version 4 and IP version 6 networks. The working group will also continue to work on improving the robustness and scalability of BGP. ---snip--- IMHO, both sentences appear to state that the WG should focus on = developing the robustness and scalability of BGP for all types of = networks, not just VPN networks. As such, it may be prudent for the WG = to consider acknowledging this is a problem with the _architecture_ of = BGP, applicable to all AFI/SAFI's, and diligently work toward a single = solution that addresses this problem in a comprehensive and consistent = manner across all AFI/SAFI's. -shane= --Apple-Mail=_EF1B1710-0223-4308-AA96-9089DFF6D0B7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
b) Folks who feel it is unacceptable that BGP = Persistence creates STALE state in domains adjacent to the persistent = domain.
Two points = here..
The first is that this = is the current behavior as defined by GR for the internet use case with = the fact that there is no method of GR informing that paths are STALE. I = have repeatedly noted this and so far E. Chen is the only person that = acknowledged the behavior with a caveat that the behavior is for a short = amount of time and therefore acceptable.. I have heard no other opinions = on this are there any?
The second is BGP = Persistence draft took note of the above fact in re GR and created the = ability to inform topologies by th setting of a STALE CV.. Adjacent = domains can easily identify the paths and decide on whether or not they = should be used. So the draft directly addresses this = issue.
So = IMO
(b) This I truly do not = understand.. My co-authors and I have provided a simple mechanism to = create a persistent solution and included and ability to inform peer = topologies as this IMO seemed like a hole in the current GR draft for = this functionality. We have also specifically stated that internet is = not a use = case..

I = have significant concerns wrt (b), in particular your last sentence = above.  More specifically, this is the IDR WG, where the = charter currently states:
---snip---
  =   The main objective of the working group is to support the use = of
    BGP-4 by IP version 4 and IP version 6 = networks. The working group
    will also continue = to work on improving the robustness and
    = scalability of BGP.
---snip---
IMHO, both sentences = appear to state that the WG should focus on developing the robustness = and scalability of BGP for all types of networks, not just VPN networks. =  As such, it may be prudent for the WG to consider = acknowledging this is a problem with the _architecture_ of BGP, = applicable to all AFI/SAFI's, and diligently work toward a single = solution that addresses this problem in a comprehensive and consistent = manner across all = AFI/SAFI's.

-shane
= --Apple-Mail=_EF1B1710-0223-4308-AA96-9089DFF6D0B7-- From brian.peter.dickson@gmail.com Wed Jun 27 14:05:47 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C143A11E80B6 for ; Wed, 27 Jun 2012 14:05:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jz8JHcIc4Yz5 for ; Wed, 27 Jun 2012 14:05:46 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2569821F86F1 for ; Wed, 27 Jun 2012 14:05:45 -0700 (PDT) Received: by werb13 with SMTP id b13so1183815wer.31 for ; Wed, 27 Jun 2012 14:05:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qw6h0WDIkPKw7QJB6jApRU6ZI01DKl/mqqHUIxyaqLY=; b=QPUol1ujL5HS/XT/Z9n8IqIrFV2eYxcw9zVDJt1PsI0UQ6JdqIpEM0STx4XvhWyURK OJJ5cRv5qNGU4xFUF+KwsfWKqt6m8dJWvmx7rNo1ogrc1g0PBQqgvrgl3Mj4A7Tc8evH Ojg/XezgSZCPo+5Du38ZyLeGY+zGR5C6m+yR9YYexGtgwYHBimyMIQrTka00ZRDVR1cA RPo+9DLuIOfa4pe8F0fTapXD8YKZCPBmv93Lj8T+OIlwR0Z6Ofnl1WIRWa7yam5Hqzyy vNUgg208/++3/OFDS0WvGo1pU1YHHTXWQYs8jrAeu5iNgSQ44moVt1TWqkkU7FEjtjv4 mCXg== MIME-Version: 1.0 Received: by 10.180.99.70 with SMTP id eo6mr7681493wib.17.1340831145277; Wed, 27 Jun 2012 14:05:45 -0700 (PDT) Received: by 10.223.39.19 with HTTP; Wed, 27 Jun 2012 14:05:45 -0700 (PDT) In-Reply-To: References: <14C7F4F06DB5814AB0DE29716C4F6D6702DF7129F6@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <4FE623B3.4060906@raszuk.net> <20120625070729.GC21620@juniper.net> <94135843-5EF1-4B4A-9CA3-885A4088A762@castlepoint.net> Date: Wed, 27 Jun 2012 17:05:45 -0400 Message-ID: From: Brian Dickson To: "UTTARO, JAMES" Content-Type: multipart/alternative; boundary=f46d04428b501e39fc04c37a94d3 Cc: Shane Amante , Robert Raszuk , "idr@ietf.org List" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 21:05:47 -0000 --f46d04428b501e39fc04c37a94d3 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jun 27, 2012 at 2:18 PM, UTTARO, JAMES wrote: > All,**** > > ** ** > > After reviewing all of the comments in re BGP Persistence > I would categorize the opinions of the WG ( At least the ones that have > chimed in ) in the following manner. I would like to get back to a > discussion about the facts.. > > ** ** > > b) Folks who feel it is unacceptable that BGP Persistence creates STALE > state in domains adjacent to the persistent domain.**** > > ** ** > > Two points here.. **** > > ** ** > > The first is that this is the current behavior as defined by GR for the > internet use case with the fact that there is no method of GR informing > that paths are STALE. I have repeatedly noted this and so far E. Chen is > the only person that acknowledged the behavior with a caveat that the > behavior is for a short amount of time and therefore acceptable.. I have > heard no other opinions on this are there any? **** > > ** ** > > The second is BGP Persistence draft took note of the above fact in re GR > and created the ability to inform topologies by th setting of a STALE CV.. > Adjacent domains can easily identify the paths and decide on whether or not > they should be used. So the draft directly addresses this issue.**** > > ** ** > > So IMO > > ** ** > > (b) This I truly do not understand.. My co-authors and I have provided a > simple mechanism to create a persistent solution and included and ability > to inform peer topologies as this IMO seemed like a hole in the current GR > draft for this functionality. We have also specifically stated that > internet is not a use case.. > I have a few questions, after more carefully reading the -01 draft. Please indulge me, I am interested in understanding the relationship between the motivation/goal, the specific use cases presented, and the mechanisms themselves. First, it seems that the "STALE" stuff is partly motivated by a perceived lack of notification in GR. Isn't that irrelevant to the draft at hand, and perhaps better addressed by updating GR? Also, in the use cases, there does not seem to be any real value to advertising this "STALE" state beyond the local systems. In the L2VPN in particular, there is no "beyond" at all. So, why bother with "STALE" at all? I don't see it being used anywhere in your draft, only that it is being set. The main problem (that needs to be solved, i.e. the motivation for Persistence) seems to be that intra-AS PE routers, doing L2VPN, would like to maintain state in the case where one or more intermediate RRs "go away" for some period of time. The scope of "state" information, is more closely aligned with the BGP peer state, rather than attributes of individual NLRIs of any given AFI/SAFI. Would it not be (a) simpler, (b) more scalable, and (c) more trivial to implement, by creating an Internet-Draft for a negotiated option, "Persistent", where, when two or more parties negotiate this option, and NLRIs heard over such sessions being "held" if/when a BGP session is terminated? This would not have any direct impact to path selection, for example, and would fairly trivially support negotiated (based on local configuration of) timers and "reaping" NLRIs upon timer expiry. Behavior per-AFI/SAFI should be able to be specified. Not needing to change the content or format of UPDATEs should be seen as a goal, rather than the other way round. Let alone further overloading the COMMUNITY attribute, with mandated behavior based on something that is both optional _and_ transitive. (Yuck.) In fact, would not this fit nicely as a sub-code to GR, with a negotiated status and timer between peers (or RR servers/clients)? Perhaps having the "negotiation" have multiple values, such as "never", "allow", "prefer", "always", so that in appropriately configured networks, on a per-peer (or peer-group) basis, it could be centrally controlled by the RR primarily. One other question I have, is about Section 6.1. I do not understand a couple of things about the diagram and text: Is the diagram just messed up a bit, with RR2 meaning to talk to PE1 and PE2, rather than RR2 talking to RR1 and CE1? Which BGP sessions are presumed to go away, i.e. where Persistence will make a difference (or fix a problem you're seeing)? Is it the case that *both* PE1-RR1 *and* PE1-RR2 BGP sessions fail simultaneously? And now to dig deeper into the diagram: Are CE1-PE1 and CE2-PE2 connections over switched (L2 Ethernet) connections? Would the problem you are experiencing not be possible to fix with, say, PVRST over dual-PE1's facing CE1, and similarly dual-PE2's facing CE2, in a redundant configuration? That way, only PE1a (and not PE1b) would dump BGP peering, and things would fail-over to PE1b? (At which point it is a hardware cost and network design exercise, rather than a protocol thing.) You'd have two wires (PE1a-PE1b, and PE2a-PE2b) and two pseudo-wires (PE1a-PE2a, ,and PE1b-PE2b) forming a "square" topology on which some spanning-tree thing would need to turn into a loop-free topology, and it wouldn't matter which PE1 or PE2 was preferred by CE1 and CE2 respectively. Sincerely, Brian Dickson --f46d04428b501e39fc04c37a94d3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Jun 27, 2012 at 2:18 PM, UTTARO,= JAMES <ju1738@att.com> wrote:

All,=

=A0<= /p>

=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 After reviewing all of the comments in re BGP Persist= ence I would categorize the opinions of the WG ( At least the ones that hav= e chimed in )=A0 in the following manner. I would like to get back to a discussion abo= ut the facts..

=A0<= /p>

b) Folks who feel it is u= nacceptable that BGP Persistence creates STALE state in domains adjacent to= the persistent domain.

=A0<= /p>

Two points here..

=A0<= /p>

The first is that this is= the current behavior as defined by GR for the internet use case with the f= act that there is no method of GR informing that paths are STALE. I have repeatedly noted this and so far E. Chen is the only person = that acknowledged the behavior with a caveat that the behavior is for a sho= rt amount of time and therefore acceptable.. I have heard no other opinions= on this are there any?

=A0<= /p>

The second is BGP Persist= ence draft took note of the above fact in re GR and created the ability to = inform topologies by th setting of a STALE CV.. Adjacent domains can easily identify the paths and decide on whether or not they sh= ould be used. So the draft directly addresses this issue.

=A0<= /p>

So IMO

=A0<= /p>

(b) This I truly do not u= nderstand.. My co-authors and I have provided a simple mechanism to create = a persistent solution and included and ability to inform peer topologies as this IMO seemed like a hole in the current GR draft for= this functionality. We have also specifically stated that internet is not = a use case..



I have a few questions, after more carefully reading the -01 dra= ft.

Please indulge me, I am interested in understa= nding the relationship between the motivation/goal, the specific use cases = presented, and the mechanisms themselves.=A0

First, it seems that the "STALE" stuff is par= tly motivated by a perceived lack of notification in GR. Isn't that irr= elevant to the draft at hand, and perhaps better addressed by updating GR?<= /div>

Also, in the use cases, there does not seem to be any r= eal value to advertising this "STALE" state beyond the local syst= ems. In the L2VPN in particular, there is no "beyond" at all. So,= why bother with "STALE" at all? I don't see it being used an= ywhere in your draft, only that it is being set.

The main problem (that needs to be solved, i.e. the mot= ivation for Persistence) seems to be that intra-AS PE routers, doing L2VPN,= would like to maintain state in the case where one or more intermediate RR= s "go away" for some period of time.
The scope of "state" information, is more closely aligned wi= th the BGP peer state, rather than attributes of individual NLRIs of any gi= ven AFI/SAFI.

Would it not be (a) simpler, (b) mor= e scalable, and (c) more trivial to implement, by creating an Internet-Draf= t for a negotiated option, "Persistent", where, when two or more = parties negotiate this option, and NLRIs heard over such sessions being &qu= ot;held" if/when a BGP session is terminated?

This would not have any direct impact to path selection= , for example, and would fairly trivially support negotiated (based on loca= l configuration of) timers and "reaping" NLRIs upon timer expiry.= Behavior per-AFI/SAFI should be able to be specified.

Not needing to change the content or format of UPDATEs = should be seen as a goal, rather than the other way round.

Let alone further overloading the COMMUNITY attribute, with mandat= ed behavior based on something that is both optional _and_ transitive. (Yuc= k.)

In fact, would not this fit nicely as a sub-code to GR,= with a negotiated status and timer between peers (or RR servers/clients)?<= /div>

Perhaps having the "negotiation" have mu= ltiple values, such as "never", "allow", "prefer&q= uot;, "always", so that in appropriately configured networks, on = a per-peer (or peer-group) basis, it could be centrally controlled by the R= R primarily.

One other question I have, is about Section 6.1.
<= div>I do not understand a couple of things about the diagram and text:
Is the diagram just messed up a bit, with RR2 meaning to talk to PE1 = and PE2, rather than RR2 talking to =A0RR1 and CE1?

Which BGP sessions are presumed to go away, i.e. where = Persistence will make a difference (or fix a problem you're seeing)?
Is it the case that *both* PE1-RR1 *and* PE1-RR2 BGP sessions fail = simultaneously?

And now to dig deeper into the diagram:
Are C= E1-PE1 and CE2-PE2 connections over switched (L2 Ethernet) connections?

Would the problem you are experiencing not be possibl= e to fix with, say, PVRST over dual-PE1's facing CE1, and similarly dua= l-PE2's facing CE2, in a redundant configuration? That way, only PE1a (= and not PE1b) would dump BGP peering, and things would fail-over to PE1b? (= At which point it is a hardware cost and network design exercise, rather th= an a protocol thing.)

You'd have two wires (PE1a-PE1b, and PE2a-PE2b) and= two pseudo-wires (PE1a-PE2a, ,and PE1b-PE2b) forming a "square" = topology on which some spanning-tree thing would need to turn into a loop-f= ree topology, and it wouldn't matter which PE1 or PE2 was=A0preferred= =A0by CE1 and CE2 respectively.

Sincerely,
Brian Dickson

=
--f46d04428b501e39fc04c37a94d3-- From rjs@rob.sh Thu Jun 28 01:48:53 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1B3021F889F; Thu, 28 Jun 2012 01:48:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.772 X-Spam-Level: X-Spam-Status: No, score=-1.772 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r3wEFj7Dz3GU; Thu, 28 Jun 2012 01:48:52 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2001:b98:201:101::10:cafe]) by ietfa.amsl.com (Postfix) with ESMTP id 8B69F21F88A5; Thu, 28 Jun 2012 01:48:52 -0700 (PDT) Received: from [217.41.227.31] (helo=[10.96.3.206]) by cappuccino.rob.sh with esmtpa (Exim 4.72) (envelope-from ) id 1SkANq-0006NR-21; Thu, 28 Jun 2012 09:47:26 +0100 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Rob Shakir In-Reply-To: Date: Thu, 28 Jun 2012 09:48:49 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3FE3D8FD-7658-4A42-8D9E-2133825A4061@rob.sh> References: <52CBEC1F-49E6-4656-A617-CAB7304479F0@rob.sh> To: "UTTARO, JAMES" X-Mailer: Apple Mail (2.1257) Cc: 'idr wg' , "'grow@ietf.org'" Subject: Re: [Idr] draft-ietf-grow-ops-reqs-for-bgp-error-handling-04 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 08:48:53 -0000 Hi Jim, Apologies for the delay in replying to this message. Further discussion = in-line marked [rjs]. On 25 Jun 2012, at 23:47, UTTARO, JAMES wrote: > [rjs]: Absolutely, this is the current behaviour. The problem with = taking a whole session down in this case is that you now take a risk of = inconsistency for all NLRI across that session for the duration that you = hold onto the learned NLRI. If one avoids being in the situation where = the session is down (e.g., by applying treat-as-withdraw behaviour in = cases where one can determine the NLRI) then all other NLRI on the = session continue to be updated as they need to be. It is only the NLRI = that were included in the erroneous UPDATE that may be affected for = looping/black-holing. >=20 >=20 >>> [Jim U>] The assumption being that the error was caused by an = upstream speaker and is therefore not truly indicative of an issue over = the session where the error manifests itself. This seems to make sense = in the IPV4 case. I am still a bit concerned as I do not understand how = the following is addressed. >=20 [rjs]: Actually, I think treat-as-withdraw applied more generally than = optional-transitive only does not necessarily imply that the error was = not the direct fault of the upstream speaker. However: > - There is no way of knowing if the adjacent peer is the speaker that = is actually responsible for the malformed attr or is coming from an = upstream speaker. I can think of no way of knowing this.. Can it be = inferred from the notion that an error is of the syntactic or semantic = variety? [rjs]: This is true, only where we have a mechanism such as the partial = bit in the optional transitive attribute can we infer that the directly = attached neighbour did not look at the session. What the semantic and = critical errors that are called out in the draft relate to is the impact = of the error on the resulting UPDATE message, rather than the direct = neighbour being responsible for it. > - There seems to be no threshold when the session is actually taking = out of service. It would seem that some number of these type of errors = would indicate a major issue is taking place and should be addressed by = severing the speaker that is advertising paths with the malformed attr = into the topology. A large number of these error will create a large = number of withdrawn messages being generated from many peers. What are = your thoughts on how this should be addressed? [rjs]: This was something that has been discussed on the list = previously. There are two key questions in this space: - Do you expect errors that are indicative of a whole box failure, that = are not related to a large change on the device (e.g., code upgrade) = that affect all prefixes in a manner that the UPDATE message is formed = well enough to extract the NLRI? - Is the state of reaching all prefixes withdrawn (with UPDATEs = withdrawing all NLRI being sent to all neighbours) an acceptable state? = I think there is (of course) a scaling impact of such UPDATES being = transmitted and parsed to all downstream neighbours, but the impact of = such an event is really dependent on assuming that large proportions of = the UPDATEs generated become erroneous. I don't think that I can categorically state that the answer to the = former is no, but I am not aware of the case. In my view, larger scale = issues on the BGP speaker (e.g., things that affect memory integrity = etc.) result in failures that produce output that is not well enough = formed to fall within the "semantic" errors described in the draft. I = would (of course) welcome implementor and tester's feed back on this = point. >> I would expect all solutions implemented in response to these = requirements to be optional. If the risk of incorrectness is = unacceptable to you/an operator, then you should absolutely not enable = any of these mechanisms. In a number of networks that I have operated, = designed and architected, I am prepared to accept the risk of = incorrectness, as I consider it acceptable when compared to the risk of = complete service outages in terms of impact to my customers during such = incidents. At the moment, without the work described through the = requirements outlined in this draft I do not have the means to make that = call... >> [Jim U>] I do not understand how it is possible to make this = configurable on a per session or AS basis..I would think all speakers = participating in a routing context would have to adhere to the same = rules for a consistent view across domains.. In my reading of the IDR = draft it seems that it would be a MUST.. Maybe I should not be = considering that IDR draft as the actual realization of the reqs.. >=20 > [rjs]: The IDR draft is the solution for some of the requirements -- = particularly those described in Section 3 of the GROW draft. >>> [Jim U>] Got it.. >=20 > [rjs]: I do not see why this behaviour needs to be consistent across = domains? >>> [Jim U>] Can you explain this [rjs]: See later point about "good"/"bad" paths.=20 >=20 > [rjs]: Essentially, if I receive an invalid UPDATE message, and apply = treat-as-withdraw, if the advertising speaker did not know that this was = erroneous then I end up with a different view of what is in the RIB than = the advertising speaker does. If this was a prefix I had no other route = to, then I may black-hole, if it was one where it was a more-specific of = some larger prefix, then we end up with the potential for loops. >>> [Jim U>] Yes.. I am not sure I like the notion of forwarding loops = especially for large flows..=20 [rjs]: The potential for loops exists in some specific scenarios I think = -- especially those where there is a covering aggregate advertised to a = speaker, and a more specific that advertised within that aggregate. If = this is the case, then in some cases, rather than forwarding back to the = device advertising the more specific (i.e., the one that was withdrawn). = I think the below example shows something like this - if 10.0.0.0/24 is = advertised from C to B, then A forwards packets destined to 10.0.0.0/24, = during the time that this prefix is withdrawn, then this will loop. Now, = I think that this is a feature of this topology anyway, since where B-C = is down, then there will be loops for 10/8 in B-D. <-- 10.0.0.0/8 -- [ A ] --0.0.0.0/0--> [ B ] ---0.0.0.0/0---> [ D ] | 10.0.0.0/24 | [ C ] [rjs]: There is then a discussion as to whether one would actually = expect such topologies to occur in practical terms. Really, I'd rather = expect that there are blackholes (e.g., I only had one path to A, and it = got withdrawn, if anyone forwards me packets destined for A, then I drop = them) or (more likely in an Internet DFZ perspective) I converge to an = alternate path I had to that NLRI. [rjs]: The reason that this is highlighted in the text is that = introducing behaviour into the protocol such that loops may occur is = obviously a compromise to protocol correctness, that may be a compromise = to overall network forwarding integrity. It's important that this risk = is understood, and balanced against the wider impact of session tear = down.=20 >=20 > [rjs]: If I am prepared to accept the black-holing or loops for the = NLRI in the erroneous UPDATE as a risk, in favour of keeping the = remaining NLRI working (and being updated/withdrawn if they change), = then this is a local decision and I do not need to imply any behaviour = of the neighbouring domains. >>> [Jim U>] I guess what I meant was the other paths that are = considered good would be treated differently.. So in an environment = where only paths with the mal-formed attr are affected by this error = condition as opposed to an environment where all paths are affected ( = withdrawn ) would create a inconsistent view of the "good" paths across = AS domains.. So not so much the "bad" paths but the "good" paths and how = they may be treated differently.. [rjs]: I'm not sure I fully understand here: - Today: UPDATE is received from element A and found to be = erroneous - session is reset, downstreams do not see any paths where A = was the best-path in the RIB.=20 - With this draft: UPDATE is received from element A, found to = be erroneous, downstreams still see all other paths where A is the = best-path in the RIB. [rjs]: I'm not sure that this is so much inconsistency of what the = "good" paths look like - both the receiving and downstream elements = still consider A's paths as valid, other than the ones that were = included in the erroneous UPDATE. In both cases, the NLRI contained in = the erroneous UPDATE is also not propagated downstream (session reset, = or treat-as-withdraw stops the further propagation). > [rjs] I'd say that it's not just applicable to IPv[46] in the Internet = - but to numerous AFIs (there is a definite use-case for these solutions = in L3VPN environments for instance). I am not saying that this is = applicable or desirable to be turned on for all AFIs -- but it seems to = me that this is a per-operator, per-deployment decision, not a per-AFI = one. For instance, if we get an RTC UPDATE that is malformed, an = operator may not want to tear down a session if it also carries other = AFIs (e.g., VPNv[46] also) - in that case, the operator may want to = treat this UPDATE as withdrawing the {as, route-target} NLRI (consider = that we have no *standardised* multi-session mechanism yet, and there = are potential scaling impacts of multiple sessions). >=20 >>> [Jim U>] Quite honestly AFs such as RT-C, Flowspec, etc... where the = info being propagated is more akin to "configuration" not path info = should persist regardless of the session.. This goes to the heart of the = discussion of BGP is used for many fields of use that require = persistence. It is not only paths that use BGP for dissemination.. I = would prefer that this solution is limited to AFs that disseminate = reachability/path info not configuration info.. [rjs]: The persistence discussion is a further optimisation over this = work I feel, it addresses (as you correctly said before) more failure = cases. In the case that one UPDATE containing modifications to this = configuration information is invalid, is it worth making the rest of it = "stale" (and not able to be updated)? I think that in the case, you also = want to keep as much of the RIB/config info up-to-date as possible, = therefore targeting the error handling mechanism to the contained NLRI = still seems advantageous. [rjs]: Now, the question may be whether treat-as-withdraw is suitable in = these cases -- is it better to remove the flow specification, or RT from = those installed, or keep it and know that it might be stale? I'd be = interested to hear your thoughts here. [rjs]: On the point of addressing this per-AF, perhaps the text to add = to the draft is that behaviour such as treat-as-withdraw must (MUST?) be = configurable on a per-AFI basis? The problem with stating something like = this, is what does one do when there is no multi-session, and it is = disabled for one AFI, yet enabled for another?=20 Thanks, r.= From adam.simpson@alcatel-lucent.com Thu Jun 28 08:02:25 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 517B921F8598 for ; Thu, 28 Jun 2012 08:02:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.043 X-Spam-Level: X-Spam-Status: No, score=-8.043 tagged_above=-999 required=5 tests=[AWL=-1.444, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d5cb5zZPmTpf for ; Thu, 28 Jun 2012 08:02:24 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 75F1721F857F for ; Thu, 28 Jun 2012 08:02:24 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id q5SF2MoH005910 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 28 Jun 2012 10:02:22 -0500 (CDT) Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q5SF2MKu026672 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 28 Jun 2012 10:02:22 -0500 Received: from USNAVSXCHMBSC1.ndc.alcatel-lucent.com ([135.3.39.147]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Thu, 28 Jun 2012 10:02:22 -0500 From: "Simpson, Adam (Adam)" To: "idr@ietf.org" Date: Thu, 28 Jun 2012 10:02:20 -0500 Thread-Topic: [Idr] I-D Action: draft-ietf-idr-error-handling-02.txt Thread-Index: Ac1Myg1W0DJH3HL4SN+atTbnq0X/BAIaZimA Message-ID: References: <20120617204451.26844.76025.idtracker@ietfa.amsl.com> In-Reply-To: <20120617204451.26844.76025.idtracker@ietfa.amsl.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="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 15:02:25 -0000 I have a few comments on the new version of this draft. My first comment is a general one: I think the draft is clear in terms of g= oals and overall framework but still lacking important details...important = if we want different BGP implementations following this draft to react more= or less the same way to the same error(s) in an Update message. I think mi= nor differences in how certain errors are handled is inevitable and probabl= y acceptable but if the same basic error causes a session reset in some par= t of the network and 'treat as withdraw' somewhere else that could really c= omplicate operations and troubleshooting.=20 I think someone suggested, in their feedback to draft-01, that a table givi= ng the expected handling for each category of error would be better than th= is alone: "The error handling of all other cases described in Section 6.3 o= f [RFC4271] that specify a session reset is revised as follows..." (section= 2 of the draft). I agree with that. In fact, what I think would be even be= tter would be some sort of flowchart in text form....i.e. receive an Update= , do these length checks {a, b, c}, if they all pass then parse the NLRI, i= f all NLRI are decipherable then check other attributes for errors, for att= ribute X its length should be N or else it is an error... However the extra detail is provided, here are some of the points/questions= I would like to see better explained in the next version: 1. The only length check that seems to be a 'critical' error in the draft i= s this: "if Withdrawn Routes Length + Total Attribute Length + 23 exceeds t= he message Length), then the Error Subcode MUST be set to Malformed Attribu= te List" [causing a session reset.] But what should happen if these other l= ength checks don't work out: (a) Message length <> withdrawn routes length + =1B$B-t=1B(B length of each= individual attribute (as reported in attribute length) + =1B$B-t=1B(B leng= th of each individual IPv4 NLRI (at the end of the Update message) (b) Total attribute length <> =1B$B-t=1B(B length of each individual attrib= ute (as reported in attribute length) (c) Length of a TLV encoded attribute <> =1B$B-t=1B(B length of each indivi= dual TLV (as reported in TLV length) To me all of these errors introduce uncertainty about whether we have ident= ified and parsed the NLRI correctly, but if the authors disagree, then they= should at least discuss why in the draft. 2. The draft still states that we should ignore all but the first attribute= with a specific type code if the attribute is duplicated in the message. S= urely that does not apply to MP_REACH_NLRI. There was also debate last time= around about whether we should instead select the first attribute with a s= pecific type *that appears correct*. Was that suggestion considered? 3. Given the importance of the MP_REACH_NLRI attribute to the treat-as-with= drawn approach I think it would be appropriate to state what errors in that= attribute specifically are expected to be recoverable and which ones are n= ot. For example, is a next-hop-length that is incorrect for the AFI/SAFI re= coverable using treat-as-withdraw or should we assume that perhaps the NLRI= fields are not starting where we think they are. And if treat-as-withdraw = should be applied when there is an error within an MP_REACH_NLRI should we = really withdraw all the NLRI in the Update message (as currently implied by= the draft) or should we only withdraw the NLRI in the MP_REACH_NLRI? Thanks, Adam -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of inter= net-drafts@ietf.org Sent: Sunday, June 17, 2012 4:45 PM To: i-d-announce@ietf.org Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-error-handling-02.txt 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 : Revised Error Handling for BGP UPDATE Messages Author(s) : John G. Scudder Enke Chen Pradosh Mohapatra Keyur Patel Filename : draft-ietf-idr-error-handling-02.txt Pages : 10 Date : 2012-06-17 Abstract: According to the base BGP specification, a BGP speaker that receives an UPDATE message containing a malformed attribute is required to reset the session over which the offending attribute was received. This behavior is undesirable as a session reset would impact not only routes with the offending attribute, but also other valid routes exchanged over the session. This document partially revises the error handling for UPDATE messages, and provides guidelines for the authors of documents defining new attributes. Finally, it revises the error handling procedures for several existing attributes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-error-handling There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-error-handling-02 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-error-handling-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From jakob.heitz@ericsson.com Thu Jun 28 09:13:57 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 435F321F857F for ; Thu, 28 Jun 2012 09:13:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.465 X-Spam-Level: X-Spam-Status: No, score=-6.465 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fCMOWG4AJdj5 for ; Thu, 28 Jun 2012 09:13:56 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 6369E21F8595 for ; Thu, 28 Jun 2012 09:13:55 -0700 (PDT) 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 q5SGDZiB027611; Thu, 28 Jun 2012 11:13:44 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.215]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Thu, 28 Jun 2012 12:13:36 -0400 From: Jakob Heitz To: "Simpson, Adam (Adam)" Date: Thu, 28 Jun 2012 12:14:27 -0400 Thread-Topic: [Idr] I-D Action: draft-ietf-idr-error-handling-02.txt Thread-Index: Ac1VSPimYhRsqxljRjSnIdjgtLJkfg== Message-ID: <620F5BF1-FE36-4E55-BA54-B15BB45296EF@ericsson.com> References: <20120617204451.26844.76025.idtracker@ietfa.amsl.com> 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "idr@ietf.org" Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 16:13:57 -0000 QWxsIGJ1dCB0aGUgdHJpdmlhbCBsZW5ndGggZXJyb3JzIGNhbiBub3QgYmUgdmVyaWZpZWQsIHNv IG5vIGF0dGVtcHQgaXMgbWFkZS4gSWYgYSBsZW5ndGggaXMgd3JvbmcsIGl0IHdpbGwgbWFuaWZl c3QgaXRzZWxmIGFzIGFuIGVycm9yIGluIHN1YnNlcXVlbnQgcGFyc2luZy4gVGhlIGRyYWZ0IHNo b3VsZCBleHBsYWluIHRoaXMuDQoNCi0tDQpKYWtvYiBIZWl0ei4NCg0KDQpPbiBKdW4gMjgsIDIw MTIsIGF0IDg6MDIgQU0sICJTaW1wc29uLCBBZGFtIChBZGFtKSIgPGFkYW0uc2ltcHNvbkBhbGNh dGVsLWx1Y2VudC5jb20+IHdyb3RlOg0KDQo+IEkgaGF2ZSBhIGZldyBjb21tZW50cyBvbiB0aGUg bmV3IHZlcnNpb24gb2YgdGhpcyBkcmFmdC4NCj4gDQo+IE15IGZpcnN0IGNvbW1lbnQgaXMgYSBn ZW5lcmFsIG9uZTogSSB0aGluayB0aGUgZHJhZnQgaXMgY2xlYXIgaW4gdGVybXMgb2YgZ29hbHMg YW5kIG92ZXJhbGwgZnJhbWV3b3JrIGJ1dCBzdGlsbCBsYWNraW5nIGltcG9ydGFudCBkZXRhaWxz Li4uaW1wb3J0YW50IGlmIHdlIHdhbnQgZGlmZmVyZW50IEJHUCBpbXBsZW1lbnRhdGlvbnMgZm9s bG93aW5nIHRoaXMgZHJhZnQgdG8gcmVhY3QgbW9yZSBvciBsZXNzIHRoZSBzYW1lIHdheSB0byB0 aGUgc2FtZSBlcnJvcihzKSBpbiBhbiBVcGRhdGUgbWVzc2FnZS4gSSB0aGluayBtaW5vciBkaWZm ZXJlbmNlcyBpbiBob3cgY2VydGFpbiBlcnJvcnMgYXJlIGhhbmRsZWQgaXMgaW5ldml0YWJsZSBh bmQgcHJvYmFibHkgYWNjZXB0YWJsZSBidXQgaWYgdGhlIHNhbWUgYmFzaWMgZXJyb3IgY2F1c2Vz IGEgc2Vzc2lvbiByZXNldCBpbiBzb21lIHBhcnQgb2YgdGhlIG5ldHdvcmsgYW5kICd0cmVhdCBh cyB3aXRoZHJhdycgc29tZXdoZXJlIGVsc2UgdGhhdCBjb3VsZCByZWFsbHkgY29tcGxpY2F0ZSBv cGVyYXRpb25zIGFuZCB0cm91Ymxlc2hvb3RpbmcuIA0KPiANCj4gSSB0aGluayBzb21lb25lIHN1 Z2dlc3RlZCwgaW4gdGhlaXIgZmVlZGJhY2sgdG8gZHJhZnQtMDEsIHRoYXQgYSB0YWJsZSBnaXZp bmcgdGhlIGV4cGVjdGVkIGhhbmRsaW5nIGZvciBlYWNoIGNhdGVnb3J5IG9mIGVycm9yIHdvdWxk IGJlIGJldHRlciB0aGFuIHRoaXMgYWxvbmU6ICJUaGUgZXJyb3IgaGFuZGxpbmcgb2YgYWxsIG90 aGVyIGNhc2VzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDYuMyBvZiBbUkZDNDI3MV0gdGhhdCBzcGVj aWZ5IGEgc2Vzc2lvbiByZXNldCBpcyByZXZpc2VkIGFzIGZvbGxvd3MuLi4iIChzZWN0aW9uIDIg b2YgdGhlIGRyYWZ0KS4gSSBhZ3JlZSB3aXRoIHRoYXQuIEluIGZhY3QsIHdoYXQgSSB0aGluayB3 b3VsZCBiZSBldmVuIGJldHRlciB3b3VsZCBiZSBzb21lIHNvcnQgb2YgZmxvd2NoYXJ0IGluIHRl eHQgZm9ybS4uLi5pLmUuIHJlY2VpdmUgYW4gVXBkYXRlLCBkbyB0aGVzZSBsZW5ndGggY2hlY2tz IHthLCBiLCBjfSwgaWYgdGhleSBhbGwgcGFzcyB0aGVuIHBhcnNlIHRoZSBOTFJJLCBpZiBhbGwg TkxSSSBhcmUgZGVjaXBoZXJhYmxlIHRoZW4gY2hlY2sgb3RoZXIgYXR0cmlidXRlcyBmb3IgZXJy b3JzLCBmb3IgYXR0cmlidXRlIFggaXRzIGxlbmd0aCBzaG91bGQgYmUgTiBvciBlbHNlIGl0IGlz IGFuIGVycm9yLi4uDQo+IA0KPiBIb3dldmVyIHRoZSBleHRyYSBkZXRhaWwgaXMgcHJvdmlkZWQs IGhlcmUgYXJlIHNvbWUgb2YgdGhlIHBvaW50cy9xdWVzdGlvbnMgSSB3b3VsZCBsaWtlIHRvIHNl ZSBiZXR0ZXIgZXhwbGFpbmVkIGluIHRoZSBuZXh0IHZlcnNpb246DQo+IA0KPiAxLiBUaGUgb25s eSBsZW5ndGggY2hlY2sgdGhhdCBzZWVtcyB0byBiZSBhICdjcml0aWNhbCcgZXJyb3IgaW4gdGhl IGRyYWZ0IGlzIHRoaXM6ICJpZiBXaXRoZHJhd24gUm91dGVzIExlbmd0aCArIFRvdGFsIEF0dHJp YnV0ZSBMZW5ndGggKyAyMyBleGNlZWRzIHRoZSBtZXNzYWdlIExlbmd0aCksIHRoZW4gdGhlIEVy cm9yIFN1YmNvZGUgTVVTVCBiZSBzZXQgdG8gTWFsZm9ybWVkIEF0dHJpYnV0ZSBMaXN0IiBbY2F1 c2luZyBhIHNlc3Npb24gcmVzZXQuXSBCdXQgd2hhdCBzaG91bGQgaGFwcGVuIGlmIHRoZXNlIG90 aGVyIGxlbmd0aCBjaGVja3MgZG9uJ3Qgd29yayBvdXQ6DQo+IA0KPiAoYSkgTWVzc2FnZSBsZW5n dGggPD4gd2l0aGRyYXduIHJvdXRlcyBsZW5ndGggKyDjiqUgbGVuZ3RoIG9mIGVhY2ggaW5kaXZp ZHVhbCBhdHRyaWJ1dGUgKGFzIHJlcG9ydGVkIGluIGF0dHJpYnV0ZSBsZW5ndGgpICsg44qlIGxl bmd0aCBvZiBlYWNoIGluZGl2aWR1YWwgSVB2NCBOTFJJIChhdCB0aGUgZW5kIG9mIHRoZSBVcGRh dGUgbWVzc2FnZSkNCj4gKGIpIFRvdGFsIGF0dHJpYnV0ZSBsZW5ndGggPD4g44qlIGxlbmd0aCBv ZiBlYWNoIGluZGl2aWR1YWwgYXR0cmlidXRlIChhcyByZXBvcnRlZCBpbiBhdHRyaWJ1dGUgbGVu Z3RoKQ0KPiAoYykgTGVuZ3RoIG9mIGEgVExWIGVuY29kZWQgYXR0cmlidXRlIDw+IOOKpSBsZW5n dGggb2YgZWFjaCBpbmRpdmlkdWFsIFRMViAoYXMgcmVwb3J0ZWQgaW4gVExWIGxlbmd0aCkNCj4g DQo+IFRvIG1lIGFsbCBvZiB0aGVzZSBlcnJvcnMgaW50cm9kdWNlIHVuY2VydGFpbnR5IGFib3V0 IHdoZXRoZXIgd2UgaGF2ZSBpZGVudGlmaWVkIGFuZCBwYXJzZWQgdGhlIE5MUkkgY29ycmVjdGx5 LCBidXQgaWYgdGhlIGF1dGhvcnMgZGlzYWdyZWUsIHRoZW4gdGhleSBzaG91bGQgYXQgbGVhc3Qg ZGlzY3VzcyB3aHkgaW4gdGhlIGRyYWZ0Lg0KPiANCj4gMi4gVGhlIGRyYWZ0IHN0aWxsIHN0YXRl cyB0aGF0IHdlIHNob3VsZCBpZ25vcmUgYWxsIGJ1dCB0aGUgZmlyc3QgYXR0cmlidXRlIHdpdGgg YSBzcGVjaWZpYyB0eXBlIGNvZGUgaWYgdGhlIGF0dHJpYnV0ZSBpcyBkdXBsaWNhdGVkIGluIHRo ZSBtZXNzYWdlLiBTdXJlbHkgdGhhdCBkb2VzIG5vdCBhcHBseSB0byBNUF9SRUFDSF9OTFJJLiBU aGVyZSB3YXMgYWxzbyBkZWJhdGUgbGFzdCB0aW1lIGFyb3VuZCBhYm91dCB3aGV0aGVyIHdlIHNo b3VsZCBpbnN0ZWFkIHNlbGVjdCB0aGUgZmlyc3QgYXR0cmlidXRlIHdpdGggYSBzcGVjaWZpYyB0 eXBlICp0aGF0IGFwcGVhcnMgY29ycmVjdCouIFdhcyB0aGF0IHN1Z2dlc3Rpb24gY29uc2lkZXJl ZD8NCj4gDQo+IDMuIEdpdmVuIHRoZSBpbXBvcnRhbmNlIG9mIHRoZSBNUF9SRUFDSF9OTFJJIGF0 dHJpYnV0ZSB0byB0aGUgdHJlYXQtYXMtd2l0aGRyYXduIGFwcHJvYWNoIEkgdGhpbmsgaXQgd291 bGQgYmUgYXBwcm9wcmlhdGUgdG8gc3RhdGUgd2hhdCBlcnJvcnMgaW4gdGhhdCBhdHRyaWJ1dGUg c3BlY2lmaWNhbGx5IGFyZSBleHBlY3RlZCB0byBiZSByZWNvdmVyYWJsZSBhbmQgd2hpY2ggb25l cyBhcmUgbm90LiBGb3IgZXhhbXBsZSwgaXMgYSBuZXh0LWhvcC1sZW5ndGggdGhhdCBpcyBpbmNv cnJlY3QgZm9yIHRoZSBBRkkvU0FGSSByZWNvdmVyYWJsZSB1c2luZyB0cmVhdC1hcy13aXRoZHJh dyBvciBzaG91bGQgd2UgYXNzdW1lIHRoYXQgcGVyaGFwcyB0aGUgTkxSSSBmaWVsZHMgYXJlIG5v dCBzdGFydGluZyB3aGVyZSB3ZSB0aGluayB0aGV5IGFyZS4gQW5kIGlmIHRyZWF0LWFzLXdpdGhk cmF3IHNob3VsZCBiZSBhcHBsaWVkIHdoZW4gdGhlcmUgaXMgYW4gZXJyb3Igd2l0aGluIGFuIE1Q X1JFQUNIX05MUkkgc2hvdWxkIHdlIHJlYWxseSB3aXRoZHJhdyBhbGwgdGhlIE5MUkkgaW4gdGhl IFVwZGF0ZSBtZXNzYWdlIChhcyBjdXJyZW50bHkgaW1wbGllZCBieSB0aGUgZHJhZnQpIG9yIHNo b3VsZCB3ZSBvbmx5IHdpdGhkcmF3IHRoZSBOTFJJIGluIHRoZSBNUF9SRUFDSF9OTFJJPw0KPiAN Cj4gVGhhbmtzLA0KPiBBZGFtDQo+IA0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4gRnJvbTogaWRyLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzppZHItYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZw0KPiBTZW50OiBTdW5kYXks IEp1bmUgMTcsIDIwMTIgNDo0NSBQTQ0KPiBUbzogaS1kLWFubm91bmNlQGlldGYub3JnDQo+IENj OiBpZHJAaWV0Zi5vcmcNCj4gU3ViamVjdDogW0lkcl0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1p ZHItZXJyb3ItaGFuZGxpbmctMDIudHh0DQo+IA0KPiANCj4gQSBOZXcgSW50ZXJuZXQtRHJhZnQg aXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVz Lg0KPiBUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBJbnRlci1Eb21haW4gUm91dGlu ZyBXb3JraW5nIEdyb3VwIG9mIHRoZSBJRVRGLg0KPiANCj4gICAgVGl0bGUgICAgICAgICAgIDog UmV2aXNlZCBFcnJvciBIYW5kbGluZyBmb3IgQkdQIFVQREFURSBNZXNzYWdlcw0KPiAgICBBdXRo b3IocykgICAgICAgOiBKb2huIEcuIFNjdWRkZXINCj4gICAgICAgICAgICAgICAgICAgICAgICAg IEVua2UgQ2hlbg0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgUHJhZG9zaCBNb2hhcGF0cmEN Cj4gICAgICAgICAgICAgICAgICAgICAgICAgIEtleXVyIFBhdGVsDQo+ICAgIEZpbGVuYW1lICAg ICAgICA6IGRyYWZ0LWlldGYtaWRyLWVycm9yLWhhbmRsaW5nLTAyLnR4dA0KPiAgICBQYWdlcyAg ICAgICAgICAgOiAxMA0KPiAgICBEYXRlICAgICAgICAgICAgOiAyMDEyLTA2LTE3DQo+IA0KPiBB YnN0cmFjdDoNCj4gICBBY2NvcmRpbmcgdG8gdGhlIGJhc2UgQkdQIHNwZWNpZmljYXRpb24sIGEg QkdQIHNwZWFrZXIgdGhhdCByZWNlaXZlcw0KPiAgIGFuIFVQREFURSBtZXNzYWdlIGNvbnRhaW5p bmcgYSBtYWxmb3JtZWQgYXR0cmlidXRlIGlzIHJlcXVpcmVkIHRvDQo+ICAgcmVzZXQgdGhlIHNl c3Npb24gb3ZlciB3aGljaCB0aGUgb2ZmZW5kaW5nIGF0dHJpYnV0ZSB3YXMgcmVjZWl2ZWQuDQo+ ICAgVGhpcyBiZWhhdmlvciBpcyB1bmRlc2lyYWJsZSBhcyBhIHNlc3Npb24gcmVzZXQgd291bGQg aW1wYWN0IG5vdCBvbmx5DQo+ICAgcm91dGVzIHdpdGggdGhlIG9mZmVuZGluZyBhdHRyaWJ1dGUs IGJ1dCBhbHNvIG90aGVyIHZhbGlkIHJvdXRlcw0KPiAgIGV4Y2hhbmdlZCBvdmVyIHRoZSBzZXNz aW9uLiAgVGhpcyBkb2N1bWVudCBwYXJ0aWFsbHkgcmV2aXNlcyB0aGUNCj4gICBlcnJvciBoYW5k bGluZyBmb3IgVVBEQVRFIG1lc3NhZ2VzLCBhbmQgcHJvdmlkZXMgZ3VpZGVsaW5lcyBmb3IgdGhl DQo+ICAgYXV0aG9ycyBvZiBkb2N1bWVudHMgZGVmaW5pbmcgbmV3IGF0dHJpYnV0ZXMuICBGaW5h bGx5LCBpdCByZXZpc2VzDQo+ICAgdGhlIGVycm9yIGhhbmRsaW5nIHByb2NlZHVyZXMgZm9yIHNl dmVyYWwgZXhpc3RpbmcgYXR0cmlidXRlcy4NCj4gDQo+IA0KPiBUaGUgSUVURiBkYXRhdHJhY2tl ciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pZHItZXJyb3ItaGFuZGxpbmcNCj4gDQo+IFRoZXJlJ3Mg YWxzbyBhIGh0bWxpemVkIHZlcnNpb24gYXZhaWxhYmxlIGF0Og0KPiBodHRwOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWlkci1lcnJvci1oYW5kbGluZy0wMg0KPiANCj4gQSBkaWZm IGZyb20gcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQo+IGh0dHA6Ly90b29scy5p ZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1pZHItZXJyb3ItaGFuZGxpbmctMDINCj4g DQo+IA0KPiBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBG VFAgYXQ6DQo+IGZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQo+IA0KPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBJZHIgbWFpbGlu ZyBsaXN0DQo+IElkckBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2lkcg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiBJZHIgbWFpbGluZyBsaXN0DQo+IElkckBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkcg0K From enkechen@cisco.com Thu Jun 28 11:47:12 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4220721F84EA for ; Thu, 28 Jun 2012 11:47:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.532 X-Spam-Level: X-Spam-Status: No, score=-10.532 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pao6Ux18MfAM for ; Thu, 28 Jun 2012 11:47:09 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 5A32E21F853F for ; Thu, 28 Jun 2012 11:47:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=enkechen@cisco.com; l=13584; q=dns/txt; s=iport; t=1340909229; x=1342118829; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=kiVXMFHoBRPdG39HHmbsPwzD0JKuoEQ4MDpwqLBDTu0=; b=Um2/G6QDnpiyD2zRiZ4zWENnxZzJ4vL3z3lZZr131Mw721gfe4TrJ5XR SVLUwCpbbtvewp2mH8sVfr7eL/6cc65sQqCalzBBg2PbwPzUtEdgKBZgw EAKZXaWzoY0VxLAOM/9BnHVmlPwqIQJwbOXGA5K84D2ikRhxCO+fcQcv5 8=; X-IronPort-AV: E=Sophos;i="4.77,493,1336348800"; d="scan'208,217";a="47379854" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 28 Jun 2012 18:47:08 +0000 Received: from dhcp-171-71-139-24.cisco.com (dhcp-171-71-139-24.cisco.com [171.71.139.24]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q5SIl8dB030464; Thu, 28 Jun 2012 18:47:08 GMT Message-ID: <4FECA70B.8050100@cisco.com> Date: Thu, 28 Jun 2012 11:48:43 -0700 From: Enke Chen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Simpson, Adam (Adam)" References: <20120617204451.26844.76025.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000704020106050407060105" Cc: "idr@ietf.org" Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 18:47:12 -0000 This is a multi-part message in MIME format. --------------000704020106050407060105 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, Adam: Thanks for your review and comments. We will work on addressing yours and Bruno's comments. -- Enke On 6/28/12 8:02 AM, Simpson, Adam (Adam) wrote: > I have a few comments on the new version of this draft. > > My first comment is a general one: I think the draft is clear in terms of goals and overall framework but still lacking important details...important if we want different BGP implementations following this draft to react more or less the same way to the same error(s) in an Update message. I think minor differences in how certain errors are handled is inevitable and probably acceptable but if the same basic error causes a session reset in some part of the network and 'treat as withdraw' somewhere else that could really complicate operations and troubleshooting. > > I think someone suggested, in their feedback to draft-01, that a table giving the expected handling for each category of error would be better than this alone: "The error handling of all other cases described in Section 6.3 of [RFC4271] that specify a session reset is revised as follows..." (section 2 of the draft). I agree with that. In fact, what I think would be even better would be some sort of flowchart in text form....i.e. receive an Update, do these length checks {a, b, c}, if they all pass then parse the NLRI, if all NLRI are decipherable then check other attributes for errors, for attribute X its length should be N or else it is an error... > > However the extra detail is provided, here are some of the points/questions I would like to see better explained in the next version: > > 1. The only length check that seems to be a 'critical' error in the draft is this: "if Withdrawn Routes Length + Total Attribute Length + 23 exceeds the message Length), then the Error Subcode MUST be set to Malformed Attribute List" [causing a session reset.] But what should happen if these other length checks don't work out: > > (a) Message length<> withdrawn routes length + ? length of each individual attribute (as reported in attribute length) + ? length of each individual IPv4 NLRI (at the end of the Update message) > (b) Total attribute length<> ? length of each individual attribute (as reported in attribute length) > (c) Length of a TLV encoded attribute<> ? length of each individual TLV (as reported in TLV length) > > To me all of these errors introduce uncertainty about whether we have identified and parsed the NLRI correctly, but if the authors disagree, then they should at least discuss why in the draft. > > 2. The draft still states that we should ignore all but the first attribute with a specific type code if the attribute is duplicated in the message. Surely that does not apply to MP_REACH_NLRI. There was also debate last time around about whether we should instead select the first attribute with a specific type *that appears correct*. Was that suggestion considered? > > 3. Given the importance of the MP_REACH_NLRI attribute to the treat-as-withdrawn approach I think it would be appropriate to state what errors in that attribute specifically are expected to be recoverable and which ones are not. For example, is a next-hop-length that is incorrect for the AFI/SAFI recoverable using treat-as-withdraw or should we assume that perhaps the NLRI fields are not starting where we think they are. And if treat-as-withdraw should be applied when there is an error within an MP_REACH_NLRI should we really withdraw all the NLRI in the Update message (as currently implied by the draft) or should we only withdraw the NLRI in the MP_REACH_NLRI? > > Thanks, > Adam > > > -----Original Message----- > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org > Sent: Sunday, June 17, 2012 4:45 PM > To: i-d-announce@ietf.org > Cc: idr@ietf.org > Subject: [Idr] I-D Action: draft-ietf-idr-error-handling-02.txt > > > 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 : Revised Error Handling for BGP UPDATE Messages > Author(s) : John G. Scudder > Enke Chen > Pradosh Mohapatra > Keyur Patel > Filename : draft-ietf-idr-error-handling-02.txt > Pages : 10 > Date : 2012-06-17 > > Abstract: > According to the base BGP specification, a BGP speaker that receives > an UPDATE message containing a malformed attribute is required to > reset the session over which the offending attribute was received. > This behavior is undesirable as a session reset would impact not only > routes with the offending attribute, but also other valid routes > exchanged over the session. This document partially revises the > error handling for UPDATE messages, and provides guidelines for the > authors of documents defining new attributes. Finally, it revises > the error handling procedures for several existing attributes. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-idr-error-handling > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-idr-error-handling-02 > > A diff from previous version is available at: > http://tools.ietf.org/rfcdiff?url2=draft-ietf-idr-error-handling-02 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > 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 --------------000704020106050407060105 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, Adam:

Thanks for your review and comments.  We will work on addressing yours and Bruno's comments.

-- Enke

On 6/28/12 8:02 AM, Simpson, Adam (Adam) wrote: 
I have a few comments on the new version of this draft.

My first comment is a general one: I think the draft is clear in terms of goals and overall framework but still lacking important details...important if we want different BGP implementations following this draft to react more or less the same way to the same error(s) in an Update message. I think minor differences in how certain errors are handled is inevitable and probably acceptable but if the same basic error causes a session reset in some part of the network and 'treat as withdraw' somewhere else that could really complicate operations and troubleshooting. 

I think someone suggested, in their feedback to draft-01, that a table giving the expected handling for each category of error would be better than this alone: "The error handling of all other cases described in Section 6.3 of [RFC4271] that specify a session reset is revised as follows..." (section 2 of the draft). I agree with that. In fact, what I think would be even better would be some sort of flowchart in text form....i.e. receive an Update, do these length checks {a, b, c}, if they all pass then parse the NLRI, if all NLRI are decipherable then check other attributes for errors, for attribute X its length should be N or else it is an error...

However the extra detail is provided, here are some of the points/questions I would like to see better explained in the next version:

1. The only length check that seems to be a 'critical' error in the draft is this: "if Withdrawn Routes Length + Total Attribute Length + 23 exceeds the message Length), then the Error Subcode MUST be set to Malformed Attribute List" [causing a session reset.] But what should happen if these other length checks don't work out:

(a) Message length <> withdrawn routes length + ∑ length of each individual attribute (as reported in attribute length) + ∑ length of each individual IPv4 NLRI (at the end of the Update message)
(b) Total attribute length <> ∑ length of each individual attribute (as reported in attribute length)
(c) Length of a TLV encoded attribute <> ∑ length of each individual TLV (as reported in TLV length)

To me all of these errors introduce uncertainty about whether we have identified and parsed the NLRI correctly, but if the authors disagree, then they should at least discuss why in the draft.

2. The draft still states that we should ignore all but the first attribute with a specific type code if the attribute is duplicated in the message. Surely that does not apply to MP_REACH_NLRI. There was also debate last time around about whether we should instead select the first attribute with a specific type *that appears correct*. Was that suggestion considered?

3. Given the importance of the MP_REACH_NLRI attribute to the treat-as-withdrawn approach I think it would be appropriate to state what errors in that attribute specifically are expected to be recoverable and which ones are not. For example, is a next-hop-length that is incorrect for the AFI/SAFI recoverable using treat-as-withdraw or should we assume that perhaps the NLRI fields are not starting where we think they are. And if treat-as-withdraw should be applied when there is an error within an MP_REACH_NLRI should we really withdraw all the NLRI in the Update message (as currently implied by the draft) or should we only withdraw the NLRI in the MP_REACH_NLRI?

Thanks,
Adam


-----Original Message-----
From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org
Sent: Sunday, June 17, 2012 4:45 PM
To: i-d-announce@ietf.org
Cc: idr@ietf.org
Subject: [Idr] I-D Action: draft-ietf-idr-error-handling-02.txt


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           : Revised Error Handling for BGP UPDATE Messages
	Author(s)       : John G. Scudder
                          Enke Chen
                          Pradosh Mohapatra
                          Keyur Patel
	Filename        : draft-ietf-idr-error-handling-02.txt
	Pages           : 10
	Date            : 2012-06-17

Abstract:
   According to the base BGP specification, a BGP speaker that receives
   an UPDATE message containing a malformed attribute is required to
   reset the session over which the offending attribute was received.
   This behavior is undesirable as a session reset would impact not only
   routes with the offending attribute, but also other valid routes
   exchanged over the session.  This document partially revises the
   error handling for UPDATE messages, and provides guidelines for the
   authors of documents defining new attributes.  Finally, it revises
   the error handling procedures for several existing attributes.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-idr-error-handling

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-idr-error-handling-02

A diff from previous version is available at:
http://tools.ietf.org/rfcdiff?url2=draft-ietf-idr-error-handling-02


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
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

--------------000704020106050407060105-- From jgs@juniper.net Thu Jun 28 12:37:21 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB60C11E8083 for ; Thu, 28 Jun 2012 12:37:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.457 X-Spam-Level: X-Spam-Status: No, score=-6.457 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xj82XxcbBtiR for ; Thu, 28 Jun 2012 12:37:20 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id 1ADBE11E807F for ; Thu, 28 Jun 2012 12:37:18 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKT+yybCUberwahPHv8Xo0nyjza/Ik3JpM@postini.com; Thu, 28 Jun 2012 12:37:20 PDT Received: from [172.16.13.202] (172.16.13.202) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server id 8.3.213.0; Thu, 28 Jun 2012 12:30:53 -0700 MIME-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset="us-ascii" From: John G.Scudder In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D213921C23CA154@EUSAACMS0701.eamcs.ericsson.se> Date: Thu, 28 Jun 2012 15:30:52 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <003c01cd4b29$97d7b150$c78713f0$@ndzh.com> <985EF8D2-DA8A-4BE7-94D3-F4BE2B74D768@castlepoint.net> <4FE07A24.7050804@raszuk.net> <1C1F2B2E-2EB7-42F0-8CFF-57965443C074@castlepoint.net> <7A614998-8FB1-4A51-9937-DE501FF31EB6@juniper.net> <4FE0D1F4.9070208@cisco.com> <4FE0E074.3070905@raszuk.net> <17490_1340180565_4FE18855_17490_15423_1_53C29892C857584299CBF5D05346208A0928AA@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FE18A61.8000405@raszuk.net> <8ED5B0B0F5B4854A912480C1521F973AD95B@xmb-rcd-x13.cisco.com> <4FE4A8F3.20809@cisco.com> <7309FCBCAE981B43ABBE69B31C8D213921C23CA154@EUSAACMS0701.eamcs.ericsson.se> To: Jakob Heitz X-Mailer: Apple Mail (2.1278) Cc: "idr@ietf.org" , "UTTARO, JAMES" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 19:37:22 -0000 Jakob, On Jun 22, 2012, at 1:46 PM, Jakob Heitz wrote: > [Jakob Heitz] SUSPECT is entirely different to low preference. > A low preference path exists. A SUSPECT path may not exist. > =20 > A less specific path (shorter netmask) exists and will forward = packets, > unless it is the default route or also SUSPECT. If by "will forward packets" you mean "... to their intended = destination" this is not generally correct. Consider the use of = more-specifics for prefix portability from one provider to another. The = provider that supplied the prefix continues to own and advertise the = supernet, but no longer provides service to their dear departed = customer. > This puts a SUSPECT route at an equal or lower preference than a = default route. > =20 > Therefore a SUSPECT path should be de-preferred among the > set of ALL available paths, including the less specific ones. Nope, see above. --John From jgs@juniper.net Thu Jun 28 12:37:27 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2414911E808A for ; Thu, 28 Jun 2012 12:37:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.464 X-Spam-Level: X-Spam-Status: No, score=-6.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9dXPzik5GODr for ; Thu, 28 Jun 2012 12:37:26 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id 0BCC011E807F for ; Thu, 28 Jun 2012 12:37:22 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKT+yycVtVMl3ujwAP8RuydFgVAENn7Rsk@postini.com; Thu, 28 Jun 2012 12:37:26 PDT Received: from [172.16.13.202] (172.16.13.202) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server id 8.3.213.0; Thu, 28 Jun 2012 12:31:01 -0700 MIME-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset="us-ascii" From: John G.Scudder In-Reply-To: <4FE46DF7.20906@raszuk.net> Date: Thu, 28 Jun 2012 15:30:59 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <71761B19-5AA1-4279-98A7-10956365185A@juniper.net> References: <003c01cd4b29$97d7b150$c78713f0$@ndzh.com> <985EF8D2-DA8A-4BE7-94D3-F4BE2B74D768@castlepoint.net> <4FE07A24.7050804@raszuk.net> <1C1F2B2E-2EB7-42F0-8CFF-57965443C074@castlepoint.net> <7A614998-8FB1-4A51-9937-DE501FF31EB6@juniper.net> <4FE0D1F4.9070208@cisco.com> <4FE0E074.3070905@raszuk.net> <17490_1340180565_4FE18855_17490_15423_1_53C29892C857584299CBF5D05346208A0928AA@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FE18A61.8000405@raszuk.net> <4FE46DF7.20906@raszuk.net> To: "robert@raszuk.net" X-Mailer: Apple Mail (2.1278) Cc: "idr@ietf.org" , "bruno.decraene@orange.com" , Shane Amante , "UTTARO, JAMES" , Susan Hares Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 19:37:27 -0000 On Jun 22, 2012, at 9:07 AM, Robert Raszuk wrote: > Last .. the session down event while BGP process is still healthy and=20= > running is being addressed by various other proposals in IDR and GROW=20= > which do target opposite solution .. keep the session up even if some=20= > errors which would trigger it down are received.=20 None of these address a problem at or below the transport level, though. = The conversation so far has largely neglected this point. --John= From robert@raszuk.net Thu Jun 28 13:54:05 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37BB511E8087 for ; Thu, 28 Jun 2012 13:54:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5gLYlEMJY78G for ; Thu, 28 Jun 2012 13:54:04 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 0881511E808F for ; Thu, 28 Jun 2012 13:54:01 -0700 (PDT) Received: (qmail 14267 invoked by uid 399); 28 Jun 2012 20:52:58 -0000 Received: from unknown (HELO ?192.168.1.58?) (pbs:robert@raszuk.net@83.31.185.95) by mail1310.opentransfer.com with ESMTPM; 28 Jun 2012 20:52:58 -0000 X-Originating-IP: 83.31.185.95 Message-ID: <4FECC427.30609@raszuk.net> Date: Thu, 28 Jun 2012 22:52:55 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: "John G.Scudder" References: <003c01cd4b29$97d7b150$c78713f0$@ndzh.com> <985EF8D2-DA8A-4BE7-94D3-F4BE2B74D768@castlepoint.net> <4FE07A24.7050804@raszuk.net> <1C1F2B2E-2EB7-42F0-8CFF-57965443C074@castlepoint.net> <7A614998-8FB1-4A51-9937-DE501FF31EB6@juniper.net> <4FE0D1F4.9070208@cisco.com> <4FE0E074.3070905@raszuk.net> <17490_1340180565_4FE18855_17490_15423_1_53C29892C857584299CBF5D05346208A0928AA@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FE18A61.8000405@raszuk.net> <4FE46DF7.20906@raszuk.net> <71761B19-5AA1-4279-98A7-10956365185A@juniper.net> In-Reply-To: <71761B19-5AA1-4279-98A7-10956365185A@juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org" , "bruno.decraene@orange.com" , Shane Amante , "UTTARO, JAMES" , Susan Hares Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 20:54:05 -0000 Hi John, Consider GR. If on the restarting speaker BGP sessions go down due to TCP bug or TCP-BGP interaction bug wouldn't receiving speaker apply BGP GR procedure ? R. > On Jun 22, 2012, at 9:07 AM, Robert Raszuk wrote: > >> Last .. the session down event while BGP process is still healthy and >> running is being addressed by various other proposals in IDR and GROW >> which do target opposite solution .. keep the session up even if some >> errors which would trigger it down are received. > > None of these address a problem at or below the transport level, though. The conversation so far has largely neglected this point. > > --John > From brian.peter.dickson@gmail.com Thu Jun 28 13:56:47 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 737DD11E808F for ; Thu, 28 Jun 2012 13:56:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZLrOaW1UF+As for ; Thu, 28 Jun 2012 13:56:45 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id ACAF011E8087 for ; Thu, 28 Jun 2012 13:56:42 -0700 (PDT) Received: by wibhq12 with SMTP id hq12so485963wib.1 for ; Thu, 28 Jun 2012 13:56:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Musp/gr8hnNIMs2y+o6AK41BmGPJdCkQlpqdp5Kf33A=; b=m45XFuW4vu9XpZTqSdmMZNIBj+JvP3zQBv2D5ZzIvY8x01c1RQNpnRfGTYZyZC+dnZ pyHwvWSicLehNDx9Yjmu78bFqg8d8ItlBJawGSxzbjbKTnZNrD9wVKk7OZjtadxDFLi7 lZwnMzjrQSUqyKE+sBOnSdeANMI9QLqI++VQMVaszizQhzSye3XPVV0N/5sTv2X4X7pp QkSpVb6VAY07TQSB4dWWLACLysquS3mD700waSuhu+FQbS6xpYl4gJu/RIstLxWkQAjq iw3uRL3Yca9cNolof7OjrnekdZPvPzbkTklgdyl+Zq2WI1DXYOvq17Q05fShkgTpWytg Qz+A== MIME-Version: 1.0 Received: by 10.180.83.196 with SMTP id s4mr2923805wiy.15.1340917001990; Thu, 28 Jun 2012 13:56:41 -0700 (PDT) Received: by 10.223.39.19 with HTTP; Thu, 28 Jun 2012 13:56:41 -0700 (PDT) In-Reply-To: References: <20120617204451.26844.76025.idtracker@ietfa.amsl.com> Date: Thu, 28 Jun 2012 16:56:41 -0400 Message-ID: From: Brian Dickson To: "John G. Scudder" Content-Type: multipart/alternative; boundary=f46d04428eee93b35d04c38e91be Cc: "idr@ietf.org" , "UTTARO, JAMES" Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 20:56:47 -0000 --f46d04428eee93b35d04c38e91be Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jun 18, 2012 at 3:48 PM, John G. Scudder wrote: > Hi Jim, > > On Jun 17, 2012, at 8:29 PM, UTTARO, JAMES wrote: > > > > Could you expand on the conditions > > One very simple case: > > A--B--C--D > > The four routers depicted form an IBGP full mesh (sessions not shown). The > links shown are the physical topology. Standard IP forwarding is used. > Routers A and D are ASBRs and both advertise a path for prefix X into IBGP. > Router C prefers the path from A, for example due to a shorter AS Path. > However, router B decides that the path from A is malformed, so it selects > the path from D. Now we have C's next hop to reach X as B, and B's next hop > to reach X as C. This is a stable forwarding loop. (Why do B and C have > different conclusions about whether the update is malformed? Different code > bases with different assumptions, as we have seen more than once in the > field.) This is a very useful example, and has prompted me to think about the problem space. See below for discussion (by me). > > > Will there be a draft whereby the detecting router somehow figures out > the offending ingress router, builds routing policy and then sends it there > to dynamically create the filter. > > I sincerely hope not and have spoken against this idea in the past. > > > This seems non-trivial, > > That's why. When you start building machinery to automatically patch > around bugs in your primary routing machinery, IMO you have officially > Jumped The Shark and started building a Rube Goldberg router. > Patch around bugs, no. However, achieving AS-wide loop-free routing should be considered an explicit goal, and to that end, how such errors get handled is pretty important. That may mean a first-order method of achieving consistency is needed, i.e. one that involves very little semantics, and doesn't attempt to overload existing per-AFI/SAFI machinery. Here are what I see as problems when a subset of IBGP speakers think a given update is malformed: - In order to prevent a routing INFORMATION loop, malformed updates need to be matched against previous corresponding non-malformed updates (if any) - A router that wants to avoid forwarding packets inside a routing loop (where the loop was induced by treat-as-withdrawn), would possibly need to basically do RPF-checks on the interface it chose as next-hop for those packets - Any attempt to infer whether a given router should selectively also withdraw a given route from its Adj-IN-RIB, to avoid a routing loop induced by treat-as-withdrawn by an IBGP peer, requires combining IGP and IBGP routing information, need to consider this on a hop-by-hop basis, and can only identify route-loops involving an immediately adjacent (topologically speaking) router. This requires hop-by-hop, route-by-route, iterative action, which clearly scales, in arbitrary topologies, arbitrarily badly. Unless all route instances are collectively marked as malformed, there should be one or more non-malformed routes available for use. The easiest way to match updates that _some_ router inside a given AS thinks are malformed, against the original non-malformed announcement, is to have the iBGP speaker do the "treat-as-withdrawn" action itself. This would accomplish several things: - Every router in the AS would receive the withdrawal (from the original iBGP speaker, i.e. with correct behavior from the stateful perspective) - Every router in the AS would have the same BGP information from which to choose best path (and is more likely to converge loop-free) - Only the original iBGP speaker would need to keep state regarding the route that is now under "treat-as-withdrawn" - Logging from the two iBGP speakers (the one that believes the update was malformed, and the one that sent the malformed update) is enough to isolate the problem quickly - Malformed updates would not propagate (this is a big plus) - Only updates that all vendors/code-bases believe are non-malformed can propagate beyond the AS (a huge plus - trap the error at the ingress boundaries) - No flapping sessions (a huge plus) The absolute minimum needed to achieve this basically is, for the receiving/detecting/reporting iBGP speaker to send back the UPDATE message, wrapped in some other message type, to the original sender (or targeted at the sender but relayed to the RR, if an RR cluster list is present). In order to make this simple and to scale implementation, the idea I have is to use a single, new AFI/SAFI, which is "Malformed", and whose message includes the AFI/SAFI and everything else from the original UPDATE. Upon receipt of such a Malformed message, the (presumed) ASBR would then send do "treat-as-withdrawn", mark the original ingress NLRI as "reported malformed", in such a way as to require operator intervention to clear the "malformed" state (and thus not repeatedly re-propagate updates and contribute churn related to malformed updates). The motivation for this is - don't create persistent routing loops (and don't check for an error condition you don't know how to handle :-)). This is only for the iBGP case, which is IMHO the most important one. Not sure if this logic can or should extend to the eBGP environment, but I think it can be inferred from the above that this would not be strictly necessary. Routing updates that are seen by an entire AS as well-formed means reachability is fine for that AS. If other AS neighbors don't agree then they won't use the affected routes, so things still result in loop-free forwarding and reachability is maximized. Thoughts? Does this make sense, and would this fit in the proposal, or should it go in a separate draft? Brian --f46d04428eee93b35d04c38e91be Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, Jun 18, 2012 at 3:48 PM, John G.= Scudder <jgs@juniper.net> wrote:
Hi Jim,

On Jun 17, 2012, at 8:29 PM, UTTARO, JAMES wrote:


> Could you expand on the conditions

One very simple case:

=A0A--B--C--D

The four routers depicted form an IBGP full mesh (sessions not shown). The = links shown are the physical topology. Standard IP forwarding is used. Rout= ers A and D are ASBRs and both advertise a path for prefix X into IBGP. Rou= ter C prefers the path from A, for example due to a shorter AS Path. Howeve= r, router B decides that the path from A is malformed, so it selects the pa= th from D. Now we have C's next hop to reach X as B, and B's next h= op to reach X as C. This is a stable forwarding loop. (Why do B and C have = different conclusions about whether the update is malformed? Different code= bases with different assumptions, as we have seen more than once in the fi= eld.)

This is a very useful example, and has prompted me to t= hink about the problem space. See below for discussion (by me).
= =A0

> Will there be a draft whereby the detecting router somehow figures out= the offending ingress router, builds routing policy and then sends it ther= e to dynamically create the filter.

I sincerely hope not and have spoken against this idea in the past.
> This seems non-trivial,

That's why. When you start building machinery to automatically patch ar= ound bugs in your primary routing machinery, IMO you have officially Jumped= The Shark and started building a Rube Goldberg router.

Patch around bugs, no. However, achieving AS-wide loop-= free routing should be considered an explicit goal, and to that end, how su= ch errors get handled is pretty important.

That ma= y mean a first-order method of achieving consistency is needed, i.e. one th= at involves very little semantics, and doesn't attempt to overload exis= ting per-AFI/SAFI machinery.=A0

Here are what I see as problems when a subset of IBGP s= peakers think a given update is malformed:

    In order to prevent a routing INFORMATION loop, malformed updates need to = be matched against previous corresponding non-malformed updates (if any)
  • A router that wants to avoid forwarding packets inside a routing loop (= where the loop was induced by treat-as-withdrawn), would possibly need to b= asically do RPF-checks on the interface it chose as next-hop for those pack= ets
  • Any attempt to infer whether a given router should selectively also wit= hdraw a given route from its Adj-IN-RIB, to avoid a routing loop induced by= treat-as-withdrawn by an IBGP peer, requires combining IGP and IBGP routin= g information, need to consider this on a hop-by-hop basis, and can only id= entify route-loops involving an immediately adjacent (topologically speakin= g) router. This requires hop-by-hop, route-by-route, iterative action, whic= h clearly scales, in arbitrary topologies, arbitrarily badly.

Unless all route instances are collectively marked as malformed, t= here should be one or more non-malformed routes available for use.

The easiest way to match updates that _some_ router inside= a given AS thinks are malformed, against the original non-malformed announ= cement, is to have the iBGP speaker do the "treat-as-withdrawn" a= ction itself.

This would accomplish several things:
  • Every = router in the AS would receive the withdrawal (from the original iBGP speak= er, i.e. with correct behavior from the stateful perspective)
  • Every= router in the AS would have the same BGP information from which to choose = best path (and is more likely to converge loop-free)
  • Only the original iBGP speaker would need to keep state regarding the r= oute that is now under "treat-as-withdrawn"
  • Logging from = the two iBGP speakers (the one that believes the update was malformed, and = the one that sent the malformed update) is enough to isolate the problem qu= ickly
  • Malformed updates would not propagate (this is a big plus)
  • Only= updates that all vendors/code-bases believe are non-malformed can propagat= e beyond the AS (a huge plus - trap the error at the ingress boundaries)
  • No flapping sessions (a huge plus)
The absolute minimum n= eeded to achieve this basically is, for the receiving/detecting/reporting i= BGP speaker to send back the UPDATE message, wrapped in some other message = type, to the original sender (or targeted at the sender but relayed to the = RR, if an RR cluster list is present).

In order to make this simple and to scale implementatio= n, the idea I have is to use a single, new AFI/SAFI, which is "Malform= ed", and whose message includes the AFI/SAFI and everything else from = the original UPDATE.

Upon receipt of such a Malformed message, the (presumed= ) ASBR would then send do "treat-as-withdrawn", mark the original= ingress NLRI as "reported malformed", in such a way as to requir= e operator intervention to clear the "malformed" state (and thus = not repeatedly re-propagate updates and contribute churn related to malform= ed updates).

The motivation for this is - don't create persisten= t routing loops (and don't check for an error condition you don't k= now how to handle :-)).

This is only for the iBGP = case, which is IMHO the most important one. Not sure if this logic can or s= hould extend to the eBGP environment, but I think it can be inferred from t= he above that this would not be strictly necessary. Routing updates that ar= e seen by an entire AS as well-formed means reachability is fine for that A= S. If other AS neighbors don't agree then they won't use the affect= ed routes, so things still result in loop-free forwarding and reachability = is maximized.

Thoughts?

Does this make sense= , and would this fit in the proposal, or should it go in a separate draft?<= /div>

Brian
--f46d04428eee93b35d04c38e91be-- From robert@raszuk.net Thu Jun 28 14:11:40 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6749111E8091 for ; Thu, 28 Jun 2012 14:11:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M07j-UGhPw-4 for ; Thu, 28 Jun 2012 14:11:37 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 19A4F11E8087 for ; Thu, 28 Jun 2012 14:11:37 -0700 (PDT) Received: (qmail 6303 invoked by uid 399); 28 Jun 2012 21:11:36 -0000 Received: from unknown (HELO ?192.168.1.58?) (pbs:robert@raszuk.net@83.31.185.95) by mail1310.opentransfer.com with ESMTPM; 28 Jun 2012 21:11:36 -0000 X-Originating-IP: 83.31.185.95 Message-ID: <4FECC889.90008@raszuk.net> Date: Thu, 28 Jun 2012 23:11:37 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Brian Dickson References: <20120617204451.26844.76025.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "UTTARO, JAMES" , "idr@ietf.org" Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 21:11:40 -0000 Hi Brian, Excellent analysis. But let me ask a very basic question. You said: > This is only for the iBGP case, which is IMHO the most important one. How much from what you have suggested do you think applies if one uses IP (or MPLS) encapsulation within the AS ingress to egress ? Optionally one could make sure next hop self is not used on the ASBRs and perform direct encapsulation to the external AS (no IP lookup at the egress ASBR). In those cases do you think you still see real value for the proposed below error handling ? Best regards, R. > On Mon, Jun 18, 2012 at 3:48 PM, John G. Scudder > wrote: > > Hi Jim, > > On Jun 17, 2012, at 8:29 PM, UTTARO, JAMES wrote: > > > > Could you expand on the conditions > > One very simple case: > > A--B--C--D > > The four routers depicted form an IBGP full mesh (sessions not > shown). The links shown are the physical topology. Standard IP > forwarding is used. Routers A and D are ASBRs and both advertise a > path for prefix X into IBGP. Router C prefers the path from A, for > example due to a shorter AS Path. However, router B decides that the > path from A is malformed, so it selects the path from D. Now we have > C's next hop to reach X as B, and B's next hop to reach X as C. This > is a stable forwarding loop. (Why do B and C have different > conclusions about whether the update is malformed? Different code > bases with different assumptions, as we have seen more than once in > the field.) > > > This is a very useful example, and has prompted me to think about the > problem space. See below for discussion (by me). > > > > Will there be a draft whereby the detecting router somehow > figures out the offending ingress router, builds routing policy and > then sends it there to dynamically create the filter. > > I sincerely hope not and have spoken against this idea in the past. > > > This seems non-trivial, > > That's why. When you start building machinery to automatically patch > around bugs in your primary routing machinery, IMO you have > officially Jumped The Shark and started building a Rube Goldberg router. > > > Patch around bugs, no. However, achieving AS-wide loop-free routing > should be considered an explicit goal, and to that end, how such errors > get handled is pretty important. > > That may mean a first-order method of achieving consistency is needed, > i.e. one that involves very little semantics, and doesn't attempt to > overload existing per-AFI/SAFI machinery. > > Here are what I see as problems when a subset of IBGP speakers think a > given update is malformed: > > * In order to prevent a routing INFORMATION loop, malformed updates > need to be matched against previous corresponding non-malformed > updates (if any) > * A router that wants to avoid forwarding packets inside a routing > loop (where the loop was induced by treat-as-withdrawn), would > possibly need to basically do RPF-checks on the interface it chose > as next-hop for those packets > * Any attempt to infer whether a given router should selectively also > withdraw a given route from its Adj-IN-RIB, to avoid a routing loop > induced by treat-as-withdrawn by an IBGP peer, requires combining > IGP and IBGP routing information, need to consider this on a > hop-by-hop basis, and can only identify route-loops involving an > immediately adjacent (topologically speaking) router. This requires > hop-by-hop, route-by-route, iterative action, which clearly scales, > in arbitrary topologies, arbitrarily badly. > > > Unless all route instances are collectively marked as malformed, there > should be one or more non-malformed routes available for use. > > The easiest way to match updates that _some_ router inside a given AS > thinks are malformed, against the original non-malformed announcement, > is to have the iBGP speaker do the "treat-as-withdrawn" action itself. > > This would accomplish several things: > > * Every router in the AS would receive the withdrawal (from the > original iBGP speaker, i.e. with correct behavior from the stateful > perspective) > * Every router in the AS would have the same BGP information from > which to choose best path (and is more likely to converge loop-free) > * Only the original iBGP speaker would need to keep state regarding > the route that is now under "treat-as-withdrawn" > * Logging from the two iBGP speakers (the one that believes the update > was malformed, and the one that sent the malformed update) is enough > to isolate the problem quickly > * Malformed updates would not propagate (this is a big plus) > * Only updates that all vendors/code-bases believe are non-malformed > can propagate beyond the AS (a huge plus - trap the error at the > ingress boundaries) > * No flapping sessions (a huge plus) > > The absolute minimum needed to achieve this basically is, for the > receiving/detecting/reporting iBGP speaker to send back the UPDATE > message, wrapped in some other message type, to the original sender (or > targeted at the sender but relayed to the RR, if an RR cluster list is > present). > > In order to make this simple and to scale implementation, the idea I > have is to use a single, new AFI/SAFI, which is "Malformed", and whose > message includes the AFI/SAFI and everything else from the original UPDATE. > > Upon receipt of such a Malformed message, the (presumed) ASBR would then > send do "treat-as-withdrawn", mark the original ingress NLRI as > "reported malformed", in such a way as to require operator intervention > to clear the "malformed" state (and thus not repeatedly re-propagate > updates and contribute churn related to malformed updates). > > The motivation for this is - don't create persistent routing loops (and > don't check for an error condition you don't know how to handle :-)). > > This is only for the iBGP case, which is IMHO the most important one. > Not sure if this logic can or should extend to the eBGP environment, but > I think it can be inferred from the above that this would not be > strictly necessary. Routing updates that are seen by an entire AS as > well-formed means reachability is fine for that AS. If other AS > neighbors don't agree then they won't use the affected routes, so things > still result in loop-free forwarding and reachability is maximized. > > Thoughts? > > Does this make sense, and would this fit in the proposal, or should it > go in a separate draft? > > Brian > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > From ju1738@att.com Thu Jun 28 16:59:11 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E250B21F85D9 for ; Thu, 28 Jun 2012 16:59:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.335 X-Spam-Level: X-Spam-Status: No, score=-106.335 tagged_above=-999 required=5 tests=[AWL=0.263, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mNR+Ccq6qHjM for ; Thu, 28 Jun 2012 16:59:09 -0700 (PDT) Received: from nbfkord-smmo03.seg.att.com (nbfkord-smmo03.seg.att.com [209.65.160.84]) by ietfa.amsl.com (Postfix) with ESMTP id C1F3521F85D8 for ; Thu, 28 Jun 2012 16:59:08 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO nbfkord-smmo03.seg.att.com) by nbfkord-smmo03.seg.att.com(mxl_mta-6.11.0-10) with ESMTP id ccfecef4.2aaad020c940.1304345.00-578.3619002.nbfkord-smmo03.seg.att.com (envelope-from ); Thu, 28 Jun 2012 23:59:08 +0000 (UTC) X-MXL-Hash: 4fecefcc2104473b-9da836923de74bc21aad0f4c50a45b7441a29ac8 Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo03.seg.att.com(mxl_mta-6.11.0-10) over TLS secured channel with ESMTP id 9afecef4.0.1304273.00-395.3618805.nbfkord-smmo03.seg.att.com (envelope-from ); Thu, 28 Jun 2012 23:58:49 +0000 (UTC) X-MXL-Hash: 4fecefb939a74789-f44a6aeac0c575dff755c26e309b74a1ffdfd5fc Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q5SNwXuh022357; Thu, 28 Jun 2012 19:58:33 -0400 Received: from sflint01.pst.cso.att.com (sflint01.pst.cso.att.com [144.154.234.228]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q5SNwT6C022349 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Jun 2012 19:58:30 -0400 Received: from MISOUT7MSGHUB9F.ITServices.sbc.com (misout7msghub9f.itservices.sbc.com [144.151.223.71]) by sflint01.pst.cso.att.com (RSA Interceptor); Thu, 28 Jun 2012 19:58:22 -0400 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9F.ITServices.sbc.com ([144.151.223.71]) with mapi id 14.02.0298.004; Thu, 28 Jun 2012 19:58:22 -0400 From: "UTTARO, JAMES" To: "'Shane Amante'" Thread-Topic: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks Thread-Index: AQHNVJ1Cc8ZsEmmpxEWbTJxs6Wew1w== Date: Thu, 28 Jun 2012 23:58:21 +0000 Message-ID: References: <14C7F4F06DB5814AB0DE29716C4F6D6702DF7129F6@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <4FE623B3.4060906@raszuk.net> <20120625070729.GC21620@juniper.net> <94135843-5EF1-4B4A-9CA3-885A4088A762@castlepoint.net> <84158396-59E4-478B-822C-02F0F42402C3@castlepoint.net> In-Reply-To: <84158396-59E4-478B-822C-02F0F42402C3@castlepoint.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.8.100] Content-Type: multipart/alternative; boundary="_000_B17A6910EEDD1F45980687268941550FB30B12MISOUT7MSGUSR9IIT_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=1.0 c=1 a=kUgo5BdQVG8A:10 a=ZQD3OTTxKqYA:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a=XK] X-AnalysisOut: [fbYx4oAAAA:8 a=48vgC7mUAAAA:8 a=so09qB8XwU2R2Bhr340A:9 a=C] X-AnalysisOut: [juIK1q_8ugA:10 a=uI1Or78iWTcA:10 a=lZB815dzVvQA:10 a=yMhMj] X-AnalysisOut: [lubAAAA:8 a=SSmOFEACAAAA:8 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4] X-AnalysisOut: [A:10 a=hTZeC7Yk6K0A:10] Cc: "idr@ietf.org List" , Robert Raszuk Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 23:59:12 -0000 --_000_B17A6910EEDD1F45980687268941550FB30B12MISOUT7MSGUSR9IIT_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Shane, I have significant concerns wrt (b), in particular your last sentence above= . More specifically, this is the IDR WG, where the charter currently state= s: ---snip--- The main objective of the working group is to support the use of BGP-4 by IP version 4 and IP version 6 networks. The working group will also continue to work on improving the robustness and scalability of BGP. ---snip--- IMHO, both sentences appear to state that the WG should focus on developing= the robustness and scalability of BGP for all types of networks, not just = VPN networks. As such, it may be prudent for the WG to consider acknowledg= ing this is a problem with the _architecture_ of BGP, applicable to all AFI= /SAFI's, and diligently work toward a single solution that addresses this p= roblem in a comprehensive and consistent manner across all AFI/SAFI's. Jim U> I believe that different use cases require different behaviors. Ther= e is simply no way of getting around this.. As I stated in my ex.. Flowspec= is a method of creating configuration via BGP.. This should persist as if = it was programmed via XML, etc... I always want robustness and scalability= but certain AFs require more than this. I think the charter should to be a= mended to accomodate the different use cases for BGP and where they diverge= in terms of behavior, customer expectations and solutions, or at minimum t= ry to operate from a framework that acknowledges these use cases and their = different requirements. Jim Uttaro From: Shane Amante [mailto:shane@castlepoint.net] Sent: Wednesday, June 27, 2012 3:36 PM To: UTTARO, JAMES Cc: Senad .Palislamovic; idr@ietf.org List; Robert Ras= zuk Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document -= 3 more weeks Jim, On Jun 27, 2012, at 12:18 PM, UTTARO, JAMES wrote: All, After reviewing all of the comments in re BGP Persistence I= would categorize the opinions of the WG ( At least the ones that have chim= ed in ) in the following manner. I would like to get back to a discussion = about the facts.. [--snip--] b) Folks who feel it is unacceptable that BGP Persistence creates STALE sta= te in domains adjacent to the persistent domain. Two points here.. The first is that this is the current behavior as defined by GR for the int= ernet use case with the fact that there is no method of GR informing that p= aths are STALE. I have repeatedly noted this and so far E. Chen is the only= person that acknowledged the behavior with a caveat that the behavior is f= or a short amount of time and therefore acceptable.. I have heard no other = opinions on this are there any? The second is BGP Persistence draft took note of the above fact in re GR an= d created the ability to inform topologies by th setting of a STALE CV.. Ad= jacent domains can easily identify the paths and decide on whether or not t= hey should be used. So the draft directly addresses this issue. So IMO (b) This I truly do not understand.. My co-authors and I have provided a si= mple mechanism to create a persistent solution and included and ability to = inform peer topologies as this IMO seemed like a hole in the current GR dra= ft for this functionality. We have also specifically stated that internet i= s not a use case.. I have significant concerns wrt (b), in particular your last sentence above= . More specifically, this is the IDR WG, where the charter currently state= s: ---snip--- The main objective of the working group is to support the use of BGP-4 by IP version 4 and IP version 6 networks. The working group will also continue to work on improving the robustness and scalability of BGP. ---snip--- IMHO, both sentences appear to state that the WG should focus on developing= the robustness and scalability of BGP for all types of networks, not just = VPN networks. As such, it may be prudent for the WG to consider acknowledg= ing this is a problem with the _architecture_ of BGP, applicable to all AFI= /SAFI's, and diligently work toward a single solution that addresses this p= roblem in a comprehensive and consistent manner across all AFI/SAFI's. -shane --_000_B17A6910EEDD1F45980687268941550FB30B12MISOUT7MSGUSR9IIT_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Shane,

 <= /p>

I have significant concerns wrt (b), in particular y= our last sentence above.  More specifically, this is the IDR WG, = where the charter currently states:

---snip---

    The main objective of the working grou= p is to support the use of

    BGP-4 by IP version 4 and IP version 6= networks. The working group

    will also continue to work on improvin= g the robustness and

    scalability of BGP.

---snip---

IMHO, both sentences appear to state that the WG sho= uld focus on developing the robustness and scalability of BGP for all types= of networks, not just VPN networks.  As such, it may be prudent for t= he WG to consider acknowledging this is a problem with the _architecture_ of BGP, applicable to all AFI/SAFI's, an= d diligently work toward a single solution that addresses this problem in a= comprehensive and consistent manner across all AFI/SAFI's.

 

Jim U> I believe= that different use cases require different behaviors. There is simply no w= ay of getting around this.. As I stated in my ex.. Flowspec is a method of = creating configuration via BGP.. This should persist as if it was programmed via XML, etc…  I always want ro= bustness and scalability but certain AFs require more than this. I think th= e charter should to be amended to accomodate the different use cases for BG= P and where they diverge in terms of behavior, customer expectations and solutions, or at minimum try to operate from a f= ramework that acknowledges these use cases and their different requirements= .

 

Jim Uttaro

 <= /p>

From: Shane Am= ante [mailto:shane@castlepoint.net= ]
Sent: Wednesday, June 27, 2012 3:36 PM
To: UTTARO, JAMES
Cc: Senad .Palislamovic; idr@ietf.or= g List; Robert Raszuk
Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG doc= ument - 3 more weeks

 

Jim,

 

On Jun 27, 2012, at 12:18 PM, UTTARO, JAMES wrote:

All,

 <= /p>

    &= nbsp;           After rev= iewing all of the comments in re BGP Persistence I would categorize the opi= nions of the WG ( At least the ones that have chimed in )  in the following manner. I would like to get back to a discussion = about the facts..

 

[--snip--]



b) Folks who feel it is unacceptable that BGP Persistence creates S= TALE state in domains adjacent to the persistent domain. <= /o:p>

 <= /p>

Two points here..<= o:p>

 <= /p>

The first is that this is= the current behavior as defined by GR for the internet use case with the f= act that there is no method of GR informing that paths are STALE. I have repeatedly noted this and so far E. Chen is the only person = that acknowledged the behavior with a caveat that the behavior is for a sho= rt amount of time and therefore acceptable.. I have heard no other opinions= on this are there any?

 <= /p>

The second is BGP Persist= ence draft took note of the above fact in re GR and created the ability to = inform topologies by th setting of a STALE CV.. Adjacent domains can easily identify the paths and decide on whether or not they sh= ould be used. So the draft directly addresses this issue.=

 <= /p>

So IMO<= /p>

 <= /p>

(b) This I truly do not u= nderstand.. My co-authors and I have provided a simple mechanism to create = a persistent solution and included and ability to inform peer topologies as this IMO seemed like a hole in the current GR draft for= this functionality. We have also specifically stated that internet is not = a use case..

 

I have significant concerns wrt (b), in particular y= our last sentence above.  More specifically, this is the IDR WG, = where the charter currently states:

---snip---

    The main objective of the working grou= p is to support the use of

    BGP-4 by IP version 4 and IP version 6= networks. The working group

    will also continue to work on improvin= g the robustness and

    scalability of BGP.

---snip---

IMHO, both sentences appear to state that the WG sho= uld focus on developing the robustness and scalability of BGP for all types= of networks, not just VPN networks.  As such, it may be prudent for t= he WG to consider acknowledging this is a problem with the _architecture_ of BGP, applicable to all AFI/SAFI's, an= d diligently work toward a single solution that addresses this problem in a= comprehensive and consistent manner across all AFI/SAFI's.

 

-shane

--_000_B17A6910EEDD1F45980687268941550FB30B12MISOUT7MSGUSR9IIT_-- From ju1738@att.com Thu Jun 28 18:38:17 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D327811E810A for ; Thu, 28 Jun 2012 18:38:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.749 X-Spam-Level: X-Spam-Status: No, score=-105.749 tagged_above=-999 required=5 tests=[AWL=-0.351, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3tTFIO4K69bS for ; Thu, 28 Jun 2012 18:38:13 -0700 (PDT) Received: from nbfkord-smmo04.seg.att.com (nbfkord-smmo04.seg.att.com [209.65.160.86]) by ietfa.amsl.com (Postfix) with ESMTP id D666D11E80FA for ; Thu, 28 Jun 2012 18:38:12 -0700 (PDT) Received: from unknown [144.160.128.153] (EHLO nbfkord-smmo04.seg.att.com) by nbfkord-smmo04.seg.att.com(mxl_mta-6.11.0-10) with ESMTP id 4070def4.6a353940.1319257.00-595.3662678.nbfkord-smmo04.seg.att.com (envelope-from ); Fri, 29 Jun 2012 01:38:12 +0000 (UTC) X-MXL-Hash: 4fed07046b89474e-b4a97b7ebd07d1c80dc69bcb5a71a554c564e877 Received: from unknown [144.160.128.153] (EHLO flpi408.enaf.ffdc.sbc.com) by nbfkord-smmo04.seg.att.com(mxl_mta-6.11.0-10) over TLS secured channel with ESMTP id ed60def4.0.1319182.00-305.3662481.nbfkord-smmo04.seg.att.com (envelope-from ); Fri, 29 Jun 2012 01:37:51 +0000 (UTC) X-MXL-Hash: 4fed06ef71b58864-96c0a7eb13477785e8468f1b68388724277d481a Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q5T1bXEi003209; Thu, 28 Jun 2012 18:37:34 -0700 Received: from fflint03.pst.cso.att.com (fflint03.pst.cso.att.com [150.234.39.63]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q5T1bL01003099 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Jun 2012 18:37:27 -0700 Received: from MISOUT7MSGHUB9E.ITServices.sbc.com (misout7msghub9e.itservices.sbc.com [144.151.223.61]) by fflint03.pst.cso.att.com (RSA Interceptor); Thu, 28 Jun 2012 18:36:43 -0700 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9E.ITServices.sbc.com ([144.151.223.61]) with mapi id 14.02.0298.004; Thu, 28 Jun 2012 21:36:43 -0400 From: "UTTARO, JAMES" To: "'Brian Dickson'" Thread-Topic: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks Thread-Index: AQHNVKijc8ZsEmmpxEWbTJxs6Wew15cQggTA Date: Fri, 29 Jun 2012 01:36:42 +0000 Message-ID: References: <14C7F4F06DB5814AB0DE29716C4F6D6702DF7129F6@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <4FE623B3.4060906@raszuk.net> <20120625070729.GC21620@juniper.net> <94135843-5EF1-4B4A-9CA3-885A4088A762@castlepoint.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.8.100] Content-Type: multipart/alternative; boundary="_000_B17A6910EEDD1F45980687268941550FB30BBEMISOUT7MSGUSR9IIT_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.128.153] X-AnalysisOut: [v=1.0 c=1 a=kUgo5BdQVG8A:10 a=ZQD3OTTxKqYA:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=xwOvzTHDVLE4u4nGvK72ag==:17 a=pG] X-AnalysisOut: [LkceISAAAA:8 a=48vgC7mUAAAA:8 a=zQP7CpKOAAAA:8 a=RZQ5zj7AX] X-AnalysisOut: [hNDZajL9J8A:9 a=CjuIK1q_8ugA:10 a=MSl-tDqOz04A:10 a=lZB815] X-AnalysisOut: [dzVvQA:10 a=Hz7IrDYlS0cA:10 a=RoJM_9EBsmv8uBnm:21 a=rxmi6F] X-AnalysisOut: [22GlPOxwi-:21 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=2Z3_UgNx] X-AnalysisOut: [l4BVbnVubEYA:9 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC] X-AnalysisOut: [7Yk6K0A:10 a=tXsnliwV7b4A:10 a=ovkihXfEPVsiQ93J:21 a=PfxtH] X-AnalysisOut: [3lUN4Qp00QQ:21] Cc: Shane Amante , Robert Raszuk , "idr@ietf.org List" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 01:38:18 -0000 --_000_B17A6910EEDD1F45980687268941550FB30BBEMISOUT7MSGUSR9IIT_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Brian, Appreciate your comments. Comments In-Line.. Thanks, Jim Uttaro From: Brian Dickson [mailto:brian.peter.dickson@gmail.com] Sent: Wednesday, June 27, 2012 5:06 PM To: UTTARO, JAMES Cc: Shane Amante; Senad .Palislamovic; idr@ietf.org List; Robert Raszuk Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document -= 3 more weeks On Wed, Jun 27, 2012 at 2:18 PM, UTTARO, JAMES > wrote: All, After reviewing all of the comments in re BGP Persistence I= would categorize the opinions of the WG ( At least the ones that have chim= ed in ) in the following manner. I would like to get back to a discussion = about the facts.. b) Folks who feel it is unacceptable that BGP Persistence creates STALE sta= te in domains adjacent to the persistent domain. Two points here.. The first is that this is the current behavior as defined by GR for the int= ernet use case with the fact that there is no method of GR informing that p= aths are STALE. I have repeatedly noted this and so far E. Chen is the only= person that acknowledged the behavior with a caveat that the behavior is f= or a short amount of time and therefore acceptable.. I have heard no other = opinions on this are there any? The second is BGP Persistence draft took note of the above fact in re GR an= d created the ability to inform topologies by th setting of a STALE CV.. Ad= jacent domains can easily identify the paths and decide on whether or not t= hey should be used. So the draft directly addresses this issue. So IMO (b) This I truly do not understand.. My co-authors and I have provided a si= mple mechanism to create a persistent solution and included and ability to = inform peer topologies as this IMO seemed like a hole in the current GR dra= ft for this functionality. We have also specifically stated that internet i= s not a use case.. I have a few questions, after more carefully reading the -01 draft. Please indulge me, I am interested in understanding the relationship betwee= n the motivation/goal, the specific use cases presented, and the mechanisms= themselves. First, it seems that the "STALE" stuff is partly motivated by a perceived l= ack of notification in GR. Isn't that irrelevant to the draft at hand, and = perhaps better addressed by updating GR? [Jim U>] ? Not sure I know what you mean.. GR does not have the ability to = inform topologies about paths learned over a session where GR is currently = Active.. IMO this is a base requirement as the same path learned over a dif= ferent egress PE should be preferred.. Whether this behavior "fits" with th= e GR spec I leave to the authors to comment on.. Also, in the use cases, there does not seem to be any real value to adverti= sing this "STALE" state beyond the local systems. In the L2VPN in particula= r, there is no "beyond" at all. So, why bother with "STALE" at all? I don't= see it being used anywhere in your draft, only that it is being set. [Jim U>] In certain use cases dealing with static configuration this is cer= tainly true, I would say exactly true when the update is specific action i.= e FlowSpec, RT-C etc... VPLS uses BGP to set up PWs while the data plane is= used like ethernet to "learn" about MAC reachability. That being said the= re are a number of corner cases in VPLS i.e Multi_homing and some inter-AS = scenarios where is may be prudent to either DO_NOT_PERSIST or to de-pref th= e path.. To be clear, the STALE and DO_NOT_PERSIST provide the operator wit= h tools to realize their individual goals.. The main problem (that needs to be solved, i.e. the motivation for Persiste= nce) seems to be that intra-AS PE routers, doing L2VPN, would like to maint= ain state in the case where one or more intermediate RRs "go away" for some= period of time. The scope of "state" information, is more closely aligned with the BGP peer= state, rather than attributes of individual NLRIs of any given AFI/SAFI. [Jim U>] Do not agree.. I think Persistence should be done at a path level = so that we have control...The use case use mention is valid, there are othe= rs considered and yet to be considered. Would it not be (a) simpler, (b) more scalable, and (c) more trivial to imp= lement, by creating an Internet-Draft for a negotiated option, "Persistent"= , where, when two or more parties negotiate this option, and NLRIs heard ov= er such sessions being "held" if/when a BGP session is terminated? [Jim U>] Why? The STALE attr is standardized, everyone knows about it, oper= ator takes action appropriate to their network.. What could be simpler?? This would not have any direct impact to path selection, for example, and w= ould fairly trivially support negotiated (based on local configuration of) = timers and "reaping" NLRIs upon timer expiry. Behavior per-AFI/SAFI should = be able to be specified. [Jim U>] We require the ability to de-pref. Not needing to change the content or format of UPDATEs should be seen as a = goal, rather than the other way round. [Jim U>] ? Let alone further overloading the COMMUNITY attribute, with mandated behavi= or based on something that is both optional _and_ transitive. (Yuck.) [Jim U>] ? In fact, would not this fit nicely as a sub-code to GR, with a negotiated s= tatus and timer between peers (or RR servers/clients)? [Jim U>] GR does not meet the reqs. Perhaps having the "negotiation" have multiple values, such as "never", "al= low", "prefer", "always", so that in appropriately configured networks, on = a per-peer (or peer-group) basis, it could be centrally controlled by the R= R primarily. One other question I have, is about Section 6.1. I do not understand a couple of things about the diagram and text: Is the diagram just messed up a bit, with RR2 meaning to talk to PE1 and PE= 2, rather than RR2 talking to RR1 and CE1? [Jim U>] The diagram got shifted to the left.. I will correct Thx.. Which BGP sessions are presumed to go away, i.e. where Persistence will mak= e a difference (or fix a problem you're seeing)? Is it the case that *both* PE1-RR1 *and* PE1-RR2 BGP sessions fail simultan= eously? [Jim U>] Not simultaneously.. For this use case the PE is peered to a clust= er of RRs.. If there is a loss of connectivity from the PE to the Cluster t= hen Persistence would kick in.. And now to dig deeper into the diagram: Are CE1-PE1 and CE2-PE2 connections over switched (L2 Ethernet) connections= ? [Jim U>] Yes Would the problem you are experiencing not be possible to fix with, say, PV= RST over dual-PE1's facing CE1, and similarly dual-PE2's facing CE2, in a r= edundant configuration? That way, only PE1a (and not PE1b) would dump BGP p= eering, and things would fail-over to PE1b? (At which point it is a hardwar= e cost and network design exercise, rather than a protocol thing.) [Jim U>] I am not familiar with this.. That being said, I want one solution= across a number of AFs i.e L3VPN, L2VPN, Flowspec, RT-C, 3107 etc.... You'd have two wires (PE1a-PE1b, and PE2a-PE2b) and two pseudo-wires (PE1a-= PE2a, ,and PE1b-PE2b) forming a "square" topology on which some spanning-tr= ee thing would need to turn into a loop-free topology, and it wouldn't matt= er which PE1 or PE2 was preferred by CE1 and CE2 respectively. Sincerely, Brian Dickson --_000_B17A6910EEDD1F45980687268941550FB30BBEMISOUT7MSGUSR9IIT_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Brian,<= /p>

 <= /p>

    &= nbsp;           Appreciat= e your comments. Comments In-Line..

 <= /p>

Thanks,=

 <= /p>

From: Brian Di= ckson [mailto:brian.peter.dickson@gmail.com]
Sent: Wednesday, June 27, 2012 5:06 PM
To: UTTARO, JAMES
Cc: Shane Amante; Senad .Palislamovic; idr@ietf.org List; Robert Ras= zuk
Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG doc= ument - 3 more weeks

 

 

On Wed, Jun 27, 2012 at 2:18 PM, UTTARO, JAMES <<= a href=3D"mailto:ju1738@att.com" target=3D"_blank">ju1738@att.com> w= rote:

All,

 

      &nb= sp;         After reviewing all of = the comments in re BGP Persistence I would categorize the opinions of the WG ( At least the ones that have chimed in )  in the = following manner. I would like to get back to a discussion about the facts.= .

 

b) Folks who feel it is unacceptable th= at BGP Persistence creates STALE state in domains adjacent to the persistent domain.

 

Two points here..

 

The first is that this is the current b= ehavior as defined by GR for the internet use case with the fact that there is no method of GR informing that paths are STALE. I have = repeatedly noted this and so far E. Chen is the only person that acknowledg= ed the behavior with a caveat that the behavior is for a short amount of ti= me and therefore acceptable.. I have heard no other opinions on this are there any?

 

The second is BGP Persistence draft too= k note of the above fact in re GR and created the ability to inform topologies by th setting of a STALE CV.. Adjacent domains can ea= sily identify the paths and decide on whether or not they should be used. S= o the draft directly addresses this issue.

 

So IMO

 

(b) This I truly do not understand.. My= co-authors and I have provided a simple mechanism to create a persistent solution and included and ability to inform peer topologies a= s this IMO seemed like a hole in the current GR draft for this functionalit= y. We have also specifically stated that internet is not a use case..

 

 

I have a few questions, after more carefully reading= the -01 draft.

 

Please indulge me, I am interested in understanding = the relationship between the motivation/goal, the specific use cases presen= ted, and the mechanisms themselves. 

 

First, it seems that the "STALE" stuff is = partly motivated by a perceived lack of notification in GR. Isn't that irre= levant to the draft at hand, and perhaps better addressed by updating GR?

[Jim U>] ? Not s= ure I know what you mean.. GR does not have the ability to inform topologie= s about paths learned over a session where GR is currently Active.. IMO this is a base requirement as the same path learned over a di= fferent egress PE should be preferred.. Whether this behavior “fits&#= 8221; with the GR spec I leave to the authors to comment on..

 

Also, in the use cases, there does not seem to be an= y real value to advertising this "STALE" state beyond the local s= ystems. In the L2VPN in particular, there is no "beyond" at all. = So, why bother with "STALE" at all? I don't see it being used anywhere in your draft, only that it is being set.

[Jim U>] In cert= ain use cases dealing with static configuration this is certainly true, I w= ould say exactly true when the update is specific action i.e FlowSpec, RT-C etc… VPLS uses BGP to set up PWs while the data plane= is used  like ethernet to “learn” about MAC reachability.= That being said there are a number of corner cases in VPLS i.e Multi_homin= g and some inter-AS scenarios where is may be prudent to either DO_NOT_PERSIST or to de-pref the path.. To be clear, the STALE and = DO_NOT_PERSIST provide the operator with tools to realize their individual = goals..

 

The main problem (that needs to be solved, i.e. the = motivation for Persistence) seems to be that intra-AS PE routers, doing L2V= PN, would like to maintain state in the case where one or more intermediate= RRs "go away" for some period of time.

The scope of "state" information, is more = closely aligned with the BGP peer state, rather than attributes of individu= al NLRIs of any given AFI/SAFI.

[Jim U>] Do not = agree.. I think Persistence should be done at a path level so that we have = control…The use case use mention is valid, there are others considered and yet to be considered.

 

Would it not be (a) simpler, (b) more scalable, and = (c) more trivial to implement, by creating an Internet-Draft for a negotiat= ed option, "Persistent", where, when two or more parties negotiat= e this option, and NLRIs heard over such sessions being "held" if/when a BGP session is terminated?

[Jim U>] Why? Th= e STALE attr is standardized, everyone knows about it, operator takes actio= n appropriate to their network.. What could be simpler??

 

This would not have any direct impact to path select= ion, for example, and would fairly trivially support negotiated (based on l= ocal configuration of) timers and "reaping" NLRIs upon timer expi= ry. Behavior per-AFI/SAFI should be able to be specified.

[Jim U>] We requ= ire the ability to de-pref.<= /o:p>

 

Not needing to change the content or format of UPDAT= Es should be seen as a goal, rather than the other way round.

[Jim U>] ?

 

Let alone further overloading the COMMUNITY attribut= e, with mandated behavior based on something that is both optional _and_ tr= ansitive. (Yuck.)

[Jim U>] ?

 

In fact, would not this fit nicely as a sub-code to = GR, with a negotiated status and timer between peers (or RR servers/clients= )?

[Jim U>] GR does= not meet the reqs.

 

Perhaps having the "negotiation" have mult= iple values, such as "never", "allow", "prefer&quo= t;, "always", so that in appropriately configured networks, on a = per-peer (or peer-group) basis, it could be centrally controlled by the RR = primarily.

 

One other question I have, is about Section 6.1.

I do not understand a couple of things about the dia= gram and text:

Is the diagram just messed up a bit, with RR2 meanin= g to talk to PE1 and PE2, rather than RR2 talking to  RR1 and CE1?

[Jim U>] The dia= gram got shifted to the left.. I will correct Thx..

 

Which BGP sessions are presumed to go away, i.e. whe= re Persistence will make a difference (or fix a problem you're seeing)?

Is it the case that *both* PE1-RR1 *and* PE1-RR2 BGP= sessions fail simultaneously?

[Jim U>] Not sim= ultaneously.. For this use case the PE is peered to a cluster of RRs.. If t= here is a loss of connectivity from the PE to the Cluster then Persistence would kick in..=

 

And now to dig deeper into the diagram:

Are CE1-PE1 and CE2-PE2 connections over switched (L= 2 Ethernet) connections?

[Jim U>] Yes

 

Would the problem you are experiencing not be possib= le to fix with, say, PVRST over dual-PE1's facing CE1, and similarly dual-P= E2's facing CE2, in a redundant configuration? That way, only PE1a (and not= PE1b) would dump BGP peering, and things would fail-over to PE1b? (At which point it is a hardware cost and = network design exercise, rather than a protocol thing.)

[Jim U>] I am no= t familiar with this.. That being said, I want one solution across a number= of AFs i.e L3VPN, L2VPN, Flowspec, RT-C, 3107 etc….

 

You'd have two wires (PE1a-PE1b, and PE2a-PE2b) and = two pseudo-wires (PE1a-PE2a, ,and PE1b-PE2b) forming a "square" t= opology on which some spanning-tree thing would need to turn into a loop-fr= ee topology, and it wouldn't matter which PE1 or PE2 was preferred by CE1 and CE2 respectively.

 

Sincerely,

Brian Dickson

 

--_000_B17A6910EEDD1F45980687268941550FB30BBEMISOUT7MSGUSR9IIT_-- From shane@castlepoint.net Thu Jun 28 19:15:12 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5407711E80FA for ; Thu, 28 Jun 2012 19:15:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.178 X-Spam-Level: X-Spam-Status: No, score=-2.178 tagged_above=-999 required=5 tests=[AWL=0.420, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EXrfBnL2Oz0B for ; Thu, 28 Jun 2012 19:15:09 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id 6C4C211E811C for ; Thu, 28 Jun 2012 19:15:08 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id AA23D368199; Thu, 28 Jun 2012 20:15:07 -0600 (MDT) Received: from mbpw.castlepoint.net (174-29-213-45.hlrn.qwest.net [174.29.213.45]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Thu, 28 Jun 2012 20:15:07 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=174.29.213.45; client-port=63366; syn-fingerprint=65535:54:1:64:M1452,N,W1,N,N,T,S; data-bytes=0 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_979D6ABF-6E23-4D02-806D-357044AEF841" From: Shane Amante In-Reply-To: Date: Thu, 28 Jun 2012 20:14:51 -0600 Message-Id: <8B32FB6E-EC5F-42BA-9553-B2755E517B4D@castlepoint.net> References: <14C7F4F06DB5814AB0DE29716C4F6D6702DF7129F6@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <4FE623B3.4060906@raszuk.net> <20120625070729.GC21620@juniper.net> <94135843-5EF1-4B4A-9CA3-885A4088A762@castlepoint.net> <84158396-59E4-478B-822C-02F0F42402C3@castlepoint.net> To: "UTTARO, JAMES" X-Mailer: Apple Mail (2.1278) Cc: "idr@ietf.org List" , Robert Raszuk Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 02:15:12 -0000 --Apple-Mail=_979D6ABF-6E23-4D02-806D-357044AEF841 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Jim, On Jun 28, 2012, at 5:58 PM, UTTARO, JAMES wrote: > Shane, > =20 > I have significant concerns wrt (b), in particular your last sentence = above. More specifically, this is the IDR WG, where the charter = currently states: > ---snip--- > The main objective of the working group is to support the use of > BGP-4 by IP version 4 and IP version 6 networks. The working group > will also continue to work on improving the robustness and > scalability of BGP. > ---snip--- > IMHO, both sentences appear to state that the WG should focus on = developing the robustness and scalability of BGP for all types of = networks, not just VPN networks. As such, it may be prudent for the WG = to consider acknowledging this is a problem with the _architecture_ of = BGP, applicable to all AFI/SAFI's, and diligently work toward a single = solution that addresses this problem in a comprehensive and consistent = manner across all AFI/SAFI's. > =20 > Jim U> I believe that different use cases require different behaviors. = There is simply no way of getting around this.. As I stated in my ex.. = Flowspec is a method of creating configuration via BGP.. This should = persist as if it was programmed via XML, etc=85 I always want = robustness and scalability but certain AFs require more than this. I = think the charter should to be amended to accomodate the different use = cases for BGP and where they diverge in terms of behavior, customer = expectations and solutions, or at minimum try to operate from a = framework that acknowledges these use cases and their different = requirements. I'm not sure why you believe that the Internet should be treated as a = "lesser citizen" in the context of requirements related to the = robustness of BGP. As a case in point, on the Internet, there exists a = variety of OTT VoIP services, (e.g.: Vonage, Ooma, MagicJack, etc.), = over which E911 services are provided. That seems like a pretty = critical application. In addition, I'm not sure if you're aware (my apologies if you are), but = recently the FCC here in the U.S., has started having discussions of = setting a date for sunsetting the PSTN, which presumably means more = customers would get pushed into using VoIP (of some form, whether as a = service of their ISP or OTT) -or- mobile/cell phones: (Please note the following is a link to a Word doc on the FCC's Web = site, I could not find a link to a HTML version): = http://transition.fcc.gov/oet/tac/tacdocs/meeting92711/Sun-Setting_the_PST= N_Paper_V03.docx The following is a link to a blog post summarizing the Word doc: = http://blog.connectedplanetonline.com/unfiltered/2011/07/07/fcc-considerin= g-exploring-end-dates-for-the-pstn/ Interestingly enough, AT&T has apparently been requesting this of the = FCC since, at least, back in 2009: = http://www.pcworld.com/businesscenter/article/185649/atandt_tells_fcc_its_= time_to_cut_the_cord.html Certainly there are other applications on the Internet that will likely = emerge over time, which also will demand similar high = availability/robustness of Internet service. Thus, I say, let's take = the opportunity now to find a common solution to a fundamental = architectural problem of BGP, which will ultimately benefit all SP's and = users of their services. -shane= --Apple-Mail=_979D6ABF-6E23-4D02-806D-357044AEF841 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Shane,
I have significant = concerns wrt (b), in particular your last sentence above.  More = specifically, this is the IDR WG, where the charter currently = states:
---snip---
    The main objective of the working group = is to support the use of
    BGP-4 by IP = version 4 and IP version 6 networks. The working = group
    will also continue to work on = improving the robustness and
    = scalability of BGP.
IMHO, both sentences = appear to state that the WG should focus on developing the robustness = and scalability of BGP for all types of networks, not just VPN networks. =  As such, it may be prudent for the WG to consider = acknowledging this is a problem with the _architecture_ of BGP, = applicable to all AFI/SAFI's, and diligently work toward a single = solution that addresses this problem in a comprehensive and consistent = manner across all AFI/SAFI's.
Jim U> I believe that different use cases require = different behaviors. There is simply no way of getting around this.. As = I stated in my ex.. Flowspec is a method of creating configuration via = BGP.. This should persist as if it was programmed via XML, etc=85 =  I always want robustness and scalability but certain AFs require = more than this. I think the charter should to be amended to accomodate = the different use cases for BGP and where they diverge in terms of = behavior, customer expectations and solutions, or at minimum try to = operate from a framework that acknowledges these use cases and their = different = requirements.
<= br>
I'm not sure why you believe that the Internet should be = treated as a "lesser citizen" in the context of requirements related to = the robustness of BGP.  As a case in point, on the Internet, there = exists a variety of OTT VoIP services, (e.g.: Vonage, Ooma, MagicJack, = etc.), over which E911 services are provided.  That seems like a = pretty critical application.

In addition, = I'm not sure if you're aware (my apologies if you are), but recently the = FCC here in the U.S., has started having discussions of setting a date = for sunsetting the PSTN, which presumably means more customers would get = pushed into using VoIP (of some form, whether as a service of their ISP = or OTT) -or- mobile/cell phones:
(Please note the following is = a link to a Word doc on the FCC's Web site, I could not find a link to a = HTML version):
The following = is a link to a blog post summarizing the Word doc:

Interestingly enough, AT&T has = apparently been requesting this of the FCC since, at least, back in = 2009:

Certainly there are other applications on the Internet = that will likely emerge over time, which also will demand similar high = availability/robustness of Internet service.  Thus, I say, let's = take the opportunity now to find a common solution to a fundamental = architectural problem of BGP, which will ultimately benefit all SP's and = users of their = services.

-shane
= --Apple-Mail=_979D6ABF-6E23-4D02-806D-357044AEF841-- From brian.peter.dickson@gmail.com Thu Jun 28 19:58:34 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F30BB11E8112 for ; Thu, 28 Jun 2012 19:58:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CFXTgTiE7dcX for ; Thu, 28 Jun 2012 19:58:33 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 87B5711E8085 for ; Thu, 28 Jun 2012 19:58:32 -0700 (PDT) Received: by eaaq13 with SMTP id q13so1140493eaa.31 for ; Thu, 28 Jun 2012 19:58:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4mEgpzGVsXBsSP5S+tOXyt36BF05frbnM8gvReh76Jc=; b=raGRZkedpf2CQ0hPOCb+QCTfbRtoPjAmtL950/hz0fScvwXDcgUZ8bQMc+SON9j9Bt 6hhxExFA+OZnWqJ+T5HoOsALO0NVvxJta8NyZJiL/Pq1JLgRzbLDRogUgiGE51CnrgSN ZBqH2g8JTMySs4ChSGEZropmHoXZa30KhgvO+w46M9hZrnbaMU5IeLz1cPNSWvzyNKw6 DIdUiollNuw4k0xgD+XKpGUz1WrhL0p08iFZUd8l9Nk/6kHyKK9K1Zev7UlnnxbC+k98 MDvigmz88cbMvgXUVmzY6+efMa0TzBjwMw7orVElNiGvlvKBq1CyC6t+gmjoE/cF2FRQ tZfg== MIME-Version: 1.0 Received: by 10.180.78.99 with SMTP id a3mr1269839wix.15.1340938711653; Thu, 28 Jun 2012 19:58:31 -0700 (PDT) Received: by 10.223.39.19 with HTTP; Thu, 28 Jun 2012 19:58:31 -0700 (PDT) In-Reply-To: References: <14C7F4F06DB5814AB0DE29716C4F6D6702DF7129F6@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <4FE623B3.4060906@raszuk.net> <20120625070729.GC21620@juniper.net> <94135843-5EF1-4B4A-9CA3-885A4088A762@castlepoint.net> Date: Thu, 28 Jun 2012 22:58:31 -0400 Message-ID: From: Brian Dickson To: "UTTARO, JAMES" Content-Type: multipart/alternative; boundary=f46d0438904192dbcc04c3939ffc Cc: Shane Amante , Robert Raszuk , "idr@ietf.org List" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 02:58:34 -0000 --f46d0438904192dbcc04c3939ffc Content-Type: text/plain; charset=ISO-8859-1 Okay, thanks for answering my questions. I'll try to simplify the discussion by splitting ongoing discussion into separate threads. I'll leave the subject unmodified, and hopefully modern mail readers can cope with the references. Brian On Thu, Jun 28, 2012 at 9:36 PM, UTTARO, JAMES wrote: > Brian,**** > > ** ** > > Appreciate your comments. Comments In-Line..**** > > ** ** > > Thanks,**** > > Jim Uttaro**** > > ** ** > > * > * > > ** ** > > This would not have any direct impact to path selection, for example, and > would fairly trivially support negotiated (based on local configuration of) > timers and "reaping" NLRIs upon timer expiry. Behavior per-AFI/SAFI should > be able to be specified.**** > > *[Jim U>] We require the ability to de-pref.***** > > ** > Can you elaborate? Who is "we" in this context? How strict is "require", and can you explain how that is a hard requirement, maybe with examples of things breaking without de-pref? Please, more use cases - the more the better. We need to fully understand the problem space, with which you are intimately familiar. If de-pref is not available, is "STALE" still useful? If you are given a choice between "STALE but no de-pref" or "nothing", would "STALE but no de-pref" be acceptable? (Currently you have "nothing", and are asking for "STALE *and* de-pref". I just want to be sure I understand the situation. I believe you could get session-level STALE for the asking, with no opposition, as long as there is no behavior modification or auto-depref mandated. I.e., if the behavior was, "negotiate option PERSISTENCE. if SESSION.PERSISTENCE && BGP_SESSION_DROPPED, add community STALE, push the 'update-it' button which then triggers out-bound route-maps et al", then I think you could get this through WGLC in 30 days or less.) > ** > > Not needing to change the content or format of UPDATEs should be seen as a > goal, rather than the other way round.**** > > *[Jim U>] ?***** > > ** > A negotiated option, call it "PERSIST", would mean that your PE1 peerings with RR1 and RR2, if negotiated, would keep the routes learned if the BGP sessions dropped. Presume that in addition to "PERSIST" that the peers also negotiate a "PERSIST_TIMER". In order to do that, the CAPABILITY_NEGOTIATE codes need to be defined, but beyond the OPEN, there is no change to the on-the-wire protocol or to the path-selection process. The only additional code change needed would be the implicit withdrawal when a BGP peer drops. Contrast that, from the perspective of multiple implementers, of all the mechanics involved in checking each UPDATE for the presence of STALE or DO_NOT_PERSIST communities, and hard-coding modifications to behavior that already involves so many moving parts. (Believe me - I've done severe hacking on, e.g. quagga, and while it is solid code, the complexity in it, which is informed directly by the plethora of BGP RFCs, makes it a huge challenge to try to do "big" changes to it on a whole cloth basis. Getting those right and debugging them are highly non-trivial. Now hand that to vendors who have trouble managing their own hardware drivers and code trains, with massive teams of developers. This needs to interoperate, right? And be stable code serving a lot of customers?) Minimizing the number of places that already-complex logic needs to be tweaked, and then looking at corner cases where those might or might not overlap (in the code, not in the UPDATE data, that is)... If the benefits (of your proposal) are only seen in corner cases, and if the benefits can maybe be achieved via other means (voluntary COMMUNITY processing via route-maps, plus maybe the setting of a STALE well-known community if/when a session drops), then would you be willing to consider the simpler solution? (It might help to try to take what I've suggested and draw it out on a white board. See if you can make sense of it and make it work, even if you have to do post-processing stuff in route-maps. The question is, does it provide sufficient mechanisms to achieve the design goals?) Sincerely, Brian Dickson ** ** ** ** --f46d0438904192dbcc04c3939ffc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Okay, thanks for answering my questions.

I'll try to= simplify the discussion by splitting ongoing discussion into separate thre= ads.
I'll leave the subject unmodified, and hopefully modern = mail readers can cope with the references.

Brian

On Thu, Jun 28,= 2012 at 9:36 PM, UTTARO, JAMES <ju1738@att.com> wrote:

Brian,

=A0<= /p>

=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 Appreciate your comments. Comments In-Line..

=A0<= /p>

Thanks,

=A0<= /p>


=

=A0

This would not have any direct impact to path select= ion, for example, and would fairly trivially support negotiated (based on l= ocal configuration of) timers and "reaping" NLRIs upon timer expi= ry. Behavior per-AFI/SAFI should be able to be specified.

[Jim U>] W= e require the ability to de-pref.=

=A0

<= div>
Can you elaborate?

Who is "= ;we" in this context?

How strict is "req= uire", and can you explain how that is a hard requirement, maybe with = examples of things breaking without de-pref?
Please, more use cases - the more the better. We need to fully underst= and the problem space, with which you are intimately familiar.
If de-pref is not available, is "STALE" still useful?
<= div>
If you are given a choice between "STALE but no de-= pref" or "nothing", would "STALE but no de-pref" b= e acceptable?

(Currently you have "nothing", and are asking= for "STALE *and* de-pref". I just want to be sure I understand t= he situation. I believe you could get session-level STALE for the asking, w= ith no opposition, as long as there is no behavior modification or auto-dep= ref mandated. I.e., if the behavior was, "negotiate option PERSISTENCE= . if SESSION.PERSISTENCE && BGP_SESSION_DROPPED, add community STAL= E, push the 'update-it' button which then triggers out-bound route-= maps et al", then I think you could get this through WGLC in 30 days o= r less.)

=A0

Not needing to change the content or format of UPDAT= Es should be seen as a goal, rather than the other way round.=

[Jim U>] ?=

=A0

<= div>
A negotiated option, call it "PERSIST", would = mean that your PE1 peerings with RR1 and RR2, if negotiated, would keep the= routes learned if the BGP sessions dropped. Presume that in addition to &q= uot;PERSIST" that the peers also negotiate a "PERSIST_TIMER"= .

In order to do that, the CAPABILITY_NEGOTIATE codes nee= d to be defined, but beyond the OPEN, there is no change to the on-the-wire= protocol or to the path-selection process. The only additional code change= needed would be the implicit withdrawal when a BGP peer drops.

Contrast that, from the perspective of multiple impleme= nters, of all the mechanics involved in checking each UPDATE for the presen= ce of STALE or DO_NOT_PERSIST communities, and hard-coding modifications to= behavior that already involves so many moving parts.
(Believe me - I've done severe hacking on, e.g. quagga, and while = it is solid code, the complexity in it, which is informed directly by the p= lethora of BGP RFCs, makes it a huge challenge to try to do "big"= changes to it on a whole cloth basis. Getting those right and debugging th= em are highly non-trivial. Now hand that to vendors who have trouble managi= ng their own hardware drivers and code trains, with massive teams of develo= pers. This needs to interoperate, right? And be stable code serving a lot o= f customers?)

Minimizing the number of places that already-complex lo= gic needs to be tweaked, and then looking at corner cases where those might= or might not overlap (in the code, not in the UPDATE data, that is)... If = the benefits (of your proposal) are only seen in corner cases, and if the b= enefits can maybe be achieved via other means (voluntary COMMUNITY processi= ng via route-maps, plus maybe the setting of a STALE well-known community i= f/when a session drops), then would you be willing to consider the simpler = solution?

(It might help to try to take what I've suggested a= nd draw it out on a white board. See if you can make sense of it and make i= t work, even if you have to do post-processing stuff in route-maps. The que= stion is, does it provide sufficient mechanisms to achieve the design goals= ?)


Sincerely,
Brian Dickson

=A0


--f46d0438904192dbcc04c3939ffc-- From brian.peter.dickson@gmail.com Thu Jun 28 20:30:36 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5712411E8132 for ; Thu, 28 Jun 2012 20:30:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oJRHCh9pnCGz for ; Thu, 28 Jun 2012 20:30:35 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 255B911E811C for ; Thu, 28 Jun 2012 20:30:34 -0700 (PDT) Received: by eaaq13 with SMTP id q13so1161598eaa.31 for ; Thu, 28 Jun 2012 20:30:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tA6Fb5Nq8raJVe44qU8VlUt16OTlRpOJEX7G77WklNw=; b=xd7k+eHc2cuojgiPXcSQl7GXsFwAHHgx7U5YWgMLeh4sYy92useBAi5PeigVff8opx bj1yC8NTfraJoKGEUnCJaVYtSpPRwhH7Gk3YK+YSqoW9D5+u5XJNeCzI6H2VIoi1uCsC eiwEL+4RXnWYWXX4kBfE6FdUBI7Sbmc26nYVL19hNPspK8m6VrLMaKVVZN7kOnzgNog+ Ea2jTC7I30oHlD8b3+WzbHFN4K6K3gCDu76VDg6SrfN6FBTQ1nG8yXwHAZ7pqgPvlIwX u6VdWBOnCn+zczL02X/PDY7c46+0ZqDlmGfoPZnkkkbuSUl7UlSSxrITE9wmeDk7J7bf P8BA== MIME-Version: 1.0 Received: by 10.180.97.135 with SMTP id ea7mr1397512wib.11.1340940634250; Thu, 28 Jun 2012 20:30:34 -0700 (PDT) Received: by 10.223.39.19 with HTTP; Thu, 28 Jun 2012 20:30:34 -0700 (PDT) In-Reply-To: References: <14C7F4F06DB5814AB0DE29716C4F6D6702DF7129F6@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <4FE623B3.4060906@raszuk.net> <20120625070729.GC21620@juniper.net> <94135843-5EF1-4B4A-9CA3-885A4088A762@castlepoint.net> Date: Thu, 28 Jun 2012 23:30:34 -0400 Message-ID: From: Brian Dickson To: "UTTARO, JAMES" Content-Type: multipart/alternative; boundary=f46d043bdb4e2b5f2d04c394124e Cc: Shane Amante , Robert Raszuk , "idr@ietf.org List" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 03:30:36 -0000 --f46d043bdb4e2b5f2d04c394124e Content-Type: text/plain; charset=ISO-8859-1 Second sub-thread... Thanks for discussing these issues/questions. Brian On Thu, Jun 28, 2012 at 9:36 PM, UTTARO, JAMES wrote: > Brian,**** > > ** ** > > Appreciate your comments. Comments In-Line..**** > > ** ** > > Thanks,**** > > Jim Uttaro**** > > > ** ** > > Which BGP sessions are presumed to go away, i.e. where Persistence will > make a difference (or fix a problem you're seeing)?**** > > Is it the case that *both* PE1-RR1 *and* PE1-RR2 BGP sessions fail > simultaneously?**** > > *[Jim U>] Not simultaneously.. For this use case the PE is peered to a > cluster of RRs.. If there is a loss of connectivity from the PE to the > Cluster then Persistence would kick in..* > Does this mean that the cluster of RRs are in one place, where the reachability of the RRs is in a "shared fate" scenario? (It's less severe than "single point of failure", but less diverse/survivable than "fully dispersed, topologically/geographically diverse RRs".) Loss of connectivity to the Cluster => simultaneous BGP session failures. The consequence is the same, regardless of cause. Simultaneous failures of BGP sessions. If the network design (single cluster of RRs) is at fault, while yes, Persistence would help, it is definitely a corner case. If you don't have an upper bound on network issues, how can you set (apriori) the values on your timers for persistence? Or would they need to be settable unilaterally on the PE? Is there a fundamental property of the Cluster, that means you can't have two Clusters to avoid the issue? And, to be clear, the problem is not on the PE end per se, or simultaneous bugs hitting RR1 and RR2, it is a network isolation thing between PE1 and RR1/RR2, that is the frequent and problematic root issue for the problems you are having in your L2VPNs? Thanks, Brian --f46d043bdb4e2b5f2d04c394124e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Second sub-thread...

Thanks for discussing these issues/= questions.

Brian

On Thu, Jun 28, 2012 at 9:36 PM, UTTARO, JAMES <ju1738@att.com> wrote:

Brian,

=A0<= /p>

=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 Appreciate your comments. Comments In-Line..

=A0<= /p>

Thanks,


=A0

Which BGP sessions are presumed to go away, i.e. whe= re Persistence will make a difference (or fix a problem you're seeing)?=

Is it the case that *both* PE1-RR1 *and* PE1-RR2 BGP= sessions fail simultaneously?

[Jim U>] N= ot simultaneously.. For this use case the PE is peered to a cluster of RRs.= . If there is a loss of connectivity from the PE to the Cluster then Persistence would kick in..


Does this mean that the cluster of RRs are in = one place, where the reachability of the RRs is in a "shared fate"= ; scenario? (It's less severe than "single point of failure",= but less diverse/survivable than "fully dispersed, topologically/geog= raphically diverse RRs".)

Loss of connectivity to the Cluster =3D> simultaneou= s BGP session failures.

The consequence is the sam= e, regardless of cause. Simultaneous failures of BGP sessions.

If the network design (single cluster of RRs) is at fault, w= hile yes, Persistence would help, it is definitely a corner case. If you do= n't have an upper bound on network issues, how can you set (apriori) th= e values on your timers for persistence? Or would they need to be settable = unilaterally on the PE?

Is there a fundamental property of the Cluster, that me= ans you can't have two Clusters to avoid the issue?

And, to be clear, the problem is not on the PE end per se, or simulta= neous bugs hitting RR1 and RR2, it is a network isolation thing between PE1= and RR1/RR2, that is the frequent and problematic root issue for the probl= ems you are having in your L2VPNs?

Thanks,
Brian
--f46d043bdb4e2b5f2d04c394124e-- From jakob.heitz@ericsson.com Thu Jun 28 23:49:32 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95BC011E80D9 for ; Thu, 28 Jun 2012 23:49:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.475 X-Spam-Level: X-Spam-Status: No, score=-6.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OmO25qLsD0VG for ; Thu, 28 Jun 2012 23:49:32 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id F060111E80CB for ; Thu, 28 Jun 2012 23:49:31 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q5T6nTJW007385 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 29 Jun 2012 01:49:29 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.215]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Fri, 29 Jun 2012 02:49:29 -0400 From: Jakob Heitz To: "John G.Scudder" Date: Fri, 29 Jun 2012 02:49:27 -0400 Thread-Topic: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks Thread-Index: Ac1VZXLoKSIN6WpFS4CHWsOODZgw8gAXHIGQ Message-ID: <7309FCBCAE981B43ABBE69B31C8D21392438303D1D@EUSAACMS0701.eamcs.ericsson.se> References: <003c01cd4b29$97d7b150$c78713f0$@ndzh.com> <985EF8D2-DA8A-4BE7-94D3-F4BE2B74D768@castlepoint.net> <4FE07A24.7050804@raszuk.net> <1C1F2B2E-2EB7-42F0-8CFF-57965443C074@castlepoint.net> <7A614998-8FB1-4A51-9937-DE501FF31EB6@juniper.net> <4FE0D1F4.9070208@cisco.com> <4FE0E074.3070905@raszuk.net> <17490_1340180565_4FE18855_17490_15423_1_53C29892C857584299CBF5D05346208A0928AA@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FE18A61.8000405@raszuk.net> <8ED5B0B0F5B4854A912480C1521F973AD95B@xmb-rcd-x13.cisco.com> <4FE4A8F3.20809@cisco.com> <7309FCBCAE981B43ABBE69B31C8D213921C23CA154@EUSAACMS0701.eamcs.ericsson.se> 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 Cc: "idr@ietf.org" , "UTTARO, JAMES" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 06:49:32 -0000 On Thursday, June 28, 2012 12:31 PM, John G.Scudder wrote: > Jakob, >=20 > On Jun 22, 2012, at 1:46 PM, Jakob Heitz wrote: >=20 >> [Jakob Heitz] SUSPECT is entirely different to low preference. >> A low preference path exists. A SUSPECT path may not exist. >>=20 >> A less specific path (shorter netmask) exists and will forward >> packets,=20 >> unless it is the default route or also SUSPECT. >=20 > If by "will forward packets" you mean "... to their intended > destination" this is not generally correct. Consider the use of > more-specifics for prefix portability from one provider to another. > The provider that supplied the prefix continues to own and advertise > the supernet, but no longer provides service to their dear departed > customer. =20 Thanks John. Makes sense. Thus, we can not depref these SUSPECT paths against other paths that may exist (the less specific ones). --=20 Jakob Heitz.= From bruno.decraene@orange.com Fri Jun 29 02:05:52 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E33421F86F2 for ; Fri, 29 Jun 2012 02:05:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.49 X-Spam-Level: X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VeCVYLeoVAtR for ; Fri, 29 Jun 2012 02:05:46 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 377A121F8726 for ; Fri, 29 Jun 2012 02:05:46 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 4CA5C264228; Fri, 29 Jun 2012 11:05:45 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 2C8D44C0A6; Fri, 29 Jun 2012 11:05:45 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Fri, 29 Jun 2012 11:05:41 +0200 From: To: Brian Dickson Thread-Topic: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks Thread-Index: AQHNVaMQS0pml8mKGk21k8ZXHsrW+pcQ7m0w Date: Fri, 29 Jun 2012 09:05:40 +0000 Message-ID: <2851_1340960745_4FED6FE9_2851_9521_1_53C29892C857584299CBF5D05346208A0A41E4@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <14C7F4F06DB5814AB0DE29716C4F6D6702DF7129F6@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <4FE623B3.4060906@raszuk.net> <20120625070729.GC21620@juniper.net> <94135843-5EF1-4B4A-9CA3-885A4088A762@castlepoint.net> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.5] Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A0A41E4PEXCVZYM11corpora_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.6.29.74222 Cc: "idr@ietf.org List" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 09:05:52 -0000 --_000_53C29892C857584299CBF5D05346208A0A41E4PEXCVZYM11corpora_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Brian, Thanks for your comments. Comments In-Line [BD] Regards, Bruno From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Brian= Dickson Sent: Friday, June 29, 2012 4:59 AM To: UTTARO, JAMES Cc: Shane Amante; Robert Raszuk; idr@ietf.org List Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document -= 3 more weeks Okay, thanks for answering my questions. I'll try to simplify the discussion by splitting ongoing discussion into se= parate threads. I'll leave the subject unmodified, and hopefully modern mail readers can co= pe with the references. Brian On Thu, Jun 28, 2012 at 9:36 PM, UTTARO, JAMES > wrote: Brian, Appreciate your comments. Comments In-Line.. Thanks, Jim Uttaro This would not have any direct impact to path selection, for example, and w= ould fairly trivially support negotiated (based on local configuration of) = timers and "reaping" NLRIs upon timer expiry. Behavior per-AFI/SAFI should = be able to be specified. [Jim U>] We require the ability to de-pref. Can you elaborate? Who is "we" in this context? How strict is "require", and can you explain how that is a hard requirement= , maybe with examples of things breaking without de-pref? Please, more use cases - the more the better. We need to fully understand t= he problem space, with which you are intimately familiar. If de-pref is not available, is "STALE" still useful? [BD] IMHO Yes. If you are given a choice between "STALE but no de-pref" or "nothing", woul= d "STALE but no de-pref" be acceptable? [BD] IMHO Yes. Because in the end, the remaining part can probably be done by the SP itsel= f using a routemap (e.g. STALE & ! DO_NOT_PERSIST --> SET Local Pref=3D 0; = SET NO_EXPORT) (Currently you have "nothing", and are asking for "STALE *and* de-pref". I = just want to be sure I understand the situation. I believe you could get se= ssion-level STALE for the asking, with no opposition, as long as there is n= o behavior modification or auto-depref mandated. [BD] not sure what you mean by "no behavior modification". There is a signi= ficant change: keep the routes while the BGP session is dead & set STALE co= mmunity I.e., if the behavior was, "negotiate option PERSISTENCE. if SESSION.PERSIS= TENCE && BGP_SESSION_DROPPED, add community STALE, push the 'update-it' but= ton which then triggers out-bound route-maps et al", [BD] within iBGP, IMHO there may not even a need for a negotiation then I think you could get this through WGLC in 30 days or less.) [BD] Looks like not :) But indeed there are a few questions which need to be discussed: - how much is this applicable to all services (or AFI/SAFI) or only specifi= c ones IMHO this relates to how much control/dynamicity we have on the routes. Whi= ch could probably translate in determining a duration which is considered r= elatively safe. Idem GR. Idem this could/should be left to the SP. But inde= ed, if for a service the "right" value is 5 minutes then the benefit is lim= ited. - how much frequent/rare. I.e. does this justify to work on this / change t= he implementation. IMHO Quite personal opinion. No comment. That's about probability. I don't know the future. In some way, a bit simil= ar to insurance policy. - this may be risky. There must be a better solution. Indeed. But this is also a very generic safety net which may b= e expected to catch lots of issues, including the next -not expected- ones.= You're very welcomed to propose a better (complementary or competing) solu= tion. IMHO persistence should not replace more specific solutions focusing = on a specific issue. Not needing to change the content or format of UPDATEs should be seen as a = goal, rather than the other way round. [Jim U>] ? A negotiated option, call it "PERSIST", would mean that your PE1 peerings w= ith RR1 and RR2, if negotiated, would keep the routes learned if the BGP se= ssions dropped. Presume that in addition to "PERSIST" that the peers also n= egotiate a "PERSIST_TIMER". In order to do that, the CAPABILITY_NEGOTIATE codes need to be defined, but= beyond the OPEN, there is no change to the on-the-wire protocol or to the = path-selection process. The only additional code change needed would be the= implicit withdrawal when a BGP peer drops. Contrast that, from the perspective of multiple implementers, of all the me= chanics involved in checking each UPDATE for the presence of STALE or DO_NO= T_PERSIST communities, and hard-coding modifications to behavior that alrea= dy involves so many moving parts. (Believe me - I've done severe hacking on, e.g. quagga, and while it is sol= id code, the complexity in it, which is informed directly by the plethora o= f BGP RFCs, makes it a huge challenge to try to do "big" changes to it on a= whole cloth basis. Getting those right and debugging them are highly non-t= rivial. Now hand that to vendors who have trouble managing their own hardwa= re drivers and code trains, with massive teams of developers. This needs to= interoperate, right? And be stable code serving a lot of customers?) Minimizing the number of places that already-complex logic needs to be twea= ked, and then looking at corner cases where those might or might not overla= p (in the code, not in the UPDATE data, that is)... If the benefits (of you= r proposal) are only seen in corner cases, and if the benefits can maybe be= achieved via other means (voluntary COMMUNITY processing via route-maps, p= lus maybe the setting of a STALE well-known community if/when a session dro= ps), then would you be willing to consider the simpler solution? (It might help to try to take what I've suggested and draw it out on a whit= e board. See if you can make sense of it and make it work, even if you have= to do post-processing stuff in route-maps. The question is, does it provid= e sufficient mechanisms to achieve the design goals?) Sincerely, Brian Dickson ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. --_000_53C29892C857584299CBF5D05346208A0A41E4PEXCVZYM11corpora_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Brian,<= /p>

 <= /p>

Thanks for= your comments.

Comments I= n-Line [BD]

 = ;

Regards,

Bruno=

 = ;

From: idr-boun= ces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Brian Dickson
Sent: Friday, June 29, 2012 4:59 AM
To: UTTARO, JAMES
Cc: Shane Amante; Robert Raszuk; idr@ietf.org List
Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG doc= ument - 3 more weeks

 

Okay, thanks for answering my questions.<= /p>

 

I'll try to simplify the discussion by splitting ong= oing discussion into separate threads.

I'll leave the subject unmodified, and hopefully mod= ern mail readers can cope with the references.

 

Brian

On Thu, Jun 28, 2012 at 9:36 PM, UTTARO, JAMES <<= a href=3D"mailto:ju1738@att.com" target=3D"_blank">ju1738@att.com> w= rote:

Brian,

 

    =             Apprecia= te your comments. Comments In-Line..=

 

Thanks,

Jim Uttaro

 

 

 

This would not have any direct impact to path= selection, for example, and would fairly trivially support negotiated (bas= ed on local configuration of) timers and "reaping" NLRIs upon timer expiry. Behavior per-AFI/SAFI should = be able to be specified.

[Jim U>] We req= uire the ability to de-pref.=

 

 

Can you elaborate?

 

Who is "we" in this context?

 

How strict is "require", and can you expla= in how that is a hard requirement, maybe with examples of things breaking w= ithout de-pref?

Please, more use cases - the more the better. We nee= d to fully understand the problem space, with which you are intimately fami= liar.

 

If de-pref is not available, is "STALE" st= ill useful?

[BD] IMHO = Yes.

 

If you are given a choice between "STALE but no= de-pref" or "nothing", would "STALE but no de-pref&quo= t; be acceptable?

[BD] IMHO = Yes.

Because= in the end, the remaining part can probably be done by the SP itself using= a routemap (e.g. STALE & ! DO_NOT_PERSIST = =E0 SET Local Pref=3D 0= ; SET NO_EXPORT)

 = ;

 = ;

(Currently you have "nothing", and are ask= ing for "STALE *and* de-pref". I just want to be sure I understan= d the situation. I believe you could get session-level STALE for the asking= , with no opposition, as long as there is no behavior modification or auto-depref mandated.

[BD] not s= ure what you mean by “no behavior modification”. There is a sig= nificant change: keep the routes while the BGP session is dead & set ST= ALE community

I.e., if the behavior was, &quo= t;negotiate option PERSISTENCE. if SESSION.PERSISTENCE && BGP_SESSI= ON_DROPPED, add community STALE, push the 'update-it' button which then tri= ggers out-bound route-maps et al",<= /o:p>

[BD] withi= n iBGP, IMHO there may not even a need for a negotiation

 = ;

then I think you could get this= through WGLC in 30 days or less.)

 [BD] Looks like not J

But indeed= there are a few questions which need to be discussed:

- how much= is this applicable to all services (or AFI/SAFI) or only specific ones

IMHO this relates to how much contro= l/dynamicity we have on the routes. Which could probably translate in determining a duration which is considered relatively safe. Idem GR. Id= em this could/should be left to the SP. But indeed, if for a service the &#= 8220;right” value is 5 minutes then the benefit is limited.

- how much= frequent/rare. I.e. does this justify to work on this / change the impleme= ntation.

IMHO Quite personal opinion. No comm= ent.

That’s about probability. I do= n’t know the future. In some way, a bit similar to insurance policy.<= o:p>

- this may= be risky. There must be a better solution.

 &nbs= p;           Indeed. But = this is also a very generic safety net which may be expected to catch lots = of issues, including the next –not expected- ones. You’re very welcomed to propose a better (complementary or com= peting) solution. IMHO persistence should not replace more specific solutio= ns focusing on a specific issue.

Not needing to change the content or format o= f UPDATEs should be seen as a goal, rather than the other way round.

[Jim U>] ?

 

 

A negotiated option, call it "PERSIST", wo= uld mean that your PE1 peerings with RR1 and RR2, if negotiated, would keep= the routes learned if the BGP sessions dropped. Presume that in addition t= o "PERSIST" that the peers also negotiate a "PERSIST_TIMER".

 

In order to do that, the CAPABILITY_NEGOTIATE codes = need to be defined, but beyond the OPEN, there is no change to the on-the-w= ire protocol or to the path-selection process. The only additional code cha= nge needed would be the implicit withdrawal when a BGP peer drops.

 

Contrast that, from the perspective of multiple impl= ementers, of all the mechanics involved in checking each UPDATE for the pre= sence of STALE or DO_NOT_PERSIST communities, and hard-coding modifications= to behavior that already involves so many moving parts.

(Believe me - I've done severe hacking on, e.g. quag= ga, and while it is solid code, the complexity in it, which is informed dir= ectly by the plethora of BGP RFCs, makes it a huge challenge to try to do &= quot;big" changes to it on a whole cloth basis. Getting those right and debugging them are highly non-trivial. Now = hand that to vendors who have trouble managing their own hardware drivers a= nd code trains, with massive teams of developers. This needs to interoperat= e, right? And be stable code serving a lot of customers?)

 

Minimizing the number of places that already-complex= logic needs to be tweaked, and then looking at corner cases where those mi= ght or might not overlap (in the code, not in the UPDATE data, that is)... = If the benefits (of your proposal) are only seen in corner cases, and if the benefits can maybe be achieved v= ia other means (voluntary COMMUNITY processing via route-maps, plus maybe t= he setting of a STALE well-known community if/when a session drops), then w= ould you be willing to consider the simpler solution?

 

(It might help to try to take what I've suggested an= d draw it out on a white board. See if you can make sense of it and make it= work, even if you have to do post-processing stuff in route-maps. The ques= tion is, does it provide sufficient mechanisms to achieve the design goals?)



Sincerely,
Brian Dickson

 

 

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete al=
tere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for message=
s that have been modified, changed or falsified.
Thank you.
--_000_53C29892C857584299CBF5D05346208A0A41E4PEXCVZYM11corpora_-- From stbryant@cisco.com Fri Jun 29 04:06:21 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF04021F8705 for ; Fri, 29 Jun 2012 04:06:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.556 X-Spam-Level: X-Spam-Status: No, score=-110.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BFsfE4vEA5L7 for ; Fri, 29 Jun 2012 04:06:21 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id EAD3221F86E2 for ; Fri, 29 Jun 2012 04:06:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=2159; q=dns/txt; s=iport; t=1340967981; x=1342177581; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=mhfWXCNa44jU8f5qni9A3afnCJq1Y+E/703cR8AQsaE=; b=BkR5S3GwB7CmEEly8TxeB2L3C65R08EKeL8aUqRwV/ohLKNHE22IP6QD smJxYLBXDGvqz1ojpfqCvpJmk+MPrcAm5pmWN9ximpF4bq0ZRTZpkzfdb n88zivnfsYXXQ9Ok70/8euEx+CqWT2wTupEtMUM9EbHdZNbVEbzvcBy1g U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EANyK7U+rRDoJ/2dsb2JhbABFtkuBB4IYAQEBBBIBAiMvBwoBEAsOCgkWBAsJAwIBAgFFBg0BBQIBAR6HaAGZS4NIEJ0LizeGCgOVMo4dgQRigmCBXg X-IronPort-AV: E=Sophos;i="4.77,497,1336348800"; d="scan'208";a="50563133" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 29 Jun 2012 11:06:20 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q5TB6IQh019595 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Jun 2012 11:06:20 GMT Received: from stbryant-mac2.lan (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id q5TB6HLT003331; Fri, 29 Jun 2012 12:06:17 +0100 (BST) Message-ID: <4FED8C28.4090404@cisco.com> Date: Fri, 29 Jun 2012 12:06:16 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Claudio Jeker References: <20120601185444.8409.85777.idtracker@ietfa.amsl.com> <20120601220000.GB9448@diehard.n-r-g.com> In-Reply-To: <20120601220000.GB9448@diehard.n-r-g.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr@ietf.org Subject: Re: [Idr] Last Call: (BGP Support for Four-octet AS Number Space) to Proposed Standard X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 11:06:22 -0000 On 01/06/2012 23:00, Claudio Jeker wrote: > On Fri, Jun 01, 2012 at 11:54:44AM -0700, The IESG wrote: >> The IESG has received a request from the Inter-Domain Routing WG (idr) to >> consider the following document: >> - 'BGP Support for Four-octet AS Number Space' >> as Proposed Standard >> >> The IESG plans to make a decision in the next few weeks, and solicits >> final comments on this action. Please send substantive comments to the >> ietf@ietf.org mailing lists by 2012-06-15. Exceptionally, comments may be >> sent to iesg@ietf.org instead. In either case, please retain the >> beginning of the Subject line to allow automated sorting. >> >> Abstract >> >> >> The Autonomous System (AS) number is encoded as a two-octet entity in >> the base BGP specification. This document describes extensions to BGP >> to carry the Autonomous System numbers as four-octet entities. This >> document obsoletes RFC 4893. >> > Just for the sake of clarity, OpenBGPD will not do the following: > > In addition, the path segment types AS_CONFED_SEQUENCE and > AS_CONFED_SET [RFC5065] MUST NOT be carried in the AS4_PATH attribute > of an UPDATE message. A NEW BGP speaker that receives these path > segment types in the AS4_PATH attribute of an UPDATE message from an > OLD BGP speaker MUST discard these path segments, adjust the relevant > attribute fields accordingly, and continue processing the UPDATE > message. This case SHOULD be logged locally for analysis. > > There is no point to do this fiddeling instead we will treat this like any > other parse error of AS4_PATH. > Claudio, Thank you for your email. I see no support for a text change to support this observation, and several emails explaining that original text addresses an observed problem. The IETF process in such circumstances is to declare that the proposed change is in the rough and proceed with the publication. I will therefore continue with the publication process for the document as revised to address the other IETF last call comments. - Stewart From brian.peter.dickson@gmail.com Fri Jun 29 05:45:42 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B0AE21F8653 for ; Fri, 29 Jun 2012 05:45:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aN90jXs4Ge9l for ; Fri, 29 Jun 2012 05:45:41 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 97FA921F8659 for ; Fri, 29 Jun 2012 05:45:40 -0700 (PDT) Received: by wibhm11 with SMTP id hm11so763877wib.13 for ; Fri, 29 Jun 2012 05:45:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8GHRSjiCaYJY9Ws8mTm+riEeuAcv9Fzs/RYaMbo8jwg=; b=rgurht4EkWRLKzTnE+8GulrywSsUyehV2mKn5CfPR7GB48YAGmOU8nXhso+9hDTF4o hJjqO5MoV2EXpu9ZwAtMxvtyENOkKT8hYLv5tnGD4YdunYgHP1pgMff6OsS5dnMpWnMV +CGaOcup6MWljWAWe8DDQBDlInw3ltWSP9RXhUZ9fbjGlFiU4hnAEz2BnowzCVBYzCI/ N/CygnFHLC+Te213fkxzuHVKW0wXqCiqshK1dDhSSkV6ux1OIDVq80zFObPxk9/5dshG E/Omm+ArlIFb52280IbeMLpbaFuwAoLDBdDeJbFlB05jKz54UPNFX29cUZ5EHzYHAd/s +A4A== MIME-Version: 1.0 Received: by 10.180.78.99 with SMTP id a3mr4396712wix.15.1340973939555; Fri, 29 Jun 2012 05:45:39 -0700 (PDT) Received: by 10.223.39.19 with HTTP; Fri, 29 Jun 2012 05:45:39 -0700 (PDT) In-Reply-To: <20120612135455.GC18025@diehard.n-r-g.com> References: <20120601185444.8409.85777.idtracker@ietfa.amsl.com> <20120601220000.GB9448@diehard.n-r-g.com> <4FD71A33.8040901@cisco.com> <20120612135455.GC18025@diehard.n-r-g.com> Date: Fri, 29 Jun 2012 08:45:39 -0400 Message-ID: From: Brian Dickson To: Claudio Jeker Content-Type: multipart/alternative; boundary=f46d0438904151fbba04c39bd39d Cc: idr@ietf.org Subject: Re: [Idr] Last Call: (BGP Support for Four-octet AS Number Space) to Proposed Standard X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 12:45:42 -0000 --f46d0438904151fbba04c39bd39d Content-Type: text/plain; charset=ISO-8859-1 Hi, Caudio, Comments in-line. On Tue, Jun 12, 2012 at 9:54 AM, Claudio Jeker wrote: > On Tue, Jun 12, 2012 at 11:30:11AM +0100, Stewart Bryant wrote: > > On 01/06/2012 23:00, Claudio Jeker wrote: > > >On Fri, Jun 01, 2012 at 11:54:44AM -0700, The IESG wrote: > > >>The IESG has received a request from the Inter-Domain Routing WG (idr) > to > > >>consider the following document: > > >>- 'BGP Support for Four-octet AS Number Space' > > >> as Proposed Standard > > >> > > >>The IESG plans to make a decision in the next few weeks, and solicits > > >>final comments on this action. Please send substantive comments to the > > >>ietf@ietf.org mailing lists by 2012-06-15. Exceptionally, comments > may be > > >>sent to iesg@ietf.org instead. In either case, please retain the > > >>beginning of the Subject line to allow automated sorting. > > >> > > >>Abstract > > >> > > >> > > >> The Autonomous System (AS) number is encoded as a two-octet entity > in > > >> the base BGP specification. This document describes extensions to > BGP > > >> to carry the Autonomous System numbers as four-octet entities. > This > > >> document obsoletes RFC 4893. > > >> > > >Just for the sake of clarity, OpenBGPD will not do the following: > > > > > > In addition, the path segment types AS_CONFED_SEQUENCE and > > > AS_CONFED_SET [RFC5065] MUST NOT be carried in the AS4_PATH > attribute > > > of an UPDATE message. A NEW BGP speaker that receives these path > > > segment types in the AS4_PATH attribute of an UPDATE message from an > > > OLD BGP speaker MUST discard these path segments, adjust the > relevant > > > attribute fields accordingly, and continue processing the UPDATE > > > message. This case SHOULD be logged locally for analysis. > > > > > >There is no point to do this fiddeling instead we will treat this like > any > > >other parse error of AS4_PATH. > > If you read the phrase "be carried in" as "be advertised in", does that help at all? Regardless of the specific cases (known to have happened), it falls under the general rule, "Be liberal in what you receive, and conservative in what you send." If you merely ignore, without stripping *_CONFED_*, you are being liberal in what you send -- which is bad. Feel free to do the stripping on the send side rather than receive, where you already have to munge the attributes (e.g. to add your own AS/AS4 to the path). Does that make it any easier to do? > > I see no reason to enforce AS_CONFED_SEQUENCE and AS_CONFED_SET stripping > on all AS4 implementations. It forces bgp implementations that don't have > confederation support to strip out something that will cause an error in > the regular path and for those systems ignoring the AS4_PATH attribute > is perfectly fine. I do not understand how a workaround needs to be a > MUST for something that is a MUST NOT at the same time? Why MUST we > workaround something that MUST NOT appear? Why do we need to add extra > code that is hard to test and maybe cause for further errors because it > modifies attributes in very uncommon way? > > I propose to remove that paragraph entierly since it does only add > complexity to the protocol for no reason and therefor is only a source of > errors without any benefit. > The assumption that incoming UPDATE messages are completely well-formed has proven to be a poor choice historically. The text above clarifies how to correct a specific error, and avoids the situation, "never check for an error condition you don't know how to handle". By specifying how to handle it, requiring the checking becomes very reasonable, IMHO. BTW - I believe it does not apply to OLD BGP speakers at all, who ignore AS4_PATH. Does that help? Brian --f46d0438904151fbba04c39bd39d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Caudio,

Comments in-line.

On Tue, Jun 12, 2012 at 9:54 AM, Claudio Jeker &l= t;cjeker@dieh= ard.n-r-g.com> wrote:
On T= ue, Jun 12, 2012 at 11:30:11AM +0100, Stewart Bryant wrote:
> On 01/06/2012 23:00, Claudio Jeker wrote:
> >On Fri, Jun 01, 2012 at 11:54:44AM -0700, The IESG wrote:
> >>The IESG has received a request from the Inter-Domain Routing = WG (idr) to
> >>consider the following document:
> >>- 'BGP Support for Four-octet AS Number Space'
> >> =A0 <draft-ietf-idr-rfc4893bis-06.txt> as Proposed Stan= dard
> >>
> >>The IESG plans to make a decision in the next few weeks, and s= olicits
> >>final comments on this action. Please send substantive comment= s to the
> >>ietf@ietf.org mailing lis= ts by 2012-06-15. Exceptionally, comments may be
> >>sent to iesg@ietf.org ins= tead. In either case, please retain the
> >>beginning of the Subject line to allow automated sorting.
> >>
> >>Abstract
> >>
> >>
> >> =A0 =A0The Autonomous System (AS) number is encoded as a two-= octet entity in
> >> =A0 =A0the base BGP specification. This document describes ex= tensions to BGP
> >> =A0 =A0to carry the Autonomous System numbers as four-octet e= ntities. =A0This
> >> =A0 =A0document obsoletes RFC 4893.
> >>
> >Just for the sake of clarity, OpenBGPD will not do the following:<= br> > >
> > =A0 =A0In addition, the path segment types AS_CONFED_SEQUENCE and=
> > =A0 =A0AS_CONFED_SET [RFC5065] MUST NOT be carried in the AS4_PAT= H attribute
> > =A0 =A0of an UPDATE message. =A0A NEW BGP speaker that receives t= hese path
> > =A0 =A0segment types in the AS4_PATH attribute of an UPDATE messa= ge from an
> > =A0 =A0OLD BGP speaker MUST discard these path segments, adjust t= he relevant
> > =A0 =A0attribute fields accordingly, and continue processing the = UPDATE
> > =A0 =A0message. =A0This case SHOULD be logged locally for analysi= s.
> >
> >There is no point to do this fiddeling instead we will treat this = like any
> >other parse error of AS4_PATH.


If you read the phrase &qu= ot;be carried in" as "be advertised in", does that help at a= ll?

Regardless of the specific cases (known to hav= e happened), it falls under the general rule,
"Be liberal in what you receive, and conservative in what you sen= d."

If you merely ignore, without stripping *= _CONFED_*, you are being liberal in what you send -- which is bad.

Feel free to do the stripping on the send side rather t= han receive, where you already have
to munge the attributes (e.g.= to add your own AS/AS4 to the path).

Does that ma= ke it any easier to do?
=A0

I see no reason to enforce AS_CONFED_SEQUENCE and AS_CONFED_SET= stripping
on all AS4 implementations. It forces bgp implementations that don't ha= ve
confederation support to strip out something that will cause an error in the regular path and for those systems ignoring the AS4_PATH attribute
is perfectly fine. I do not understand how a workaround needs to be a
MUST for something that is a MUST NOT at the same time? Why MUST we
workaround something that MUST NOT appear? Why do we need to add extra
code that is hard to test and maybe cause for further errors because it
modifies attributes in very uncommon way?

I propose to remove that paragraph entierly since it does only add
complexity to the protocol for no reason and therefor is only a source of errors without any benefit.

The assumpt= ion that incoming UPDATE messages are completely well-formed has proven to = be a poor choice historically.

The text above clar= ifies how to correct a specific error, and avoids the situation,
"never check for an error condition you don't know how to han= dle".

By specifying how to handle it, requiri= ng the checking becomes very reasonable, IMHO.

BTW - I believe it does not apply to OLD BGP speakers at all, who ignore AS= 4_PATH. Does that help?

Brian=A0

--f46d0438904151fbba04c39bd39d-- From jgs@juniper.net Fri Jun 29 07:36:22 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A78B321F8699 for ; Fri, 29 Jun 2012 07:36:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.47 X-Spam-Level: X-Spam-Status: No, score=-6.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id quAkqzxrkEzZ for ; Fri, 29 Jun 2012 07:36:22 -0700 (PDT) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by ietfa.amsl.com (Postfix) with ESMTP id 3713121F8769 for ; Fri, 29 Jun 2012 07:36:16 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKT+29Xt1Y0v2bX/e0gQThyoBWU9t0oWjk@postini.com; Fri, 29 Jun 2012 07:36:21 PDT Received: from [172.16.13.202] (172.16.13.202) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server id 8.3.213.0; Fri, 29 Jun 2012 07:35:46 -0700 MIME-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset="iso-8859-1" From: "John G. Scudder" In-Reply-To: <4FECC427.30609@raszuk.net> Date: Fri, 29 Jun 2012 10:35:45 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <0415D044-D1A2-496D-A033-8F2ECD6CFF8A@juniper.net> References: <003c01cd4b29$97d7b150$c78713f0$@ndzh.com> <985EF8D2-DA8A-4BE7-94D3-F4BE2B74D768@castlepoint.net> <4FE07A24.7050804@raszuk.net> <1C1F2B2E-2EB7-42F0-8CFF-57965443C074@castlepoint.net> <7A614998-8FB1-4A51-9937-DE501FF31EB6@juniper.net> <4FE0D1F4.9070208@cisco.com> <4FE0E074.3070905@raszuk.net> <17490_1340180565_4FE18855_17490_15423_1_53C29892C857584299CBF5D05346208A0928AA@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FE18A61.8000405@raszuk.net> <4FE46DF7.20906@raszuk.net> <71761B19-5AA1-4279-98A7-10956365185A@juniper.net> <4FECC427.30609@raszuk.net> To: "robert@raszuk.net" X-Mailer: Apple Mail (2.1278) Cc: "idr@ietf.org" , "bruno.decraene@orange.com" , Shane Amante , "UTTARO, JAMES" , Susan Hares Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 14:36:22 -0000 Yes. I was specifically referring to "keep the session up even if some = errors which would trigger it down are received", which I took to mean = the error handling draft and related work.=20 Graceful Restart can indeed address transport-and-below issues, but then = we need to review the discussion of the specific differences between = persistence and GR, notably the decision to withhold any signaling about = the outage (GR) vs. depreffing the stale routes (persistence) and the = applicability of the respective strategies given different time windows. = I don't have anything new to say about that. --John On Jun 28, 2012, at 4:52 PM, Robert Raszuk wrote: > Hi John, >=20 > Consider GR. >=20 > If on the restarting speaker BGP sessions go down due to TCP bug or=20 > TCP-BGP interaction bug wouldn't receiving speaker apply BGP GR = procedure ? >=20 > R. >=20 >> On Jun 22, 2012, at 9:07 AM, Robert Raszuk wrote: >>=20 >>> Last .. the session down event while BGP process is still healthy = and >>> running is being addressed by various other proposals in IDR and = GROW >>> which do target opposite solution .. keep the session up even if = some >>> errors which would trigger it down are received. >>=20 >> None of these address a problem at or below the transport level, = though. The conversation so far has largely neglected this point. >>=20 >> --John >>=20 >=20 >=20 From ju1738@att.com Fri Jun 29 10:44:46 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9000821F8811 for ; Fri, 29 Jun 2012 10:44:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.032 X-Spam-Level: X-Spam-Status: No, score=-106.032 tagged_above=-999 required=5 tests=[AWL=-0.034, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DiRM+POBla1P for ; Fri, 29 Jun 2012 10:44:41 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id A175321F87E2 for ; Fri, 29 Jun 2012 10:44:40 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO nbfkord-smmo07.seg.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.11.0-10) with ESMTP id 889edef4.75215940.172885.00-568.472131.nbfkord-smmo07.seg.att.com (envelope-from ); Fri, 29 Jun 2012 17:44:40 +0000 (UTC) X-MXL-Hash: 4fede9885efe3061-a69c94b09ffc13b52a2af7a05a11444970e4d0d9 Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.11.0-10) over TLS secured channel with ESMTP id b59edef4.0.172669.00-356.471496.nbfkord-smmo07.seg.att.com (envelope-from ); Fri, 29 Jun 2012 17:44:11 +0000 (UTC) X-MXL-Hash: 4fede96b19a750d4-0b3da8770a8c13115e504a204582287c109fe298 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q5THhtIf016831; Fri, 29 Jun 2012 13:43:55 -0400 Received: from sflint01.pst.cso.att.com (sflint01.pst.cso.att.com [144.154.234.228]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q5THhoGg016793 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Jun 2012 13:43:51 -0400 Received: from MISOUT7MSGHUB9E.ITServices.sbc.com (misout7msghub9e.itservices.sbc.com [144.151.223.61]) by sflint01.pst.cso.att.com (RSA Interceptor); Fri, 29 Jun 2012 13:43:34 -0400 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9E.ITServices.sbc.com ([144.151.223.61]) with mapi id 14.02.0298.004; Fri, 29 Jun 2012 13:43:34 -0400 From: "UTTARO, JAMES" To: "'Shane Amante'" Thread-Topic: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks Thread-Index: AQHNVJ1Cc8ZsEmmpxEWbTJxs6Wew15cQ08GAgAC46wA= Date: Fri, 29 Jun 2012 17:43:34 +0000 Message-ID: References: <14C7F4F06DB5814AB0DE29716C4F6D6702DF7129F6@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <4FE623B3.4060906@raszuk.net> <20120625070729.GC21620@juniper.net> <94135843-5EF1-4B4A-9CA3-885A4088A762@castlepoint.net> <84158396-59E4-478B-822C-02F0F42402C3@castlepoint.net> <8B32FB6E-EC5F-42BA-9553-B2755E517B4D@castlepoint.net> In-Reply-To: <8B32FB6E-EC5F-42BA-9553-B2755E517B4D@castlepoint.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.20.193] Content-Type: multipart/alternative; boundary="_000_B17A6910EEDD1F45980687268941550FB30EE9MISOUT7MSGUSR9IIT_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=1.0 c=1 a=VZVp10EGlooA:10 a=ZQD3OTTxKqYA:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a=XK] X-AnalysisOut: [fbYx4oAAAA:8 a=48vgC7mUAAAA:8 a=doUQZJtgAAAA:8 a=YF-yWaXEA] X-AnalysisOut: [AAA:8 a=ljfNB86AAAAA:8 a=-VZgrAQ3AN0g_PZNo5kA:9 a=CjuIK1q_] X-AnalysisOut: [8ugA:10 a=dqPZvQn0m_wA:10 a=uI1Or78iWTcA:10 a=lZB815dzVvQA] X-AnalysisOut: [:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=gKO2Hq4RSVkA:10 a=] X-AnalysisOut: [UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10] Cc: "idr@ietf.org List" , Robert Raszuk Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 17:44:46 -0000 --_000_B17A6910EEDD1F45980687268941550FB30EE9MISOUT7MSGUSR9IIT_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Shane, I agree, there will be applications that use the internet = service requiring persistence and I believe the technical specification BGP= Persistence should be used.. That being said there are unique challenges t= hat come to mind: a) Advertisements.. When Persistence is active, a speaker cannot inform the= topology of changes to the state.. For static services i.e L2VPN, or L3VPN= which is considered less dynamic than the internet this inability is a goo= d tradeoff as we know the state does not change often and therefore the inc= orrectness will be minimal. Regardless the customer would have the ability = to DO_NOT _PERSIST state.. b) IMO Persistence is most applicable where forwarding and control plane ar= e decoupled.. Not an internet person but in the case where a speaker is a N= H for paths and advertiser for those paths is it an appropriate topology fo= r Persistence?? I may be wrong, to be honest I have not considered the int= ernet use case enough to be sure.. c) From the responses on the forum it is clear that there are very strong f= eelings in re changing the behavior in the internet.. Too be honest I felt = that the discussions would become religious if the internet was included . = I really want to advance this draft for a number of applications where I do= not have alternative paths via other peering points, and the state is quit= e static. I in no way meant to infer that the internet was a "lesser citizen" I was o= nly attempting to convey that there is a requirement for Persistence for ot= her services which has never been a requirement for the Internet use case.= I believe that the services over the internet ( As you point out below ) w= ill require Persistence. Jim Uttaro From: Shane Amante [mailto:shane@castlepoint.net] Sent: Thursday, June 28, 2012 10:15 PM To: UTTARO, JAMES Cc: Senad .Palislamovic; idr@ietf.org List; Robert Raszuk Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document -= 3 more weeks Jim, On Jun 28, 2012, at 5:58 PM, UTTARO, JAMES wrote: Shane, I have significant concerns wrt (b), in particular your last sentence above= . More specifically, this is the IDR WG, where the charter currently state= s: ---snip--- The main objective of the working group is to support the use of BGP-4 by IP version 4 and IP version 6 networks. The working group will also continue to work on improving the robustness and scalability of BGP. ---snip--- IMHO, both sentences appear to state that the WG should focus on developing= the robustness and scalability of BGP for all types of networks, not just = VPN networks. As such, it may be prudent for the WG to consider acknowledg= ing this is a problem with the _architecture_ of BGP, applicable to all AFI= /SAFI's, and diligently work toward a single solution that addresses this p= roblem in a comprehensive and consistent manner across all AFI/SAFI's. Jim U> I believe that different use cases require different behaviors. Ther= e is simply no way of getting around this.. As I stated in my ex.. Flowspec= is a method of creating configuration via BGP.. This should persist as if = it was programmed via XML, etc... I always want robustness and scalability= but certain AFs require more than this. I think the charter should to be a= mended to accomodate the different use cases for BGP and where they diverge= in terms of behavior, customer expectations and solutions, or at minimum t= ry to operate from a framework that acknowledges these use cases and their = different requirements. I'm not sure why you believe that the Internet should be treated as a "less= er citizen" in the context of requirements related to the robustness of BGP= . As a case in point, on the Internet, there exists a variety of OTT VoIP = services, (e.g.: Vonage, Ooma, MagicJack, etc.), over which E911 services a= re provided. That seems like a pretty critical application. In addition, I'm not sure if you're aware (my apologies if you are), but re= cently the FCC here in the U.S., has started having discussions of setting = a date for sunsetting the PSTN, which presumably means more customers would= get pushed into using VoIP (of some form, whether as a service of their IS= P or OTT) -or- mobile/cell phones: (Please note the following is a link to a Word doc on the FCC's Web site, I= could not find a link to a HTML version): http://transition.fcc.gov/oet/tac/tacdocs/meeting92711/Sun-Setting_the_PSTN= _Paper_V03.docx The following is a link to a blog post summarizing the Word doc: http://blog.connectedplanetonline.com/unfiltered/2011/07/07/fcc-considering= -exploring-end-dates-for-the-pstn/ Interestingly enough, AT&T has apparently been requesting this of the FCC s= ince, at least, back in 2009: http://www.pcworld.com/businesscenter/article/185649/atandt_tells_fcc_its_t= ime_to_cut_the_cord.html Certainly there are other applications on the Internet that will likely eme= rge over time, which also will demand similar high availability/robustness = of Internet service. Thus, I say, let's take the opportunity now to find a= common solution to a fundamental architectural problem of BGP, which will = ultimately benefit all SP's and users of their services. -shane --_000_B17A6910EEDD1F45980687268941550FB30EE9MISOUT7MSGUSR9IIT_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Shane,<= /p>

 <= /p>

    &= nbsp;           I agree, =  there will be applications that use the internet service requiring pe= rsistence and I believe the technical specification BGP Persistence should be used.. That being said there are unique challenges that come to = mind:

 <= /p>

a) Advertisements.. When = Persistence is active, a speaker cannot inform the topology of changes to t= he state.. For static services i.e L2VPN, or L3VPN which is considered less dynamic than the internet this inability is a good trad= eoff as we know the state does not change often and therefore the incorrect= ness will be minimal. Regardless the customer would have the ability to DO_= NOT _PERSIST state..

 <= /p>

b) IMO Persistence is mos= t applicable where forwarding and control plane are decoupled.. Not an inte= rnet person but in the case where a speaker is a NH for paths and advertiser for those paths is it an appropriate topology for Per= sistence??  I may be wrong, to be honest I have not considered the int= ernet use case enough to be sure..

 <= /p>

c) From the responses on = the forum it is clear that there are very strong feelings in re changing th= e behavior in the internet.. Too be honest I felt that the discussions would become religious if the internet was included . I really= want to advance this draft for a number of applications where I do not hav= e alternative paths via other peering points, and the state is quite static= .

 <= /p>

I in no way meant to infe= r that the internet was a “lesser citizen” I was only attemptin= g to convey that there is a requirement for Persistence for other services which has never been  a requirement for the Internet use case. I beli= eve that the services over the internet ( As you point out below ) will req= uire Persistence.

 <= /p>

Jim Uttaro

 <= /p>

From: Shane Am= ante [mailto:shane@castlepoint.net]
Sent: Thursday, June 28, 2012 10:15 PM
To: UTTARO, JAMES
Cc: Senad .Palislamovic; idr@ietf.org List; Robert Raszuk
Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG doc= ument - 3 more weeks

 

Jim,

 

On Jun 28, 2012, at 5:58 PM, UTTARO, JAMES wrote:

Shane,=

 <= /p>

I have significant concerns wrt (b), in particular y= our last sentence above.  More specifically, this is the IDR WG, = where the charter currently states:

---snip---

    The main objective of the working grou= p is to support the use of

    BGP-4 by IP version 4 and IP version 6= networks. The working group

    will also continue to work on improvin= g the robustness and

    scalability of BGP.

---snip---

IMHO, both sentences appear to state that the WG sho= uld focus on developing the robustness and scalability of BGP for all types= of networks, not just VPN networks.  As such, it may be prudent for t= he WG to consider acknowledging this is a problem with the _architecture_ of BGP, applicable to all AFI/SAFI's, an= d diligently work toward a single solution that addresses this problem in a= comprehensive and consistent manner across all AFI/SAFI's.

 

Jim U> I believe= that different use cases require different behaviors. There is simply no w= ay of getting around this.. As I stated in my ex.. Flowspec is a method of = creating configuration via BGP.. This should persist as if it was programmed via XML, etc…  I always want ro= bustness and scalability but certain AFs require more than this. I think th= e charter should to be amended to accomodate the different use cases for BG= P and where they diverge in terms of behavior, customer expectations and solutions, or at minimum try to operate from a f= ramework that acknowledges these use cases and their different requirements= .

 

I'm not sure why you believe that the Internet shoul= d be treated as a "lesser citizen" in the context of requirements= related to the robustness of BGP.  As a case in point, on the Interne= t, there exists a variety of OTT VoIP services, (e.g.: Vonage, Ooma, MagicJack, etc.), over which E911 services are provided. &nb= sp;That seems like a pretty critical application.

 

In addition, I'm not sure if you're aware (my apolog= ies if you are), but recently the FCC here in the U.S., has started having = discussions of setting a date for sunsetting the PSTN, which presumably mea= ns more customers would get pushed into using VoIP (of some form, whether as a service of their ISP or OTT) -= or- mobile/cell phones:

(Please note the following is a link to a Word doc o= n the FCC's Web site, I could not find a link to a HTML version):

The following is a link to a blog post summarizing t= he Word doc:

 

Interestingly enough, AT&T has apparently been r= equesting this of the FCC since, at least, back in 2009:

 

Certainly there are other applications on the Intern= et that will likely emerge over time, which also will demand similar high a= vailability/robustness of Internet service.  Thus, I say, let's take t= he opportunity now to find a common solution to a fundamental architectural problem of BGP, which will ultimately benef= it all SP's and users of their services.

 

-shane

--_000_B17A6910EEDD1F45980687268941550FB30EE9MISOUT7MSGUSR9IIT_-- From ju1738@att.com Fri Jun 29 10:50:43 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBCF321F8828 for ; Fri, 29 Jun 2012 10:50:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.331 X-Spam-Level: X-Spam-Status: No, score=-106.331 tagged_above=-999 required=5 tests=[AWL=0.268, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NVqF1WGfyU+1 for ; Fri, 29 Jun 2012 10:50:43 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id 27A4C21F8726 for ; Fri, 29 Jun 2012 10:50:43 -0700 (PDT) Received: from unknown [144.160.128.153] (EHLO nbfkord-smmo05.seg.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.11.0-10) with ESMTP id 3faedef4.2aaacf80b940.1495589.00-582.4147749.nbfkord-smmo05.seg.att.com (envelope-from ); Fri, 29 Jun 2012 17:50:43 +0000 (UTC) X-MXL-Hash: 4fedeaf3152d39a0-0f2cd656d0f5d824dfa56883257270367d5dca0f Received: from unknown [144.160.128.153] (EHLO flpi408.enaf.ffdc.sbc.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.11.0-10) over TLS secured channel with ESMTP id ecaedef4.0.1495308.00-365.4146927.nbfkord-smmo05.seg.att.com (envelope-from ); Fri, 29 Jun 2012 17:50:21 +0000 (UTC) X-MXL-Hash: 4fedeadd7030a525-f1101bca7e271a80837ff9bc0e554a1810fbf95a Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q5THo5RC021652; Fri, 29 Jun 2012 10:50:06 -0700 Received: from fflint04.pst.cso.att.com (fflint04.pst.cso.att.com [150.234.39.64]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q5THnv7j021509 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Jun 2012 10:49:58 -0700 Received: from MISOUT7MSGHUB9B.ITServices.sbc.com (misout7msghub9b.itservices.sbc.com [144.151.223.72]) by fflint04.pst.cso.att.com (RSA Interceptor); Fri, 29 Jun 2012 10:49:39 -0700 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9B.ITServices.sbc.com ([144.151.223.72]) with mapi id 14.02.0298.004; Fri, 29 Jun 2012 13:49:38 -0400 From: "UTTARO, JAMES" To: "'John G. Scudder'" , "robert@raszuk.net" Thread-Topic: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks Thread-Index: AQHNVh+AzD9537iAcUezY2tl4OfbNg== Date: Fri, 29 Jun 2012 17:49:38 +0000 Message-ID: References: <003c01cd4b29$97d7b150$c78713f0$@ndzh.com> <985EF8D2-DA8A-4BE7-94D3-F4BE2B74D768@castlepoint.net> <4FE07A24.7050804@raszuk.net> <1C1F2B2E-2EB7-42F0-8CFF-57965443C074@castlepoint.net> <7A614998-8FB1-4A51-9937-DE501FF31EB6@juniper.net> <4FE0D1F4.9070208@cisco.com> <4FE0E074.3070905@raszuk.net> <17490_1340180565_4FE18855_17490_15423_1_53C29892C857584299CBF5D05346208A0928AA@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4FE18A61.8000405@raszuk.net> <4FE46DF7.20906@raszuk.net> <71761B19-5AA1-4279-98A7-10956365185A@juniper.net> <4FECC427.30609@raszuk.net> <0415D044-D1A2-496D-A033-8F2ECD6CFF8A@juniper.net> In-Reply-To: <0415D044-D1A2-496D-A033-8F2ECD6CFF8A@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.20.193] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.128.153] X-AnalysisOut: [v=1.0 c=1 a=VZVp10EGlooA:10 a=ZQD3OTTxKqYA:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=xwOvzTHDVLE4u4] X-AnalysisOut: [nGvK72ag==:17 a=OUXY8nFuAAAA:8 a=2clOPd4PAAAA:8 a=z9tbli-v] X-AnalysisOut: [AAAA:8 a=48vgC7mUAAAA:8 a=MCaw7bYH5pSWVlWeWrkA:9 a=CjuIK1q] X-AnalysisOut: [_8ugA:10 a=peF9eE_zjQwA:10 a=bDUki_mJ7DgA:10 a=oAXR_kdF8uM] X-AnalysisOut: [A:10 a=lZB815dzVvQA:10 a=aprBEn1QvWItc3rH:21 a=g9XP1gf0nGr] X-AnalysisOut: [axjiN:21] Cc: Shane Amante , "idr@ietf.org" , Susan Hares , "bruno.decraene@orange.com" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 17:50:44 -0000 John, One additional comment here in re GR and Persistence. We need to include t= he discussion in re the failure modes and how GR and Persistence react.. As= an ex.. Subsequent Restart, Timer Expiry, Mal-Formed update failures force= GR to flush the state as it is assumed to be a failure mode that should no= t be survivable.. Persistence does not flush the state when the session "fa= ils" due to these conditions... Jim Uttaro -----Original Message----- From: John G. Scudder [mailto:jgs@juniper.net]=20 Sent: Friday, June 29, 2012 10:36 AM To: robert@raszuk.net Cc: Senad .Palislamovic; Shane Amante; bruno.decraene@orange.com; UTTARO, J= AMES; Susan Hares; idr@ietf.org Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document -= 3 more weeks Yes. I was specifically referring to "keep the session up even if some erro= rs which would trigger it down are received", which I took to mean the erro= r handling draft and related work.=20 Graceful Restart can indeed address transport-and-below issues, but then we= need to review the discussion of the specific differences between persiste= nce and GR, notably the decision to withhold any signaling about the outage= (GR) vs. depreffing the stale routes (persistence) and the applicability o= f the respective strategies given different time windows. I don't have anyt= hing new to say about that. --John On Jun 28, 2012, at 4:52 PM, Robert Raszuk wrote: > Hi John, >=20 > Consider GR. >=20 > If on the restarting speaker BGP sessions go down due to TCP bug or=20 > TCP-BGP interaction bug wouldn't receiving speaker apply BGP GR procedure= ? >=20 > R. >=20 >> On Jun 22, 2012, at 9:07 AM, Robert Raszuk wrote: >>=20 >>> Last .. the session down event while BGP process is still healthy and >>> running is being addressed by various other proposals in IDR and GROW >>> which do target opposite solution .. keep the session up even if some >>> errors which would trigger it down are received. >>=20 >> None of these address a problem at or below the transport level, though.= The conversation so far has largely neglected this point. >>=20 >> --John >>=20 >=20 >=20 From ju1738@att.com Fri Jun 29 10:56:53 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7064121F882F for ; Fri, 29 Jun 2012 10:56:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.042 X-Spam-Level: X-Spam-Status: No, score=-106.042 tagged_above=-999 required=5 tests=[AWL=-0.044, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7wq+DPm7ZoQZ for ; Fri, 29 Jun 2012 10:56:51 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id AFA2121F8817 for ; Fri, 29 Jun 2012 10:56:50 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO nbfkord-smmo07.seg.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.11.0-10) with ESMTP id 26cedef4.7e824940.177089.00-557.484176.nbfkord-smmo07.seg.att.com (envelope-from ); Fri, 29 Jun 2012 17:56:50 +0000 (UTC) X-MXL-Hash: 4fedec6258eecbfe-39a5ac6e0c0f7261b83f94ff41e0a0c04d6e6376 Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.11.0-10) over TLS secured channel with ESMTP id 14cedef4.0.176934.00-372.483726.nbfkord-smmo07.seg.att.com (envelope-from ); Fri, 29 Jun 2012 17:56:32 +0000 (UTC) X-MXL-Hash: 4fedec501ea5836e-82615c2e7ffafb75f42c6e141ef1eb0480330898 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q5THuFfS022166; Fri, 29 Jun 2012 13:56:17 -0400 Received: from sflint01.pst.cso.att.com (sflint01.pst.cso.att.com [144.154.234.228]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q5THuB2W022126 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Jun 2012 13:56:12 -0400 Received: from MISOUT7MSGHUB9A.ITServices.sbc.com (misout7msghub9a.itservices.sbc.com [144.151.223.62]) by sflint01.pst.cso.att.com (RSA Interceptor); Fri, 29 Jun 2012 13:56:09 -0400 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9A.ITServices.sbc.com ([144.151.223.62]) with mapi id 14.02.0298.004; Fri, 29 Jun 2012 13:56:09 -0400 From: "UTTARO, JAMES" To: "'Brian Dickson'" Thread-Topic: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks Thread-Index: AQHNVKijc8ZsEmmpxEWbTJxs6Wew15cQggTAgABmzgCAAK2agA== Date: Fri, 29 Jun 2012 17:56:08 +0000 Message-ID: References: <14C7F4F06DB5814AB0DE29716C4F6D6702DF7129F6@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <4FE623B3.4060906@raszuk.net> <20120625070729.GC21620@juniper.net> <94135843-5EF1-4B4A-9CA3-885A4088A762@castlepoint.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.20.193] Content-Type: multipart/alternative; boundary="_000_B17A6910EEDD1F45980687268941550FB30F0AMISOUT7MSGUSR9IIT_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=1.0 c=1 a=VZVp10EGlooA:10 a=ZQD3OTTxKqYA:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a=pG] X-AnalysisOut: [LkceISAAAA:8 a=48vgC7mUAAAA:8 a=zQP7CpKOAAAA:8 a=rgdtBBad5] X-AnalysisOut: [af0W2MoIy0A:9 a=CjuIK1q_8ugA:10 a=MSl-tDqOz04A:10 a=lZB815] X-AnalysisOut: [dzVvQA:10 a=Hz7IrDYlS0cA:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAA] X-AnalysisOut: [A:8 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 ] X-AnalysisOut: [a=tXsnliwV7b4A:10] Cc: Shane Amante , Robert Raszuk , "idr@ietf.org List" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 17:56:53 -0000 --_000_B17A6910EEDD1F45980687268941550FB30F0AMISOUT7MSGUSR9IIT_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Brian, Comments In-Line... Jim Uttaro From: Brian Dickson [mailto:brian.peter.dickson@gmail.com] Sent: Thursday, June 28, 2012 11:31 PM To: UTTARO, JAMES Cc: Shane Amante; Senad .Palislamovic; idr@ietf.org List; Robert Raszuk Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document -= 3 more weeks Second sub-thread... Thanks for discussing these issues/questions. Brian On Thu, Jun 28, 2012 at 9:36 PM, UTTARO, JAMES > wrote: Brian, Appreciate your comments. Comments In-Line.. Thanks, Jim Uttaro Which BGP sessions are presumed to go away, i.e. where Persistence will mak= e a difference (or fix a problem you're seeing)? Is it the case that *both* PE1-RR1 *and* PE1-RR2 BGP sessions fail simultan= eously? [Jim U>] Not simultaneously.. For this use case the PE is peered to a clust= er of RRs.. If there is a loss of connectivity from the PE to the Cluster t= hen Persistence would kick in.. Does this mean that the cluster of RRs are in one place, where the reachabi= lity of the RRs is in a "shared fate" scenario? (It's less severe than "sin= gle point of failure", but less diverse/survivable than "fully dispersed, t= opologically/geographically diverse RRs".) [Jim U>] No.. The Cluster has RRs its RRs in diverse geography and topology= .. Loss of connectivity to the Cluster =3D> simultaneous BGP session failures. [Jim U>] True The consequence is the same, regardless of cause. Simultaneous failures of = BGP sessions. [Jim U>] Yes If the network design (single cluster of RRs) is at fault, while yes, Persi= stence would help, it is definitely a corner case. If you don't have an upp= er bound on network issues, how can you set (apriori) the values on your ti= mers for persistence? Or would they need to be settable unilaterally on the= PE? [Jim U>] Interesting question.. I believe for configuration type services t= he upper bound should be set quite high.. For L3VPN probably lower as there= is a greater risk of incorrectness.. Is there a fundamental property of the Cluster, that means you can't have t= wo Clusters to avoid the issue? [Jim U>] Although at first blush it would seem that adding addl redundant c= lusters would solve the problem it can only mitigate the effect as the dama= ge can be localized.. At some point we get to a full mesh which is unsustai= nable... And, to be clear, the problem is not on the PE end per se, or simultaneous = bugs hitting RR1 and RR2, it is a network isolation thing between PE1 and R= R1/RR2, that is the frequent and problematic root issue for the problems yo= u are having in your L2VPNs? [Jim U>] Not limited to L2VPNs.. Could be bugs, could be topological, could= be scale, etc....We have seen different triggers. Thanks, Brian --_000_B17A6910EEDD1F45980687268941550FB30F0AMISOUT7MSGUSR9IIT_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Brian,<= /p>

 <= /p>

    &= nbsp;           Comments = In-Line…

 <= /p>

Jim Uttaro

 <= /p>

From: Brian Di= ckson [mailto:brian.peter.dickson@gmail.com]
Sent: Thursday, June 28, 2012 11:31 PM
To: UTTARO, JAMES
Cc: Shane Amante; Senad .Palislamovic; idr@ietf.org List; Robert Ras= zuk
Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG doc= ument - 3 more weeks

 

Second sub-thread...

 

Thanks for discussing these issues/questions.

 

Brian

On Thu, Jun 28, 2012 at 9:36 PM, UTTARO, JAMES <<= a href=3D"mailto:ju1738@att.com" target=3D"_blank">ju1738@att.com> w= rote:

Brian,

 

      &nb= sp;         Appreciate your comment= s. Comments In-Line..

 

Thanks,

Jim Uttaro

 

 

Which BGP sessions are presumed to go away, i.e. where Persistence= will make a difference (or fix a problem you're seeing)?

Is it the case that *both* PE1-RR1 *and* PE1-RR2 BGP sessions fail= simultaneously?

[Jim U>] Not simultaneously.. = For this use case the PE is peered to a cluster of RRs.. If there is a loss of connectivity from the PE to the Cluster then Persistence woul= d kick in..

 

Does this mean that the cluster of RRs are in one pl= ace, where the reachability of the RRs is in a "shared fate" scen= ario? (It's less severe than "single point of failure", but less = diverse/survivable than "fully dispersed, topologically/geographically diverse RRs".)

[Jim U>] No.. Th= e Cluster has RRs its RRs in diverse geography and topology..

 

Loss of connectivity to the Cluster =3D> simultan= eous BGP session failures.

[Jim U>] True

 

The consequence is the same, regardless of cause. Si= multaneous failures of BGP sessions.

[Jim U>] Yes

 

If the network design (single cluster of RRs) is at = fault, while yes, Persistence would help, it is definitely a corner case. I= f you don't have an upper bound on network issues, how can you set (apriori= ) the values on your timers for persistence? Or would they need to be settable unilaterally on the PE?

[Jim U>] Interes= ting question.. I believe for configuration type services the upper bound s= hould be set quite high.. For L3VPN probably lower as there is a greater risk of incorrectness..

 

Is there a fundamental property of the Cluster, that= means you can't have two Clusters to avoid the issue?

[Jim U>] Althoug= h at first blush it would seem that adding addl redundant clusters would so= lve the problem it can only mitigate the effect as the damage can be localized.. At some point we get to a full mesh which is unsustaina= ble…

 

And, to be clear, the problem is not on the PE end p= er se, or simultaneous bugs hitting RR1 and RR2, it is a network isolation = thing between PE1 and RR1/RR2, that is the frequent and problematic root is= sue for the problems you are having in your L2VPNs?

[Jim U>] Not lim= ited to L2VPNs.. Could be bugs, could be topological, could be scale, etc&#= 8230;.We have seen different triggers.

 

Thanks,

Brian

--_000_B17A6910EEDD1F45980687268941550FB30F0AMISOUT7MSGUSR9IIT_-- From ju1738@att.com Fri Jun 29 11:03:24 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4AE221F869A for ; Fri, 29 Jun 2012 11:03:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.34 X-Spam-Level: X-Spam-Status: No, score=-106.34 tagged_above=-999 required=5 tests=[AWL=0.258, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zq2IFtqUhrS6 for ; Fri, 29 Jun 2012 11:03:23 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id 3A69F21F8699 for ; Fri, 29 Jun 2012 11:03:23 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO nbfkord-smmo05.seg.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.11.0-10) with ESMTP id bededef4.2aaae7431940.1499942.00-566.4160226.nbfkord-smmo05.seg.att.com (envelope-from ); Fri, 29 Jun 2012 18:03:23 +0000 (UTC) X-MXL-Hash: 4fededeb4cc8589f-3e427f2385a90df3dadb47985e971ff909f1b4a0 Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.11.0-10) over TLS secured channel with ESMTP id acdedef4.0.1499756.00-307.4159684.nbfkord-smmo05.seg.att.com (envelope-from ); Fri, 29 Jun 2012 18:03:05 +0000 (UTC) X-MXL-Hash: 4fededd9169510ba-064048c30f9573cbb1e8b3b7464d2ec4cf1e0721 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q5TI2o1K025666; Fri, 29 Jun 2012 14:02:50 -0400 Received: from sflint01.pst.cso.att.com (sflint01.pst.cso.att.com [144.154.234.228]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q5TI2fMS025541 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Jun 2012 14:02:45 -0400 Received: from MISOUT7MSGHUB9A.ITServices.sbc.com (misout7msghub9a.itservices.sbc.com [144.151.223.62]) by sflint01.pst.cso.att.com (RSA Interceptor); Fri, 29 Jun 2012 14:02:33 -0400 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9A.ITServices.sbc.com ([144.151.223.62]) with mapi id 14.02.0298.004; Fri, 29 Jun 2012 14:02:33 -0400 From: "UTTARO, JAMES" To: "'Brian Dickson'" Thread-Topic: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks Thread-Index: AQHNVKijc8ZsEmmpxEWbTJxs6Wew15cQggTAgABd2oCAALfy0A== Date: Fri, 29 Jun 2012 18:02:33 +0000 Message-ID: References: <14C7F4F06DB5814AB0DE29716C4F6D6702DF7129F6@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <4FE623B3.4060906@raszuk.net> <20120625070729.GC21620@juniper.net> <94135843-5EF1-4B4A-9CA3-885A4088A762@castlepoint.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.20.193] Content-Type: multipart/alternative; boundary="_000_B17A6910EEDD1F45980687268941550FB30F1CMISOUT7MSGUSR9IIT_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=1.0 c=1 a=VZVp10EGlooA:10 a=ZQD3OTTxKqYA:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a=pG] X-AnalysisOut: [LkceISAAAA:8 a=48vgC7mUAAAA:8 a=zQP7CpKOAAAA:8 a=TOymi588L] X-AnalysisOut: [zhJlFdOMScA:9 a=CjuIK1q_8ugA:10 a=MSl-tDqOz04A:10 a=lZB815] X-AnalysisOut: [dzVvQA:10 a=Hz7IrDYlS0cA:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAA] X-AnalysisOut: [A:8 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 ] X-AnalysisOut: [a=tXsnliwV7b4A:10] Cc: Shane Amante , Robert Raszuk , "idr@ietf.org List" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 18:03:25 -0000 --_000_B17A6910EEDD1F45980687268941550FB30F1CMISOUT7MSGUSR9IIT_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Brian, Comments In-Line.. Jim Uttaro From: Brian Dickson [mailto:brian.peter.dickson@gmail.com] Sent: Thursday, June 28, 2012 10:59 PM To: UTTARO, JAMES Cc: Shane Amante; Senad .Palislamovic; idr@ietf.org List; Robert Raszuk Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document -= 3 more weeks Okay, thanks for answering my questions. I'll try to simplify the discussion by splitting ongoing discussion into se= parate threads. I'll leave the subject unmodified, and hopefully modern mail readers can co= pe with the references. Brian On Thu, Jun 28, 2012 at 9:36 PM, UTTARO, JAMES > wrote: Brian, Appreciate your comments. Comments In-Line.. Thanks, Jim Uttaro This would not have any direct impact to path selection, for example, and w= ould fairly trivially support negotiated (based on local configuration of) = timers and "reaping" NLRIs upon timer expiry. Behavior per-AFI/SAFI should = be able to be specified. [Jim U>] We require the ability to de-pref. Can you elaborate? [Jim U>] If there is another path in the topology then that should be used.= . Who is "we" in this context? [Jim U>]I guess I will only speak for myself here.. How strict is "require", and can you explain how that is a hard requirement= , maybe with examples of things breaking without de-pref? Please, more use cases - the more the better. We need to fully understand t= he problem space, with which you are intimately familiar. [Jim U>] I guess it is important to note that the draft provides two mechan= isms, the first is de-pref the second is DO_NOT _PERSIST.. These tools allo= w the SP to have different behaviors.. It may also be appropriate to simply= Persist the state without de-preffing although that does not seem right if= there is a path over a session which is not experiencing issues.. If de-pref is not available, is "STALE" still useful? [Jim U>] Yes, this would be the case where that is the only path available = or better said the content of the update is not about paths but about confi= guration..Too be clear configuration BGP needs further examination.. If you are given a choice between "STALE but no de-pref" or "nothing", woul= d "STALE but no de-pref" be acceptable? [Jim U>] Not really sure why I have to have a choice.. We are using LP to d= e-pref.. (Currently you have "nothing", and are asking for "STALE *and* de-pref". I = just want to be sure I understand the situation. I believe you could get se= ssion-level STALE for the asking, with no opposition, as long as there is n= o behavior modification or auto-depref mandated. I.e., if the behavior was,= "negotiate option PERSISTENCE. if SESSION.PERSISTENCE && BGP_SESSION_DROPP= ED, add community STALE, push the 'update-it' button which then triggers ou= t-bound route-maps et al", then I think you could get this through WGLC in = 30 days or less.) [Jim U>] That is quite optimistic ;) Not needing to change the content or format of UPDATEs should be seen as a = goal, rather than the other way round. [Jim U>] ? A negotiated option, call it "PERSIST", would mean that your PE1 peerings w= ith RR1 and RR2, if negotiated, would keep the routes learned if the BGP se= ssions dropped. Presume that in addition to "PERSIST" that the peers also n= egotiate a "PERSIST_TIMER". In order to do that, the CAPABILITY_NEGOTIATE codes need to be defined, but= beyond the OPEN, there is no change to the on-the-wire protocol or to the = path-selection process. The only additional code change needed would be the= implicit withdrawal when a BGP peer drops. Contrast that, from the perspective of multiple implementers, of all the me= chanics involved in checking each UPDATE for the presence of STALE or DO_NO= T_PERSIST communities, and hard-coding modifications to behavior that alrea= dy involves so many moving parts. (Believe me - I've done severe hacking on, e.g. quagga, and while it is sol= id code, the complexity in it, which is informed directly by the plethora o= f BGP RFCs, makes it a huge challenge to try to do "big" changes to it on a= whole cloth basis. Getting those right and debugging them are highly non-t= rivial. Now hand that to vendors who have trouble managing their own hardwa= re drivers and code trains, with massive teams of developers. This needs to= interoperate, right? And be stable code serving a lot of customers?) Minimizing the number of places that already-complex logic needs to be twea= ked, and then looking at corner cases where those might or might not overla= p (in the code, not in the UPDATE data, that is)... If the benefits (of you= r proposal) are only seen in corner cases, and if the benefits can maybe be= achieved via other means (voluntary COMMUNITY processing via route-maps, p= lus maybe the setting of a STALE well-known community if/when a session dro= ps), then would you be willing to consider the simpler solution? (It might help to try to take what I've suggested and draw it out on a whit= e board. See if you can make sense of it and make it work, even if you have= to do post-processing stuff in route-maps. The question is, does it provid= e sufficient mechanisms to achieve the design goals?) Sincerely, Brian Dickson --_000_B17A6910EEDD1F45980687268941550FB30F1CMISOUT7MSGUSR9IIT_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Brian,<= /p>

 <= /p>

    &= nbsp;           Comments = In-Line..

 <= /p>

Jim Uttaro

 <= /p>

From: Brian Di= ckson [mailto:brian.peter.dickson@gmail.com]
Sent: Thursday, June 28, 2012 10:59 PM
To: UTTARO, JAMES
Cc: Shane Amante; Senad .Palislamovic; idr@ietf.org List; Robert Ras= zuk
Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG doc= ument - 3 more weeks

 

Okay, thanks for answering my questions.<= /p>

 

I'll try to simplify the discussion by splitting ong= oing discussion into separate threads.

I'll leave the subject unmodified, and hopefully mod= ern mail readers can cope with the references.

 

Brian

On Thu, Jun 28, 2012 at 9:36 PM, UTTARO, JAMES <<= a href=3D"mailto:ju1738@att.com" target=3D"_blank">ju1738@att.com> w= rote:

Brian,

 

      &nb= sp;         Appreciate your comment= s. Comments In-Line..

 

Thanks,

Jim Uttaro

 

 

 

This would not have any direct impact to path selection, for examp= le, and would fairly trivially support negotiated (based on local configura= tion of) timers and "reaping" NLRIs upon timer expiry. Behavior per-AFI/SAFI should be able to be specified.

[Jim U>] We require the abilit= y to de-pref.

 

 

Can you elaborate?

[Jim U>] If ther= e is another path in the topology then that should be used..=

 

Who is "we" in this context?

[Jim U>]I guess = I will only speak for myself here.. 

How strict is "require", and can you expla= in how that is a hard requirement, maybe with examples of things breaking w= ithout de-pref?

Please, more use cases - the more the better. We nee= d to fully understand the problem space, with which you are intimately fami= liar.

[Jim U>] I guess= it is important to note that the draft provides two mechanisms, the first = is de-pref the second is DO_NOT _PERSIST.. These tools allow the SP to have different behaviors.. It may also be appropriate to simply = Persist the state without de-preffing although that does not seem right if = there is a path over a session which is not experiencing issues..

 

If de-pref is not available, is "STALE" st= ill useful?

[Jim U>] Yes, th= is would be the case where that is the only path available or better said t= he content of the update is not about paths but about configuration..Too be clear configuration BGP needs further examination..

 

If you are given a choice between "STALE but no= de-pref" or "nothing", would "STALE but no de-pref&quo= t; be acceptable?

[Jim U>] Not rea= lly sure why I have to have a choice.. We are using LP to de-pref..<= /i>

 

(Currently you have "nothing", and are ask= ing for "STALE *and* de-pref". I just want to be sure I understan= d the situation. I believe you could get session-level STALE for the asking= , with no opposition, as long as there is no behavior modification or auto-depref mandated. I.e., if the behavior was, "neg= otiate option PERSISTENCE. if SESSION.PERSISTENCE && BGP_SESSION_DR= OPPED, add community STALE, push the 'update-it' button which then triggers= out-bound route-maps et al", then I think you could get this through WGLC in 30 days or less.)

[Jim U>] That is= quite optimistic ;)

 

 

Not needing to change the content or format of UPDATEs should be s= een as a goal, rather than the other way round.

[Jim U>] ?=

 

 

A negotiated option, call it "PERSIST", wo= uld mean that your PE1 peerings with RR1 and RR2, if negotiated, would keep= the routes learned if the BGP sessions dropped. Presume that in addition t= o "PERSIST" that the peers also negotiate a "PERSIST_TIMER".

 

In order to do that, the CAPABILITY_NEGOTIATE codes = need to be defined, but beyond the OPEN, there is no change to the on-the-w= ire protocol or to the path-selection process. The only additional code cha= nge needed would be the implicit withdrawal when a BGP peer drops.

 

Contrast that, from the perspective of multiple impl= ementers, of all the mechanics involved in checking each UPDATE for the pre= sence of STALE or DO_NOT_PERSIST communities, and hard-coding modifications= to behavior that already involves so many moving parts.

(Believe me - I've done severe hacking on, e.g. quag= ga, and while it is solid code, the complexity in it, which is informed dir= ectly by the plethora of BGP RFCs, makes it a huge challenge to try to do &= quot;big" changes to it on a whole cloth basis. Getting those right and debugging them are highly non-trivial. Now = hand that to vendors who have trouble managing their own hardware drivers a= nd code trains, with massive teams of developers. This needs to interoperat= e, right? And be stable code serving a lot of customers?)

 

Minimizing the number of places that already-complex= logic needs to be tweaked, and then looking at corner cases where those mi= ght or might not overlap (in the code, not in the UPDATE data, that is)... = If the benefits (of your proposal) are only seen in corner cases, and if the benefits can maybe be achieved v= ia other means (voluntary COMMUNITY processing via route-maps, plus maybe t= he setting of a STALE well-known community if/when a session drops), then w= ould you be willing to consider the simpler solution?

 

(It might help to try to take what I've suggested an= d draw it out on a white board. See if you can make sense of it and make it= work, even if you have to do post-processing stuff in route-maps. The ques= tion is, does it provide sufficient mechanisms to achieve the design goals?)



Sincerely,
Brian Dickson

 

 

--_000_B17A6910EEDD1F45980687268941550FB30F1CMISOUT7MSGUSR9IIT_-- From jgs@juniper.net Fri Jun 29 14:55:57 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5489521F85F6 for ; Fri, 29 Jun 2012 14:55:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.475 X-Spam-Level: X-Spam-Status: No, score=-6.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LeV3GEN5vzlW for ; Fri, 29 Jun 2012 14:55:56 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by ietfa.amsl.com (Postfix) with ESMTP id 2023221F85E7 for ; Fri, 29 Jun 2012 14:55:55 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKT+4kan7xMKIWwDPO2i05nHgqULJ3CBwC@postini.com; Fri, 29 Jun 2012 14:55:56 PDT Received: from [172.16.13.202] (172.16.13.202) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server id 8.3.213.0; Fri, 29 Jun 2012 14:55:47 -0700 MIME-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset="windows-1252" From: "John G. Scudder" In-Reply-To: Date: Fri, 29 Jun 2012 17:55:46 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <3597858F-E825-4ACB-B0B3-6DC0351357C8@juniper.net> References: <20120617204451.26844.76025.idtracker@ietfa.amsl.com> To: Brian Dickson X-Mailer: Apple Mail (2.1278) Cc: "idr@ietf.org wg" Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 21:55:57 -0000 Hi Brian, This is a good analysis. I'd like to point out that this topic was = discussed briefly at our IETF-82 meeting. In particular, see slide 4 of = http://www.ietf.org/proceedings/82/slides/idr-5.pdf: =95 Not pursuing automation of the procedures in protocol=20 - Issues from EBGP typically dominate - Require significant changes to the protocol Your analysis is a good illustration of "require significant changes to = the protocol". If the pathology in question were considered to be either = sufficiently high-probability, or sufficiently grave even if = low-probability, that could motivate work on an approach such as you = describe. However I think that is not the case. Recall that the types of = errors we are mitigating against have only been seen in the field = rarely. The motivation for proposing the changes in idr-error-handling = is that the consequences can be quite grave. On the flip side, the cost = of implementing idr-error-handling is relatively modest and equally = important, it can be deployed piecemeal. On the other hand, the = potential forwarding loops that we're talking about would occur only in = a (possibly small) subset of these incidents, which themselves only = occur with low probability. Furthermore, as Robert points out, in a = network that uses edge-to-edge tunneling, as is quite common, looping = will not occur. The cost of implementing the solution appears quite a = bit higher and it must be deployed in a coordinated fashion. Finally, = it's the case that if my argument above turns out to be wrong, a = proposal such as yours could be implemented in the future -- lack of it = shouldn't impede deployment of idr-error-handling. For these reasons I would prefer not to pursue this approach right now. Regards, --John P.S.: It should go without saying, but I'm speaking as a WG member. On Jun 28, 2012, at 4:56 PM, Brian Dickson wrote: >=20 >=20 > On Mon, Jun 18, 2012 at 3:48 PM, John G. Scudder = wrote: > Hi Jim, >=20 > On Jun 17, 2012, at 8:29 PM, UTTARO, JAMES wrote: >=20 >=20 > > Could you expand on the conditions >=20 > One very simple case: >=20 > A--B--C--D >=20 > The four routers depicted form an IBGP full mesh (sessions not shown). = The links shown are the physical topology. Standard IP forwarding is = used. Routers A and D are ASBRs and both advertise a path for prefix X = into IBGP. Router C prefers the path from A, for example due to a = shorter AS Path. However, router B decides that the path from A is = malformed, so it selects the path from D. Now we have C's next hop to = reach X as B, and B's next hop to reach X as C. This is a stable = forwarding loop. (Why do B and C have different conclusions about = whether the update is malformed? Different code bases with different = assumptions, as we have seen more than once in the field.) >=20 > This is a very useful example, and has prompted me to think about the = problem space. See below for discussion (by me). > =20 >=20 > > Will there be a draft whereby the detecting router somehow figures = out the offending ingress router, builds routing policy and then sends = it there to dynamically create the filter. >=20 > I sincerely hope not and have spoken against this idea in the past. >=20 > > This seems non-trivial, >=20 > That's why. When you start building machinery to automatically patch = around bugs in your primary routing machinery, IMO you have officially = Jumped The Shark and started building a Rube Goldberg router. >=20 > Patch around bugs, no. However, achieving AS-wide loop-free routing = should be considered an explicit goal, and to that end, how such errors = get handled is pretty important. >=20 > That may mean a first-order method of achieving consistency is needed, = i.e. one that involves very little semantics, and doesn't attempt to = overload existing per-AFI/SAFI machinery.=20 >=20 > Here are what I see as problems when a subset of IBGP speakers think a = given update is malformed: >=20 > =95 In order to prevent a routing INFORMATION loop, malformed = updates need to be matched against previous corresponding non-malformed = updates (if any) > =95 A router that wants to avoid forwarding packets inside a = routing loop (where the loop was induced by treat-as-withdrawn), would = possibly need to basically do RPF-checks on the interface it chose as = next-hop for those packets > =95 Any attempt to infer whether a given router should = selectively also withdraw a given route from its Adj-IN-RIB, to avoid a = routing loop induced by treat-as-withdrawn by an IBGP peer, requires = combining IGP and IBGP routing information, need to consider this on a = hop-by-hop basis, and can only identify route-loops involving an = immediately adjacent (topologically speaking) router. This requires = hop-by-hop, route-by-route, iterative action, which clearly scales, in = arbitrary topologies, arbitrarily badly. >=20 > Unless all route instances are collectively marked as malformed, there = should be one or more non-malformed routes available for use. >=20 > The easiest way to match updates that _some_ router inside a given AS = thinks are malformed, against the original non-malformed announcement, = is to have the iBGP speaker do the "treat-as-withdrawn" action itself. >=20 > This would accomplish several things: > =95 Every router in the AS would receive the withdrawal (from = the original iBGP speaker, i.e. with correct behavior from the stateful = perspective) > =95 Every router in the AS would have the same BGP information = from which to choose best path (and is more likely to converge = loop-free) > =95 Only the original iBGP speaker would need to keep state = regarding the route that is now under "treat-as-withdrawn" > =95 Logging from the two iBGP speakers (the one that believes = the update was malformed, and the one that sent the malformed update) is = enough to isolate the problem quickly > =95 Malformed updates would not propagate (this is a big plus) > =95 Only updates that all vendors/code-bases believe are = non-malformed can propagate beyond the AS (a huge plus - trap the error = at the ingress boundaries) > =95 No flapping sessions (a huge plus) > The absolute minimum needed to achieve this basically is, for the = receiving/detecting/reporting iBGP speaker to send back the UPDATE = message, wrapped in some other message type, to the original sender (or = targeted at the sender but relayed to the RR, if an RR cluster list is = present). >=20 > In order to make this simple and to scale implementation, the idea I = have is to use a single, new AFI/SAFI, which is "Malformed", and whose = message includes the AFI/SAFI and everything else from the original = UPDATE. >=20 > Upon receipt of such a Malformed message, the (presumed) ASBR would = then send do "treat-as-withdrawn", mark the original ingress NLRI as = "reported malformed", in such a way as to require operator intervention = to clear the "malformed" state (and thus not repeatedly re-propagate = updates and contribute churn related to malformed updates). >=20 > The motivation for this is - don't create persistent routing loops = (and don't check for an error condition you don't know how to handle = :-)). >=20 > This is only for the iBGP case, which is IMHO the most important one. = Not sure if this logic can or should extend to the eBGP environment, but = I think it can be inferred from the above that this would not be = strictly necessary. Routing updates that are seen by an entire AS as = well-formed means reachability is fine for that AS. If other AS = neighbors don't agree then they won't use the affected routes, so things = still result in loop-free forwarding and reachability is maximized. >=20 > Thoughts? >=20 > Does this make sense, and would this fit in the proposal, or should it = go in a separate draft? >=20 > Brian