Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by
 nic.merit.edu (8.9.3/8.9.1) with ESMTP id XAA05056 for
 <idr-archive@nic.merit.edu>; Sun, 29 Feb 2004 23:45:03 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by
 optimus.ietf.org with esmtp (Exim 4.20) id 1AxfIc-0000bH-3g;
 Sun, 29 Feb 2004 23:45:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by
 optimus.ietf.org with esmtp (Exim 4.20) id 1AxfI7-0000aD-RM for
 idr@optimus.ietf.org; Sun, 29 Feb 2004 23:44:31 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org
 (8.9.1a/8.9.1a) with ESMTP id XAA01716 for <idr@ietf.org>;
 Sun, 29 Feb 2004 23:44:29 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id
 1AxfI5-0005b4-00 for idr@ietf.org; Sun, 29 Feb 2004 23:44:29 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id
 1AxfHD-0005UW-00 for idr@ietf.org; Sun, 29 Feb 2004 23:43:36 -0500
Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12)
 id 1AxfGW-0005Lv-00 for idr@ietf.org; Sun, 29 Feb 2004 23:42:52 -0500
Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with
 ESMTP id i214gNm28160 for <idr@ietf.org>; Mon, 1 Mar 2004 06:42:23 +0200
From: Pekka Savola <pekkas@netcore.fi>
To: idr@ietf.org
Subject: Re: [Idr] issue 11.2: active route,
 again [Re: comments on idr-bgp4-20] (fwd)
Message-ID: <Pine.LNX.4.44.0403010634130.27997-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on
 ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Sender: idr-admin@ietf.org
Errors-To: idr-admin@ietf.org
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>,
 <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>,
 <mailto:idr-request@ietf.org?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Mon, 1 Mar 2004 06:42:23 +0200 (EET)

FWIW, I do ot believe my re-opening this issue -- has been addressed.

In short, there are very valid operational requirements why BGP should 
consider route of any protocol, not just BGP, as active.  (This is the 
problem with point-to-point and loopback addresses.)

I can also raise this issue at IETF LC, or later at IESG review time,
of course.

My first message below.
====
Date: Tue, 7 Oct 2003 22:56:30 +0300 (EEST)
From: Pekka Savola <pekkas@netcore.fi>
To: Yakov Rekhter <yakov@juniper.net>
Cc: idr@ietf.org
Subject: issue 11.2: active route, again [Re: comments on idr-bgp4-20]

Hi again,

[clipping the quote down]

On Tue, 30 Sep 2003, Yakov Rekhter wrote:
[...]
> From draft-ietf-idr-bgp-issues-01.txt:
> 
>    After some additional discussion (in the "issue 11.2" thread), we
>    have come to a consensus on this text:
>    
>    In the context of this document we assume that a BGP speaker
>    advertises to its peers only those routes that it itself uses (in
>    this context a BGP speaker is said to "use" a BGP route if it is the 
>    most preferred BGP route and is used in forwarding). All other cases
>    are outside the scope of this document.
>    
>    This issue is at consensus.
> 
> So, the text in the spec represents consensus of the WG. Also note
> the last sentence in the above paragraph.

I've looked at the several threads in the archives, which do not seem to 
address the relevant points at all.

So, I think the issue needs to be reconsidered.

For example, consider a scenario of three routers in two ASs:

 rtr1 |      | rtr2 --- rtr3
 AS1  | ---- | AS2      AS2
 -----'      '-----

rtr3 is configured to advertise prefix 1.0.0.0/8 using BGP.  It has an
IBGP session to rtr2, where it will advertise it.  The AS2 also has an 
IGP, which includes only the loopbacks and point-to-point addresses of the 
AS.

IBGP also includes the loopback addresses and point-to-point addresses.
AS2 also wants to advertise the loopback addresses and PtP's to AS1 using
specific communities marked at the routers.  (There are multiple reasons
advertising loopbacks/ptps such is desirable.. for example, our network
employs private AS numbers and eBGP sessions and this is vital.)

Now, rtr2 advertises the prefix 1.0.0.0/8 just fine using eBGP to rtr1, 
but the loopback addresses and PtP's won't get advertised because the IGP 
is more preferred, and for BGP's perspective, the BGP routes are not 
"active".

Workarounds to this issue exist:
 - use an implementation-specific clause like "advertise-inactive", 
breaking the spec, to advertise them anyway, or
 - redistribute the IGP routes to BGP at the border router rtr2, losing 
communities etc. markings of iBGP in the process.  Ugly.

What I'm arguing here that there seem to be very clear operational reasons
why the "BGP route must be used for forwarding" is very counterproductive
and we should fix/clarify the spec to have a more useful definition for
it.

Are there any killer arguments why this is *NOT* a good idea?
======

---------- Forwarded message ----------
Date: Thu, 9 Oct 2003 19:36:49 +0300 (EEST)
From: Pekka Savola <pekkas@netcore.fi>
To: Pedro Roque Marques <roque@juniper.net>
Cc: idr@ietf.org
Subject: Re: [Idr] issue 11.2: active route,
     again [Re: comments on idr-bgp4-20]

On Wed, 8 Oct 2003, Pedro Roque Marques wrote:
> Pekka Savola writes:
> > On Tue, 7 Oct 2003, Pedro Roque Marques wrote:
> >> Pekka Savola writes: > Are there any killer arguments why this is
> >> *NOT* a good idea?
> >> 
> >> The main objective of BGP is to make sure that there are no routing
> >> or forwarding loops. When BGP advertises a route that is not in the
> >> forwarding table those guarantees disapear.
> 
> > The route to the same prefix (and in this case, the same nexthop as
> > well) _is_ in the forwarding table.
> 
> - BGP shouldn't be required to understand which next-hops other
> protocols use.

Who said it would have to?  All it has to do it to look at the forwarding 
table, which it must be able to do anyway.

> - Given that it typically doesn, and actually typically a route w/
> another protocol as a different next-hop, there is no way to guarantee
> that you will not have routing/forwarding loops.

I think the practice has shown this does not occur.
 
-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings





_______________________________________________
Idr mailing list
Idr@ietf.org
https://www1.ietf.org/mailman/listinfo/idr

