Re: Helpful BGP Feature

"John W. Stewart III" <jstewart@isi.edu> Mon, 03 February 1997 22:38 UTC

Received: from cnri by ietf.org id aa11601; 3 Feb 97 17:38 EST
Received: from merit.edu by CNRI.Reston.VA.US id aa24775; 3 Feb 97 17:38 EST
Received: (from daemon@localhost) by merit.edu (8.8.5/merit-2.0) id QAA29051 for idr-outgoing; Mon, 3 Feb 1997 16:53:59 -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 QAA29046 for <bgp@merit.edu>; Mon, 3 Feb 1997 16:53:55 -0500 (EST)
Received: by interlock.ans.net id AA17178 (InterLock SMTP Gateway 3.0 for bgp@ans.net); Mon, 3 Feb 1997 16:53:53 -0500
Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 3 Feb 1997 16:53:53 -0500
Message-Id: <199702032153.AA27330@metro.isi.edu>
To: Paul Ferguson <pferguso@cisco.com>
Cc: EDS@rhqvm21.vnet.ibm.com, bgp@ans.net
Subject: Re: Helpful BGP Feature
In-Reply-To: Your message of "Mon, 03 Feb 1997 16:10:31 EST." <3.0.32.19970203161020.006fcdc4@lint.cisco.com>
X-Phone: +1 703 812 3704
From: "John W. Stewart III" <jstewart@isi.edu>
Date: Mon, 03 Feb 1997 16:53:40 -0500
Sender: owner-idr@merit.edu
Precedence: bulk

another point here is that controlling the distribution of
routing information is at least as important to transit
routing domain as it is to the originator of that routing
information.  so having an all-singing and all-dancing
attribute for the originator doesn't mean squat if the
immediately adjacent domain stomps on it...

/jws

 > At 03:05 PM 2/3/97 EST, EDS@RHQVM21.VNET.IBM.COM wrote:
 > 
 > >I dont believe current implementations provide sufficient
 > >granularity, and are defined in a static manner anyway.
 > >
 > >If you could specify what features are available in
 > >"current implementation" that you are referring to
 > >it may be helpful in understanding this.
 > 
 > Basically, I am referring to explicit (static) definition
 > of BGP peers in a configuration. I suppose I'm just being
 > thick, but could you elaborate what types of granularity
 > which statically defining peers does not provide?
 > 
 > Thanks,
 > 
 > - paul
 >