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 1992 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