[Idr] Clarification for section 9.1.2 of rfc4271
"Ilya Varlashkin" <Ilya.Varlashkin@de.easynet.net> Tue, 23 October 2007 10:46 UTC
Return-path: <idr-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkHHm-0004OI-0O; Tue, 23 Oct 2007 06:46:58 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkHHi-0004G3-OC for idr@ietf.org; Tue, 23 Oct 2007 06:46:54 -0400
Received: from softy.ision.net ([194.163.250.97]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IkHHY-0000z0-C9 for idr@ietf.org; Tue, 23 Oct 2007 06:46:50 -0400
Received: from paul.de.easynet.net ([195.180.208.152] helo=paul.adoffice.de.easynet.net) by softy.ision.net with esmtp (Exim 4.50) id 1IkHGt-0006xr-Br for idr@ietf.org; Tue, 23 Oct 2007 12:46:03 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 23 Oct 2007 12:46:02 +0200
Message-ID: <7000E71D8C525042A815432358B2F1240130461E@paul.adoffice.local.de.easynet.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Clarification for section 9.1.2 of rfc4271
Thread-Index: AcgVYegLb0mZP18RRwy9XBy/dFYjFA==
From: Ilya Varlashkin <Ilya.Varlashkin@de.easynet.net>
To: idr@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
Subject: [Idr] Clarification for section 9.1.2 of rfc4271
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
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>
Errors-To: idr-bounces@ietf.org
Hi, in the section 9.1.2 of RFC4271 third paragraph has phrase: "..., or if it would become unresolvable if the route was installed in the routing table, the BGP route MUST be excluded from the Phase 2 decision function." Consider a BGP router (say, router C) that received prefix 192.2.1.1/32 from two different iBGP neighbours as follow: 1) neighbour A set NEXT_HOP to itself and local-pref for this prefix is 100; this update was received first (in time) 2) neighbour B preserved original next-hop, which happened to be 192.2.1.1 and local-pref for this prefix is 150 (this update was received later) There are no any other routing information (whether via BGP or any other protocol) known to router C. Router C at the moment has 192.2.1.1/32 prefix in it's RIB pointing to router A's address. In this condition, does update from router B falls under cited requirement "would become unresolvable" and should it be excluded from further consideration or is it permissible (per RFC) to select such update as best and install it to the RIB? Kind regards, iLya _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr
- [Idr] Clarification for section 9.1.2 of rfc4271 Ilya Varlashkin
- Re: [Idr] Clarification for section 9.1.2 of rfc4… Tony Li