Re: Addr: Re: BGP-4 - revised I-D

Curtis Villamizar <curtis@ans.net> Wed, 28 August 1996 18:21 UTC

Received: from ietf.org by ietf.org id aa25171; 28 Aug 96 14:21 EDT
Received: from cnri by ietf.org id aa25160; 28 Aug 96 14:21 EDT
Received: from merit.edu by CNRI.Reston.VA.US id aa11185; 28 Aug 96 14:21 EDT
Received: (from daemon@localhost) by merit.edu (8.7.5/merit-2.0) id NAA18938 for idr-outgoing; Wed, 28 Aug 1996 13:38:45 -0400 (EDT)
Received: from interlock.ans.net (interlock.ans.net [147.225.5.5]) by merit.edu (8.7.5/merit-2.0) with SMTP id NAA18933 for <bgp@merit.edu>; Wed, 28 Aug 1996 13:38:42 -0400 (EDT)
Received: by interlock.ans.net id AA14835 (InterLock SMTP Gateway 3.0 for bgp@ans.net); Wed, 28 Aug 1996 13:38:40 -0400
Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 28 Aug 1996 13:38:40 -0400
Message-Id: <199608281736.NAA29650@brookfield.ans.net>
To: "John G. Scudder" <jgs@ieng.com>
Cc: bgp@ans.net, tli@jnx.com, yakov@cisco.com
Reply-To: curtis@ans.net
Subject: Re: Addr: Re: BGP-4 - revised I-D
In-Reply-To: Your message of "Tue, 27 Aug 1996 15:14:54 PDT." <v03007820ae49140b08b4@[36.141.0.30]>
Date: Wed, 28 Aug 1996 13:36:19 -0400
Sender: ietf-archive-request@ietf.org
From: Curtis Villamizar <curtis@ans.net>
X-Orig-Sender: owner-idr@merit.edu
Precedence: bulk

In message <v03007820ae49140b08b4@[36.141.0.30]>0]>, "John G. Scudder" writes:
> 
> I don't know if folks think it is also necessary to specify an algorithm to
> do this, e.g. the election Rich has written about.  I tend to think of this
> as an implementation detail, but if people are complaining that MED is too
> hard to implement, I guess an existence proof to the contrary might be
> useful.  Perhaps as an appendix?


Yes it is absolutely neccesary.  The order in which routes are
compared impacts the outcome of the comparison.

Lets say we don't.

Most readers will not notice that there is the possibility of a
routing loop.  Routing loops will form.

The very astute reader will notice that there is the possibility of a
routing loop if the order of comparison is not constrained to be the
same on all routers.  Said reader picks an algorithm.  The algorithm
chosen is to compare all routes in order of lowest advertising router
first.  These routers work fine in a network of like routers.  Put in
a router using Rich's algorithm and a routing loop forms since those
routers evaluate in a different order and come to a different
conclusion about which route is best.

This will form routing loops.  Its been proven in real networks.

The text could be as simple as:

> 5.1.4   MULTI_EXIT_DISC
> 
>    The MULTI_EXIT_DISC attribute may be used on external (inter-AS)
>    links to discriminate among multiple exit or entry points to the same
>    neighboring AS.  The value of the MULTI_EXIT_DISC attribute is a four
>    octet unsigned number which is called a metric.  All other factors
>    being equal, the exit or entry point with lower metric should be
>    preferred.  If received over external links, the MULTI_EXIT_DISC
>    attribute may be propagated over internal links to other BGP speakers
>    within the same AS.  The MULTI_EXIT_DISC attribute is never
>    propagated to other BGP speakers in neighboring AS's.

   Due to the MED rules, route comparisons among all of the available
   routes may not have the transitive property.  Under some circumstances
   routing loops can form if routes are not evaluated in the same or a
   similar order on all routers.  The following order of comparison must
   be implemented:

   All routes from the same neighboring AS are compared.  The MED value
   and the presence or absence of MED must be considered when comparing
   routes from the same neighboring AS.  One route from the neighboring
   AS is selected as best.  The best routes from each of these
   neighboring AS are then compared.  The MED value or the presence or
   absence of MED must be ignored when comparing the best route from each
   neighboring AS.

This text assures that all implementors that carefully read an follow
the BGP4 spec will end up with implementations that 1) are loop free,
2) interoperate in a loop free manner with other implementations, 3)
don't require that MED be completely disabled to remain loop free in
the presence of other implementations.

Curtis