Re: BGP-4 changes

Curtis Villamizar <curtis@ans.net> Fri, 06 September 1996 01:08 UTC

Received: from ietf.org by ietf.org id aa16063; 5 Sep 96 21:08 EDT
Received: from cnri by ietf.org id aa16059; 5 Sep 96 21:08 EDT
Received: from merit.edu by CNRI.Reston.VA.US id aa19799; 5 Sep 96 21:08 EDT
Received: (from daemon@localhost) by merit.edu (8.7.5/merit-2.0) id UAA04117 for idr-outgoing; Thu, 5 Sep 1996 20:42:20 -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 UAA04112 for <bgp@merit.edu>; Thu, 5 Sep 1996 20:42:18 -0400 (EDT)
Received: by interlock.ans.net id AA08761 (InterLock SMTP Gateway 3.0 for bgp@ans.net); Thu, 5 Sep 1996 20:42:16 -0400
Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 5 Sep 1996 20:42:16 -0400
Message-Id: <199609060041.UAA13992@brookfield.ans.net>
To: rwoundy@vnet.ibm.com
Cc: MNittmann@shl.com, bgp@ans.net
Reply-To: curtis@ans.net
Subject: Re: BGP-4 changes
In-Reply-To: Your message of "Thu, 05 Sep 1996 19:03:06 EDT." <199609052303.AA06502@interlock.ans.net>
Date: Thu, 05 Sep 1996 20:41:56 -0400
Sender: ietf-archive-request@ietf.org
From: Curtis Villamizar <curtis@ans.net>
X-Orig-Sender: owner-idr@merit.edu
Precedence: bulk

In message <199609052303.AA06502@interlock.ans.net>et>, rwoundy@VNET.IBM.COM write
s:
> *** Resending note of 09/04/96 11:14
> Subject: RE: BGP-4 changes
> 
> >So you want to (e.g.) be able to say something like "For all MAE-E routes,
> >increment MED by 100"?
> 
> >I think that the proposed text already allows this, and the details of
> >how/when/if to do it should be left to implementors.
> 
> >But, I kinda agree with Rich that localpref and policy may be a cleaner way
> >to reflect stuff like this.
> 
> Thanks, John.
> 
> I would be worried about what the value "100" means, with respect
> to the metrics of a neighboring AS.  Does it mean two DS-3 hops
> or one hundred hops? and what if their link metrics change? etc.
> 
> You can safely drop MED attributes, but you modify MED values
> at your own risk...
> 
> -- 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.

Curtis