Re: [Idr] I-D Action: draft-ietf-idr-error-handling-01.txt

Robert Raszuk <robert@raszuk.net> Mon, 19 December 2011 14:25 UTC

Return-Path: <robert@raszuk.net>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEBA521F8B7D for <idr@ietfa.amsl.com>; Mon, 19 Dec 2011 06:25:07 -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 zWpZRbkkmIg0 for <idr@ietfa.amsl.com>; Mon, 19 Dec 2011 06:25:07 -0800 (PST)
Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 066E021F8B38 for <idr@ietf.org>; Mon, 19 Dec 2011 06:25:07 -0800 (PST)
Received: (qmail 19524 invoked by uid 399); 19 Dec 2011 14:25:06 -0000
Received: from unknown (HELO ?192.168.1.91?) (83.31.234.225) by mail1310.opentransfer.com with ESMTP; 19 Dec 2011 14:25:06 -0000
X-Originating-IP: 83.31.234.225
Message-ID: <4EEF4942.6050105@raszuk.net>
Date: Mon, 19 Dec 2011 15:25:06 +0100
From: Robert Raszuk <robert@raszuk.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: bruno.decraene@orange.com
References: <20111215233845.21432.33837.idtracker@ietfa.amsl.com> <37936E57-4A5E-4B6B-8BA8-C7CD5722C1A6@ericsson.com> <4EEB6C23.4080803@raszuk.net> <DD5D1AB4-35A6-4B5E-AB1B-B5F21AA3CE31@ericsson.com> <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>
In-Reply-To: <26782_1324294649_4EEF21F9_26782_3157_1_53C29892C857584299CBF5D05346208A010D51@PEXCVZYM11.corporate.adroot.infra.ftgroup>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "idr@ietf.org" <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
Reply-To: robert@raszuk.net
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/idr>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Dec 2011 14:25:07 -0000

Hi Bruno,

> You are assuming a local error with your neighbor. Chances are that
> errors have been trigger by a specific state and that all backup
> paths also got that state. Hence you can't assume that there would be
> a backup path if you choose to shut down the session.

Reasonable networks have many neighbors. The like hood that due to 
mandatory BGP attribute error we will experience an outage from all 
neighbors is rather quite unlikely IMHO.

However I am not opposing recommendations of 
draft-ietf-idr-error-handling. What I am not quite comfortable with is 
to assume that this should be the new default behaviour.

You say that "we don't like it" what is happening today. One may argue 
that "some do not like it some do". Those who do not like it do they 
really use already available tools like multisession deployed in 
production to limit one SAFI impacting other SAFIs ? Could they just not 
use validating layer before the BGP update hits RP ?

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.

--

Also note that if this is hacker on the CE trying to mess with his EBGP 
session towards PE to perhaps destroy other VPNs on such PE keeping the 
session up is only helping him to better attack the PE. Is this the 
aspect of "improvement" you have all considered ?

--

Last is I think the point that Ilya brought. While we are at the topic 
let's address the flapping session problem (assume that non of 
conditions in the new draft apply) and that session is getting resetted. 
It seems valid to me to accumulate penalty on such consecutive resets 
and keep the session shut when such penalty reaches some value. While 
some may say that this is implementation thing some may also see 
reasonable to define what the behaviour should be.

Best regards,
R.