Re: BGP-4 changes
rwoundy@vnet.ibm.com Fri, 06 September 1996 15:44 UTC
Received: from ietf.org by ietf.org id aa08791; 6 Sep 96 11:44 EDT
Received: from cnri by ietf.org id aa08787; 6 Sep 96 11:44 EDT
Received: from merit.edu by CNRI.Reston.VA.US id aa09651; 6 Sep 96 11:44 EDT
Received: (from daemon@localhost) by merit.edu (8.7.5/merit-2.0) id KAA14926
for idr-outgoing; Fri, 6 Sep 1996 10:29:50 -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 KAA14921 for <bgp@merit.edu>;
Fri, 6 Sep 1996 10:29:46 -0400 (EDT)
Sender: ietf-archive-request@ietf.org
From: rwoundy@vnet.ibm.com
Received: by interlock.ans.net id AA23000
(InterLock SMTP Gateway 3.0 for bgp@ans.net);
Fri, 6 Sep 1996 10:29:43 -0400
Message-Id: <199609061429.AA23000@interlock.ans.net>
Received: by interlock.ans.net (Internal Mail Agent-1);
Fri, 6 Sep 1996 10:29:43 -0400
Date: Fri, 06 Sep 96 10:29:45 EDT
To: curtis@ans.net, bgp@ans.net
Subject: Re: BGP-4 changes
X-Orig-Sender: owner-idr@merit.edu
Precedence: bulk
*** Resending note of 09/05/96 20:42 Subject: Re: BGP-4 changes Curtis, I agree that BGP-savvy gurus (like yourself) might find application for modification of MED values from neighbor ASs, so the "MAY" keyword in the current proposed text is OK with me. Flexibility can be rewarding in unintended ways... But we could solve the problem that you describe below by other means: (1) by lowering your LOCAL_PREF value for routes using the hot link(s), or (2) getting the neighbor AS to increase the MED values that it sends to you. Neither of these methods requires knowing the semantics of metrics of neighboring ASs, nor modification of received MED values. -- Richard Woundy, IBM >I could see doing this if you are in agreement with whoever you are >sending MED about what the MEDs mean. For example, some big customer >with more than one attachment might twiddle their OSPF metrics to get >traffic tuned sort of right. If one of the provider/customer >attachments or provider links near it were running a bit hot and there >was agreement to do so, the MEDs at one attachment point might be >bumped up. This could also apply to providers with multiple >interconnections who are willing to shuffle a bit of traffic from one >place to another to give both provider's customers better service. >This sort of cooperation is definitely not unheard of.
- Re: BGP-4 changes John G. Scudder
- Re: BGP-4 changes Curtis Villamizar
- Re: BGP-4 changes John G. Scudder
- Re: BGP-4 changes Yakov Rekhter
- Re: BGP-4 changes Curtis Villamizar
- BGP-4 changes Yakov Rekhter
- Re: BGP-4 changes Rich Woundy
- Re: BGP-4 changes Yakov Rekhter
- Re: BGP-4 changes John G. Scudder
- Re: BGP-4 changes rwoundy
- Re: BGP-4 changes rwoundy
- RE: BGP-4 changes rwoundy
- Re: BGP-4 changes rwoundy
- Re: BGP-4 changes Yakov Rekhter
- Re: BGP-4 changes Yakov Rekhter
- Re: BGP-4 changes Yakov Rekhter
- Re: BGP-4 changes John G. Scudder
- Re: BGP-4 changes Curtis Villamizar
- RE: BGP-4 changes NITTMANN Michael (MSMail)
- RE: BGP-4 changes John G. Scudder
- Re: BGP-4 changes Curtis Villamizar