RFC 1267
Martha Steenstrup <msteenst@bbn.com> Sat, 23 May 1992 00:05 UTC
Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa03543;
22 May 92 20:05 EDT
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa23078;
22 May 92 20:12 EDT
Received: from PIZZA.BBN.COM by NRI.Reston.VA.US id aa23074;
22 May 92 20:12 EDT
Received: from pizza by PIZZA.BBN.COM id aa03323; 22 May 92 18:50 EDT
To: tli@cisco.com
cc: idpr-wg@bbn.com
Subject: RFC 1267
Date: Fri, 22 May 92 19:48:47 -0400
From: Martha Steenstrup <msteenst@bbn.com>
Message-ID: <9205222012.aa23074@NRI.Reston.VA.US>
Tony,
Thanks, I now understand what you are talking about. However, RFC
1267 does not indiciate the order in which the following should be
applied:
(1) Generally speaking, the rules for comparing routes among several
alternatives are outside the scope of this document. There are two
exceptions:
- If the local AS appears in the AS path of the new route being
considered, then that new route cannot be viewed as better than
any other route. If such a route were ever used, a routing loop
would result.
(2) In order for a route to a network to be removed, it must be
explicitly listed in an Update message as being unreachable or with
new routing information to replace the old. Note that a BGP peer will
only advertise one route to a given network, so any announcement of
that network by a particular peer replaces any previous information
about that network received from the same peer.
The order of application definitely matters so that the routes that
will cause the looping are actually removed. However, all of this is
predicated on the fact the route .. Y .. X .. Z is advertised back to
X and the route .. X .. Y .. Z is advertised back to Y. If these
advertisements are not made, then the looped routes X .. Y .. Z and
Y .. X .. Z will not be removed.
m