From internet-drafts@ietf.org Tue Jan 3 13:40: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 CD83211E80DD; Tue, 3 Jan 2012 13:40:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 kwusyJoV255v; Tue, 3 Jan 2012 13:40:42 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6633C11E80B2; Tue, 3 Jan 2012 13:40:42 -0800 (PST) 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: 3.64p1 Message-ID: <20120103214042.6014.65246.idtracker@ietfa.amsl.com> Date: Tue, 03 Jan 2012 13:40:42 -0800 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-best-external-05.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, 03 Jan 2012 21:40:43 -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 the best external route in BGP Author(s) : Pedro Marques Rex Fernando Enke Chen Pradosh Mohapatra Hannes Gredler Filename : draft-ietf-idr-best-external-05.txt Pages : 21 Date : 2012-01-03 The current BGP-4 protocol specification [RFC4271] states that the selection process chooses the best path for a given route which is added to the Loc-Rib and advertised to all peers. Previous versions [RFC1771] of the specification defined a different rule for Internal BGP Updates. Given that Internal paths are not re- advertised to Internal peers, it was specified that the best of the external paths, as determined by the path selection tie breaking algorithm, would be advertised to Internal peers. This document extends that procedure to operate in environments where Route Reflection [RFC4456] or Confederations [RFC5065] are used and explains why advertising the additional routing information can improve convergence time without causing routing loops. Additional benefits include reduction of inter-domain churn and avoidance of permanent route oscillation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-best-external-05.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-best-external-05.txt From paul@jakma.org Wed Jan 4 03: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 C302921F8682 for ; Wed, 4 Jan 2012 03:56:53 -0800 (PST) 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 dHCZdcbT71Mk for ; Wed, 4 Jan 2012 03:56:53 -0800 (PST) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 0B4F921F8679 for ; Wed, 4 Jan 2012 03:56:52 -0800 (PST) Received: by wgbds13 with SMTP id ds13so23461488wgb.1 for ; Wed, 04 Jan 2012 03:56:52 -0800 (PST) Received: by 10.216.137.148 with SMTP id y20mr14686786wei.32.1325678212103; Wed, 04 Jan 2012 03:56:52 -0800 (PST) Received: from jamaica.dcs.gla.ac.uk (jamaica.dcs.gla.ac.uk. [130.209.244.4]) by mx.google.com with ESMTPS id fq7sm59241707wbb.1.2012.01.04.03.56.50 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 04 Jan 2012 03:56:50 -0800 (PST) Date: Wed, 4 Jan 2012 11:56:45 +0000 (GMT) From: Paul Jakma X-X-Sender: paul@jamaica.dcs.gla.ac.uk To: Robert Raszuk In-Reply-To: <4EEF4942.6050105@raszuk.net> Message-ID: References: <20111215233845.21432.33837.idtracker@ietfa.amsl.com> <37936E57-4A5E-4B6B-8BA8-C7CD5722C1A6@ericsson.com> <4EEB6C23.4080803@raszuk.net> <4EEB78E5.6070809@raszuk.net> <20111216220720.GB10812@diehard.n-r-g.com> <4EEBE42B.2020700@cisco.com> <20111217103952.GA7158@diehard.n-r-g.com> <26782_1324294649_4EEF21F9_26782_3157_1_53C29892C857584299CBF5D05346208A010D51@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4EEF4942.6050105@raszuk.net> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: bruno.decraene@orange.com, "idr@ietf.org" Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-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: Wed, 04 Jan 2012 11:56:53 -0000 On Mon, 19 Dec 2011, Robert Raszuk wrote: > You say that "we don't like it" what is happening today. One may argue > that "some do not like it some do". > The fact that draft-ietf-idr-error-handling seems to be targetting to > update 4271 means that when I boot router with new software the > behaviour will change and now all of the operations teams worldwide need > to develop new syslog parsing scripts to catch the new error categories. > Today they see it easily as session is going down. 2nd this. "Treat-as-withdraw" should be an option, but possibly shouldn't be the default for core message parsing. To use "treat-as-withdraw" safely will require operational-best-practice of carefully checking logs to detect when a "treat-as-withdraw" will occur. If implementations switch to "treat-as-withdraw" as default for core messages then software problems change from quite obvious (to both sides) session resets; into problems that potentially affect just a tiny % of routes, for paths whose sources have no relationship with either speaker involved in the route-drop (be it the problem speaker or the dropping one). It turns problems that are obvious to the ASes involved in the BGP errors, into ones that may only be obvious to remote ASes who may find it very hard to get their routing problems fixed. Some care needs to be taken before vendors roll out general "treat-as-withdraw" as the default behaviour to potentially unsuspecting and/or unprepared operators. regards, -- Paul Jakma paul@jakma.org twitter: @pjakma PGP: 64A2FF6A Fortune: I know on which side my bread is buttered. -- John Heywood From jhaas@slice.pfrc.org Wed Jan 4 17:29: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 C924A21F87B5 for ; Wed, 4 Jan 2012 17:29:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.411 X-Spam-Level: X-Spam-Status: No, score=-100.411 tagged_above=-999 required=5 tests=[AWL=1.854, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 qhiEZ42N0Go8 for ; Wed, 4 Jan 2012 17:29:21 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 6560421F8579 for ; Wed, 4 Jan 2012 17:29:21 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id EBBA522411F; Thu, 5 Jan 2012 01:29:20 +0000 (UTC) Date: Wed, 4 Jan 2012 20:29:20 -0500 From: Jeffrey Haas To: stephane.litkowski@orange.com Message-ID: <20120105012920.GB7464@slice> References: <4EEB78E5.6070809@raszuk.net> <20111216220720.GB10812@diehard.n-r-g.com> <4EEBE42B.2020700@cisco.com> <20111217103952.GA7158@diehard.n-r-g.com> <26782_1324294649_4EEF21F9_26782_3157_1_53C29892C857584299CBF5D05346208A010D51@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4EEF4942.6050105@raszuk.net> <22583_1324309396_4EEF5B94_22583_6701_1_53C29892C857584299CBF5D05346208A010EC8@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4EEF6192.1090901@raszuk.net> <29770_1324997549_4EF9DBAD_29770_218328_1_4FC3556A36EE3646A09DAA60429F533507861664@PUEXCBL0.nanterre.francetelecom.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <29770_1324997549_4EF9DBAD_29770_218328_1_4FC3556A36EE3646A09DAA60429F533507861664@PUEXCBL0.nanterre.francetelecom.fr> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: DECRAENE Bruno RD-CORE , robert@raszuk.net, idr@ietf.org Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-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, 05 Jan 2012 01:29:21 -0000 On Tue, Dec 27, 2011 at 03:52:27PM +0100, stephane.litkowski@orange.com wrote: > Alcatel/Cisco were not supporting DampPeerOscillations when the survey was done. Maybe it changed, maybe not (RFC is old ...). > No feedback about Juniper. Like many things in the updated FSM in RFC 4271, you could say JunOS supports DampPeerOscillations if you squint at it a little. -- Jeff From jhaas@slice.pfrc.org Wed Jan 4 17:45: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 9F4B411E808D for ; Wed, 4 Jan 2012 17:45:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.038 X-Spam-Level: X-Spam-Status: No, score=-101.038 tagged_above=-999 required=5 tests=[AWL=0.627, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_43=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 foh-bd2ewqeM for ; Wed, 4 Jan 2012 17:45:33 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 34BF211E8080 for ; Wed, 4 Jan 2012 17:45:33 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id CA2182240DB; Thu, 5 Jan 2012 01:45:32 +0000 (UTC) Date: Wed, 4 Jan 2012 20:45:32 -0500 From: Jeffrey Haas To: Warren Kumari Message-ID: <20120105014532.GC7464@slice> References: <20111216182324.17528.28150.idtracker@ietfa.amsl.com> <9CD76392-6F52-441C-BCF5-2335D7F49B8F@kumari.net> <4EEBEAEB.8070304@cisco.com> <0156DFD0-B706-42B0-93AB-89C9E6E252FD@kumari.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0156DFD0-B706-42B0-93AB-89C9E6E252FD@kumari.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: keyupate@cisco.com, idr@ietf.org Subject: Re: [Idr] I-D Action: draft-ietf-idr-as0-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, 05 Jan 2012 01:45:33 -0000 [Explicit cc on the draft-ietf-idr-error-handling authors for the comments below.] Warren, On Sat, Dec 17, 2011 at 12:26:10PM -0500, Warren Kumari wrote: > On Dec 16, 2011, at 8:05 PM, Enke Chen wrote: > > 1) Is it really necessary to make AS 0 an error in the AGGREGATOR and AS4_AGGREGATOR attributes? What is the gain? > > I'll double check with co-authors on Monday -- I don't think it is strictly necessary to prevent attack, rather it seemed more elegant to check AS 0 where ever it occurs. While I generally agree with Enke that treating as a malformed route is probably excessive, I think the recommended behavior is desirable. The mandate that the error-handling draft procedures must be used makes it acceptable. Without those procedures, bouncing the session is almost certainly the wrong thing to do. > It was brought up on the NANOG list that some vendors support zero'ing out the AGGREGATOR (see Junipers "no-aggregator-id" as an example -- this appears to only zero out the router ID, but I haven't checked all implementations), so checking for AS 0 in the .*AGGREGATOR may be a bad idea, so at the moment I'm leaning towards removing it (obviously, this being a WG doc, with the WG's approval) Older varieties of gated had bugs with respect to the AS number that was selected to be placed in the aggregator AS field. JunOS may have had similar bugs at one point but the behavior that I can see in a cursory check of the code should result in a system AS number being placed there. My recommendation for the as0 draft is that we leave in the current text and let the attribute be treated as "malformed" by the error-handling draft. The behavior in that draft of attribute-discard is reasonable. > > 2) The error handling for AS4_PATH / AS4_AGGREGATOR is specified in rfc4893bis (draft-ietf-idr-rfc4893bis-04.txt). Thus it should be referenced if you specify AS 0 as an error for the AS4_PATH / AS4_AGGREGATOR. > > > > Doh! This was mentioned a few times and I intended to do so, but it completely slipped my mind when typing... Thanks for reminding me.... Similarly, there should be references for these attributes added to the error-handling draft. -- Jeff From jeff.tantsura@ericsson.com Wed Jan 4 17:51: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 468801F0C38 for ; Wed, 4 Jan 2012 17:51:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.051 X-Spam-Level: X-Spam-Status: No, score=-6.051 tagged_above=-999 required=5 tests=[AWL=-0.052, 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 eMQIU2aHUKZ2 for ; Wed, 4 Jan 2012 17:51:25 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 927931F0C48 for ; Wed, 4 Jan 2012 17:51:25 -0800 (PST) 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 q051pNZJ015867; Wed, 4 Jan 2012 19:51:24 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.20]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Wed, 4 Jan 2012 20:51:18 -0500 From: Jeff Tantsura To: Jeffrey Haas , Warren Kumari Date: Wed, 4 Jan 2012 20:51:17 -0500 Thread-Topic: [Idr] I-D Action: draft-ietf-idr-as0-01.txt Thread-Index: AczLS7p0WjUyh/n/QCW5xk66d95DuAAAJltA Message-ID: <0ED867EB33AB2B45AAB470D5A64CDBF6181C654044@EUSAACMS0701.eamcs.ericsson.se> References: <20111216182324.17528.28150.idtracker@ietfa.amsl.com> <9CD76392-6F52-441C-BCF5-2335D7F49B8F@kumari.net> <4EEBEAEB.8070304@cisco.com> <0156DFD0-B706-42B0-93AB-89C9E6E252FD@kumari.net> <20120105014532.GC7464@slice> In-Reply-To: <20120105014532.GC7464@slice> 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: "keyupate@cisco.com" , "idr@ietf.org" Subject: Re: [Idr] I-D Action: draft-ietf-idr-as0-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, 05 Jan 2012 01:51:26 -0000 +1 Regards, Jeff -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Jeffr= ey Haas Sent: Wednesday, January 04, 2012 5:46 PM To: Warren Kumari Cc: keyupate@cisco.com; idr@ietf.org Subject: Re: [Idr] I-D Action: draft-ietf-idr-as0-01.txt [Explicit cc on the draft-ietf-idr-error-handling authors for the comments = below.] Warren, On Sat, Dec 17, 2011 at 12:26:10PM -0500, Warren Kumari wrote: > On Dec 16, 2011, at 8:05 PM, Enke Chen wrote: > > 1) Is it really necessary to make AS 0 an error in the AGGREGATOR and = AS4_AGGREGATOR attributes? What is the gain? >=20 > I'll double check with co-authors on Monday -- I don't think it is strict= ly necessary to prevent attack, rather it seemed more elegant to check AS 0= where ever it occurs. While I generally agree with Enke that treating as a malformed route is pro= bably excessive, I think the recommended behavior is desirable. The mandat= e that the error-handling draft procedures must be used makes it acceptable= . Without those procedures, bouncing the session is almost certainly the w= rong thing to do. > It was brought up on the NANOG list that some vendors support zero'ing=20 > out the AGGREGATOR (see Junipers "no-aggregator-id" as an example --=20 > this appears to only zero out the router ID, but I haven't checked all=20 > implementations), so checking for AS 0 in the .*AGGREGATOR may be a=20 > bad idea, so at the moment I'm leaning towards removing it (obviously,=20 > this being a WG doc, with the WG's approval) Older varieties of gated had bugs with respect to the AS number that was se= lected to be placed in the aggregator AS field. JunOS may have had similar= bugs at one point but the behavior that I can see in a cursory check of th= e code should result in a system AS number being placed there. My recommendation for the as0 draft is that we leave in the current text an= d let the attribute be treated as "malformed" by the error-handling draft. The behavior in that draft of attribute-discard is reasonable. > > 2) The error handling for AS4_PATH / AS4_AGGREGATOR is specified in rf= c4893bis (draft-ietf-idr-rfc4893bis-04.txt). Thus it should be referenced i= f you specify AS 0 as an error for the AS4_PATH / AS4_AGGREGATOR. > >=20 >=20 > Doh! This was mentioned a few times and I intended to do so, but it compl= etely slipped my mind when typing... Thanks for reminding me.... Similarly, there should be references for these attributes added to the err= or-handling draft. -- Jeff _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From stephane.litkowski@orange.com Thu Jan 5 00:41: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 90F9821F86E6 for ; Thu, 5 Jan 2012 00:41:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.868 X-Spam-Level: X-Spam-Status: No, score=-1.868 tagged_above=-999 required=5 tests=[AWL=0.380, 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 oKcGdgp7fLic for ; Thu, 5 Jan 2012 00:41:34 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id C1F1021F86DF for ; Thu, 5 Jan 2012 00:41:33 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 8C95026466F; Thu, 5 Jan 2012 09:41:30 +0100 (CET) Received: from puexcc31.nanterre.francetelecom.fr (unknown [10.168.74.8]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 6A161238048; Thu, 5 Jan 2012 09:41:30 +0100 (CET) Received: from PUEXCBL0.nanterre.francetelecom.fr ([10.168.74.46]) by puexcc31.nanterre.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Jan 2012 09:41:30 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 5 Jan 2012 09:41:28 +0100 Message-ID: <3567_1325752890_4F05623A_3567_56392_1_4FC3556A36EE3646A09DAA60429F5335078CA06B@PUEXCBL0.nanterre.francetelecom.fr> In-Reply-To: <20120105012920.GB7464@slice> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] I-D Action: draft-ietf-idr-error-handling-01.txt Thread-Index: AczLSXRSk+DFBBh4SJaWnEcahdWs+gAO94vg References: <4EEB78E5.6070809@raszuk.net> <20111216220720.GB10812@diehard.n-r-g.com> <4EEBE42B.2020700@cisco.com> <20111217103952.GA7158@diehard.n-r-g.com> <26782_1324294649_4EEF21F9_26782_3157_1_53C29892C857584299CBF5D05346208A010D51@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4EEF4942.6050105@raszuk.net> <22583_1324309396_4EEF5B94_22583_6701_1_53C29892C857584299CBF5D05346208A010EC8@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4EEF6192.1090901@raszuk.net> <29770_1324997549_4EF9DBAD_29770_218328_1_4FC3556A36EE3646A09DAA60429F533507861664@PUEXCBL0.nanterre.francetelecom.fr> <20120105012920.GB7464@slice> From: To: "Jeffrey Haas" X-OriginalArrivalTime: 05 Jan 2012 08:41:30.0391 (UTC) FILETIME=[D2294270:01CCCB85] X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.1.5.80024 Cc: DECRAENE Bruno RD-CORE , robert@raszuk.net, idr@ietf.org Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-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, 05 Jan 2012 08:41:34 -0000 Hi Jeff, I had a feedback from our Juniper SE that said that support is only "partia= l" but without details ... So don't know what is behind ... Regards, Stephane -----Message d'origine----- De : Jeffrey Haas [mailto:jhaas@pfrc.org]=20 Envoy=E9 : jeudi 5 janvier 2012 02:29 =C0 : LITKOWSKI Stephane DTF/DERX Cc : Ilya Varlashkin; robert@raszuk.net; DECRAENE Bruno RD-CORE; idr@ietf.o= rg Objet : Re: [Idr] I-D Action: draft-ietf-idr-error-handling-01.txt On Tue, Dec 27, 2011 at 03:52:27PM +0100, stephane.litkowski@orange.com wro= te: > Alcatel/Cisco were not supporting DampPeerOscillations when the survey wa= s done. Maybe it changed, maybe not (RFC is old ...). > No feedback about Juniper. Like many things in the updated FSM in RFC 4271, you could say JunOS suppor= ts DampPeerOscillations if you squint at it a little.=20=20 -- Jeff ___________________________________________________________________________= ______________________________________________ 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 authorization. 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 shall not be liable if th= is message was modified, changed or falsified. Thank you. From jhaas@slice.pfrc.org Thu Jan 5 06:58: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 F40F621F8577 for ; Thu, 5 Jan 2012 06:58:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.547 X-Spam-Level: X-Spam-Status: No, score=-101.547 tagged_above=-999 required=5 tests=[AWL=0.718, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 FynDWQ6UGvGG for ; Thu, 5 Jan 2012 06:58:52 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 8C41C21F8541 for ; Thu, 5 Jan 2012 06:58:52 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 1B7F5224137; Thu, 5 Jan 2012 14:58:51 +0000 (UTC) Date: Thu, 5 Jan 2012 09:58:50 -0500 From: Jeffrey Haas To: stephane.litkowski@orange.com Message-ID: <20120105145850.GG7464@slice> References: <4EEBE42B.2020700@cisco.com> <20111217103952.GA7158@diehard.n-r-g.com> <26782_1324294649_4EEF21F9_26782_3157_1_53C29892C857584299CBF5D05346208A010D51@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4EEF4942.6050105@raszuk.net> <22583_1324309396_4EEF5B94_22583_6701_1_53C29892C857584299CBF5D05346208A010EC8@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4EEF6192.1090901@raszuk.net> <29770_1324997549_4EF9DBAD_29770_218328_1_4FC3556A36EE3646A09DAA60429F533507861664@PUEXCBL0.nanterre.francetelecom.fr> <20120105012920.GB7464@slice> <3567_1325752890_4F05623A_3567_56392_1_4FC3556A36EE3646A09DAA60429F5335078CA06B@PUEXCBL0.nanterre.francetelecom.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3567_1325752890_4F05623A_3567_56392_1_4FC3556A36EE3646A09DAA60429F5335078CA06B@PUEXCBL0.nanterre.francetelecom.fr> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: DECRAENE Bruno RD-CORE , robert@raszuk.net, idr@ietf.org Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-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, 05 Jan 2012 14:58:53 -0000 One last followup here since it's apropos to the implementation report, but I suggest further followups on Juniper specific details off-list. On Thu, Jan 05, 2012 at 09:41:28AM +0100, stephane.litkowski@orange.com wrote: > I had a feedback from our Juniper SE that said that support is only "partial" but without details ... So don't know what is behind ... Upon a connection failing, the implementation will have a backoff for three exponentially increasing intervals. This has been in the implementation for quite some time. This happens to preserve the spirit of the DampPeerOscillations feature. What is likely not 100% compliant is all of the FSM transition logic surrounding the backoff. Speaking as an individual contributor, I believe IDR was pushed into having an excessively complicated FSM where many of the details are not relevant to on-the-wire behavior. I doubt you'll find a 100% compliant with all of the optional knobs implementation that's more than a few years old. (And, if someone was doing a fresh implementation, we should have seen errata filed against the FSM - I was aware of at least two minor issues with it, but this was prior to the errata system going online and those notes are gone.) -- Jeff From internet-drafts@ietf.org Tue Jan 10 15:42: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 C494E5E8001; Tue, 10 Jan 2012 15:42:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.040, 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 UXxl5fQS1z28; Tue, 10 Jan 2012 15:42:17 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F3BF21F86E4; Tue, 10 Jan 2012 15:42:17 -0800 (PST) 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: 3.64p1 Message-ID: <20120110234217.15392.42019.idtracker@ietfa.amsl.com> Date: Tue, 10 Jan 2012 15:42:17 -0800 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-as0-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, 10 Jan 2012 23:42:17 -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 : Codification of AS 0 processing. Author(s) : Warren Kumari Randy Bush Heather Schiller Keyur Patel Filename : draft-ietf-idr-as0-02.txt Pages : 7 Date : 2012-01-10 This document proscribes the use of AS 0 in BGP OPEN and AS_PATH / AS4_PATH BGP attribute. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-as0-02.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-as0-02.txt From warren@kumari.net Tue Jan 10 15: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 DB5A221F85F7 for ; Tue, 10 Jan 2012 15:53:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.231 X-Spam-Level: X-Spam-Status: No, score=-106.231 tagged_above=-999 required=5 tests=[AWL=-0.232, 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 qKU-iqf9bJBP for ; Tue, 10 Jan 2012 15:53:08 -0800 (PST) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 33E3221F8777 for ; Tue, 10 Jan 2012 15:53:07 -0800 (PST) Received: from [192.168.0.12] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id E709A1B40BCB; Tue, 10 Jan 2012 18:53:06 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: <0ED867EB33AB2B45AAB470D5A64CDBF6181C654044@EUSAACMS0701.eamcs.ericsson.se> Date: Tue, 10 Jan 2012 18:53:06 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20111216182324.17528.28150.idtracker@ietfa.amsl.com> <9CD76392-6F52-441C-BCF5-2335D7F49B8F@kumari.net> <4EEBEAEB.8070304@cisco.com> <0156DFD0-B706-42B0-93AB-89C9E6E252FD@kumari.net> <20120105014532.GC7464@slice> <0ED867EB33AB2B45AAB470D5A64CDBF6181C654044@EUSAACMS0701.eamcs.ericsson.se> To: Jeff Tantsura X-Mailer: Apple Mail (2.1084) Cc: "keyupate@cisco.com" , "idr@ietf.org" Subject: Re: [Idr] I-D Action: draft-ietf-idr-as0-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: Tue, 10 Jan 2012 23:53:09 -0000 On Jan 4, 2012, at 8:51 PM, Jeff Tantsura wrote: > +1 >=20 Thank you. I have just uploaded a new version with this text slightly changed, = please confirm that this version is still acceptable to you. Keyur also pointed out that AS numbers show up in all sorts of other = places (as an example, AS specific Extended Communities) -- as they may = show up in yet more places as BGP gets extended I also inserted some = fairly generic text saying that you SHOULD handle these as malformed and = respond appropriately. While not ideal, I think it is OK. W > Regards, > Jeff > -----Original Message----- > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of = Jeffrey Haas > Sent: Wednesday, January 04, 2012 5:46 PM > To: Warren Kumari > Cc: keyupate@cisco.com; idr@ietf.org > Subject: Re: [Idr] I-D Action: draft-ietf-idr-as0-01.txt >=20 > [Explicit cc on the draft-ietf-idr-error-handling authors for the = comments below.] >=20 > Warren, >=20 > On Sat, Dec 17, 2011 at 12:26:10PM -0500, Warren Kumari wrote: >> On Dec 16, 2011, at 8:05 PM, Enke Chen wrote: >>> 1) Is it really necessary to make AS 0 an error in the AGGREGATOR = and AS4_AGGREGATOR attributes? What is the gain? >>=20 >> I'll double check with co-authors on Monday -- I don't think it is = strictly necessary to prevent attack, rather it seemed more elegant to = check AS 0 where ever it occurs. >=20 > While I generally agree with Enke that treating as a malformed route = is probably excessive, I think the recommended behavior is desirable. = The mandate that the error-handling draft procedures must be used makes = it acceptable. Without those procedures, bouncing the session is almost = certainly the wrong thing to do. >=20 >> It was brought up on the NANOG list that some vendors support = zero'ing=20 >> out the AGGREGATOR (see Junipers "no-aggregator-id" as an example --=20= >> this appears to only zero out the router ID, but I haven't checked = all=20 >> implementations), so checking for AS 0 in the .*AGGREGATOR may be a=20= >> bad idea, so at the moment I'm leaning towards removing it = (obviously,=20 >> this being a WG doc, with the WG's approval) >=20 > Older varieties of gated had bugs with respect to the AS number that = was selected to be placed in the aggregator AS field. JunOS may have = had similar bugs at one point but the behavior that I can see in a = cursory check of the code should result in a system AS number being = placed there. >=20 > My recommendation for the as0 draft is that we leave in the current = text and let the attribute be treated as "malformed" by the = error-handling draft. > The behavior in that draft of attribute-discard is reasonable. >=20 >>> 2) The error handling for AS4_PATH / AS4_AGGREGATOR is specified in = rfc4893bis (draft-ietf-idr-rfc4893bis-04.txt). Thus it should be = referenced if you specify AS 0 as an error for the AS4_PATH / = AS4_AGGREGATOR. >>>=20 >>=20 >> Doh! This was mentioned a few times and I intended to do so, but it = completely slipped my mind when typing... Thanks for reminding me.... >=20 > Similarly, there should be references for these attributes added to = the error-handling draft. >=20 > -- Jeff > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr >=20 --- Don't be impressed with unintelligible stuff said condescendingly . -- Radia Perlman. Warren Kumari warren@kumari.net From internet-drafts@ietf.org Tue Jan 10 19:30: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 963B121F8559; Tue, 10 Jan 2012 19:30:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.56 X-Spam-Level: X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=0.039, 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 dBmt2-a6WtG3; Tue, 10 Jan 2012 19:30:07 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36D4821F854B; Tue, 10 Jan 2012 19:30:07 -0800 (PST) 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: 3.64p1 Message-ID: <20120111033007.4379.78063.idtracker@ietfa.amsl.com> Date: Tue, 10 Jan 2012 19:30:07 -0800 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-bgp-extended-messages-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, 11 Jan 2012 03:30: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 : Extended Message support for BGP Author(s) : Keyur Patel Dave Ward Randy Bush Filename : draft-ietf-idr-bgp-extended-messages-02.txt Pages : 5 Date : 2012-01-10 The BGP specification mandates a maximum BGP message size of 4096 octets. As BGP is extended to support newer AFI/SAFIs, there is a need to extend the maximum message size beyond 4096 octets. This draft provides an extension to BGP to extend its current message size from 4096 octets to 65535 octets. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-extended-messages-02= .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-bgp-extended-messages-02.= txt From ttauber@1-4-5.net Tue Jan 10 20:21: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 7612411E8087 for ; Tue, 10 Jan 2012 20:21:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.376 X-Spam-Level: X-Spam-Status: No, score=-102.376 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1, 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 v+gAIPA6dWuE for ; Tue, 10 Jan 2012 20:21:09 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id A402A11E8080 for ; Tue, 10 Jan 2012 20:21:06 -0800 (PST) Received: by vcbfk13 with SMTP id fk13so259278vcb.31 for ; Tue, 10 Jan 2012 20:21:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.155.142 with SMTP id s14mr14287525vcw.20.1326255664489; Tue, 10 Jan 2012 20:21:04 -0800 (PST) Received: by 10.220.180.200 with HTTP; Tue, 10 Jan 2012 20:21:04 -0800 (PST) X-Originating-IP: [24.104.152.66] In-Reply-To: References: <20111216182324.17528.28150.idtracker@ietfa.amsl.com> <9CD76392-6F52-441C-BCF5-2335D7F49B8F@kumari.net> <4EEBEAEB.8070304@cisco.com> <0156DFD0-B706-42B0-93AB-89C9E6E252FD@kumari.net> <20120105014532.GC7464@slice> <0ED867EB33AB2B45AAB470D5A64CDBF6181C654044@EUSAACMS0701.eamcs.ericsson.se> Date: Tue, 10 Jan 2012 23:21:04 -0500 Message-ID: From: Tony Tauber To: Warren Kumari Content-Type: multipart/alternative; boundary=f46d04389439c3671604b638f550 Cc: "keyupate@cisco.com" , "idr@ietf.org" Subject: Re: [Idr] I-D Action: draft-ietf-idr-as0-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: Wed, 11 Jan 2012 04:21:10 -0000 --f46d04389439c3671604b638f550 Content-Type: text/plain; charset=ISO-8859-1 A zero in the "ASN portion" of a community value may not be a good practice in that it may be harder to figure out who injected it, but I don't think it needs to be considered an error from a software processing point of view. Tony On Tue, Jan 10, 2012 at 6:53 PM, Warren Kumari wrote: > > On Jan 4, 2012, at 8:51 PM, Jeff Tantsura wrote: > > > +1 > > > > Thank you. > > I have just uploaded a new version with this text slightly changed, please > confirm that this version is still acceptable to you. > > Keyur also pointed out that AS numbers show up in all sorts of other > places (as an example, AS specific Extended Communities) -- as they may > show up in yet more places as BGP gets extended I also inserted some fairly > generic text saying that you SHOULD handle these as malformed and respond > appropriately. While not ideal, I think it is OK. > > > W > > > > Regards, > > Jeff > > -----Original Message----- > > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of > Jeffrey Haas > > Sent: Wednesday, January 04, 2012 5:46 PM > > To: Warren Kumari > > Cc: keyupate@cisco.com; idr@ietf.org > > Subject: Re: [Idr] I-D Action: draft-ietf-idr-as0-01.txt > > > > [Explicit cc on the draft-ietf-idr-error-handling authors for the > comments below.] > > > > Warren, > > > > On Sat, Dec 17, 2011 at 12:26:10PM -0500, Warren Kumari wrote: > >> On Dec 16, 2011, at 8:05 PM, Enke Chen wrote: > >>> 1) Is it really necessary to make AS 0 an error in the AGGREGATOR and > AS4_AGGREGATOR attributes? What is the gain? > >> > >> I'll double check with co-authors on Monday -- I don't think it is > strictly necessary to prevent attack, rather it seemed more elegant to > check AS 0 where ever it occurs. > > > > While I generally agree with Enke that treating as a malformed route is > probably excessive, I think the recommended behavior is desirable. The > mandate that the error-handling draft procedures must be used makes it > acceptable. Without those procedures, bouncing the session is almost > certainly the wrong thing to do. > > > >> It was brought up on the NANOG list that some vendors support zero'ing > >> out the AGGREGATOR (see Junipers "no-aggregator-id" as an example -- > >> this appears to only zero out the router ID, but I haven't checked all > >> implementations), so checking for AS 0 in the .*AGGREGATOR may be a > >> bad idea, so at the moment I'm leaning towards removing it (obviously, > >> this being a WG doc, with the WG's approval) > > > > Older varieties of gated had bugs with respect to the AS number that was > selected to be placed in the aggregator AS field. JunOS may have had > similar bugs at one point but the behavior that I can see in a cursory > check of the code should result in a system AS number being placed there. > > > > My recommendation for the as0 draft is that we leave in the current text > and let the attribute be treated as "malformed" by the error-handling draft. > > The behavior in that draft of attribute-discard is reasonable. > > > >>> 2) The error handling for AS4_PATH / AS4_AGGREGATOR is specified in > rfc4893bis (draft-ietf-idr-rfc4893bis-04.txt). Thus it should be referenced > if you specify AS 0 as an error for the AS4_PATH / AS4_AGGREGATOR. > >>> > >> > >> Doh! This was mentioned a few times and I intended to do so, but it > completely slipped my mind when typing... Thanks for reminding me.... > > > > Similarly, there should be references for these attributes added to the > error-handling draft. > > > > -- Jeff > > _______________________________________________ > > Idr mailing list > > Idr@ietf.org > > https://www.ietf.org/mailman/listinfo/idr > > > > > --- > Don't be impressed with unintelligible stuff said condescendingly . > -- Radia Perlman. > > Warren Kumari > warren@kumari.net > > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --f46d04389439c3671604b638f550 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable A zero in the "ASN portion" of a community value may not be a goo= d practice in that it may be harder to figure out who injected it, but I do= n't think it needs to be considered an error from a software processing= point of view.

Tony

On Tue, Jan 10, 2012 at 6:53 PM,= Warren Kumari <w= arren@kumari.net> wrote:

On Jan 4, 2012, at 8:51 PM, Jeff Tantsura wrote:

> +1
>

Thank you.

I have just uploaded a new version with this text slightly changed, please = confirm that this version is still acceptable to you.

Keyur also pointed out that AS numbers show up in all sorts of other places= (as an example, AS specific Extended Communities) -- as they may show up i= n yet more places as BGP gets extended I also inserted some fairly generic = text saying that you SHOULD handle these as malformed and respond appropria= tely. While not ideal, I think it is OK.


W


> Regards,
> Jeff
> -----Original Message-----
> From: idr-bounces@ietf.org= [mailto:idr-bounces@ietf.org] = On Behalf Of Jeffrey Haas
> Sent: Wednesday, January 04, 2012 5:46 PM
> To: Warren Kumari
> Cc: keyupate@cisco.com; idr@ietf.org
> Subject: Re: [Idr] I-D Action: draft-ietf-idr-as0-01.txt
>
> [Explicit cc on the draft-ietf-idr-error-handling authors for the comm= ents below.]
>
> Warren,
>
> On Sat, Dec 17, 2011 at 12:26:10PM -0500, Warren Kumari wrote:
>> On Dec 16, 2011, at 8:05 PM, Enke Chen wrote:
>>> 1) Is it really necessary to make AS 0 an error in the AGGREGA= TOR and AS4_AGGREGATOR attributes? =A0What is the gain?
>>
>> I'll double check with co-authors on Monday -- I don't thi= nk it is strictly necessary to prevent attack, rather it seemed more elegan= t to check AS 0 where ever it occurs.
>
> While I generally agree with Enke that treating as a malformed route i= s probably excessive, I think the recommended behavior is desirable. =A0The= mandate that the error-handling draft procedures must be used makes it acc= eptable. =A0Without those procedures, bouncing the session is almost certai= nly the wrong thing to do.
>
>> It was brought up on the NANOG list that some vendors support zero= 'ing
>> out the AGGREGATOR (see Junipers "no-aggregator-id" as a= n example --
>> this appears to only zero out the router ID, but I haven't che= cked all
>> implementations), so checking for AS 0 in the .*AGGREGATOR may be = a
>> bad idea, so at the moment I'm leaning towards removing it (ob= viously,
>> this being a WG doc, with the WG's approval)
>
> Older varieties of gated had bugs with respect to the AS number that w= as selected to be placed in the aggregator AS field. =A0JunOS may have had = similar bugs at one point but the behavior that I can see in a cursory chec= k of the code should result in a system AS number being placed there.
>
> My recommendation for the as0 draft is that we leave in the current te= xt and let the attribute be treated as "malformed" by the error-h= andling draft.
> The behavior in that draft of attribute-discard is reasonable.
>
>>> 2) The error handling for AS4_PATH / AS4_AGGREGATOR is specifi= ed in rfc4893bis (draft-ietf-idr-rfc4893bis-04.txt). Thus it should be refe= renced if you specify AS 0 as an error for the AS4_PATH / AS4_AGGREGATOR. >>>
>>
>> Doh! This was mentioned a few times and I intended to do so, but i= t completely slipped my mind when typing... Thanks for reminding me....
>
> Similarly, there should be references for these attributes added to th= e error-handling draft.
>
> -- Jeff
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>


---
Don't be impressed with unintelligible stuff said condescendingly .
=A0 =A0-- Radia Perlman.

Warren Kumari
warren@kumari.net



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

--f46d04389439c3671604b638f550-- From bruno.decraene@orange.com Thu Jan 12 00:45: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 16B6D21F84CE for ; Thu, 12 Jan 2012 00:45:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.648 X-Spam-Level: X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[AWL=0.350, 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 4D+s5Inhez9H for ; Thu, 12 Jan 2012 00:45:37 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id DCF8A21F84C8 for ; Thu, 12 Jan 2012 00:45:36 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 63757E0009; Thu, 12 Jan 2012 09:45:33 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 46D41238059; Thu, 12 Jan 2012 09:45:33 +0100 (CET) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.01.0323.000; Thu, 12 Jan 2012 09:45:33 +0100 From: To: Warren Kumari , "keyupate@cisco.com" , "idr@ietf.org" Thread-Topic: draft-ietf-idr-as0-02 Thread-Index: AQHMz/MEFqlIdevVtEaq6d63tiSU4pYIZZ1w Date: Thu, 12 Jan 2012 08:45:31 +0000 Message-ID: <24590_1326357933_4F0E9DAD_24590_2274_1_53C29892C857584299CBF5D05346208A0166A9@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <20111216182324.17528.28150.idtracker@ietfa.amsl.com> <9CD76392-6F52-441C-BCF5-2335D7F49B8F@kumari.net> <4EEBEAEB.8070304@cisco.com> <0156DFD0-B706-42B0-93AB-89C9E6E252FD@kumari.net> <20120105014532.GC7464@slice> <0ED867EB33AB2B45AAB470D5A64CDBF6181C654044@EUSAACMS0701.eamcs.ericsson.se> 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.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.1.11.215414 Subject: [Idr] draft-ietf-idr-as0-02 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, 12 Jan 2012 08:45:38 -0000 Hi Warren, Keyur, all, >From: Warren Kumari >Sent: Wednesday, January 11, 2012 12:53 AM [...] >Keyur also pointed out that AS numbers show up in all sorts of other place= s (as >an example, AS specific Extended Communities) -- as they may show up in yet >more places as BGP gets extended I also inserted some fairly generic text >saying that you SHOULD handle these as malformed and respond appropriately. >While not ideal, I think it is OK. Warren, thanks for highlighting the diff on the IDR mailing list. v02 of the draft adds: "As UPDATE with zero in any other field where an AS = number is expected (for example, "4-Octet AS specific Extended Community" [= RFC5668]) SHOULD be treated as malformed and handled appropriately." 1) This is in contradiction with the use of AS number 0 for "well known" / = IANA assigned communities. Both regular ones as defined in RFC 1997 and ext= ended ones as defined in draft-ietf-idr-reserved-extended-communities. So a= t the minimum, these 2 usages must be allowed. 2) More generally, I tend to disagree with this addition: - for existing fields, this document should specify where the use of AS 0 i= s accepted or not (and hence treated as error). (for simplicity, I guess it= 's enough to defined fields when it's not accepted) - for future fields, IMO this document should only call for asking further = specifications to define what should be the behavior with AS 0. And for existing fields, IMHO, this document should be conservative with re= gards to its change on existing specifications. IMHO it should only forbid = the use of AS 0 when necessary (for your new use case). As an another example, I don't think treating as an error a BGP/MPLS VPN ro= ute having an AS 0 in its Route Target or Route Distinguisher field is a go= od idea. This may unexpectedly withdraw VPN routes in some live networks. A= nd I don't see a reason for this. Thanks, Regards, Bruno PS: Obviously my comment also applies to the following v02 addition "A BGP = speaker SHOULD NOT generate or propagate an UPDATE with zero in any field w= here an AS number is expected (for example, "4-Octet AS specific Extended C= ommunity" [RFC5668]) > >W > > >> Regards, >> Jeff >> -----Original Message----- >> From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Je= ffrey >Haas >> Sent: Wednesday, January 04, 2012 5:46 PM >> To: Warren Kumari >> Cc: keyupate@cisco.com; idr@ietf.org >> Subject: Re: [Idr] I-D Action: draft-ietf-idr-as0-01.txt >> >> [Explicit cc on the draft-ietf-idr-error-handling authors for the commen= ts >below.] >> >> Warren, >> >> On Sat, Dec 17, 2011 at 12:26:10PM -0500, Warren Kumari wrote: >>> On Dec 16, 2011, at 8:05 PM, Enke Chen wrote: >>>> 1) Is it really necessary to make AS 0 an error in the AGGREGATOR and >AS4_AGGREGATOR attributes? What is the gain? >>> >>> I'll double check with co-authors on Monday -- I don't think it is stri= ctly >necessary to prevent attack, rather it seemed more elegant to check AS 0 w= here >ever it occurs. >> >> While I generally agree with Enke that treating as a malformed route is >probably excessive, I think the recommended behavior is desirable. The ma= ndate >that the error-handling draft procedures must be used makes it acceptable. >Without those procedures, bouncing the session is almost certainly the wro= ng >thing to do. >> >>> It was brought up on the NANOG list that some vendors support zero'ing >>> out the AGGREGATOR (see Junipers "no-aggregator-id" as an example -- >>> this appears to only zero out the router ID, but I haven't checked all >>> implementations), so checking for AS 0 in the .*AGGREGATOR may be a >>> bad idea, so at the moment I'm leaning towards removing it (obviously, >>> this being a WG doc, with the WG's approval) >> >> Older varieties of gated had bugs with respect to the AS number that was >selected to be placed in the aggregator AS field. JunOS may have had simi= lar >bugs at one point but the behavior that I can see in a cursory check of the >code should result in a system AS number being placed there. >> >> My recommendation for the as0 draft is that we leave in the current text= and >let the attribute be treated as "malformed" by the error-handling draft. >> The behavior in that draft of attribute-discard is reasonable. >> >>>> 2) The error handling for AS4_PATH / AS4_AGGREGATOR is specified in >rfc4893bis (draft-ietf-idr-rfc4893bis-04.txt). Thus it should be reference= d if >you specify AS 0 as an error for the AS4_PATH / AS4_AGGREGATOR. >>>> >>> >>> Doh! This was mentioned a few times and I intended to do so, but it >completely slipped my mind when typing... Thanks for reminding me.... >> >> Similarly, there should be references for these attributes added to the >error-handling draft. >> >> -- Jeff >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr >> > > >--- >Don't be impressed with unintelligible stuff said condescendingly . > -- Radia Perlman. > >Warren Kumari >warren@kumari.net > > > >_______________________________________________ >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 authorization. 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 shall not be liable if th= is message was modified, changed or falsified. Thank you. From bruno.decraene@orange.com Thu Jan 12 06:56: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 A769621F8592 for ; Thu, 12 Jan 2012 06:56:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.065 X-Spam-Level: X-Spam-Status: No, score=-2.065 tagged_above=-999 required=5 tests=[AWL=0.533, 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 e+j1CKnv+tBN for ; Thu, 12 Jan 2012 06:56:38 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 3220D21F8587 for ; Thu, 12 Jan 2012 06:56:33 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id DEDE118C487 for ; Thu, 12 Jan 2012 15:56:31 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id C30A7238061 for ; Thu, 12 Jan 2012 15:56:31 +0100 (CET) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.01.0323.000; Thu, 12 Jan 2012 15:56:31 +0100 From: To: "idr@ietf.org" Thread-Topic: draft-ietf-idr-error-handling Thread-Index: AczROl3MjbHyjBOYTdaYkGYE2ygt8Q== Date: Thu, 12 Jan 2012 14:56:30 +0000 Message-ID: <14376_1326380191_4F0EF49F_14376_3284_1_53C29892C857584299CBF5D05346208A016944@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.3] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.1.11.215414 Subject: [Idr] draft-ietf-idr-error-handling 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, 12 Jan 2012 14:56:38 -0000 Hi all, The draft currently does not discuss nor address how to recover from error = i.e. for the BGP receiver to get back all the NLRI / attributes after it ha= s withdrawn/discarded some. IMHO it should as the current mechanism it is r= eplacing (session reset) address both error handling and error recovery. In order to initiate discussion on this, may I suggest the following text: When the approach "treat-as-withdraw" or "attribute discard" has been used = on a BGP session, the BGP receiver has not the full set of attributes or NL= RI that the BGP speaker sent. There MUST be a way to latter recover from th= is inconsistency. In some cases, this inconsistency will naturally be resolved. As the error = is fixed on the speaker or on an upstream speaker (possibly the originator = of the route), the BGP attribute in error will be updated and a new UPDATE = message will be propagated on downstream BGP routers. If the error has inde= ed been fixed, the new BGP UPDATE message will be accepted and the dropped = attribute or withdrawn NLRI will be learnt again. To cover remaining cases, an automatic recovery mechanism SHOULD be impleme= nted. The use of the ROUTE-REFRESH message is suggested but others non traf= fic disruptive mechanisms may be used. This recovery mechanism SHOULD be in= itiated after a configurable delay. If the mechanism failed to recover all = NLRI or attributes in error, subsequent tentative SHOULD be initiated after= a timer. Timer value SHOULD be carefully defined to allow for both a reaso= nably quick recovery and a reasonable impact on the BGP control plane load.= The use of a (exponential) backof algorithm may be considered. The maximum= value should be high enough (e.g. days) in order for the mechanism to keep= trying the recovery possibly for ever while having a low impact on the BGP= control plane. Timer MAY be on a per BGP session basis or MAY be global to= the BGP speaker. If an implementation chooses not the implement an automatic recovery mechan= ism, when or prior to configure this revised error handling, network operat= or MUST be made aware that the recovery will require a manual action (typic= ally a session (soft) reset). 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 authorization. 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 shall not be liable if th= is message was modified, changed or falsified. Thank you. From enkechen@cisco.com Thu Jan 12 09:49: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 DE48E21F859A for ; Thu, 12 Jan 2012 09:49:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[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 CD3iUZBu-sFp for ; Thu, 12 Jan 2012 09:49:13 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id D68D421F8594 for ; Thu, 12 Jan 2012 09:49:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=enkechen@cisco.com; l=7040; q=dns/txt; s=iport; t=1326390553; x=1327600153; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=1pnxuU2eGiTeqcBYV/Nx9FEEVBZkAebpuUTFhiG52CM=; b=OAOItgqmHNykyRJsWT2bbtnmep2+yMhGVdwtztLg4vjmCA+dmsKFSK2y UxEoHzms1C2GPlggmj1FHakDPywlzZCPx2HIqNk+FmIERrB9CKSHZWnax MNbCcUO94UlslN2xHpHN+kWYqOdam70e9fY/naOjAp0PLYLemlTCEH/f8 o=; X-IronPort-AV: E=Sophos;i="4.71,499,1320624000"; d="scan'208";a="25102518" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 12 Jan 2012 17:49:13 +0000 Received: from sjc-vpn6-1773.cisco.com (sjc-vpn6-1773.cisco.com [10.21.126.237]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q0CHnDW6009168; Thu, 12 Jan 2012 17:49:13 GMT Message-ID: <4F0F1DE8.1010105@cisco.com> Date: Thu, 12 Jan 2012 09:52:40 -0800 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: bruno.decraene@orange.com References: <20111216182324.17528.28150.idtracker@ietfa.amsl.com> <9CD76392-6F52-441C-BCF5-2335D7F49B8F@kumari.net> <4EEBEAEB.8070304@cisco.com> <0156DFD0-B706-42B0-93AB-89C9E6E252FD@kumari.net> <20120105014532.GC7464@slice> <0ED867EB33AB2B45AAB470D5A64CDBF6181C654044@EUSAACMS0701.eamcs.ericsson.se> <24590_1326357933_4F0E9DAD_24590_2274_1_53C29892C857584299CBF5D05346208A0166A9@PEXCVZYM11.corporate.adroot.infra.ftgroup> In-Reply-To: <24590_1326357933_4F0E9DAD_24590_2274_1_53C29892C857584299CBF5D05346208A0166A9@PEXCVZYM11.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "keyupate@cisco.com" , "idr@ietf.org" Subject: Re: [Idr] draft-ietf-idr-as0-02 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, 12 Jan 2012 17:49:15 -0000 Hi, Bruno: This is really well said, and I share the same concern: And for existing fields, IMHO, this document should be conservative with regards to its change on existing specifications. IMHO it should only forbid the use of AS 0 when necessary for your new use case). So far I have not seen much justifications (nor need) for expanding error conditions of AS 0 beyond the AS_PATH / AS4_PATH. Thanks. -- Enke On 1/12/12 12:45 AM, bruno.decraene@orange.com wrote: > Hi Warren, Keyur, all, > >> From: Warren Kumari>Sent: Wednesday, January 11, 2012 12:53 AM > [...] > >> Keyur also pointed out that AS numbers show up in all sorts of other places (as >> an example, AS specific Extended Communities) -- as they may show up in yet >> more places as BGP gets extended I also inserted some fairly generic text >> saying that you SHOULD handle these as malformed and respond appropriately. >> While not ideal, I think it is OK. > Warren, thanks for highlighting the diff on the IDR mailing list. > > v02 of the draft adds: "As UPDATE with zero in any other field where an AS number is expected (for example, "4-Octet AS specific Extended Community" [RFC5668]) SHOULD be treated as malformed and handled appropriately." > > 1) This is in contradiction with the use of AS number 0 for "well known" / IANA assigned communities. Both regular ones as defined in RFC 1997 and extended ones as defined in draft-ietf-idr-reserved-extended-communities. So at the minimum, these 2 usages must be allowed. > > 2) More generally, I tend to disagree with this addition: > - for existing fields, this document should specify where the use of AS 0 is accepted or not (and hence treated as error). (for simplicity, I guess it's enough to defined fields when it's not accepted) > - for future fields, IMO this document should only call for asking further specifications to define what should be the behavior with AS 0. > > And for existing fields, IMHO, this document should be conservative with regards to its change on existing specifications. IMHO it should only forbid the use of AS 0 when necessary (for your new use case). > As an another example, I don't think treating as an error a BGP/MPLS VPN route having an AS 0 in its Route Target or Route Distinguisher field is a good idea. This may unexpectedly withdraw VPN routes in some live networks. And I don't see a reason for this. > > Thanks, > Regards, > Bruno > > PS: Obviously my comment also applies to the following v02 addition "A BGP speaker SHOULD NOT generate or propagate an UPDATE with zero in any field where an AS number is expected (for example, "4-Octet AS specific Extended Community" [RFC5668]) > >> W >> >> >>> Regards, >>> Jeff >>> -----Original Message----- >>> From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Jeffrey >> Haas >>> Sent: Wednesday, January 04, 2012 5:46 PM >>> To: Warren Kumari >>> Cc: keyupate@cisco.com; idr@ietf.org >>> Subject: Re: [Idr] I-D Action: draft-ietf-idr-as0-01.txt >>> >>> [Explicit cc on the draft-ietf-idr-error-handling authors for the comments >> below.] >>> Warren, >>> >>> On Sat, Dec 17, 2011 at 12:26:10PM -0500, Warren Kumari wrote: >>>> On Dec 16, 2011, at 8:05 PM, Enke Chen wrote: >>>>> 1) Is it really necessary to make AS 0 an error in the AGGREGATOR and >> AS4_AGGREGATOR attributes? What is the gain? >>>> I'll double check with co-authors on Monday -- I don't think it is strictly >> necessary to prevent attack, rather it seemed more elegant to check AS 0 where >> ever it occurs. >>> While I generally agree with Enke that treating as a malformed route is >> probably excessive, I think the recommended behavior is desirable. The mandate >> that the error-handling draft procedures must be used makes it acceptable. >> Without those procedures, bouncing the session is almost certainly the wrong >> thing to do. >>>> It was brought up on the NANOG list that some vendors support zero'ing >>>> out the AGGREGATOR (see Junipers "no-aggregator-id" as an example -- >>>> this appears to only zero out the router ID, but I haven't checked all >>>> implementations), so checking for AS 0 in the .*AGGREGATOR may be a >>>> bad idea, so at the moment I'm leaning towards removing it (obviously, >>>> this being a WG doc, with the WG's approval) >>> Older varieties of gated had bugs with respect to the AS number that was >> selected to be placed in the aggregator AS field. JunOS may have had similar >> bugs at one point but the behavior that I can see in a cursory check of the >> code should result in a system AS number being placed there. >>> My recommendation for the as0 draft is that we leave in the current text and >> let the attribute be treated as "malformed" by the error-handling draft. >>> The behavior in that draft of attribute-discard is reasonable. >>> >>>>> 2) The error handling for AS4_PATH / AS4_AGGREGATOR is specified in >> rfc4893bis (draft-ietf-idr-rfc4893bis-04.txt). Thus it should be referenced if >> you specify AS 0 as an error for the AS4_PATH / AS4_AGGREGATOR. >>>> Doh! This was mentioned a few times and I intended to do so, but it >> completely slipped my mind when typing... Thanks for reminding me.... >>> Similarly, there should be references for these attributes added to the >> error-handling draft. >>> -- Jeff >>> _______________________________________________ >>> Idr mailing list >>> Idr@ietf.org >>> https://www.ietf.org/mailman/listinfo/idr >>> >> >> --- >> Don't be impressed with unintelligible stuff said condescendingly . >> -- Radia Perlman. >> >> Warren Kumari >> warren@kumari.net >> >> >> >> _______________________________________________ >> 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 authorization. > 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 shall not be liable if this message was modified, changed or falsified. > Thank you. > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From robert@raszuk.net Thu Jan 12 10:04: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 96BAE21F867A for ; Thu, 12 Jan 2012 10:04:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wpJDGGDo216g for ; Thu, 12 Jan 2012 10:04:51 -0800 (PST) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 9A8BD21F8674 for ; Thu, 12 Jan 2012 10:04:51 -0800 (PST) Received: (qmail 3041 invoked by uid 399); 12 Jan 2012 18:04:45 -0000 Received: from unknown (HELO ?216.69.69.180?) (216.69.69.180) by mail1310.opentransfer.com with ESMTP; 12 Jan 2012 18:04:45 -0000 X-Originating-IP: 216.69.69.180 Message-ID: <4F0F20C0.9020807@raszuk.net> Date: Thu, 12 Jan 2012 19:04:48 +0100 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: bruno.decraene@orange.com References: <14376_1326380191_4F0EF49F_14376_3284_1_53C29892C857584299CBF5D05346208A016944@PEXCVZYM11.corporate.adroot.infra.ftgroup> In-Reply-To: <14376_1326380191_4F0EF49F_14376_3284_1_53C29892C857584299CBF5D05346208A016944@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-ietf-idr-error-handling 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, 12 Jan 2012 18:04:52 -0000 Hi Bruno, The recovery you are proposing is a valid concern. However what you are proposing will be just local across given ebgp session while the error as many have pointed out on this topic before may have been originated far away. In such case periodic refresh requests or even soft clear will just result in continued reception of bad attributes and their local drops and it will not help to recover at all. The session drop had the nice property of raising red alarms on NOC screens. It normally (other then in some implementations periodic reestablishment attempts) did not correct the problem. So in the "treat-as-withdraw" cases perhaps what needs to happen the same level of red alarms will be seen by NOCs and either manual or automated triggered scripting will attempt to recover from the problem. Therefor I am not sure if adding any mechanism for recovery to the draft is required. Worse it may even further be received by some NOCs as sort of let the network fix itself message. Best regards, R. > Hi all, > > The draft currently does not discuss nor address how to recover from > error i.e. for the BGP receiver to get back all the NLRI / attributes > after it has withdrawn/discarded some. IMHO it should as the current > mechanism it is replacing (session reset) address both error handling > and error recovery. In order to initiate discussion on this, may I > suggest the following text: > > > When the approach "treat-as-withdraw" or "attribute discard" has been > used on a BGP session, the BGP receiver has not the full set of > attributes or NLRI that the BGP speaker sent. There MUST be a way to > latter recover from this inconsistency. > > In some cases, this inconsistency will naturally be resolved. As the > error is fixed on the speaker or on an upstream speaker (possibly the > originator of the route), the BGP attribute in error will be updated > and a new UPDATE message will be propagated on downstream BGP > routers. If the error has indeed been fixed, the new BGP UPDATE > message will be accepted and the dropped attribute or withdrawn NLRI > will be learnt again. > > To cover remaining cases, an automatic recovery mechanism SHOULD be > implemented. The use of the ROUTE-REFRESH message is suggested but > others non traffic disruptive mechanisms may be used. This recovery > mechanism SHOULD be initiated after a configurable delay. If the > mechanism failed to recover all NLRI or attributes in error, > subsequent tentative SHOULD be initiated after a timer. Timer value > SHOULD be carefully defined to allow for both a reasonably quick > recovery and a reasonable impact on the BGP control plane load. The > use of a (exponential) backof algorithm may be considered. The > maximum value should be high enough (e.g. days) in order for the > mechanism to keep trying the recovery possibly for ever while having > a low impact on the BGP control plane. Timer MAY be on a per BGP > session basis or MAY be global to the BGP speaker. > > If an implementation chooses not the implement an automatic recovery > mechanism, when or prior to configure this revised error handling, > network operator MUST be made aware that the recovery will require a > manual action (typically a session (soft) reset). > > > Thanks, 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 authorization. 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 shall not be liable if this message was modified, > changed or falsified. Thank you. > > _______________________________________________ Idr mailing list > Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr > > From jhaas@slice.pfrc.org Thu Jan 12 10:13: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 E7C6621F85D6 for ; Thu, 12 Jan 2012 10:13:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.032 X-Spam-Level: X-Spam-Status: No, score=-102.032 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 jPdmAhqndriK for ; Thu, 12 Jan 2012 10:13:44 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 3481521F8484 for ; Thu, 12 Jan 2012 10:13:44 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 7E3F8224141; Thu, 12 Jan 2012 18:13:43 +0000 (UTC) Date: Thu, 12 Jan 2012 13:13:43 -0500 From: Jeffrey Haas To: Enke Chen Message-ID: <20120112181343.GY7464@slice> References: <20111216182324.17528.28150.idtracker@ietfa.amsl.com> <9CD76392-6F52-441C-BCF5-2335D7F49B8F@kumari.net> <4EEBEAEB.8070304@cisco.com> <0156DFD0-B706-42B0-93AB-89C9E6E252FD@kumari.net> <20120105014532.GC7464@slice> <0ED867EB33AB2B45AAB470D5A64CDBF6181C654044@EUSAACMS0701.eamcs.ericsson.se> <24590_1326357933_4F0E9DAD_24590_2274_1_53C29892C857584299CBF5D05346208A0166A9@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4F0F1DE8.1010105@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F0F1DE8.1010105@cisco.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "keyupate@cisco.com" , bruno.decraene@orange.com, "idr@ietf.org" Subject: Re: [Idr] draft-ietf-idr-as0-02 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, 12 Jan 2012 18:13:45 -0000 On Thu, Jan 12, 2012 at 09:52:40AM -0800, Enke Chen wrote: > Hi, Bruno: > > This is really well said, and I share the same concern: > > And for existing fields, IMHO, this document should be conservative with regards to its > change on existing specifications. IMHO it should only forbid the use of AS 0 when necessary > for your new use case). > > > So far I have not seen much justifications (nor need) for expanding > error conditions of AS 0 beyond the AS_PATH / AS4_PATH. I also agree. I think the text as written tends to violate the Robustness principle. -- Jeff From jakob.heitz@ericsson.com Thu Jan 12 11:13: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 E819621F8589 for ; Thu, 12 Jan 2012 11:13:42 -0800 (PST) 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, 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 n8hEbDwvbG8s for ; Thu, 12 Jan 2012 11:13:42 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 1E1BE21F857D for ; Thu, 12 Jan 2012 11:13:42 -0800 (PST) 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 q0CJDdEq001288; Thu, 12 Jan 2012 13:13:41 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.20]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Thu, 12 Jan 2012 14:13:36 -0500 From: Jakob Heitz To: "robert@raszuk.net" , "bruno.decraene@orange.com" Date: Thu, 12 Jan 2012 14:13:35 -0500 Thread-Topic: [Idr] draft-ietf-idr-error-handling Thread-Index: AczRVL7RQDF/3NjbTaS0+l15rlM8bAACSysQ Message-ID: <7309FCBCAE981B43ABBE69B31C8D21391A47997E56@EUSAACMS0701.eamcs.ericsson.se> References: <14376_1326380191_4F0EF49F_14376_3284_1_53C29892C857584299CBF5D05346208A016944@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4F0F20C0.9020807@raszuk.net> In-Reply-To: <4F0F20C0.9020807@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-ietf-idr-error-handling 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, 12 Jan 2012 19:13:43 -0000 One thing is clear: the originator of the malformed message needs manual intervention. No automatic fix is possible. Question is: once the originator is fixed, will the corrected updates propagate properly throughout the Internet? -- Jakob Heitz. -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Rober= t Raszuk Sent: Thursday, January 12, 2012 10:05 AM To: bruno.decraene@orange.com Cc: idr@ietf.org Subject: Re: [Idr] draft-ietf-idr-error-handling Hi Bruno, The recovery you are proposing is a valid concern. However what you are=20 proposing will be just local across given ebgp session while the error=20 as many have pointed out on this topic before may have been originated=20 far away. In such case periodic refresh requests or even soft clear will just=20 result in continued reception of bad attributes and their local drops=20 and it will not help to recover at all. The session drop had the nice property of raising red alarms on NOC=20 screens. It normally (other then in some implementations periodic=20 reestablishment attempts) did not correct the problem. So in the "treat-as-withdraw" cases perhaps what needs to happen the=20 same level of red alarms will be seen by NOCs and either manual or=20 automated triggered scripting will attempt to recover from the problem. Therefor I am not sure if adding any mechanism for recovery to the draft=20 is required. Worse it may even further be received by some NOCs as sort=20 of let the network fix itself message. Best regards, R. > Hi all, > > The draft currently does not discuss nor address how to recover from > error i.e. for the BGP receiver to get back all the NLRI / attributes > after it has withdrawn/discarded some. IMHO it should as the current > mechanism it is replacing (session reset) address both error handling > and error recovery. In order to initiate discussion on this, may I > suggest the following text: > > > When the approach "treat-as-withdraw" or "attribute discard" has been > used on a BGP session, the BGP receiver has not the full set of > attributes or NLRI that the BGP speaker sent. There MUST be a way to > latter recover from this inconsistency. > > In some cases, this inconsistency will naturally be resolved. As the > error is fixed on the speaker or on an upstream speaker (possibly the > originator of the route), the BGP attribute in error will be updated > and a new UPDATE message will be propagated on downstream BGP > routers. If the error has indeed been fixed, the new BGP UPDATE > message will be accepted and the dropped attribute or withdrawn NLRI > will be learnt again. > > To cover remaining cases, an automatic recovery mechanism SHOULD be > implemented. The use of the ROUTE-REFRESH message is suggested but > others non traffic disruptive mechanisms may be used. This recovery > mechanism SHOULD be initiated after a configurable delay. If the > mechanism failed to recover all NLRI or attributes in error, > subsequent tentative SHOULD be initiated after a timer. Timer value > SHOULD be carefully defined to allow for both a reasonably quick > recovery and a reasonable impact on the BGP control plane load. The > use of a (exponential) backof algorithm may be considered. The > maximum value should be high enough (e.g. days) in order for the > mechanism to keep trying the recovery possibly for ever while having > a low impact on the BGP control plane. Timer MAY be on a per BGP > session basis or MAY be global to the BGP speaker. > > If an implementation chooses not the implement an automatic recovery > mechanism, when or prior to configure this revised error handling, > network operator MUST be made aware that the recovery will require a > manual action (typically a session (soft) reset). > > > Thanks, 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 authorization. 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 shall not be liable if this message was 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 jie.dong@huawei.com Thu Jan 12 17:28: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 D6B2F21F854A for ; Thu, 12 Jan 2012 17:28:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 CElwMtL2BQvA for ; Thu, 12 Jan 2012 17:28:22 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 4E92F21F8542 for ; Thu, 12 Jan 2012 17:28:22 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LXP00FDBQR26M@szxga05-in.huawei.com> for idr@ietf.org; Fri, 13 Jan 2012 09:28:14 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LXP00GDRQR2GQ@szxga05-in.huawei.com> for idr@ietf.org; Fri, 13 Jan 2012 09:28:14 +0800 (CST) Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGK36595; Fri, 13 Jan 2012 09:28:09 +0800 Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 13 Jan 2012 09:27:59 +0800 Received: from SZXEML509-MBX.china.huawei.com ([169.254.1.21]) by szxeml410-hub.china.huawei.com ([10.82.67.137]) with mapi id 14.01.0323.003; Fri, 13 Jan 2012 09:28:00 +0800 Date: Fri, 13 Jan 2012 01:27:59 +0000 From: Jie Dong In-reply-to: <24590_1326357933_4F0E9DAD_24590_2274_1_53C29892C857584299CBF5D05346208A0166A9@PEXCVZYM11.corporate.adroot.infra.ftgroup> X-Originating-IP: [10.108.4.57] To: "bruno.decraene@orange.com" , Warren Kumari , "keyupate@cisco.com" , "idr@ietf.org" Message-id: <76CD132C3ADEF848BD84D028D243C92722A4972D@szxeml509-mbx.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: draft-ietf-idr-as0-02 Thread-index: AQHM0QaaAYmauPl370SetWOPMONqTpYJgHoA X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <20111216182324.17528.28150.idtracker@ietfa.amsl.com> <9CD76392-6F52-441C-BCF5-2335D7F49B8F@kumari.net> <4EEBEAEB.8070304@cisco.com> <0156DFD0-B706-42B0-93AB-89C9E6E252FD@kumari.net> <20120105014532.GC7464@slice> <0ED867EB33AB2B45AAB470D5A64CDBF6181C654044@EUSAACMS0701.eamcs.ericsson.se> <24590_1326357933_4F0E9DAD_24590_2274_1_53C29892C857584299CBF5D05346208A0166A9@PEXCVZYM11.corporate.adroot.infra.ftgroup> Subject: Re: [Idr] draft-ietf-idr-as0-02 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, 13 Jan 2012 01:28:22 -0000 Hi Bruno, > And for existing fields, IMHO, this document should be conservative with > regards to its change on existing specifications. IMHO it should only forbid the > use of AS 0 when necessary (for your new use case). > As an another example, I don't think treating as an error a BGP/MPLS VPN route > having an AS 0 in its Route Target or Route Distinguisher field is a good idea. > This may unexpectedly withdraw VPN routes in some live networks. And I don't > see a reason for this. Also agree with this. Should be conservative with changes to existing fields. Regards, Jie From russw@riw.us Thu Jan 12 17: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 76E9E21F855B for ; Thu, 12 Jan 2012 17:29:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2pQzVLQKHA1z for ; Thu, 12 Jan 2012 17:29:15 -0800 (PST) Received: from ecbiz91.inmotionhosting.com (ecbiz91.inmotionhosting.com [173.205.124.250]) by ietfa.amsl.com (Postfix) with ESMTP id E5A3421F854A for ; Thu, 12 Jan 2012 17:29:14 -0800 (PST) Received: from rrcs-24-199-145-66.midsouth.biz.rr.com ([24.199.145.66]:11319 helo=[192.168.3.115]) by ecbiz91.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RlVxB-00019R-HE for idr@ietf.org; Thu, 12 Jan 2012 20:29:13 -0500 Message-ID: <4F0F88E9.6080602@riw.us> Date: Thu, 12 Jan 2012 20:29:13 -0500 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: idr@ietf.org References: <20111216182324.17528.28150.idtracker@ietfa.amsl.com> <9CD76392-6F52-441C-BCF5-2335D7F49B8F@kumari.net> <4EEBEAEB.8070304@cisco.com> <0156DFD0-B706-42B0-93AB-89C9E6E252FD@kumari.net> <20120105014532.GC7464@slice> <0ED867EB33AB2B45AAB470D5A64CDBF6181C654044@EUSAACMS0701.eamcs.ericsson.se> <24590_1326357933_4F0E9DAD_24590_2274_1_53C29892C857584299CBF5D05346208A0166A9@PEXCVZYM11.corporate.adroot.infra.ftgroup> <76CD132C3ADEF848BD84D028D243C92722A4972D@szxeml509-mbx.china.huawei.com> In-Reply-To: <76CD132C3ADEF848BD84D028D243C92722A4972D@szxeml509-mbx.china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz91.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Idr] draft-ietf-idr-as0-02 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, 13 Jan 2012 01:29:15 -0000 >> And for existing fields, IMHO, this document should be conservative with >> regards to its change on existing specifications. IMHO it should only forbid the >> use of AS 0 when necessary (for your new use case). > >> As an another example, I don't think treating as an error a BGP/MPLS VPN route >> having an AS 0 in its Route Target or Route Distinguisher field is a good idea. >> This may unexpectedly withdraw VPN routes in some live networks. And I don't >> see a reason for this. > > Also agree with this. Should be conservative with changes to existing fields. +1 :-) Russ From stephane.litkowski@orange.com Fri Jan 13 05:59: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 8795221F8655 for ; Fri, 13 Jan 2012 05:59:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.631 X-Spam-Level: X-Spam-Status: No, score=-1.631 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_29=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 IpIzC5RtE2wg for ; Fri, 13 Jan 2012 05:59:41 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 522D421F8653 for ; Fri, 13 Jan 2012 05:59:41 -0800 (PST) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 0277C2DC1AA; Fri, 13 Jan 2012 14:59:40 +0100 (CET) Received: from PUEXCC21.nanterre.francetelecom.fr (unknown [10.168.72.145]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id D1F6035C04E; Fri, 13 Jan 2012 14:59:39 +0100 (CET) Received: from PUEXCBL0.nanterre.francetelecom.fr ([10.168.74.47]) by PUEXCC21.nanterre.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Fri, 13 Jan 2012 14:59:38 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 13 Jan 2012 14:59:38 +0100 Message-ID: <21291_1326463179_4F1038CB_21291_6481_1_4FC3556A36EE3646A09DAA60429F5335079826D9@PUEXCBL0.nanterre.francetelecom.fr> In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21391A47997E56@EUSAACMS0701.eamcs.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] draft-ietf-idr-error-handling Thread-Index: AczRVL7RQDF/3NjbTaS0+l15rlM8bAACSysQACbytrA= References: <14376_1326380191_4F0EF49F_14376_3284_1_53C29892C857584299CBF5D05346208A016944@PEXCVZYM11.corporate.adroot.infra.ftgroup><4F0F20C0.9020807@raszuk.net> <7309FCBCAE981B43ABBE69B31C8D21391A47997E56@EUSAACMS0701.eamcs.ericsson.se> From: To: "Jakob Heitz" , , "DECRAENE Bruno RD-CORE" X-OriginalArrivalTime: 13 Jan 2012 13:59:38.0990 (UTC) FILETIME=[972850E0:01CCD1FB] X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.1.13.104215 Cc: idr@ietf.org Subject: Re: [Idr] draft-ietf-idr-error-handling 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, 13 Jan 2012 13:59:42 -0000 Hi, I agree that a route-refresh may not correct the issue. Based on our experi= ence, sometimes it works (not really often :) ), sometimes not. In this cas= e, as you mentionned Jakob, only manual action on originator would fix the = issue. If we decide to implement a route-refresh to correct the issue, we need to = care on not doing an infinite loop in case of persistent error. I mean : re= ceiving a bad attribute, sending a rr,receiving same bad attribute, sending= a rr , receiving same bad attribute, sending a rr ... If people agree on = implementing such correction mechanism, I would propose to only try to fix = one time, and not going into a loop. When a correct update (after fix) is received from originator, it should be= propagated correctly by peers through the Internet. I don't see why this c= ould cause an issue ... Still a question on informing NOCs about the issue, do we agree that only = BGP speaker that detect the issue will inform "locally" the NOC (using sysl= og, SNMP or other monitoring mechanism ...), so only the service provider t= hat detected the issue is informed about the issue , others are receiving w= ithdraws or path update (if another path is available in local provider whe= re the error occurred) or path with some stripped attributes ? Or do you th= ink it could be interresting to inform peers (in a transitive way) that an = error occurred ? There was already some topics on this, but I can't see any= clear position on this (but maybe I missed it). =20 Regards, ---=20 Stephane -----Message d'origine----- De : idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] De la part de Jakob= Heitz Envoy=E9 : jeudi 12 janvier 2012 20:14 =C0 : robert@raszuk.net; DECRAENE Bruno RD-CORE Cc : idr@ietf.org Objet : Re: [Idr] draft-ietf-idr-error-handling One thing is clear: the originator of the malformed message needs manual in= tervention. No automatic fix is possible. Question is: once the originator is fixed, will the corrected updates propa= gate properly throughout the Internet? -- Jakob Heitz. -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Rober= t Raszuk Sent: Thursday, January 12, 2012 10:05 AM To: bruno.decraene@orange.com Cc: idr@ietf.org Subject: Re: [Idr] draft-ietf-idr-error-handling Hi Bruno, The recovery you are proposing is a valid concern. However what you are pro= posing will be just local across given ebgp session while the error as many= have pointed out on this topic before may have been originated far away. In such case periodic refresh requests or even soft clear will just result = in continued reception of bad attributes and their local drops and it will = not help to recover at all. The session drop had the nice property of raising red alarms on NOC screens= . It normally (other then in some implementations periodic reestablishment = attempts) did not correct the problem. So in the "treat-as-withdraw" cases perhaps what needs to happen the same l= evel of red alarms will be seen by NOCs and either manual or automated trig= gered scripting will attempt to recover from the problem. Therefor I am not sure if adding any mechanism for recovery to the draft is= required. Worse it may even further be received by some NOCs as sort of le= t the network fix itself message. Best regards, R. > Hi all, > > The draft currently does not discuss nor address how to recover from=20 > error i.e. for the BGP receiver to get back all the NLRI / attributes=20 > after it has withdrawn/discarded some. IMHO it should as the current=20 > mechanism it is replacing (session reset) address both error handling=20 > and error recovery. In order to initiate discussion on this, may I=20 > suggest the following text: > > > When the approach "treat-as-withdraw" or "attribute discard" has been=20 > used on a BGP session, the BGP receiver has not the full set of=20 > attributes or NLRI that the BGP speaker sent. There MUST be a way to=20 > latter recover from this inconsistency. > > In some cases, this inconsistency will naturally be resolved. As the=20 > error is fixed on the speaker or on an upstream speaker (possibly the=20 > originator of the route), the BGP attribute in error will be updated=20 > and a new UPDATE message will be propagated on downstream BGP routers.=20 > If the error has indeed been fixed, the new BGP UPDATE message will be=20 > accepted and the dropped attribute or withdrawn NLRI will be learnt=20 > again. > > To cover remaining cases, an automatic recovery mechanism SHOULD be=20 > implemented. The use of the ROUTE-REFRESH message is suggested but=20 > others non traffic disruptive mechanisms may be used. This recovery=20 > mechanism SHOULD be initiated after a configurable delay. If the=20 > mechanism failed to recover all NLRI or attributes in error,=20 > subsequent tentative SHOULD be initiated after a timer. Timer value=20 > SHOULD be carefully defined to allow for both a reasonably quick=20 > recovery and a reasonable impact on the BGP control plane load. The=20 > use of a (exponential) backof algorithm may be considered. The maximum=20 > value should be high enough (e.g. days) in order for the mechanism to=20 > keep trying the recovery possibly for ever while having a low impact=20 > on the BGP control plane. Timer MAY be on a per BGP session basis or=20 > MAY be global to the BGP speaker. > > If an implementation chooses not the implement an automatic recovery=20 > mechanism, when or prior to configure this revised error handling,=20 > network operator MUST be made aware that the recovery will require a=20 > manual action (typically a session (soft) reset). > > > Thanks, Regards, Bruno > > > ______________________________________________________________________ > ___________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations=20 > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi=20 > que les pieces jointes. Les messages electroniques etant susceptibles=20 > d'alteration, France Telecom - Orange decline toute responsabilite si=20 > ce message a ete altere, deforme ou falsifie. Merci > > This message and its attachments may contain confidential or=20 > privileged information that may be protected by law; they should not=20 > be distributed, used or copied without authorization. If you have=20 > received this email in error, please notify the sender and delete this=20 > message and its attachments. As emails may be altered, France Telecom=20 > - Orange shall not be liable if this message was modified, changed or=20 > falsified. Thank you. > > _______________________________________________ Idr mailing list=20 > 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 authorization. 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 shall not be liable if th= is message was modified, changed or falsified. Thank you. From jhaas@slice.pfrc.org Fri Jan 13 07:08: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 CBBB521F8535 for ; Fri, 13 Jan 2012 07:08:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.073 X-Spam-Level: X-Spam-Status: No, score=-102.073 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 EvLhkKp6Xmi5 for ; Fri, 13 Jan 2012 07:08:03 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 6D72D21F855F for ; Fri, 13 Jan 2012 07:08:03 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id D67A522415F; Fri, 13 Jan 2012 15:07:59 +0000 (UTC) Date: Fri, 13 Jan 2012 10:07:59 -0500 From: Jeffrey Haas To: stephane.litkowski@orange.com Message-ID: <20120113150759.GG7464@slice> References: <14376_1326380191_4F0EF49F_14376_3284_1_53C29892C857584299CBF5D05346208A016944@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4F0F20C0.9020807@raszuk.net> <7309FCBCAE981B43ABBE69B31C8D21391A47997E56@EUSAACMS0701.eamcs.ericsson.se> <21291_1326463179_4F1038CB_21291_6481_1_4FC3556A36EE3646A09DAA60429F5335079826D9@PUEXCBL0.nanterre.francetelecom.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <21291_1326463179_4F1038CB_21291_6481_1_4FC3556A36EE3646A09DAA60429F5335079826D9@PUEXCBL0.nanterre.francetelecom.fr> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: DECRAENE Bruno RD-CORE , robert@raszuk.net, idr@ietf.org Subject: Re: [Idr] draft-ietf-idr-error-handling 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, 13 Jan 2012 15:08:05 -0000 On Fri, Jan 13, 2012 at 02:59:38PM +0100, stephane.litkowski@orange.com wrote: > If we decide to implement a route-refresh to correct the issue, we need to care on not doing an infinite loop in case of persistent error. Never mind the fact that route refresh is a very large and expensive hammer. "I received one Bad route from you. Mind sending me 349,999 of the good ones again so I can see if the Bad route is better this time around?" Mechanisms that request the same prefix again are potentially better, but not be well received by operators. (This opinion is under the "don't let people ask me for stuff" operational umbrella. Some operators really prefer a push-only model.) -- Jeff From robert@raszuk.net Fri Jan 13 07:21: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 73FA921F857A for ; Fri, 13 Jan 2012 07:21:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cT8Ja6ppBHH6 for ; Fri, 13 Jan 2012 07:21:42 -0800 (PST) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id B292621F84AF for ; Fri, 13 Jan 2012 07:21:41 -0800 (PST) Received: (qmail 14196 invoked by uid 399); 13 Jan 2012 15:21:41 -0000 Received: from unknown (HELO ?10.0.1.3?) (207.47.5.130) by mail1310.opentransfer.com with ESMTP; 13 Jan 2012 15:21:41 -0000 X-Originating-IP: 207.47.5.130 Message-ID: <4F104C07.7060808@raszuk.net> Date: Fri, 13 Jan 2012 16:21:43 +0100 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Jeffrey Haas References: <14376_1326380191_4F0EF49F_14376_3284_1_53C29892C857584299CBF5D05346208A016944@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4F0F20C0.9020807@raszuk.net> <7309FCBCAE981B43ABBE69B31C8D21391A47997E56@EUSAACMS0701.eamcs.ericsson.se> <21291_1326463179_4F1038CB_21291_6481_1_4FC3556A36EE3646A09DAA60429F5335079826D9@PUEXCBL0.nanterre.francetelecom.fr> <20120113150759.GG7464@slice> In-Reply-To: <20120113150759.GG7464@slice> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr@ietf.org, DECRAENE Bruno RD-CORE Subject: Re: [Idr] draft-ietf-idr-error-handling 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, 13 Jan 2012 15:21:42 -0000 Jeff, > On Fri, Jan 13, 2012 at 02:59:38PM +0100, stephane.litkowski@orange.com wrote: >> If we decide to implement a route-refresh to correct the issue, we need to care on not doing an infinite loop in case of persistent error. > > Never mind the fact that route refresh is a very large and expensive hammer. > "I received one Bad route from you. Mind sending me 349,999 of the good > ones again so I can see if the Bad route is better this time around?" I would rather see draft-zeng-idr-one-time-prefix-orf-01 which is I think what you are referring to below. > Mechanisms that request the same prefix again are potentially better, but > not be well received by operators. (This opinion is under the "don't let > people ask me for stuff" operational umbrella. Some operators really prefer > a push-only model.) Such operators are free to disable functionality they do not appreciate. However I am not aware about any operator who forcefully disables route refresh capability on their BGP sessions. And those who disable route refresh would be subject to session reset anyway as even soft clear would not be possible therefor it seems obvious that they are least interested in draft-ietf-idr-error-handling which struggles to preserve BGP session. Cheers, R. From jhaas@slice.pfrc.org Fri Jan 13 07:35: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 5746521F84A0 for ; Fri, 13 Jan 2012 07:35:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.093 X-Spam-Level: X-Spam-Status: No, score=-102.093 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 mDUsLEgRlZYd for ; Fri, 13 Jan 2012 07:35:40 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id E8EF621F849A for ; Fri, 13 Jan 2012 07:35:39 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 89412224157; Fri, 13 Jan 2012 15:35:39 +0000 (UTC) Date: Fri, 13 Jan 2012 10:35:38 -0500 From: Jeffrey Haas To: Robert Raszuk Message-ID: <20120113153538.GI7464@slice> References: <14376_1326380191_4F0EF49F_14376_3284_1_53C29892C857584299CBF5D05346208A016944@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4F0F20C0.9020807@raszuk.net> <7309FCBCAE981B43ABBE69B31C8D21391A47997E56@EUSAACMS0701.eamcs.ericsson.se> <21291_1326463179_4F1038CB_21291_6481_1_4FC3556A36EE3646A09DAA60429F5335079826D9@PUEXCBL0.nanterre.francetelecom.fr> <20120113150759.GG7464@slice> <4F104C07.7060808@raszuk.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F104C07.7060808@raszuk.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: idr@ietf.org, DECRAENE Bruno RD-CORE Subject: Re: [Idr] draft-ietf-idr-error-handling 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, 13 Jan 2012 15:35:40 -0000 On Fri, Jan 13, 2012 at 04:21:43PM +0100, Robert Raszuk wrote: > >On Fri, Jan 13, 2012 at 02:59:38PM +0100, stephane.litkowski@orange.com wrote: > >>If we decide to implement a route-refresh to correct the issue, we need to care on not doing an infinite loop in case of persistent error. > > > >Never mind the fact that route refresh is a very large and expensive hammer. > >"I received one Bad route from you. Mind sending me 349,999 of the good > >ones again so I can see if the Bad route is better this time around?" > > I would rather see draft-zeng-idr-one-time-prefix-orf-01 which is I > think what you are referring to below. Indeed. Or at least things in that solution space. > >Mechanisms that request the same prefix again are potentially better, but > >not be well received by operators. (This opinion is under the "don't let > >people ask me for stuff" operational umbrella. Some operators really prefer > >a push-only model.) > > Such operators are free to disable functionality they do not > appreciate. However I am not aware about any operator who forcefully > disables route refresh capability on their BGP sessions. But I believe you're aware of implementations that rate limit refreshes. Even though the benefits of route refresh are clear, I think it'll take some discussion to determine if such prefix polling is similarly useful. Of course, a big part of my opinion on this is still prompted by the belief that if you're getting bad UPDATE messages that trusting the NLRI are correct is a wager at best, albeit one with good odds. -- Jeff From john@jlc.net Fri Jan 13 07:37: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 84EE821F8606 for ; Fri, 13 Jan 2012 07:37:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.078 X-Spam-Level: X-Spam-Status: No, score=-106.078 tagged_above=-999 required=5 tests=[AWL=0.521, 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 zeQVCVBwqRCy for ; Fri, 13 Jan 2012 07:37:10 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 9812321F84A0 for ; Fri, 13 Jan 2012 07:37:10 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 4837B33C20; Fri, 13 Jan 2012 10:37:10 -0500 (EST) Date: Fri, 13 Jan 2012 10:37:10 -0500 From: John Leslie To: Jeffrey Haas Message-ID: <20120113153710.GC72155@verdi> References: <14376_1326380191_4F0EF49F_14376_3284_1_53C29892C857584299CBF5D05346208A016944@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4F0F20C0.9020807@raszuk.net> <7309FCBCAE981B43ABBE69B31C8D21391A47997E56@EUSAACMS0701.eamcs.ericsson.se> <21291_1326463179_4F1038CB_21291_6481_1_4FC3556A36EE3646A09DAA60429F5335079826D9@PUEXCBL0.nanterre.francetelecom.fr> <20120113150759.GG7464@slice> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120113150759.GG7464@slice> User-Agent: Mutt/1.4.1i Cc: idr@ietf.org Subject: Re: [Idr] draft-ietf-idr-error-handling 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, 13 Jan 2012 15:37:11 -0000 Jeffrey Haas wrote: > On Fri, Jan 13, 2012 at 02:59:38PM +0100, > stephane.litkowski@orange.com wrote: > >> If we decide to implement a route-refresh to correct the issue, we need >> to care on not doing an infinite loop in case of persistent error. > > Never mind the fact that route refresh is a very large and expensive > hammer. (But one that already exists...) > "I received one Bad route from you. Mind sending me 349,999 of the good > ones again so I can see if the Bad route is better this time around?" Yes, it sounds silly... > Mechanisms that request the same prefix again are potentially better, > but not be well received by operators. Clearly, no particular response can be required. Indeed, if there is a response, it would be wise to be especially "conservative in what you send". > (This opinion is under the "don't let people ask me for stuff" > operational umbrella. Which I regard as "silly". I much prefer telling them to go to hell. > Some operators really prefer a push-only model.) Which is perfectly reasonable for some, not all, operators. When I advertise customer routes, I want them to reach as much of the Internet as possible. There definitely are cases, though, where something you advertise is merely an optimization, not _expected_ to reach the whole Internet. IMHO, it would be good to have a way to tell a peer you want his route(s) to a CIDR block (and anything you have will be treated as withdrawn if there is no response). Simultaneously, it would help to have a way to recognize the response. Our BGP paradigm is kinda simplistic (and fragile IMHO) for the 21st century. -- John Leslie From internet-drafts@ietf.org Fri Jan 13 08:38: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 2FB0121F85F1; Fri, 13 Jan 2012 08:38:52 -0800 (PST) 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 K4-zUIftafIv; Fri, 13 Jan 2012 08:38:51 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CB3F21F8584; Fri, 13 Jan 2012 08:38:33 -0800 (PST) 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: 3.64p1 Message-ID: <20120113163833.24327.26470.idtracker@ietfa.amsl.com> Date: Fri, 13 Jan 2012 08:38:33 -0800 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-bgp-gr-notification-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: Fri, 13 Jan 2012 16:38: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 : Notification Message support for BGP Graceful Restart Author(s) : Keyur Patel Rex Fernando John Scudder Jeff Haas Filename : draft-ietf-idr-bgp-gr-notification-00.txt Pages : 8 Date : 2011-12-06 The current BGP Graceful Restart mechanism limits the usage of BGP Graceful Restart to BGP protocol messages other than a BGP NOTIFICATION message. This document defines an extension to the BGP Graceful Restart that permits the Graceful Restart procedures to be performed when the BGP speaker receives a BGP NOTIFICATION Message. This document also defines a new BGP NOTIFICATION Cease Error subcode to prevent BGP speakers supporting the extension defined in this document from performing a Graceful Restart. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-gr-notification-00.t= xt 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-bgp-gr-notification-00.txt From jhaas@slice.pfrc.org Fri Jan 13 08:51: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 6DC0721F8532 for ; Fri, 13 Jan 2012 08:50:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.102 X-Spam-Level: X-Spam-Status: No, score=-102.102 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 M-bc+IjA0GhK for ; Fri, 13 Jan 2012 08:50:57 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id D21D321F8522 for ; Fri, 13 Jan 2012 08:50:55 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 15F5122415C; Fri, 13 Jan 2012 16:50:55 +0000 (UTC) Date: Fri, 13 Jan 2012 11:50:55 -0500 From: Jeffrey Haas To: idr@ietf.org Message-ID: <20120113165054.GL7464@slice> References: <14376_1326380191_4F0EF49F_14376_3284_1_53C29892C857584299CBF5D05346208A016944@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4F0F20C0.9020807@raszuk.net> <7309FCBCAE981B43ABBE69B31C8D21391A47997E56@EUSAACMS0701.eamcs.ericsson.se> <21291_1326463179_4F1038CB_21291_6481_1_4FC3556A36EE3646A09DAA60429F5335079826D9@PUEXCBL0.nanterre.francetelecom.fr> <20120113150759.GG7464@slice> <4F104C07.7060808@raszuk.net> <20120113153538.GI7464@slice> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120113153538.GI7464@slice> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Robert Raszuk , DECRAENE Bruno RD-CORE Subject: Re: [Idr] draft-ietf-idr-error-handling 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, 13 Jan 2012 16:51:02 -0000 On Fri, Jan 13, 2012 at 10:35:38AM -0500, Jeffrey Haas wrote: > Of course, a big part of my opinion on this is still prompted by the belief > that if you're getting bad UPDATE messages that trusting the NLRI are > correct is a wager at best, albeit one with good odds. In thinking about this a bit more over lunch, here's something else I'd like for the list archives. I think this was discussed during an IETF session, but I can't recall who would have made the statement if so: Part of our problem is that when errors are happening, they're typically transitive errors that aren't noticed until they've traveled some distance down stream. Thus, if an implementation has noted an error and is applying the error-handling draft's semantics to treat as a withdrawal, there's a very *low* chance that re-requesting the destination again will result in a corrected announcement. For a request to have an impact, I believe one of the following conditions must apply: - It might have to be transitive. This means the request might have to travel upstream all the way to the originator. - The error would have to had occurred at the adjacent peering session. -- Jeff From internet-drafts@ietf.org Fri Jan 13 09:35: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 01E8D21F8492; Fri, 13 Jan 2012 09:35:32 -0800 (PST) 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 jnWC4g1LiEuC; Fri, 13 Jan 2012 09:35:31 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E577821F842D; Fri, 13 Jan 2012 09:35:30 -0800 (PST) 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: 3.64p1 Message-ID: <20120113173530.8856.44896.idtracker@ietfa.amsl.com> Date: Fri, 13 Jan 2012 09:35:30 -0800 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-enhanced-gr-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: Fri, 13 Jan 2012 17:35:36 -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-00.txt Pages : 9 Date : 2011-12-05 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-00.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-00.txt From ruichuan.chen@gmail.com Fri Jan 13 10:48: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 F025821F85C2 for ; Fri, 13 Jan 2012 10:48:42 -0800 (PST) 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 fWCKo+43VwZ4 for ; Fri, 13 Jan 2012 10:48:42 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4AAB721F85BE for ; Fri, 13 Jan 2012 10:48:42 -0800 (PST) Received: by ghbg2 with SMTP id g2so1187477ghb.31 for ; Fri, 13 Jan 2012 10:48:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=JcX9843I11935XbdHP7vRbJsc+5nntqN70q0Xz1j0FM=; b=PfddJBkYhqED9w0OBQY2YM24UPptfACTllVuLQohdnPBX28s3/r24D7yg2JxOOIzMB 9iBnBB9RnFfAvCrjy4F3EzxR0/dkm7GajTtGEodki3WfLDZVRaV4pTsY6BdeRQIploxp HlI2izgHWMpxwg+XmlkvZq/LiKKTUsUGokUzk= MIME-Version: 1.0 Received: by 10.101.199.7 with SMTP id b7mr1052050anq.59.1326480520271; Fri, 13 Jan 2012 10:48:40 -0800 (PST) Sender: ruichuan.chen@gmail.com Received: by 10.147.33.12 with HTTP; Fri, 13 Jan 2012 10:48:40 -0800 (PST) In-Reply-To: References: Date: Fri, 13 Jan 2012 19:48:40 +0100 X-Google-Sender-Auth: okYgvC7bG5iQ0rjhxvJSPQ_TpJk Message-ID: From: Ruichuan Chen To: idr@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [Idr] Address-based Route Reflection 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, 13 Jan 2012 18:48:43 -0000 Dear all, The document below may be of interest: "Address-based Route Reflection" at http://bgp.mpi-sws.org/papers/abrr-CoNEXT11.pdf by Ruichuan Chen (MPI-SWS), Aman Shaikh (AT&T Labs Research), Jia Wang (AT&T Labs Research), Paul Francis (MPI-SWS) ==== Abstract ==== This work presents Address-Based Route Reflection (ABRR): the first iBGP solution that completely solves all oscillation and looping problems, has no path inefficiencies, and puts no constraints on RR placement. ABRR does this by emulating the semantics of full-mesh iBGP, and thereby adopting the correctness and path efficiency properties of full-mesh iBGP. Both traditional Topology-Based Route Reflection (TBRR) and ABRR take a divide-and-conquer approach. While TBRR scales by making each RR responsible for all prefixes from some fraction of routers, ABRR scales by making each RR responsible for some fraction of prefixes from all routers. Best regards, --Ruichuan From jgs@juniper.net Fri Jan 13 11:56: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 A135B21F852B for ; Fri, 13 Jan 2012 11:56:20 -0800 (PST) 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 XVfdHJ95gYb0 for ; Fri, 13 Jan 2012 11:56:20 -0800 (PST) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id CC8B621F85BB for ; Fri, 13 Jan 2012 11:56:13 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKTxCMXYFhql+e90lRr6HF2XVZO2eI/WId@postini.com; Fri, 13 Jan 2012 11:56:19 PST Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Fri, 13 Jan 2012 11:54:57 -0800 From: John Scudder To: "idr@ietf.org List" Date: Fri, 13 Jan 2012 11:54:56 -0800 Thread-Topic: draft-frs-bgp-operational-message as IDR WG item Thread-Index: AczSLTlrwp8UXf9DSO+SbV6Isr/q7Q== Message-ID: <3C561B08-37F2-4069-833E-E8E2316CF5C9@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" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-frs-bgp-operational-message@tools.ietf.org" Subject: [Idr] draft-frs-bgp-operational-message as IDR WG item 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, 13 Jan 2012 19:56:20 -0000 Folks, As we've discussed in the past and with the concurrence of the WG and autho= rs, draft-frs-bgp-operational-message will replace draft-ietf-idr-advisory = as a WG item. In particular, there was WG consensus to proceed forward with= the remote logging type functionality that is present in draft-ietf-idr-ad= visory and which is developed further in draft-frs-bgp-operational-message.= Other functionality present in draft-frs-bgp-operational-message is a good= subject for further WG discussion and revisions of the draft. Authors, please resubmit draft-frs-bgp-operational-message as draft-ietf-id= r-. Thanks, --John= From jgs@juniper.net Fri Jan 13 11:56: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 E79FF21F85BE for ; Fri, 13 Jan 2012 11:56:35 -0800 (PST) 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 XSzKuA6T-LNB for ; Fri, 13 Jan 2012 11:56:35 -0800 (PST) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 4F58D21F84AE for ; Fri, 13 Jan 2012 11:56:32 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKTxCMb7nrKfu9AaF6Xwg/gcgbKcz8mGgf@postini.com; Fri, 13 Jan 2012 11:56:35 PST Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Fri, 13 Jan 2012 11:55:08 -0800 From: John Scudder To: "idr@ietf.org List" Date: Fri, 13 Jan 2012 11:55:07 -0800 Thread-Topic: [Idr] Adoption of draft-l3vpn-legacy-rtc-00 as IDR WG document? Thread-Index: AczSLUBf3Na7O/+YRcG06KY5ZOHXJQ== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-l3vpn-legacy-rtc@tools.ietf.org" Subject: Re: [Idr] Adoption of draft-l3vpn-legacy-rtc-00 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, 13 Jan 2012 19:56:36 -0000 The draft is adopted as an IDR Working Group document. Authors, please resu= bmit as draft-ietf-idr. Thanks, --John On Nov 16, 2011, at 4:01 AM, John Scudder wrote: > Folks, >=20 > We have received a request from the authors to adopt draft-l3vpn-legacy-r= tc-00 as an IDR WG document. Please send your comments to the list. The d= eadline for comments is December 5, 2011 at noon EST. >=20 > Thanks, >=20 > --John > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From jgs@juniper.net Fri Jan 13 11:57: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 73D6E21F85BE for ; Fri, 13 Jan 2012 11:57:49 -0800 (PST) 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 lwyiqGvipuvS for ; Fri, 13 Jan 2012 11:57:48 -0800 (PST) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by ietfa.amsl.com (Postfix) with ESMTP id 0438221F84AE for ; Fri, 13 Jan 2012 11:57:44 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKTxCMuCJ3wV6KIRHWbknETHgnK1alltCZ@postini.com; Fri, 13 Jan 2012 11:57:48 PST Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Fri, 13 Jan 2012 11:55:02 -0800 From: John Scudder To: "idr@ietf.org List" Date: Fri, 13 Jan 2012 11:55:00 -0800 Thread-Topic: [Idr] Adoption of draft-jasinska-ix-bgp-route-server-03 as IDR WG document? Thread-Index: AczSLTwpfq4WE6mpSZChp3HuPbdSeA== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-jasinska-ix-bgp-route-server@tools.ietf.org" Subject: Re: [Idr] Adoption of draft-jasinska-ix-bgp-route-server-03 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, 13 Jan 2012 19:57:49 -0000 The draft is adopted as an IDR Working Group document. Authors, please resu= bmit as draft-ietf-idr. Thanks, --John On Nov 16, 2011, at 1:36 AM, John Scudder wrote: > Folks, >=20 > We have received a request from the authors to adopt draft-jasinska-ix-bg= p-route-server-03 as an IDR WG document. Please send your comments to the = list. The deadline for comments is December 5, 2011 at noon EST. >=20 > Thanks, >=20 > --John > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From jgs@juniper.net Fri Jan 13 12: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 C208221F84BF for ; Fri, 13 Jan 2012 12:06:29 -0800 (PST) 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 pj8R5xDYXbVR for ; Fri, 13 Jan 2012 12:06:29 -0800 (PST) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id 1D57C21F8473 for ; Fri, 13 Jan 2012 12:06:27 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKTxCOw4ppUQsBWD8yVecjHGlYN+axRYmx@postini.com; Fri, 13 Jan 2012 12:06:28 PST Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Fri, 13 Jan 2012 11:55:11 -0800 From: John Scudder To: "idr@ietf.org List" Date: Fri, 13 Jan 2012 11:55:10 -0800 Thread-Topic: Weesan stepping down as secretary Thread-Index: AczSLUIR4JWlxTjKRr6l5UPLCL9K+Q== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Idr] Weesan stepping down as secretary 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, 13 Jan 2012 20:06:30 -0000 Folks, Weesan Lee has stepped down as IDR Secretary. Please join me in thanking hi= m for his service and direct any future administrative requests to the chai= rs.=20 Thanks, --John= From jgs@juniper.net Fri Jan 13 12:57: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 A950D21F84FF for ; Fri, 13 Jan 2012 12:57:13 -0800 (PST) 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 kqgQdH3OTWVi for ; Fri, 13 Jan 2012 12:57:12 -0800 (PST) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id E91AB21F84EE for ; Fri, 13 Jan 2012 12:57:08 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKTxCaogMB+9VcPJZ8xIeJdMD0RRCnPrqR@postini.com; Fri, 13 Jan 2012 12:57:09 PST Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Fri, 13 Jan 2012 12:56:05 -0800 From: John Scudder To: "bruno.decraene@orange.com" Date: Fri, 13 Jan 2012 12:56:04 -0800 Thread-Topic: [Idr] draft-ietf-idr-error-handling Thread-Index: AczSNcP7RqNOJWnmTx6lyv4pAXxm9g== Message-ID: <71A025B8-2774-4C6A-B1AE-0268998C7186@juniper.net> References: <14376_1326380191_4F0EF49F_14376_3284_1_53C29892C857584299CBF5D05346208A016944@PEXCVZYM11.corporate.adroot.infra.ftgroup> In-Reply-To: <14376_1326380191_4F0EF49F_14376_3284_1_53C29892C857584299CBF5D05346208A016944@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" Subject: Re: [Idr] draft-ietf-idr-error-handling 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, 13 Jan 2012 20:57:13 -0000 Folks, I see little to no benefit from attempting some kind of try-to-fix-the-prob= lem-automatically mechanism, and on the other hand I do see drawbacks. Cons= ider the different kinds of errors that can be handled by the scheme in thi= s draft: - Updates that are malformed due to some spec implementation error on the p= art of the update's originator, or one of the intermediate routers. In this= case, one can expect that requesting the update again, will fetch the same= data as before. "The definition of insanity is doing the same thing over a= nd over and expecting different results." Let's not. - Updates that are malformed due to some more general implementation error = on the part of some upstream router, e.g. memory corruption. Such an error = might be effectively 'random' and amenable to correction through a refresh,= but OTOH the originating implementation is very badly broken and might be = expected to crash soon anyway. The class of problems where there's just an = itty bit of corruption that breaks one update and then clears up forever is= probably very small. If you know of some plausible class of errors that would be expected to be = corrected by some self-healing mechanism, please explain in more detail. When the originator of the error is fixed, I would expect the proper update= to be propagated and installed without any special-case "healing" mechanis= ms. I think this is self-evident, so I'm not going to present arguments for= why it is so; rather, if you think it's not so, please explain why. Remember that we are proposing to replace a simple and reliable (but proble= matic!) error handling mechanism that has many years of deployment experien= ce. In doing so, I think one worthwhile goal is to keep the replacement als= o as simple as possible. To the extent that any bells and whistles are to b= e added, I suggest they be on the error reporting and diagnostics side and = not on an attempt to introduce self-repair mechanisms. Remember that additi= onal complexity has cost and such code paths may themselves be subject to b= ugs (are more likely to be actually, since less frequently exercised) and m= ay complicate debugging in the field. Finally, I strongly agree that a treat-as-withdraw error should be treated = as though it's (almost) equal in severity to a downed session. On the route= r side, this means raising appropriate alarms. --John On Jan 12, 2012, at 9:56 AM, bruno.decraene@orange.com wrote: > Hi all, >=20 > The draft currently does not discuss nor address how to recover from erro= r i.e. for the BGP receiver to get back all the NLRI / attributes after it = has withdrawn/discarded some. IMHO it should as the current mechanism it is= replacing (session reset) address both error handling and error recovery. > In order to initiate discussion on this, may I suggest the following text= : >=20 >=20 > When the approach "treat-as-withdraw" or "attribute discard" has been use= d on a BGP session, the BGP receiver has not the full set of attributes or = NLRI that the BGP speaker sent. There MUST be a way to latter recover from = this inconsistency. >=20 > In some cases, this inconsistency will naturally be resolved. As the erro= r is fixed on the speaker or on an upstream speaker (possibly the originato= r of the route), the BGP attribute in error will be updated and a new UPDAT= E message will be propagated on downstream BGP routers. If the error has in= deed been fixed, the new BGP UPDATE message will be accepted and the droppe= d attribute or withdrawn NLRI will be learnt again. >=20 > To cover remaining cases, an automatic recovery mechanism SHOULD be imple= mented. The use of the ROUTE-REFRESH message is suggested but others non tr= affic disruptive mechanisms may be used. This recovery mechanism SHOULD be = initiated after a configurable delay. If the mechanism failed to recover al= l NLRI or attributes in error, subsequent tentative SHOULD be initiated aft= er a timer. Timer value SHOULD be carefully defined to allow for both a rea= sonably quick recovery and a reasonable impact on the BGP control plane loa= d. The use of a (exponential) backof algorithm may be considered. The maxim= um value should be high enough (e.g. days) in order for the mechanism to ke= ep trying the recovery possibly for ever while having a low impact on the B= GP control plane. Timer MAY be on a per BGP session basis or MAY be global = to the BGP speaker. >=20 > If an implementation chooses not the implement an automatic recovery mech= anism, when or prior to configure this revised error handling, network oper= ator MUST be made aware that the recovery will require a manual action (typ= ically a session (soft) reset). >=20 >=20 > Thanks, > Regards, > Bruno >=20 >=20 > _________________________________________________________________________= ________________________________________________ >=20 > 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 >=20 > 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 authorization. > 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 shall not be liable if = this message was modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From jakob.heitz@ericsson.com Fri Jan 13 13:22: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 D4F3C21F8514 for ; Fri, 13 Jan 2012 13:22:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 kTIuqOV2CYg7 for ; Fri, 13 Jan 2012 13:22:22 -0800 (PST) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id E134321F84D5 for ; Fri, 13 Jan 2012 13:22:21 -0800 (PST) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q0DLMK68029616 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 13 Jan 2012 15:22:20 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.20]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Fri, 13 Jan 2012 16:22:19 -0500 From: Jakob Heitz To: "idr@ietf.org" Date: Fri, 13 Jan 2012 16:23:33 -0500 Thread-Topic: [Idr] draft-ietf-idr-error-handling Thread-Index: AczSOW5UB/cGec9HQtKuaxuPn6FGSw== Message-ID: <79B1F714-F384-484E-AA76-FCA14CD6458D@ericsson.com> References: <14376_1326380191_4F0EF49F_14376_3284_1_53C29892C857584299CBF5D05346208A016944@PEXCVZYM11.corporate.adroot.infra.ftgroup> <71A025B8-2774-4C6A-B1AE-0268998C7186@juniper.net> In-Reply-To: <71A025B8-2774-4C6A-B1AE-0268998C7186@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" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Idr] draft-ietf-idr-error-handling 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, 13 Jan 2012 21:22:23 -0000 Strongly agree. As I said before, we are only trying to define how to limp along instead of needlessly spreading damage. -- Jakob Heitz. On Jan 13, 2012, at 12:57 PM, "John Scudder" wrote: > Folks, >=20 > I see little to no benefit from attempting some kind of try-to-fix-the-pr= oblem-automatically mechanism, and on the other hand I do see drawbacks. Co= nsider the different kinds of errors that can be handled by the scheme in t= his draft: >=20 > - Updates that are malformed due to some spec implementation error on the= part of the update's originator, or one of the intermediate routers. In th= is case, one can expect that requesting the update again, will fetch the sa= me data as before. "The definition of insanity is doing the same thing over= and over and expecting different results." Let's not. >=20 > - Updates that are malformed due to some more general implementation erro= r on the part of some upstream router, e.g. memory corruption. Such an erro= r might be effectively 'random' and amenable to correction through a refres= h, but OTOH the originating implementation is very badly broken and might b= e expected to crash soon anyway. The class of problems where there's just a= n itty bit of corruption that breaks one update and then clears up forever = is probably very small. >=20 > If you know of some plausible class of errors that would be expected to b= e corrected by some self-healing mechanism, please explain in more detail. >=20 > When the originator of the error is fixed, I would expect the proper upda= te to be propagated and installed without any special-case "healing" mechan= isms. I think this is self-evident, so I'm not going to present arguments f= or why it is so; rather, if you think it's not so, please explain why. >=20 > Remember that we are proposing to replace a simple and reliable (but prob= lematic!) error handling mechanism that has many years of deployment experi= ence. In doing so, I think one worthwhile goal is to keep the replacement a= lso as simple as possible. To the extent that any bells and whistles are to= be added, I suggest they be on the error reporting and diagnostics side an= d not on an attempt to introduce self-repair mechanisms. Remember that addi= tional complexity has cost and such code paths may themselves be subject to= bugs (are more likely to be actually, since less frequently exercised) and= may complicate debugging in the field. >=20 > Finally, I strongly agree that a treat-as-withdraw error should be treate= d as though it's (almost) equal in severity to a downed session. On the rou= ter side, this means raising appropriate alarms. >=20 > --John >=20 > On Jan 12, 2012, at 9:56 AM, bruno.decraene@orange.com wrote: >=20 >> Hi all, >>=20 >> The draft currently does not discuss nor address how to recover from err= or i.e. for the BGP receiver to get back all the NLRI / attributes after it= has withdrawn/discarded some. IMHO it should as the current mechanism it i= s replacing (session reset) address both error handling and error recovery. >> In order to initiate discussion on this, may I suggest the following tex= t: >>=20 >>=20 >> When the approach "treat-as-withdraw" or "attribute discard" has been us= ed on a BGP session, the BGP receiver has not the full set of attributes or= NLRI that the BGP speaker sent. There MUST be a way to latter recover from= this inconsistency. >>=20 >> In some cases, this inconsistency will naturally be resolved. As the err= or is fixed on the speaker or on an upstream speaker (possibly the originat= or of the route), the BGP attribute in error will be updated and a new UPDA= TE message will be propagated on downstream BGP routers. If the error has i= ndeed been fixed, the new BGP UPDATE message will be accepted and the dropp= ed attribute or withdrawn NLRI will be learnt again. >>=20 >> To cover remaining cases, an automatic recovery mechanism SHOULD be impl= emented. The use of the ROUTE-REFRESH message is suggested but others non t= raffic disruptive mechanisms may be used. This recovery mechanism SHOULD be= initiated after a configurable delay. If the mechanism failed to recover a= ll NLRI or attributes in error, subsequent tentative SHOULD be initiated af= ter a timer. Timer value SHOULD be carefully defined to allow for both a re= asonably quick recovery and a reasonable impact on the BGP control plane lo= ad. The use of a (exponential) backof algorithm may be considered. The maxi= mum value should be high enough (e.g. days) in order for the mechanism to k= eep trying the recovery possibly for ever while having a low impact on the = BGP control plane. Timer MAY be on a per BGP session basis or MAY be global= to the BGP speaker. >>=20 >> If an implementation chooses not the implement an automatic recovery mec= hanism, when or prior to configure this revised error handling, network ope= rator MUST be made aware that the recovery will require a manual action (ty= pically a session (soft) reset). >>=20 >>=20 >> Thanks, >> Regards, >> Bruno >>=20 >>=20 >> ________________________________________________________________________= _________________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations confi= dentielles 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 >>=20 >> 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 authorization. >> 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 shall not be liable if= this message was modified, changed or falsified. >> Thank you. >>=20 >> _______________________________________________ >> 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 randy@psg.com Fri Jan 13 15:58: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 8E6AE21F85D4 for ; Fri, 13 Jan 2012 15:58:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.076, 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 JDmL5HLCeqXM for ; Fri, 13 Jan 2012 15:58:36 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 315B621F85D3 for ; Fri, 13 Jan 2012 15:58:36 -0800 (PST) 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 1Rlr0y-000Dcu-OG; Fri, 13 Jan 2012 23:58:32 +0000 Date: Fri, 13 Jan 2012 15:58:32 -0800 Message-ID: From: Randy Bush To: John Scudder In-Reply-To: <71A025B8-2774-4C6A-B1AE-0268998C7186@juniper.net> References: <14376_1326380191_4F0EF49F_14376_3284_1_53C29892C857584299CBF5D05346208A016944@PEXCVZYM11.corporate.adroot.infra.ftgroup> <71A025B8-2774-4C6A-B1AE-0268998C7186@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: Bruno Decraene , idr wg Subject: Re: [Idr] draft-ietf-idr-error-handling 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, 13 Jan 2012 23:58:36 -0000 there is an approach i call "do-gooder software" which attempts to fix the broken. when it works, no one notices and says "thanks." when it screws up, and it always does, the resulting poolpah results in more problems than the one it was trying to whitewash. and i do not believe in being liberal in what one accepts, that way lies entropic death. randy, a naggumite From jie.dong@huawei.com Sun Jan 15 22:27: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 7C02821F8507 for ; Sun, 15 Jan 2012 22:27:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.561 X-Spam-Level: X-Spam-Status: No, score=-6.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 ZFhJ2Jw3cib7 for ; Sun, 15 Jan 2012 22:27:41 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id D523421F8501 for ; Sun, 15 Jan 2012 22:27:40 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LXV00IJ9OKAYZ@szxga05-in.huawei.com> for idr@ietf.org; Mon, 16 Jan 2012 14:26:34 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LXV00ASKOKAYN@szxga05-in.huawei.com> for idr@ietf.org; Mon, 16 Jan 2012 14:26:34 +0800 (CST) Received: from szxeml202-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGI15461; Mon, 16 Jan 2012 14:26:31 +0800 Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 16 Jan 2012 14:26:29 +0800 Received: from SZXEML509-MBS.china.huawei.com ([169.254.2.186]) by szxeml410-hub.china.huawei.com ([10.82.67.137]) with mapi id 14.01.0323.003; Mon, 16 Jan 2012 14:26:25 +0800 Date: Mon, 16 Jan 2012 06:26:24 +0000 From: Jie Dong In-reply-to: <4F104C07.7060808@raszuk.net> X-Originating-IP: [10.108.4.57] To: "robert@raszuk.net" , Jeffrey Haas Message-id: <76CD132C3ADEF848BD84D028D243C92722A57F2C@szxeml509-mbs.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: [Idr] draft-ietf-idr-error-handling Thread-index: AczROl3MjbHyjBOYTdaYkGYE2ygt8f//roAAgAATN4CAATqeAIAAExmAgAAD1oD/+18yYA== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <14376_1326380191_4F0EF49F_14376_3284_1_53C29892C857584299CBF5D05346208A016944@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4F0F20C0.9020807@raszuk.net> <7309FCBCAE981B43ABBE69B31C8D21391A47997E56@EUSAACMS0701.eamcs.ericsson.se> <21291_1326463179_4F1038CB_21291_6481_1_4FC3556A36EE3646A09DAA60429F5335079826D9@PUEXCBL0.nanterre.francetelecom.fr> <20120113150759.GG7464@slice> <4F104C07.7060808@raszuk.net> Cc: "idr@ietf.org" , DECRAENE Bruno RD-CORE Subject: Re: [Idr] draft-ietf-idr-error-handling 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, 16 Jan 2012 06:27:41 -0000 Robert, Jeff, Bruno, > >> If we decide to implement a route-refresh to correct the issue, we need to > care on not doing an infinite loop in case of persistent error. > > > > Never mind the fact that route refresh is a very large and expensive hammer. > > "I received one Bad route from you. Mind sending me 349,999 of the good > > ones again so I can see if the Bad route is better this time around?" > > I would rather see draft-zeng-idr-one-time-prefix-orf-01 which is I > think what you are referring to below. Yes. One use case of one-time prefix ORF is to trigger this selective refresh after some routes have been "treat-as-withdraw". Though treat-as-withdraw will not turn down the BGP session, reachability for some specific prefixes may already be lost, which may not be accepted by customers. Request those prefixes again may solve this issue (though not in all cases). Definitely an infinite loop should be avoided by limiting the number of requests and with some back-off mechanism. Note that now the mechanism in draft-ietf-idr-error-handling is also applicable to the well-known attributes, thus it could be more possible that the fault is at the local BGP peer. Best regards, Jie From stephane.litkowski@orange.com Mon Jan 16 01:06: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 E773721F84DA for ; Mon, 16 Jan 2012 01:06:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[AWL=0.314, 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 bwbFOd6j1vKd for ; Mon, 16 Jan 2012 01:06:04 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 2EA8A21F84BF for ; Mon, 16 Jan 2012 01:06:04 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id CBB203B41B2; Mon, 16 Jan 2012 10:06:02 +0100 (CET) Received: from PUEXCC51.nanterre.francetelecom.fr (unknown [10.168.74.61]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id AFF082380B5; Mon, 16 Jan 2012 10:06:02 +0100 (CET) Received: from PUEXCBL0.nanterre.francetelecom.fr ([10.168.74.47]) by PUEXCC51.nanterre.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Mon, 16 Jan 2012 10:06:02 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 16 Jan 2012 10:06:00 +0100 Message-ID: <23924_1326704762_4F13E87A_23924_118751_1_4FC3556A36EE3646A09DAA60429F533507982A00@PUEXCBL0.nanterre.francetelecom.fr> In-Reply-To: <20120113150759.GG7464@slice> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] draft-ietf-idr-error-handling Thread-Index: AczSBSS7hORh0QijRiuxE1RtrYe2MwCJwQeA References: <14376_1326380191_4F0EF49F_14376_3284_1_53C29892C857584299CBF5D05346208A016944@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4F0F20C0.9020807@raszuk.net> <7309FCBCAE981B43ABBE69B31C8D21391A47997E56@EUSAACMS0701.eamcs.ericsson.se> <21291_1326463179_4F1038CB_21291_6481_1_4FC3556A36EE3646A09DAA60429F5335079826D9@PUEXCBL0.nanterre.francetelecom.fr> <20120113150759.GG7464@slice> From: To: "Jeffrey Haas" X-OriginalArrivalTime: 16 Jan 2012 09:06:02.0768 (UTC) FILETIME=[124F6900:01CCD42E] X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.1.16.80015 Cc: DECRAENE Bruno RD-CORE , robert@raszuk.net, idr@ietf.org Subject: Re: [Idr] draft-ietf-idr-error-handling 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, 16 Jan 2012 09:06:05 -0000 >> If we decide to implement a route-refresh to correct the issue, we need to care on not doing an infinite loop in case of persistent error. >Never mind the fact that route refresh is a very large and expensive hammer. >"I received one Bad route from you. Mind sending me 349,999 of the good ones again so I can see if the=20 >Bad route is better this time around?" >Mechanisms that request the same prefix again are potentially better I agree that route-refresh is mostly wasted but it's a "quick win" as it's already available in most (all) codes and moreover I hope there is no more bugs in it ! ;) ... But optimization (like draft-zeng-idr-one-time-prefix-orf-01) are fine but not available yet. I agree with Jakob and John that we should try to keep the error processing as simple as possible, and introducing new mechanisms would introduce complexity. Maybe for a future , it will be interresting. I agree too that the number of cases that would be solved by the route-refresh would be small. But IMHO, introducing a route-refresh in code path is not costly, this is something stable, available in all codes (no need of new code on peer too), and route-refresh is not costly for the router (remember that for VPNs, each time we provision an RT, a route-refresh is sent, and number of routes are really higher than in Internet !!). Question to answer : how much it cost vs number of occurences solved. I think cost is about 0, but I'm not a BGP coder ... So maybe I'm wrong. ---=20 Stephane ___________________________________________________________________________= ______________________________________________ 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 authorization. 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 shall not be liable if th= is message was modified, changed or falsified. Thank you. From jakob.heitz@ericsson.com Mon Jan 16 09:03: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 9320721F86A9 for ; Mon, 16 Jan 2012 09:03:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 sX3P7JGGhAXX for ; Mon, 16 Jan 2012 09:03:22 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id EA29321F86A8 for ; Mon, 16 Jan 2012 09:03:21 -0800 (PST) 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 q0GH3DT8007305; Mon, 16 Jan 2012 11:03:20 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.33]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Mon, 16 Jan 2012 12:03:16 -0500 From: Jakob Heitz To: "stephane.litkowski@orange.com" Date: Mon, 16 Jan 2012 12:04:42 -0500 Thread-Topic: [Idr] draft-ietf-idr-error-handling Thread-Index: AczUcL0V0s/5LtZdSKCnX1jm5Y+kxA== Message-ID: <69329C2B-1343-477E-9560-0D96EB654051@ericsson.com> References: <14376_1326380191_4F0EF49F_14376_3284_1_53C29892C857584299CBF5D05346208A016944@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4F0F20C0.9020807@raszuk.net> <7309FCBCAE981B43ABBE69B31C8D21391A47997E56@EUSAACMS0701.eamcs.ericsson.se> <21291_1326463179_4F1038CB_21291_6481_1_4FC3556A36EE3646A09DAA60429F5335079826D9@PUEXCBL0.nanterre.francetelecom.fr> <20120113150759.GG7464@slice> <23924_1326704762_4F13E87A_23924_118751_1_4FC3556A36EE3646A09DAA60429F533507982A00@PUEXCBL0.nanterre.francetelecom.fr> In-Reply-To: <23924_1326704762_4F13E87A_23924_118751_1_4FC3556A36EE3646A09DAA60429F533507982A00@PUEXCBL0.nanterre.francetelecom.fr> 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 , "robert@raszuk.net" , "idr@ietf.org" Subject: Re: [Idr] draft-ietf-idr-error-handling 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, 16 Jan 2012 17:03:22 -0000 The solution is to fix the root cause. Once that's done, is there a scenari= o in which the updates will not propagate naturally? -- Jakob Heitz. On Jan 16, 2012, at 1:06 AM, "stephane.litkowski@orange.com" wrote: >>> If we decide to implement a route-refresh to correct the issue, we > need to care on not doing an infinite loop in case of persistent error. >> Never mind the fact that route refresh is a very large and expensive > hammer. >> "I received one Bad route from you. Mind sending me 349,999 of the > good ones again so I can see if the=20 >> Bad route is better this time around?" >> Mechanisms that request the same prefix again are potentially better >=20 > I agree that route-refresh is mostly wasted but it's a "quick win" as > it's already available in most (all) codes and moreover I hope there is > no more bugs in it ! ;) ... But optimization (like > draft-zeng-idr-one-time-prefix-orf-01) are fine but not available yet. >=20 > I agree with Jakob and John that we should try to keep the error > processing as simple as possible, and introducing new mechanisms would > introduce complexity. Maybe for a future , it will be interresting. >=20 > I agree too that the number of cases that would be solved by the > route-refresh would be small. > But IMHO, introducing a route-refresh in code path is not costly, this > is something stable, available in all codes (no need of new code on peer > too), and route-refresh is not costly for the router (remember that for > VPNs, each time we provision an RT, a route-refresh is sent, and number > of routes are really higher than in Internet !!). Question to answer : > how much it cost vs number of occurences solved. I think cost is about > 0, but I'm not a BGP coder ... So maybe I'm wrong. >=20 > ---=20 > Stephane >=20 > _________________________________________________________________________= ________________________________________________ >=20 > 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 >=20 > 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 authorization. > 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 shall not be liable if = this message was modified, changed or falsified. > Thank you. >=20 From stephane.litkowski@orange.com Tue Jan 17 00:52: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 4AECB21F8634 for ; Tue, 17 Jan 2012 00:52:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.973 X-Spam-Level: X-Spam-Status: No, score=-1.973 tagged_above=-999 required=5 tests=[AWL=0.275, 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 czY0EdOAxqsh for ; Tue, 17 Jan 2012 00:52:29 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 75F6621F8625 for ; Tue, 17 Jan 2012 00:52:29 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 67B692DC09E; Tue, 17 Jan 2012 09:52:25 +0100 (CET) Received: from PUEXCC51.nanterre.francetelecom.fr (unknown [10.168.74.61]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id B4EBE4C024; Tue, 17 Jan 2012 09:52:24 +0100 (CET) Received: from PUEXCBL0.nanterre.francetelecom.fr ([10.168.74.47]) by PUEXCC51.nanterre.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Jan 2012 09:52:23 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 17 Jan 2012 09:52:23 +0100 Message-ID: <3598_1326790345_4F1536C9_3598_4487_1_4FC3556A36EE3646A09DAA60429F5335079D158D@PUEXCBL0.nanterre.francetelecom.fr> In-Reply-To: <69329C2B-1343-477E-9560-0D96EB654051@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] draft-ietf-idr-error-handling Thread-Index: AczUcL0V0s/5LtZdSKCnX1jm5Y+kxAAhGKIA References: <14376_1326380191_4F0EF49F_14376_3284_1_53C29892C857584299CBF5D05346208A016944@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4F0F20C0.9020807@raszuk.net> <7309FCBCAE981B43ABBE69B31C8D21391A47997E56@EUSAACMS0701.eamcs.ericsson.se> <21291_1326463179_4F1038CB_21291_6481_1_4FC3556A36EE3646A09DAA60429F5335079826D9@PUEXCBL0.nanterre.francetelecom.fr> <20120113150759.GG7464@slice> <23924_1326704762_4F13E87A_23924_118751_1_4FC3556A36EE3646A09DAA60429F533507982A00@PUEXCBL0.nanterre.francetelecom.fr> <69329C2B-1343-477E-9560-0D96EB654051@ericsson.com> From: To: "Jakob Heitz" X-OriginalArrivalTime: 17 Jan 2012 08:52:23.0922 (UTC) FILETIME=[54A72D20:01CCD4F5] X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.1.17.64217 Cc: DECRAENE Bruno RD-CORE , robert@raszuk.net, idr@ietf.org Subject: Re: [Idr] draft-ietf-idr-error-handling 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, 17 Jan 2012 08:52:30 -0000 >The solution is to fix the root cause. Once that's done, is there a scena= rio in which the updates will not propagate naturally? I don't think so ... As soon as issue is cleared on originator (of the fail= ure), the updates will propagate naturally. Why do you think there could no= t ? -- Stephane -----Message d'origine----- De : Jakob Heitz [mailto:jakob.heitz@ericsson.com]=20 Envoy=E9 : lundi 16 janvier 2012 18:05 =C0 : LITKOWSKI Stephane DTF/DERX Cc : Jeffrey Haas; robert@raszuk.net; DECRAENE Bruno RD-CORE; idr@ietf.org Objet : Re: [Idr] draft-ietf-idr-error-handling The solution is to fix the root cause. Once that's done, is there a scenari= o in which the updates will not propagate naturally? -- Jakob Heitz. On Jan 16, 2012, at 1:06 AM, "stephane.litkowski@orange.com" wrote: >>> If we decide to implement a route-refresh to correct the issue, we > need to care on not doing an infinite loop in case of persistent error. >> Never mind the fact that route refresh is a very large and expensive > hammer. >> "I received one Bad route from you. Mind sending me 349,999 of the > good ones again so I can see if the >> Bad route is better this time around?" >> Mechanisms that request the same prefix again are potentially better >=20 > I agree that route-refresh is mostly wasted but it's a "quick win" as=20 > it's already available in most (all) codes and moreover I hope there=20 > is no more bugs in it ! ;) ... But optimization (like > draft-zeng-idr-one-time-prefix-orf-01) are fine but not available yet. >=20 > I agree with Jakob and John that we should try to keep the error=20 > processing as simple as possible, and introducing new mechanisms would=20 > introduce complexity. Maybe for a future , it will be interresting. >=20 > I agree too that the number of cases that would be solved by the=20 > route-refresh would be small. > But IMHO, introducing a route-refresh in code path is not costly, this=20 > is something stable, available in all codes (no need of new code on=20 > peer too), and route-refresh is not costly for the router (remember=20 > that for VPNs, each time we provision an RT, a route-refresh is sent,=20 > and number of routes are really higher than in Internet !!). Question to = answer : > how much it cost vs number of occurences solved. I think cost is about=20 > 0, but I'm not a BGP coder ... So maybe I'm wrong. >=20 > --- > Stephane >=20 > ______________________________________________________________________ > ___________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations=20 > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi=20 > que les pieces jointes. Les messages electroniques etant susceptibles=20 > d'alteration, France Telecom - Orange decline toute responsabilite si=20 > ce message a ete altere, deforme ou falsifie. Merci >=20 > This message and its attachments may contain confidential or=20 > privileged information that may be protected by law; they should not be d= istributed, used or copied without authorization. > 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 shall not be liable if = this message was modified, changed or falsified. > Thank you. >=20 ___________________________________________________________________________= ______________________________________________ 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 authorization. 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 shall not be liable if th= is message was modified, changed or falsified. Thank you. From jakob.heitz@ericsson.com Tue Jan 17 08:41: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 A446021F852D for ; Tue, 17 Jan 2012 08:41:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 ntRobvA2n2zN for ; Tue, 17 Jan 2012 08:41:06 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id E562221F867B for ; Tue, 17 Jan 2012 08:41:04 -0800 (PST) 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 q0HGex37031673; Tue, 17 Jan 2012 10:41:02 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.33]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Tue, 17 Jan 2012 11:40:55 -0500 From: Jakob Heitz To: "stephane.litkowski@orange.com" Date: Tue, 17 Jan 2012 11:40:52 -0500 Thread-Topic: [Idr] draft-ietf-idr-error-handling Thread-Index: AczVNsfh5QwZiFYAQqWffCVhVngC/g== Message-ID: <87A2B691-1C50-46C8-8A53-330D9B02C052@ericsson.com> References: <14376_1326380191_4F0EF49F_14376_3284_1_53C29892C857584299CBF5D05346208A016944@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4F0F20C0.9020807@raszuk.net> <7309FCBCAE981B43ABBE69B31C8D21391A47997E56@EUSAACMS0701.eamcs.ericsson.se> <21291_1326463179_4F1038CB_21291_6481_1_4FC3556A36EE3646A09DAA60429F5335079826D9@PUEXCBL0.nanterre.francetelecom.fr> <20120113150759.GG7464@slice> <23924_1326704762_4F13E87A_23924_118751_1_4FC3556A36EE3646A09DAA60429F533507982A00@PUEXCBL0.nanterre.francetelecom.fr> <69329C2B-1343-477E-9560-0D96EB654051@ericsson.com> <3598_1326790345_4F1536C9_3598_4487_1_4FC3556A36EE3646A09DAA60429F5335079D158D@PUEXCBL0.nanterre.francetelecom.fr> In-Reply-To: <3598_1326790345_4F1536C9_3598_4487_1_4FC3556A36EE3646A09DAA60429F5335079D158D@PUEXCBL0.nanterre.francetelecom.fr> 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: DECRAENE Bruno RD-CORE , "robert@raszuk.net" , "idr@ietf.org" Subject: Re: [Idr] draft-ietf-idr-error-handling 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, 17 Jan 2012 16:41:08 -0000 SW4gdGhhdCBjYXNlLCBhIHJvdXRlIHJlZnJlc2ggd2lsbCBmaXggbm90aGluZy4NCg0KLS0NCkph a29iIEhlaXR6Lg0KDQpPbiBKYW4gMTcsIDIwMTIsIGF0IDEyOjUyIEFNLCAic3RlcGhhbmUubGl0 a293c2tpQG9yYW5nZS5jb20iIDxzdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbT4gd3JvdGU6 DQoNCj4gDQo+PiBUaGUgc29sdXRpb24gaXMgdG8gZml4IHRoZSByb290IGNhdXNlLiBPbmNlIHRo YXQncyBkb25lLCBpcyB0aGVyZSBhIHNjZW5hcmlvIGluIHdoaWNoIHRoZSB1cGRhdGVzIHdpbGwg bm90IHByb3BhZ2F0ZSBuYXR1cmFsbHk/DQo+IA0KPiBJIGRvbid0IHRoaW5rIHNvIC4uLiBBcyBz b29uIGFzIGlzc3VlIGlzIGNsZWFyZWQgb24gb3JpZ2luYXRvciAob2YgdGhlIGZhaWx1cmUpLCB0 aGUgdXBkYXRlcyB3aWxsIHByb3BhZ2F0ZSBuYXR1cmFsbHkuIFdoeSBkbyB5b3UgdGhpbmsgdGhl cmUgY291bGQgbm90ID8NCj4gDQo+IC0tDQo+IFN0ZXBoYW5lDQo+IA0KPiANCj4gDQo+IC0tLS0t TWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiBEZSA6IEpha29iIEhlaXR6IFttYWlsdG86amFrb2Iu aGVpdHpAZXJpY3Nzb24uY29tXSANCj4gRW52b3nDqSA6IGx1bmRpIDE2IGphbnZpZXIgMjAxMiAx ODowNQ0KPiDDgCA6IExJVEtPV1NLSSBTdGVwaGFuZSBEVEYvREVSWA0KPiBDYyA6IEplZmZyZXkg SGFhczsgcm9iZXJ0QHJhc3p1ay5uZXQ7IERFQ1JBRU5FIEJydW5vIFJELUNPUkU7IGlkckBpZXRm Lm9yZw0KPiBPYmpldCA6IFJlOiBbSWRyXSBkcmFmdC1pZXRmLWlkci1lcnJvci1oYW5kbGluZw0K PiANCj4gVGhlIHNvbHV0aW9uIGlzIHRvIGZpeCB0aGUgcm9vdCBjYXVzZS4gT25jZSB0aGF0J3Mg ZG9uZSwgaXMgdGhlcmUgYSBzY2VuYXJpbyBpbiB3aGljaCB0aGUgdXBkYXRlcyB3aWxsIG5vdCBw cm9wYWdhdGUgbmF0dXJhbGx5Pw0KPiANCj4gLS0NCj4gSmFrb2IgSGVpdHouDQo+IA0KPiANCj4g T24gSmFuIDE2LCAyMDEyLCBhdCAxOjA2IEFNLCAic3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5j b20iIDxzdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbT4gd3JvdGU6DQo+IA0KPj4+PiBJZiB3 ZSBkZWNpZGUgdG8gaW1wbGVtZW50IGEgcm91dGUtcmVmcmVzaCB0byBjb3JyZWN0IHRoZSBpc3N1 ZSwgd2UNCj4+IG5lZWQgdG8gY2FyZSBvbiBub3QgZG9pbmcgYW4gaW5maW5pdGUgbG9vcCBpbiBj YXNlIG9mIHBlcnNpc3RlbnQgZXJyb3IuDQo+Pj4gTmV2ZXIgbWluZCB0aGUgZmFjdCB0aGF0IHJv dXRlIHJlZnJlc2ggaXMgYSB2ZXJ5IGxhcmdlIGFuZCBleHBlbnNpdmUNCj4+IGhhbW1lci4NCj4+ PiAiSSByZWNlaXZlZCBvbmUgQmFkIHJvdXRlIGZyb20geW91LiAgTWluZCBzZW5kaW5nIG1lIDM0 OSw5OTkgb2YgdGhlDQo+PiBnb29kIG9uZXMgYWdhaW4gc28gSSBjYW4gc2VlIGlmIHRoZQ0KPj4+ IEJhZCByb3V0ZSBpcyBiZXR0ZXIgdGhpcyB0aW1lIGFyb3VuZD8iDQo+Pj4gTWVjaGFuaXNtcyB0 aGF0IHJlcXVlc3QgdGhlIHNhbWUgcHJlZml4IGFnYWluIGFyZSBwb3RlbnRpYWxseSBiZXR0ZXIN Cj4+IA0KPj4gSSBhZ3JlZSB0aGF0IHJvdXRlLXJlZnJlc2ggaXMgbW9zdGx5IHdhc3RlZCBidXQg aXQncyBhICJxdWljayB3aW4iIGFzIA0KPj4gaXQncyBhbHJlYWR5IGF2YWlsYWJsZSBpbiBtb3N0 IChhbGwpIGNvZGVzIGFuZCBtb3Jlb3ZlciBJIGhvcGUgdGhlcmUgDQo+PiBpcyBubyBtb3JlIGJ1 Z3MgaW4gaXQgISA7KSAuLi4gQnV0IG9wdGltaXphdGlvbiAobGlrZQ0KPj4gZHJhZnQtemVuZy1p ZHItb25lLXRpbWUtcHJlZml4LW9yZi0wMSkgYXJlIGZpbmUgYnV0IG5vdCBhdmFpbGFibGUgeWV0 Lg0KPj4gDQo+PiBJIGFncmVlIHdpdGggSmFrb2IgYW5kIEpvaG4gdGhhdCB3ZSBzaG91bGQgdHJ5 IHRvIGtlZXAgdGhlIGVycm9yIA0KPj4gcHJvY2Vzc2luZyBhcyBzaW1wbGUgYXMgcG9zc2libGUs IGFuZCBpbnRyb2R1Y2luZyBuZXcgbWVjaGFuaXNtcyB3b3VsZCANCj4+IGludHJvZHVjZSBjb21w bGV4aXR5LiBNYXliZSBmb3IgYSBmdXR1cmUgLCBpdCB3aWxsIGJlIGludGVycmVzdGluZy4NCj4+ IA0KPj4gSSBhZ3JlZSB0b28gdGhhdCB0aGUgbnVtYmVyIG9mIGNhc2VzIHRoYXQgd291bGQgYmUg c29sdmVkIGJ5IHRoZSANCj4+IHJvdXRlLXJlZnJlc2ggd291bGQgYmUgc21hbGwuDQo+PiBCdXQg SU1ITywgaW50cm9kdWNpbmcgYSByb3V0ZS1yZWZyZXNoIGluIGNvZGUgcGF0aCBpcyBub3QgY29z dGx5LCB0aGlzIA0KPj4gaXMgc29tZXRoaW5nIHN0YWJsZSwgYXZhaWxhYmxlIGluIGFsbCBjb2Rl cyAobm8gbmVlZCBvZiBuZXcgY29kZSBvbiANCj4+IHBlZXIgdG9vKSwgYW5kIHJvdXRlLXJlZnJl c2ggaXMgbm90IGNvc3RseSBmb3IgdGhlIHJvdXRlciAocmVtZW1iZXIgDQo+PiB0aGF0IGZvciBW UE5zLCBlYWNoIHRpbWUgd2UgcHJvdmlzaW9uIGFuIFJULCBhIHJvdXRlLXJlZnJlc2ggaXMgc2Vu dCwgDQo+PiBhbmQgbnVtYmVyIG9mIHJvdXRlcyBhcmUgcmVhbGx5IGhpZ2hlciB0aGFuIGluIElu dGVybmV0ICEhKS4gUXVlc3Rpb24gdG8gYW5zd2VyIDoNCj4+IGhvdyBtdWNoIGl0IGNvc3QgdnMg bnVtYmVyIG9mIG9jY3VyZW5jZXMgc29sdmVkLiBJIHRoaW5rIGNvc3QgaXMgYWJvdXQgDQo+PiAw LCBidXQgSSdtIG5vdCBhIEJHUCBjb2RlciAuLi4gU28gbWF5YmUgSSdtIHdyb25nLg0KPj4gDQo+ PiAtLS0NCj4+IFN0ZXBoYW5lDQo+PiANCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gDQo+PiBDZSBtZXNz YWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlv bnMgDQo+PiBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9u YyBwYXMgZXRyZSBkaWZmdXNlcywgDQo+PiBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jp c2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIA0KPj4gcGFyIGVycmV1ciwgdmV1 aWxsZXogbGUgc2lnbmFsZXIgYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgDQo+ PiBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFu dCBzdXNjZXB0aWJsZXMgDQo+PiBkJ2FsdGVyYXRpb24sIEZyYW5jZSBUZWxlY29tIC0gT3Jhbmdl IGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgDQo+PiBjZSBtZXNzYWdlIGEgZXRlIGFs dGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kNCj4+IA0KPj4gVGhpcyBtZXNzYWdlIGFu ZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIA0KPj4gcHJpdmls ZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3OyB0aGV5IHNob3Vs ZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXphdGlv bi4NCj4+IElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBu b3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1l bnRzLg0KPj4gQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBGcmFuY2UgVGVsZWNvbSAtIE9yYW5n ZSBzaGFsbCBub3QgYmUgbGlhYmxlIGlmIHRoaXMgbWVzc2FnZSB3YXMgbW9kaWZpZWQsIGNoYW5n ZWQgb3IgZmFsc2lmaWVkLg0KPj4gVGhhbmsgeW91Lg0KPj4gDQo+IA0KPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IA0K PiBDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBp bmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50 IGRvbmMNCj4gcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRv cmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxs ZXogbGUgc2lnbmFsZXINCj4gYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVl IGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3Vz Y2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwNCj4gRnJhbmNlIFRlbGVjb20gLSBPcmFuZ2UgZGVjbGlu ZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3Jt ZSBvdSBmYWxzaWZpZS4gTWVyY2kNCj4gDQo+IFRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1l bnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRo YXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7DQo+IHRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmli dXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3JpemF0aW9uLg0KPiBJZiB5b3UgaGF2 ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIg YW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCj4gQXMgZW1haWxz IG1heSBiZSBhbHRlcmVkLCBGcmFuY2UgVGVsZWNvbSAtIE9yYW5nZSBzaGFsbCBub3QgYmUgbGlh YmxlIGlmIHRoaXMgbWVzc2FnZSB3YXMgbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0K PiBUaGFuayB5b3UuDQo+IA0K From stephane.litkowski@orange.com Wed Jan 18 01:31: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 7F57A21F874C for ; Wed, 18 Jan 2012 01:31:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.048 X-Spam-Level: X-Spam-Status: No, score=-2.048 tagged_above=-999 required=5 tests=[AWL=0.200, 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 BYSmiATSSjnK for ; Wed, 18 Jan 2012 01:31:41 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 6219B21F874A for ; Wed, 18 Jan 2012 01:31:41 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id C831626418D; Wed, 18 Jan 2012 10:31:40 +0100 (CET) Received: from PUEXCC21.nanterre.francetelecom.fr (unknown [10.168.72.145]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id A69E7238059; Wed, 18 Jan 2012 10:31:40 +0100 (CET) Received: from PUEXCBL0.nanterre.francetelecom.fr ([10.168.74.47]) by PUEXCC21.nanterre.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 18 Jan 2012 10:31:40 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 18 Jan 2012 10:31:39 +0100 Message-ID: <12218_1326879100_4F16917C_12218_8785_1_4FC3556A36EE3646A09DAA60429F5335079D1C24@PUEXCBL0.nanterre.francetelecom.fr> In-Reply-To: <87A2B691-1C50-46C8-8A53-330D9B02C052@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] draft-ietf-idr-error-handling Thread-Index: AczVNsfh5QwZiFYAQqWffCVhVngC/gAjI/QA References: <14376_1326380191_4F0EF49F_14376_3284_1_53C29892C857584299CBF5D05346208A016944@PEXCVZYM11.corporate.adroot.infra.ftgroup> <4F0F20C0.9020807@raszuk.net> <7309FCBCAE981B43ABBE69B31C8D21391A47997E56@EUSAACMS0701.eamcs.ericsson.se> <21291_1326463179_4F1038CB_21291_6481_1_4FC3556A36EE3646A09DAA60429F5335079826D9@PUEXCBL0.nanterre.francetelecom.fr> <20120113150759.GG7464@slice> <23924_1326704762_4F13E87A_23924_118751_1_4FC3556A36EE3646A09DAA60429F533507982A00@PUEXCBL0.nanterre.francetelecom.fr> <69329C2B-1343-477E-9560-0D96EB654051@ericsson.com> <3598_1326790345_4F1536C9_3598_4487_1_4FC3556A36EE3646A09DAA60429F5335079D158D@PUEXCBL0.nanterre.francetelecom.fr> <87A2B691-1C50-46C8-8A53-330D9B02C052@ericsson.com> From: To: "Jakob Heitz" X-OriginalArrivalTime: 18 Jan 2012 09:31:40.0665 (UTC) FILETIME=[FBCB5E90:01CCD5C3] X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.1.18.82115 Cc: DECRAENE Bruno RD-CORE , robert@raszuk.net, idr@ietf.org Subject: Re: [Idr] draft-ietf-idr-error-handling 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, 18 Jan 2012 09:31:42 -0000 It depends of kind of errors. I can reuse what John said about type of errors :=20 [John]=20 "- Updates that are malformed due to some spec implementation error on the = part of the update's originator, or one of the intermediate routers. In thi= s case, one can expect that requesting the update again, will fetch the sam= e data as before. "The definition of insanity is doing the same thing over = and over and expecting different results." Let's not. - Updates that are malformed due to some more general implementation error = on the part of some upstream router, e.g. memory corruption. Such an error = might be effectively 'random' and amenable to correction through a refresh,= but OTOH the originating implementation is very badly broken and might be = expected to crash soon anyway. The class of problems where there's just an = itty bit of corruption that breaks one update and then clears up forever is= probably very small." In case two, when there is a random memory corruption when update is format= ted and sent, a route-refresh may clear the issue. As I mentionned, and as = John said too, probability is low but it exists : just a question of cost (= to implement and on router ressources), vs nb of occurences. =20 -- Stephane -----Message d'origine----- De : Jakob Heitz [mailto:jakob.heitz@ericsson.com]=20 Envoy=E9 : mardi 17 janvier 2012 17:41 =C0 : LITKOWSKI Stephane DTF/DERX Cc : Jeffrey Haas; robert@raszuk.net; DECRAENE Bruno RD-CORE; idr@ietf.org Objet : Re: [Idr] draft-ietf-idr-error-handling In that case, a route refresh will fix nothing. -- Jakob Heitz. On Jan 17, 2012, at 12:52 AM, "stephane.litkowski@orange.com" wrote: >=20 >> The solution is to fix the root cause. Once that's done, is there a scen= ario in which the updates will not propagate naturally? >=20 > I don't think so ... As soon as issue is cleared on originator (of the fa= ilure), the updates will propagate naturally. Why do you think there could = not ? >=20 > -- > Stephane >=20 >=20 >=20 > -----Message d'origine----- > De : Jakob Heitz [mailto:jakob.heitz@ericsson.com] Envoy=E9 : lundi 16=20 > janvier 2012 18:05 =C0 : LITKOWSKI Stephane DTF/DERX Cc : Jeffrey Haas;= =20 > robert@raszuk.net; DECRAENE Bruno RD-CORE; idr@ietf.org Objet : Re:=20 > [Idr] draft-ietf-idr-error-handling >=20 > The solution is to fix the root cause. Once that's done, is there a scena= rio in which the updates will not propagate naturally? >=20 > -- > Jakob Heitz. >=20 >=20 > On Jan 16, 2012, at 1:06 AM, "stephane.litkowski@orange.com" wrote: >=20 >>>> If we decide to implement a route-refresh to correct the issue, we >> need to care on not doing an infinite loop in case of persistent error. >>> Never mind the fact that route refresh is a very large and expensive >> hammer. >>> "I received one Bad route from you. Mind sending me 349,999 of the >> good ones again so I can see if the >>> Bad route is better this time around?" >>> Mechanisms that request the same prefix again are potentially better >>=20 >> I agree that route-refresh is mostly wasted but it's a "quick win" as=20 >> it's already available in most (all) codes and moreover I hope there=20 >> is no more bugs in it ! ;) ... But optimization (like >> draft-zeng-idr-one-time-prefix-orf-01) are fine but not available yet. >>=20 >> I agree with Jakob and John that we should try to keep the error=20 >> processing as simple as possible, and introducing new mechanisms=20 >> would introduce complexity. Maybe for a future , it will be interresting. >>=20 >> I agree too that the number of cases that would be solved by the=20 >> route-refresh would be small. >> But IMHO, introducing a route-refresh in code path is not costly,=20 >> this is something stable, available in all codes (no need of new code=20 >> on peer too), and route-refresh is not costly for the router=20 >> (remember that for VPNs, each time we provision an RT, a=20 >> route-refresh is sent, and number of routes are really higher than in In= ternet !!). Question to answer : >> how much it cost vs number of occurences solved. I think cost is=20 >> about 0, but I'm not a BGP coder ... So maybe I'm wrong. >>=20 >> --- >> Stephane >>=20 >> _____________________________________________________________________ >> _ ___________________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations=20 >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 >> exploites ou copies sans autorisation. Si vous avez recu ce message=20 >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi=20 >> que les pieces jointes. Les messages electroniques etant susceptibles=20 >> d'alteration, France Telecom - Orange decline toute responsabilite si=20 >> ce message a ete altere, deforme ou falsifie. Merci >>=20 >> This message and its attachments may contain confidential or=20 >> privileged information that may be protected by law; they should not be = distributed, used or copied without authorization. >> 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 shall not be liable if= this message was modified, changed or falsified. >> Thank you. >>=20 >=20 > ______________________________________________________________________ > ___________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations=20 > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi=20 > que les pieces jointes. Les messages electroniques etant susceptibles=20 > d'alteration, France Telecom - Orange decline toute responsabilite si=20 > ce message a ete altere, deforme ou falsifie. Merci >=20 > This message and its attachments may contain confidential or=20 > privileged information that may be protected by law; they should not be d= istributed, used or copied without authorization. > 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 shall not be liable if = this message was modified, changed or falsified. > Thank you. >=20 ___________________________________________________________________________= ______________________________________________ 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 authorization. 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 shall not be liable if th= is message was modified, changed or falsified. Thank you. From jgs@juniper.net Wed Jan 18 08:40: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 3B6B121F87DE for ; Wed, 18 Jan 2012 08:40:39 -0800 (PST) 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 AO4U7ewAQO99 for ; Wed, 18 Jan 2012 08:40:38 -0800 (PST) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by ietfa.amsl.com (Postfix) with ESMTP id 814AB21F87D5 for ; Wed, 18 Jan 2012 08:40:38 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKTxb1+jw5Oq88LcJoSEpBUIfB7aNUh/Wl@postini.com; Wed, 18 Jan 2012 08:40:38 PST Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Wed, 18 Jan 2012 08:39:03 -0800 From: John Scudder To: "idr@ietf.org List" Date: Wed, 18 Jan 2012 08:39:02 -0800 Thread-Topic: [Idr] Adoption of ft-zeng-idr-bgp-mtu-extension-01 as IDR WG document? Thread-Index: AczV/6/0VMx3Nf27QaW04UOe+a0y2w== Message-ID: References: <9B76DC1E-7F59-4E07-B90D-762A173B8C82@juniper.net> In-Reply-To: <9B76DC1E-7F59-4E07-B90D-762A173B8C82@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" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Idr] Adoption of ft-zeng-idr-bgp-mtu-extension-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, 18 Jan 2012 16:40:39 -0000 All, This draft is not accepted as a WG document. Thanks, --John and Sue On Nov 16, 2011, at 4:01 AM, John Scudder wrote: > Folks, >=20 > We have received a request from the authors to adopt ft-zeng-idr-bgp-mtu-= extension-01 as an IDR WG document. Please send your comments to the list.= The deadline for comments is December 5, 2011 at noon EST. >=20 > Thanks, >=20 > --John From internet-drafts@ietf.org Wed Jan 18 16:14: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 7A42111E80B5; Wed, 18 Jan 2012 16:14:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.434 X-Spam-Level: X-Spam-Status: No, score=-102.434 tagged_above=-999 required=5 tests=[AWL=0.165, 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 AeNCLe1qZCv8; Wed, 18 Jan 2012 16:14:55 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DEB021F84BD; Wed, 18 Jan 2012 16:14:55 -0800 (PST) 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: 3.64p1 Message-ID: <20120119001455.5790.51802.idtracker@ietfa.amsl.com> Date: Wed, 18 Jan 2012 16:14:55 -0800 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-as0-03.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, 19 Jan 2012 00:14:55 -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 : Codification of AS 0 processing. Author(s) : Warren Kumari Randy Bush Heather Schiller Keyur Patel Filename : draft-ietf-idr-as0-03.txt Pages : 7 Date : 2012-01-18 This document proscribes the use of AS 0 in BGP OPEN and AS_PATH / AS4_PATH BGP attribute. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-as0-03.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-as0-03.txt From warren@kumari.net Wed Jan 18 16:21: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 36D5F11E80DD for ; Wed, 18 Jan 2012 16:21:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.526 X-Spam-Level: X-Spam-Status: No, score=-106.526 tagged_above=-999 required=5 tests=[AWL=0.073, 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 hfnpJoqSL18W for ; Wed, 18 Jan 2012 16:21:49 -0800 (PST) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 9FBE711E80D7 for ; Wed, 18 Jan 2012 16:21:49 -0800 (PST) Received: from [192.168.0.12] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id BE7B21B405C3 for ; Wed, 18 Jan 2012 19:21:48 -0500 (EST) From: Warren Kumari Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Wed, 18 Jan 2012 19:22:02 -0500 References: <20120119001455.5790.57934.idtracker@ietfa.amsl.com> To: "idr@ietf.org List" Message-Id: <0F58219C-7F0D-4AD6-9F81-66EB08445763@kumari.net> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [Idr] Fwd: New Version Notification for draft-ietf-idr-as0-03.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, 19 Jan 2012 00:21:53 -0000 Hello all, A number of folk expressed unhappiness with the "and any other place = that an AS number shows up" text (:-)), and so it has been removed=85 A helpful diff is here: = http://tools.ietf.org//rfcdiff?url1=3Dhttp://www.ietf.org/id/draft-ietf-id= r-as0-02.txt&url2=3Dhttp://www.ietf.org/id/draft-ietf-idr-as0-03.txt We really appreciate folks feedback and think / hope that we finally = have something acceptable to all=85 W Begin forwarded message: > From: internet-drafts@ietf.org > Date: January 18, 2012 7:14:55 PM EST > To: warren@kumari.net > Cc: randy@psg.com, heather.schiller@verizon.com, keyupate@cisco.com, = warren@kumari.net > Subject: New Version Notification for draft-ietf-idr-as0-03.txt >=20 > A new version of I-D, draft-ietf-idr-as0-03.txt has been successfully = submitted by Warren Kumari and posted to the IETF repository. >=20 > Filename: draft-ietf-idr-as0 > Revision: 03 > Title: Codification of AS 0 processing. > Creation date: 2012-01-16 > WG ID: idr > Number of pages: 7 >=20 > Abstract: > This document proscribes the use of AS 0 in BGP OPEN and AS_PATH / > AS4_PATH BGP attribute. >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 --- Don't be impressed with unintelligible stuff said condescendingly . -- Radia Perlman. Warren Kumari warren@kumari.net From david.freedman@uk.clara.net Thu Jan 19 15:58: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 AAF5A21F8690 for ; Thu, 19 Jan 2012 15:58:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.047 X-Spam-Level: X-Spam-Status: No, score=-1.047 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, 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 XNESgF+XaGrH for ; Thu, 19 Jan 2012 15:58:11 -0800 (PST) Received: from staff00.mail.eu.clara.net (staff00.mail.eu.clara.net [IPv6:2001:a88:0:fff7::68]) by ietfa.amsl.com (Postfix) with ESMTP id 2673621F85E7 for ; Thu, 19 Jan 2012 15:58:10 -0800 (PST) Received: from [195.157.10.59] (port=10307 helo=SRVGREXCAS01.claranet.local) by staff00.mail.eu.clara.net (staff00.mail.eu.clara.net [80.168.65.68]:25) with esmtps (TLS-1.0:RSA_AES_128_CBC_SHA1:16) id 1Ro1rs-000446-2P for idr@ietf.org (return-path ); Thu, 19 Jan 2012 23:58:08 +0000 Received: from SRVGREXMB03.claranet.local ([10.75.5.26]) by SRVGREXCAS01.claranet.local ([fe80::d0e0:3f28:712f:4dea%10]) with mapi id 14.01.0339.001; Thu, 19 Jan 2012 23:58:08 +0000 From: David Freedman To: "idr@ietf.org" Thread-Topic: Adoption of draft-jasinska-ix-bgp-route-server-03 as IDR WG document? Thread-Index: AQHM1wYxyEXzRf9+B0K6MJl2L6t3qQ== Date: Thu, 19 Jan 2012 23:58:08 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [172.18.6.3] Content-Type: multipart/alternative; boundary="_000_CB3E5E8D7B77Edavidfreedmaneuclaranet_" MIME-Version: 1.0 X-BorderScout-Spam: 0.00 X-BorderScout-Virus: clean Subject: Re: [Idr] Adoption of draft-jasinska-ix-bgp-route-server-03 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, 19 Jan 2012 23:58:11 -0000 --_000_CB3E5E8D7B77Edavidfreedmaneuclaranet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support! --_000_CB3E5E8D7B77Edavidfreedmaneuclaranet_ Content-Type: text/html; charset="us-ascii" Content-ID: <89248C61A8715B4499B1D5F1EC156507@claranet.local> Content-Transfer-Encoding: quoted-printable
Support!
--_000_CB3E5E8D7B77Edavidfreedmaneuclaranet_-- From jhaas@slice.pfrc.org Fri Jan 20 06:41: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 29F8D21F84B6 for ; Fri, 20 Jan 2012 06:41:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.11 X-Spam-Level: X-Spam-Status: No, score=-102.11 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 63mlQ4LdYFOC for ; Fri, 20 Jan 2012 06:41:38 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 11DE721F84FD for ; Fri, 20 Jan 2012 06:41:38 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 9EE3717036B; Fri, 20 Jan 2012 09:41:37 -0500 (EST) Date: Fri, 20 Jan 2012 09:41:37 -0500 From: Jeffrey Haas To: idr@ietf.org Message-ID: <20120120144137.GB9830@slice> References: <20120119001455.5790.51802.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120119001455.5790.51802.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [Idr] I-D Action: draft-ietf-idr-as0-03.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, 20 Jan 2012 14:41:39 -0000 On Wed, Jan 18, 2012 at 04:14:55PM -0800, 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 : Codification of AS 0 processing. > Author(s) : Warren Kumari > Randy Bush > Heather Schiller > Keyur Patel > Filename : draft-ietf-idr-as0-03.txt > Pages : 7 > Date : 2012-01-18 > > This document proscribes the use of AS 0 in BGP OPEN and AS_PATH / > AS4_PATH BGP attribute. I feel significantly better about this text. :-) -- Jeff From warren@kumari.net Fri Jan 20 07:46: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 0508521F861B for ; Fri, 20 Jan 2012 07:46:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.528 X-Spam-Level: X-Spam-Status: No, score=-106.528 tagged_above=-999 required=5 tests=[AWL=0.071, 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 7deOZ9QE5Rnq for ; Fri, 20 Jan 2012 07:46:58 -0800 (PST) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 6551D21F8619 for ; Fri, 20 Jan 2012 07:46:58 -0800 (PST) Received: from dhcp-172-19-119-228.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 73E451B413C9; Fri, 20 Jan 2012 10:46:56 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: <20120120144137.GB9830@slice> Date: Fri, 20 Jan 2012 10:46:55 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <68DEE991-A64A-41C0-8EE3-5384BD063A40@kumari.net> References: <20120119001455.5790.51802.idtracker@ietfa.amsl.com> <20120120144137.GB9830@slice> To: Jeffrey Haas X-Mailer: Apple Mail (2.1084) Cc: idr@ietf.org Subject: Re: [Idr] I-D Action: draft-ietf-idr-as0-03.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, 20 Jan 2012 15:46:59 -0000 On Jan 20, 2012, at 9:41 AM, Jeffrey Haas wrote: > On Wed, Jan 18, 2012 at 04:14:55PM -0800, 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 : Codification of AS 0 processing. >> Author(s) : Warren Kumari >> Randy Bush >> Heather Schiller >> Keyur Patel >> Filename : draft-ietf-idr-as0-03.txt >> Pages : 7 >> Date : 2012-01-18 >>=20 >> This document proscribes the use of AS 0 in BGP OPEN and AS_PATH / >> AS4_PATH BGP attribute. >=20 > I feel significantly better about this text. :-) >=20 Excellent, we aim to please :-P W > -- Jeff > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr >=20 From warren@kumari.net Fri Jan 20 13:18: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 155F721F8587 for ; Fri, 20 Jan 2012 13:18:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.535 X-Spam-Level: X-Spam-Status: No, score=-106.535 tagged_above=-999 required=5 tests=[AWL=0.064, 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 Us2sUAs6vSfm for ; Fri, 20 Jan 2012 13:18:25 -0800 (PST) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 90ED521F8589 for ; Fri, 20 Jan 2012 13:18:25 -0800 (PST) Received: from dhcp-172-19-119-228.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 991231B413C9; Fri, 20 Jan 2012 16:18:24 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: Date: Fri, 20 Jan 2012 16:18:22 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: David Freedman X-Mailer: Apple Mail (2.1084) Cc: "idr@ietf.org" Subject: Re: [Idr] Adoption of draft-jasinska-ix-bgp-route-server-03 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, 20 Jan 2012 21:18:26 -0000 Er, thunked I already said this, but don't see it in A: my sent mail or = b: the archives.=20 Support. W On Jan 19, 2012, at 6:58 PM, David Freedman wrote: > Support! > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From ttauber@1-4-5.net Fri Jan 20 21:14: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 CD09C21F850F for ; Fri, 20 Jan 2012 21:14:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.676 X-Spam-Level: X-Spam-Status: No, score=-102.676 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 xWEFqtvzVHxZ for ; Fri, 20 Jan 2012 21:14:02 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 47B6A21F84A2 for ; Fri, 20 Jan 2012 21:14:02 -0800 (PST) Received: by vbbfr13 with SMTP id fr13so945017vbb.31 for ; Fri, 20 Jan 2012 21:14:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.71.106 with SMTP id t10mr223733vdu.103.1327122841741; Fri, 20 Jan 2012 21:14:01 -0800 (PST) Received: by 10.220.180.200 with HTTP; Fri, 20 Jan 2012 21:14:01 -0800 (PST) X-Originating-IP: [24.104.152.66] In-Reply-To: <20120120144137.GB9830@slice> References: <20120119001455.5790.51802.idtracker@ietfa.amsl.com> <20120120144137.GB9830@slice> Date: Sat, 21 Jan 2012 00:14:01 -0500 Message-ID: From: Tony Tauber To: Jeffrey Haas X-Gm-Message-State: ALoCoQn9Xn09bZPC16PU5XIQ+glG6D5SOOh6rUumteyyXrQzOIbTmxNngMhG/SCQAX6C+4mbs6oz Content-Type: multipart/alternative; boundary=20cf307cfbce8e281804b702dd16 Cc: idr@ietf.org Subject: Re: [Idr] I-D Action: draft-ietf-idr-as0-03.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: Sat, 21 Jan 2012 05:14:02 -0000 --20cf307cfbce8e281804b702dd16 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jan 20, 2012 at 9:41 AM, Jeffrey Haas wrote: > > > Filename : draft-ietf-idr-as0-03.txt > > I feel significantly better about this text. :-) > > -- Jeff > Likewise. Tony --20cf307cfbce8e281804b702dd16 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Jan 20, 2012 at 9:41 AM, Jeffrey Haas <jhaas@pfrc.org> wrote:

> =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-idr-as0-03.txt

I feel significantly better about this text. :-)

-- Jeff

Likewise.

Tony
--20cf307cfbce8e281804b702dd16-- From ub@cs.uni-bonn.de Sun Jan 22 10:04: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 F21FF21F8541 for ; Sun, 22 Jan 2012 10:04:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.76 X-Spam-Level: X-Spam-Status: No, score=-4.76 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_DE=0.35, 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 Y0DG23KRYe6p for ; Sun, 22 Jan 2012 10:04:30 -0800 (PST) Received: from postfix.iai.uni-bonn.de (postfix.iai.uni-bonn.de [131.220.8.4]) by ietfa.amsl.com (Postfix) with ESMTP id 3652021F853F for ; Sun, 22 Jan 2012 10:04:28 -0800 (PST) X-IAI-Env-From: : [93.129.170.85] Received: from uli-nb-unibonn-wlan.fritz.box (koln-5d81aa55.pool.mediaWays.net [93.129.170.85]) by postfix.iai.uni-bonn.de (Postfix) with ESMTP id 56C8A5C403; Sun, 22 Jan 2012 19:04:26 +0100 (MET) (envelope-from ub@cs.uni-bonn.de) (envelope-to VARIOUS) (7) (internal use: ta=1, tu=1, te=1, am=P, au=ub) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Uli Bornhauser In-Reply-To: Date: Sun, 22 Jan 2012 19:04:16 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Ruichuan Chen X-Pgp-Agent: GPGMail 1.3.3 X-Mailer: Apple Mail (2.1084) Cc: "idr@ietf.org List" , rrg@irtf.org, Martin Horneffer , routing-wg@ripe.net Subject: Re: [Idr] Address-based Route Reflection 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, 22 Jan 2012 18:04:32 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Ruichuan, I am really happy that we can see new concepts that address the iBGP = anomaly problem. A few years ago, we also worked at that problem. In = that context, we could already develop and publish a concept that = inherently solves the iBGP anomaly problem. A paper presenting the = concept was published at the LCN 2009 [1]. Focussing the demands of ISPs, we developed the so called "iBGP Route = Server Architecture". For the architecture, we *formally* proved that = the concept inherently avoids suboptimal routing decisions, inconsistent = routing decisions, and robustness problems (oscillation, = non-determinism). In the following document, you find all details on the = concept: = https://net.cs.uni-bonn.de/fileadmin/user_upload/ub/slides/bornhauser-phd-= 2011.pdf Against the background of that experience, let me give you some feedback = on your approach: (1) As far as I understood your abstract and the paper itself, your = approach realizes an information exchange that is comparable to = full-mesh iBGP (even if the information exchange is slightly different). = In principle, this leads to correctness properties comparable to = full-mesh iBGP. However, the conclusion that this means that your = concept implements an anomaly-free iBGP is not correct. To be precise, = it means: - - I agree that your concepts avoids robustness problems (especially = oscillation). - - Your concept still allows consistency problems. - - I disagree to your assertion that path inefficiencies are avoided in = arbitrary configurations. You find all the details and exemplary configurations on that in [2]. = The point here is that even if iBGP is clearly more robust than RR or AS = confederations due to the lower degree of information reduction, = operationally unwanted behavior (anomalies) may still appear. (2) To really guarantee an anomaly-free iBGP, your concept can be = developed in two different ways: Either the decision process has to be = modified (unwanted in general) or also clients (to be precise speakers = that keep eBGP sessions) have to provide more information to your = central component(s) than common iBGP specifies. You find the details in = the document I linked above. (3) Even if dividing the amount of information processed by a central = routing device by address space (and not by topological closeness) is a = helpful concept to avoid scalability problems, this should not be = necessary in most cases. You also find a detailed scalability analysis = for a large AS and the generalizing conclusions substantiating my = opinion in the document I linked above, too. (4) Assuming that putting no constraints on RR placements may also mean = that your abandon RRs at all (what you also propose in my understanding = by replacing TBRRs by ABRRs), your concept is not the first solution = ;-). Generally, if you modify your concepts to address these issues, you will = probably come to an architecture that is a mixture between the iBGP = Route Server Architecture and Iuniana's oBGP concept. Thoughts that may = help to improve your concept may be found in [4]. I would be really = happy if we discuss some further details on your concept.=20 Best Regards Uli [1] http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=3D5355200 [2] = http://net.cs.uni-bonn.de/fileadmin/user_upload/ub/papers/UB-KIVS-2011.pdf= [3] http://iuniana.ro/publications/networking_11.pdf [4] http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=3D5735762 Am 13.01.2012 um 19:48 schrieb Ruichuan Chen: > Dear all, >=20 > The document below may be of interest: >=20 > "Address-based Route Reflection" at > http://bgp.mpi-sws.org/papers/abrr-CoNEXT11.pdf >=20 > by Ruichuan Chen (MPI-SWS), Aman Shaikh (AT&T Labs Research), Jia Wang > (AT&T Labs Research), Paul Francis (MPI-SWS) >=20 > =3D=3D=3D=3D Abstract =3D=3D=3D=3D >=20 > This work presents Address-Based Route Reflection (ABRR): the first > iBGP solution that completely solves all oscillation and looping > problems, has no path inefficiencies, and puts no constraints on RR > placement. ABRR does this by emulating the semantics of full-mesh > iBGP, and thereby adopting the correctness and path efficiency > properties of full-mesh iBGP. Both traditional Topology-Based Route > Reflection (TBRR) and ABRR take a divide-and-conquer approach. While > TBRR scales by making each RR responsible for all prefixes from some > fraction of routers, ABRR scales by making each RR responsible for > some fraction of prefixes from all routers. >=20 > Best regards, > --Ruichuan > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr - --=20 https://net.cs.uni-bonn.de/ub -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) iF4EAREIAAYFAk8cT6kACgkQHjTkVxyUO5wRpQEAsB3x1kyG5L5hlQX4dXvHNCaW vqkR677GE0ZfzHOQ1gwBAIpeY6/OBZTYLbuc4pChHXycYsje6js1aKLPeEmjFIJC =3D5bYk -----END PGP SIGNATURE----- From internet-drafts@ietf.org Wed Jan 25 09:38: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 544C121F8618; Wed, 25 Jan 2012 09:38:46 -0800 (PST) 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 RibtSPQq99eI; Wed, 25 Jan 2012 09:38:45 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEC1821F8601; Wed, 25 Jan 2012 09:38:45 -0800 (PST) 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: 3.64p1 Message-ID: <20120125173845.25435.17059.idtracker@ietfa.amsl.com> Date: Wed, 25 Jan 2012 09:38:45 -0800 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-legacy-rtc-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: Wed, 25 Jan 2012 17:38: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 : Automatic Route Target Filtering for legacy PEs Author(s) : Pradosh Mohapatra Arjun Sreekantiah Keyur Patel Burjiz Pithawala Alton Lo Filename : draft-ietf-idr-legacy-rtc-00.txt Pages : 11 Date : 2012-01-18 This document describes a simple procedure that allows "legacy" BGP speakers to exchange route target membership information in BGP without using mechanisms specified in RFC 4684. The intention of the proposed technique is to help in partial deployment scenarios and is not meant to replace RFC 4684. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-legacy-rtc-00.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-legacy-rtc-00.txt From jgs@juniper.net Fri Jan 27 08:04: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 28DE921F84F3 for ; Fri, 27 Jan 2012 08:04:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[AWL=0.047, 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 EPVYdmzV0qwP for ; Fri, 27 Jan 2012 08:04:15 -0800 (PST) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by ietfa.amsl.com (Postfix) with ESMTP id 9689C21F84F1 for ; Fri, 27 Jan 2012 08:04:14 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKTyLK/qRbPItZ2irhU852r4DE2kljZddf@postini.com; Fri, 27 Jan 2012 08:04:14 PST Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Fri, 27 Jan 2012 08:02:19 -0800 From: John Scudder To: John Scudder Date: Fri, 27 Jan 2012 08:02:17 -0800 Thread-Topic: [Idr] Adoption of draft-varlashkin-bgp-nh-cost-02 as IDR WG document? Thread-Index: AczdDQtJ65heFySaTz2pNVTp0tZ0jA== Message-ID: <3B78ECA0-B9DE-442A-A0E8-F974B2827923@juniper.net> References: <7B61DC70-08D9-46C7-8C15-5DD339C61C2D@juniper.net> In-Reply-To: <7B61DC70-08D9-46C7-8C15-5DD339C61C2D@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" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "idr@ietf.org List" Subject: Re: [Idr] Adoption of draft-varlashkin-bgp-nh-cost-02 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, 27 Jan 2012 16:04:19 -0000 The draft is adopted as an IDR Working Group document. Authors, please resu= bmit as draft-ietf-idr. Thanks, --John On Nov 16, 2011, at 1:06 AM, John Scudder wrote: Folks, We have received a request from the authors to adopt draft-varlashkin-bgp-n= h-cost-02 as an IDR WG document. Please send your comments to the list. T= he deadline for comments is December 5, 2011 at noon EST. Thanks, --John _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From internet-drafts@ietf.org Mon Jan 30 08:46: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 3C04611E808D; Mon, 30 Jan 2012 08:46:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, 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 KGRNeMVvnTpE; Mon, 30 Jan 2012 08:46:26 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B97DF11E8072; Mon, 30 Jan 2012 08:46:26 -0800 (PST) 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: 3.64p1 Message-ID: <20120130164626.4262.87242.idtracker@ietfa.amsl.com> Date: Mon, 30 Jan 2012 08:46:26 -0800 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-bgp-nh-cost-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, 30 Jan 2012 16:46:27 -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 : Carrying next-hop cost information in BGP Author(s) : Ilya Varlashkin Robert Raszuk Filename : draft-ietf-idr-bgp-nh-cost-00.txt Pages : 9 Date : 2012-01-30 This document describes new BGP SAFI to exchange cost information to next-hops for the purpose of calculating best path from a peer perspective rather than local BGP speaker own perspective. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-nh-cost-00.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-bgp-nh-cost-00.txt From warren@kumari.net Tue Jan 31 19:40: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 931ED21F858A for ; Tue, 31 Jan 2012 19:40:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.478 X-Spam-Level: X-Spam-Status: No, score=-106.478 tagged_above=-999 required=5 tests=[AWL=0.121, 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 ATlgmt+I-QE2 for ; Tue, 31 Jan 2012 19:40:25 -0800 (PST) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 10E6A21F8585 for ; Tue, 31 Jan 2012 19:40:24 -0800 (PST) Received: from [192.168.0.12] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id E450A1B415EE; Tue, 31 Jan 2012 22:40:23 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Warren Kumari In-Reply-To: Date: Tue, 31 Jan 2012 22:40:23 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <41B3F4D7-D2A9-4843-8210-5D6920F62F92@kumari.net> References: <20120119001455.5790.51802.idtracker@ietfa.amsl.com> <20120120144137.GB9830@slice> To: Tony Tauber X-Mailer: Apple Mail (2.1084) Cc: idr@ietf.org Subject: Re: [Idr] I-D Action: draft-ietf-idr-as0-03.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, 01 Feb 2012 03:40:25 -0000 On Jan 21, 2012, at 12:14 AM, Tony Tauber wrote: > On Fri, Jan 20, 2012 at 9:41 AM, Jeffrey Haas wrote: >=20 > > Filename : draft-ietf-idr-as0-03.txt >=20 > I feel significantly better about this text. :-) >=20 > -- Jeff >=20 > Likewise. >=20 So, is the WG generally happy with this? Does it feel that this is = sufficiently baked to request WGLC? Get your final hits in now=85 W > Tony=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr -- Don't be impressed with unintelligible stuff said condescendingly. -- Radia Perlman.