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