Re: Addr: Re: BGP-4 - revised I-D
Curtis Villamizar <curtis@ans.net> Wed, 28 August 1996 07:42 UTC
Received: from ietf.org by ietf.org id aa04760; 28 Aug 96 3:42 EDT
Received: from cnri by ietf.org id aa04756; 28 Aug 96 3:42 EDT
Received: from merit.edu by CNRI.Reston.VA.US id aa03023; 28 Aug 96 3:42 EDT
Received: (from daemon@localhost) by merit.edu (8.7.5/merit-2.0) id DAA10437
for idr-outgoing; Wed, 28 Aug 1996 03:16:34 -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 DAA10432 for <bgp@merit.edu>;
Wed, 28 Aug 1996 03:16:31 -0400 (EDT)
Received: by interlock.ans.net id AA01915
(InterLock SMTP Gateway 3.0 for bgp@ans.net);
Wed, 28 Aug 1996 03:16:29 -0400
Received: by interlock.ans.net (Internal Mail Agent-1);
Wed, 28 Aug 1996 03:16:29 -0400
Message-Id: <199608280714.DAA28875@brookfield.ans.net>
To: Tony Li <tli@jnx.com>
Cc: curtis@ans.net, jyy@ans.net, rwoundy@vnet.ibm.com, bgp@ans.net
Reply-To: curtis@ans.net
Subject: Re: Addr: Re: BGP-4 - revised I-D
In-Reply-To: Your message of "Tue, 27 Aug 1996 13:48:22 PDT."
<199608272048.NAA00324@chimp.jnx.com>
Date: Wed, 28 Aug 1996 03:14:33 -0400
Sender: ietf-archive-request@ietf.org
From: Curtis Villamizar <curtis@ans.net>
X-Orig-Sender: owner-idr@merit.edu
Precedence: bulk
In message <199608272048.NAA00324@chimp.jnx.com>om>, Tony Li writes: > > Curtis, > > MEDs are useful and are still useful if compared across AS. > > Why? There are clearly some semantics that you have in mind, but you're > not expressing the need at all. Given a global administrative metric > (hmmm... and I guess calling it the GAM attribute would lead us to be > politically incorrect... ;-), what information are you trying to convey? No. I'm saying that the normal case, at least for us, is to set local-pref based on the border AS and then only resolve using MED if the prefixes came from the same AS at two different places and it was same router or different routers and cold potatoe. The case where two border AS are announcing the same prefix at the same local-pref is an odd case and the policy indication is "we don't care - pick either one". So I don't care which one gets picked as long as the traffic goes out and doesn't go around in circles. I'm not saying I want to compare MEDs across AS, just that if local-pref ends up the same I don't want a routing loop. If you want to finess it with Rich Woundy's MED election rather than comparing MED across AS to avoid loops, then fine. The group seems to have come to consensus so please don't get pissed and start proposing new attributes. > I suppose that I can still see _some_ utility in expressing a local > preference for an entry point where there are truly multiple interconnects, > but I fail to see the need for global semantics. Moreover, I can see that > having two interacting metrics with global semantics is just another way to > increase the complexity of the current (ridiculous) situation. Thanks for the analysis. We'll stick with best exit AS indicated by local-pref, then either IGP cost or MED in the same AS. > The way > we use BGP, no two AS should be announcing the same prefix at the same > local-pref under normal circumstances. If the local-pref were the > same I'd rather have something that didn't form a routing loop. > > I'm confused. How did local-pref enter the discussion? See above. If you still don't get it I'll explain a third time. > Getting rid of MED is not a constructive suggestion. > > I'm very sorry you feel that way. Perfection is only attained when you > have removed everything that can be removed, and no more. Perhaps you > would care to make some simple, concrete, and constructive suggestions? > > Tony We seemed to have already reached consensus on the list for Rich's MED election. We still don't have a proposed change in the BGP4 text. If Rich is busy I'll write something. Curtis
- 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)