Re: Addr: Re: BGP-4 - revised I-D
Tony Li <tli@jnx.com> Wed, 28 August 1996 22:36 UTC
Received: from ietf.org by ietf.org id aa04986; 28 Aug 96 18:36 EDT
Received: from cnri by ietf.org id aa04982; 28 Aug 96 18:36 EDT
Received: from merit.edu by CNRI.Reston.VA.US id aa15053; 28 Aug 96 18:36 EDT
Received: (from daemon@localhost) by merit.edu (8.7.5/merit-2.0) id SAA24020
for idr-outgoing; Wed, 28 Aug 1996 18:02:04 -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 SAA24015 for <bgp@merit.edu>;
Wed, 28 Aug 1996 18:02:01 -0400 (EDT)
Received: by interlock.ans.net id AA23365
(InterLock SMTP Gateway 3.0 for bgp@ans.net);
Wed, 28 Aug 1996 18:01:55 -0400
Received: by interlock.ans.net (Internal Mail Agent-2);
Wed, 28 Aug 1996 18:01:55 -0400
Received: by interlock.ans.net (Internal Mail Agent-1);
Wed, 28 Aug 1996 18:01:55 -0400
Date: Wed, 28 Aug 1996 15:01:48 -0700 (PDT)
Message-Id: <199608282201.PAA04415@chimp.jnx.com>
Sender: ietf-archive-request@ietf.org
From: Tony Li <tli@jnx.com>
To: jgs@ieng.com
Cc: curtis@ans.net, bgp@ans.net, tli@jnx.com, yakov@cisco.com
In-Reply-To: <v0300781dae4a5559835d@[36.141.0.30]> (jgs@ieng.com)
Subject: Re: Addr: Re: BGP-4 - revised I-D
X-Orig-Sender: owner-idr@merit.edu
Precedence: bulk
>Yes it is absolutely neccesary. The order in which routes are >compared impacts the outcome of the comparison. How is the text already in RFC 1771 section 9.1 not sufficient to clearly specify the order? To summarize, it says that when selecting a route you should consider, *in this order*: - Local_Pref - MED (adding the note that you can only compare MED between like ASes) - IGP distance - EBGP better than IBGP - Router ID If I understand what Curtis is getting at (50% chance, max), there is some ambiguity (or at least possibility of misinterpretation) in the MED comparison step. One interpretation is: - group the routes by neighboring AS - within each group, select the routes with the best MED which is also what I think is the intended interpretation. Alternate interpretations include: i) - group the routes by neighboring AS - within each group, select _a_ route with the best MED ii) - across all routes, select the routes with the best MED [yes, this violates the comparison] iii) - if route A has a better MED than route B, but both are incomparable to route C, and route B has a better IGP distance than C, while A has a worse IGP distance than C, select route B. [I believe that cisco's implementation had this bug for a while and that this is now fixed.] As far as I can tell this specifies everything which is needed for loop-free operation (I do understand the issue and agree with you). I think that this: > One route from the neighboring > AS is selected as best. The best routes from each of these > neighboring AS are then compared. goes from specifying the algorithm (necessary) to specifying implementation (unneccessary). Perhaps 9.1.2.1 could be made even more explicit as to the order in which the tie-breaking criteria must be applied, and there could be a forward reference from 5.1.4 to make sure people don't miss this. I would suggest that while it is more specific, it possibly introduces more bugs (do you select ONE route? what happens if there are multiple routes with identical best MED?). Yes, I think that this all boils down to wordsmithing some more explicit text... I look forward to the concrete proposals. Tony
- Addr: Re: BGP-4 - revised I-D rwoundy
- Re: Addr: Re: BGP-4 - revised I-D Curtis Villamizar
- RE: Addr: Re: BGP-4 - revised I-D NITTMANN Michael (MSMail)
- Re: Addr: Re: BGP-4 - revised I-D Curtis Villamizar
- Re: Addr: Re: BGP-4 - revised I-D Jessica Yu
- Re: Addr: Re: BGP-4 - revised I-D Tony Li
- Re: Addr: Re: BGP-4 - revised I-D Curtis Villamizar
- Re: Addr: Re: BGP-4 - revised I-D Curtis Villamizar
- Re: Addr: Re: BGP-4 - revised I-D John G. Scudder
- Re: Addr: Re: BGP-4 - revised I-D Curtis Villamizar
- Re: Addr: Re: BGP-4 - revised I-D Tony Li
- Re: Addr: Re: BGP-4 - revised I-D Curtis Villamizar
- Re: Addr: Re: BGP-4 - revised I-D Curtis Villamizar
- Re: Addr: Re: BGP-4 - revised I-D Tony Li
- Re: Addr: Re: BGP-4 - revised I-D John G. Scudder
- Re: Addr: Re: BGP-4 - revised I-D Tony Li
- Re: Addr: Re: BGP-4 - revised I-D Curtis Villamizar
- Re: FW: Addr: Re: BGP-4 - revised I-D Curtis Villamizar
- Re: Addr: Re: BGP-4 - revised I-D Curtis Villamizar
- Re: Addr: Re: BGP-4 - revised I-D Curtis Villamizar
- Re: Addr: Re: BGP-4 - revised I-D Tony Li
- Re: Addr: Re: BGP-4 - revised I-D Curtis Villamizar
- Re: Addr: Re: BGP-4 - revised I-D Tony Li
- Re: Addr: Re: BGP-4 - revised I-D John G. Scudder
- Re: Addr: Re: BGP-4 - revised I-D John G. Scudder
- FW: Addr: Re: BGP-4 - revised I-D NITTMANN Michael (MSMail)
- RE: FW: Addr: Re: BGP-4 - revised I-D NITTMANN Michael (MSMail)