Re: IDR WG agenda
Vince Fuller <vaf@wr.bbnplanet.com> Fri, 28 February 1997 00:33 UTC
Received: from cnri by ietf.org id aa26246; 27 Feb 97 19:33 EST
Received: from merit.edu by CNRI.Reston.VA.US id aa27151; 27 Feb 97 19:33 EST
Received: (from daemon@localhost) by merit.edu (8.8.5/merit-2.0) id TAA21485 for idr-outgoing; Thu, 27 Feb 1997 19:03:11 -0500 (EST)
Received: from interlock.ans.net (interlock.ans.net [147.225.5.5]) by merit.edu (8.8.5/merit-2.0) with SMTP id TAA21480 for <bgp@merit.edu>; Thu, 27 Feb 1997 19:03:08 -0500 (EST)
Received: by interlock.ans.net id AA15965 (InterLock SMTP Gateway 3.0 for bgp@ans.net); Thu, 27 Feb 1997 19:03:05 -0500
Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 27 Feb 1997 19:03:05 -0500
Date: Thu, 27 Feb 1997 16:03:38 -0800
From: Vince Fuller <vaf@wr.bbnplanet.com>
To: curtis@ans.net
Cc: curtis@ans.net, Yakov Rekhter <yakov@cisco.com>, bgp@ans.net
Phone: (415) 528-7227
Usmail: 3801 East Bayshore Rd, Palo Alto, CA, 94303
Subject: Re: IDR WG agenda
In-Reply-To: Your message of Thu, 27 Feb 1997 16:18:41 -0500
Message-Id: <CMM.0.90.2.857088218.vaf@hq.barrnet.net>
Sender: owner-idr@merit.edu
Precedence: bulk
In message <CMM.0.90.2.857071325.vaf@hq.barrnet.net>, Vince Fuller writes: > Isn't that MED with a BGP community to send MED no further? > > Is this "BGP community" in the sense of the IRR or in the sense of the > community attribute? An IRR community isn't very useful to most of us and > while a well-known community attribute number could be defined to mean > this, none exists at present (though that might be a reasonable > solution). I meant a yet to be defined BGP community. Making it a well known community would help. This would work, but there are still some situations where a new attribute would be preferred. The specific case that occurs to me is that of a provider who has multiple routers which are colocated with an exchange point. Right now, those routers could believe MED and the overwrite it on iBGP output but they still have to trust that the received MEDs aren't unreasonably high so as to cause them to prefer an iBGP route and break shortest-exit. There is an easy workaround if the routers at the IXP are dedicated -- always prefer external information over external information -- and a less obvious and less reliable general workaround -- overwrite the MED with a value larger than anything that a peer will ever send (but how to determine that value). But from an archtectural standpoint, having a separate "local-metric" attribute, used as a tie-breaker if equal MEDs are encountered and only sent or received on eBGP sessions, would be cleaner. Getting the right next hop is a common use for MED. I think what you are asking for is something like this that is guarenteed not to be propogated further. Yes. Again, overloading MED for this purpose is doable but rather ugly. --Vince
- IDR WG agenda yakov
- IDR WG agenda Yakov Rekhter
- IDR WG agenda Yakov Rekhter
- IDR WG agenda Yakov Rekhter
- Re: IDR WG agenda Tony Bates
- Re: IDR WG agenda Bill Manning
- Re: IDR WG agenda Yakov Rekhter
- IDR WG agenda Yakov Rekhter
- IDR WG agenda Yakov Rekhter
- Re: IDR WG agenda Vince Fuller
- Re: IDR WG agenda Curtis Villamizar
- Re: IDR WG agenda Yakov Rekhter
- Re: IDR WG agenda Vince Fuller
- Re: IDR WG agenda Paul Knight
- Re: IDR WG agenda Curtis Villamizar
- Re: IDR WG agenda John Scudder
- Re: IDR WG agenda Vince Fuller
- Re: IDR WG agenda Curtis Villamizar
- Re: IDR WG agenda Curtis Villamizar
- Re: IDR WG agenda Randy Bush
- IDR WG agenda Yakov Rekhter