Re: [Idr] draft-uttaro-idr-bgp-persistence-00

<bruno.decraene@orange.com> Tue, 22 November 2011 14:48 UTC

Return-Path: <bruno.decraene@orange.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FFFC21F8C99 for <idr@ietfa.amsl.com>; Tue, 22 Nov 2011 06:48:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.189
X-Spam-Level:
X-Spam-Status: No, score=-4.189 tagged_above=-999 required=5 tests=[AWL=2.060, BAYES_00=-2.599, HELO_EQ_FR=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 mMamXckMLIex for <idr@ietfa.amsl.com>; Tue, 22 Nov 2011 06:48:26 -0800 (PST)
Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id 9A95621F8C8E for <idr@ietf.org>; Tue, 22 Nov 2011 06:48:26 -0800 (PST)
Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 98CBD340003; Tue, 22 Nov 2011 15:48:24 +0100 (CET)
Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 8DA39340001; Tue, 22 Nov 2011 15:48:24 +0100 (CET)
Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 22 Nov 2011 15:48:24 +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: Tue, 22 Nov 2011 15:48:23 +0100
Message-ID: <FE8F6A65A433A744964C65B6EDFDC24002A155DF@ftrdmel0.rd.francetelecom.fr>
In-Reply-To: <4EC32C36.8070902@riw.us>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Idr] draft-uttaro-idr-bgp-persistence-00
Thread-Index: AcykDtz5gMgIU07kSjaciAI+tzczqAE58UEQ
References: <4EA1F0FB.3090100@raszuk.net> <4EA487E4.2040201@raszuk.net><B17A6910EEDD1F45980687268941550FA20750@MISOUT7MSGUSR9I.ITServices.sbc.com><4EA84254.9000400@raszuk.net> <4EA8A91C.4090305@cisco.com><B17A6910EEDD1F45980687268941550FA20BB8@MISOUT7MSGUSR9I.ITServices.sbc.com><4EAA496C.9070605@cisco.com><B17A6910EEDD1F45980687268941550FA21F96@MISOUT7MSGUSR9I.ITServices.sbc.com><B17A6910EEDD1F45980687268941550FA324FA@MISOUT7MSGUSR9I.ITServices.sbc.com><4EC21062.5020504@raszuk.net><B17A6910EEDD1F45980687268941550FA32664@MISOUT7MSGUSR9I.ITServices.sbc.com><4EC28B45.1040509@raszuk.net> <4EC32C36.8070902@riw.us>
From: bruno.decraene@orange.com
To: russw@riw.us
X-OriginalArrivalTime: 22 Nov 2011 14:48:24.0798 (UTC) FILETIME=[C9982FE0:01CCA925]
Cc: idr@ietf.org, ju1738@att.com
Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-00
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
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: Tue, 22 Nov 2011 14:48:27 -0000

Russ,

>From: Russ White, Sent: Wednesday, November 16, 2011 4:21 AM
>
>> I am personally completely not convinced that there is any value in
>> informing my peers that one of my BGP sessions went down. You either
>> have reachability to next hop and can attract traffic or you do not
and
>> if so you withdraw.
>>
>> Telling peers that "I may be perhaps used to reach prefix X as last
>> resort" is of highly questionable value.
>
>I would go farther --this isn't questionable, it's really bad. If you
>have a route you know exists, but you don't want people to use, set
>things so it's a "last resort" (wait for BGP, wait for LDP, etc). If
you
>don't know whether or not you really have reachability, don't advertise
it.

As you don't comment on Graceful Restart (GR), I assume that you are
fine with GR.
Are you?

Then I think we need to make a distinction between the information we
have on a route, and the routing decision we make based on those
information.

a) failure assumption:
let's assume a PE can lose both its iBGP session toward its redundant RR
Note: the assumption is the same for GR and persistence.

b) information available:
Once the BGP session(s) are down, we have the following information
available on the BGP router: cause of failure, route tags, time (t)
elapsed since the session failure, local configuration/preference
Note: idem for GR and persistence.

At that point, I would say that once t>0, we have no certainty on the
validity of the route (from the BGP peer/BGP Next-Hop and from
downstream BGP routers). And the longer the duration, the less
certainty.
Note: for a given "t", this is the same for GR and persistence. Hence I
don't get how you claim that "it's really bad" for persistence while
it's ok for GR.

c) routing decision:
Given the above information and level of uncertainty, at a given "t"
time, currently 2 routing decisions are possible:
- withdraw the route.
	- This is the regular BGP behavior. 
	- The reasoning is that the level of uncertainty is too high to
use that route.
- keep the route.
	- This is the BGP Graceful Restart behavior. 
	- The reasoning is that the level of uncertainty is low enough
so that the route can still be considered perfectly valid.


But the router making the above decision is the BGP advertising router
hence the egress router. It's lacking some information only available on
the ingress router. Namely the availability of alternate paths/Next Hop
on the ingress. I call that this is an important information to make the
routing decision. Because in the end, each router/AS tries to take the
_best_ decision among _available_ options. This is not a binary decision
between "right/good" and "bad". So compared to GR, BGP persistence
proposes to give some additional information and routing decision on
upstream ingress BGP routers. (e.g. using "STALE" community, low BGP
local pref. But other vehicles could be considered).

Could you elaborate on why this would be "really bad"?

Thanks,
Regards,
Bruno

>The possible problems involved in saying, "I might have a route to x,
>just in case you don't have any other path there," will end up being
>really, really ugly.
>
>:-)
>
>Russ
>_______________________________________________
>Idr mailing list
>Idr@ietf.org
>https://www.ietf.org/mailman/listinfo/idr