Re: FW: Addr: Re: BGP-4 - revised I-D

Curtis Villamizar <curtis@ans.net> Thu, 29 August 1996 19:32 UTC

Received: from ietf.org by ietf.org id aa16240; 29 Aug 96 15:32 EDT
Received: from cnri by ietf.org id aa16236; 29 Aug 96 15:32 EDT
Received: from merit.edu by CNRI.Reston.VA.US id aa13224; 29 Aug 96 15:32 EDT
Received: (from daemon@localhost) by merit.edu (8.7.5/merit-2.0) id OAA13734 for idr-outgoing; Thu, 29 Aug 1996 14:57:22 -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 OAA13729 for <bgp@merit.edu>; Thu, 29 Aug 1996 14:57:19 -0400 (EDT)
Received: by interlock.ans.net id AA20260 (InterLock SMTP Gateway 3.0 for bgp@ans.net); Thu, 29 Aug 1996 14:57:17 -0400
Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 29 Aug 1996 14:57:17 -0400
Message-Id: <199608291855.OAA04318@brookfield.ans.net>
To: "NITTMANN Michael (MSMail)" <MNittmann@shl.com>
Cc: "'bgp@ans.net'" <bgp@ans.net>
Reply-To: curtis@ans.net
Subject: Re: FW: Addr: Re: BGP-4 - revised I-D
In-Reply-To: Your message of "Wed, 28 Aug 1996 13:50:01 MDT." <c=US%a=_%p=SHL%l=SHL/CANADAW/001A0893@cocms1.calwdc.shl.com>
Date: Thu, 29 Aug 1996 14:55:10 -0400
Sender: ietf-archive-request@ietf.org
From: Curtis Villamizar <curtis@ans.net>
X-Orig-Sender: owner-idr@merit.edu
Precedence: bulk

In message <c=US%a=_%p=SHL%l=SHL/CANADAW/001A0893@cocms1.calwdc.shl.com>om>, "NITT
MANN Michael (MSMail)" writes:
> 
> AS A has multiple meetpoints with AS B. 
> AS A would like to drain traffic to a set of networks to AS B preferably 
> through a meetpoint M.
> As A sets parameters to result in an MED favouring meetpoint M for the set 
> of routes that is announced by AS B there (can be a subset of all announced 
> ones, most of the times some people like to have shorter, i.e. low latency 
> paths, between themselves, e.g. people working together but being behind 
> different Ass).
> 
> In the current scheme, there is no feedback to AS B that this kind of 
> preference had been sent. This leads to a routing loop in most cases. AS A 
> can call up AS B to negotiate routing with preference. But, since this would 
> require real work, i.e. typing and changing router configs, on the side of 
> AS B, guess what: they say 'we waited exactly for this request of yours and 
> will do it immediately'.
>
> If there were a mechanism that the routing engines would exchange this MED 
> and install the corresponding routes to AS A for the subset of networks in 
> AS B via meetpoint M, this would work without loops.

AS path loop supression already prevents a loop from forming in this
case.

This sounds a bit like setting MED based on IGP cost.  Are you aware
of that option?

> Such requests are always founded on a shortest desired path, whatever 
> 'shortest' means: latency, hops, uptime, or packet loss. In most of the 
> cases, AS B has an interest to follow the MED suggestion of AS A.
> In cases where AS B would not like to do this, e.g. the administrator finds 
> that path and would not like to agree to it, there should be a mechanism of 
> programmed dissent, which is exchanged too. 
> Now the admin of AS A sees that AS B did reject the request, and the routing 
> engines in AS A can either chose an offered alternative, or the admin can 
> try another one, or call AS B up and talk it out. But the cases where such 
> an intervention is necessary, are really rare I would say.
> 
> This negotiation piece had been missing, which makes it not very useful to 
> define MEDs on an island (my AS).

If setting MED based on IGP cost does not do what you want, try
looking at PDA.  I think that is close to what you are suggesting.

If not you may be able to set BGP communities and translate to an
admninistratively chosen MED or do an admninistratively chosen MED
based on AS path.

It's not entirely clear what you want to do, plus your loop argument
is flawed.

> All this can then be steered via the snmp tables of course, so it is 
> possible to integrate it into an NMS or EMS system, and point/click out 
> preferred paths and watch results. 

You must not have a whole lot of experience configuring routers or
have a very small network if you like SNMP and point and click as a
way to do this.

We process a few thousand lines of diffs in many config runs.  I'd
really hate to paste these changes in with a mouse or retype them into
dialog boxes.  Much easier to derive this from a database and just
move out new configuration files.

Of course this is not a protocol issue.

> Mike

Curtis