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

["NITTMANN Michael (MSMail)" <[e-mail]>]

... resent

----------
From:  NITTMANN Michael
Sent:  Wednesday, August 28, 1996 9:42 AM
To:  [e-mail]; Tony Li
Cc:  [e-mail]; [e-mail]; [e-mail]; [e-mail]; 
[e-mail]
Subject:  RE: Addr: Re: BGP-4 - revised I-D

To me an MED scheme would be very useful, without having a global static 
metric.

How about this:

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.

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).

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. 

Mike

----------
From:  Tony Li[SMTP:[e-mail]]
Sent:  Tuesday, August 27, 1996 3:48 PM
To:  [e-mail]
Cc:  [e-mail]; [e-mail]; [e-mail]; [e-mail]; 
[e-mail]
Subject:  Re: Addr: Re: BGP-4 - revised I-D


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?  

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.

   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?

   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