Re: [curtis@ans.net: Re: BGP4 stuff: Local Preference Computation]

Paul Ferguson <pferguso@cisco.com> Thu, 05 September 1996 22:48 UTC

Received: from ietf.org by ietf.org id aa14288; 5 Sep 96 18:48 EDT
Received: from cnri by ietf.org id aa14284; 5 Sep 96 18:48 EDT
Received: from merit.edu by CNRI.Reston.VA.US id aa17734; 5 Sep 96 18:48 EDT
Received: (from daemon@localhost) by merit.edu (8.7.5/merit-2.0) id SAA01916 for idr-outgoing; Thu, 5 Sep 1996 18:29:06 -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 SAA01911 for <bgp@merit.edu>; Thu, 5 Sep 1996 18:29:03 -0400 (EDT)
Received: by interlock.ans.net id AA05454 (InterLock SMTP Gateway 3.0 for bgp@ans.net); Thu, 5 Sep 1996 18:29:01 -0400
Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 5 Sep 1996 18:29:01 -0400
Message-Id: <2.2.32.19960905222855.006d7574@lint.cisco.com>
X-Sender: pferguso@lint.cisco.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 05 Sep 1996 18:28:55 -0400
To: curtis@ans.net
Sender: ietf-archive-request@ietf.org
From: Paul Ferguson <pferguso@cisco.com>
Subject: Re: [curtis@ans.net: Re: BGP4 stuff: Local Preference Computation]
Cc: Yakov Rekhter <yakov@cisco.com>, "John G. Scudder" <jgs@ieng.com>, bgp@ans.net
X-Orig-Sender: owner-idr@merit.edu
Precedence: bulk

I personally like the elaboration of iBGP and eBGP implementations here;
the verbiage Curtis suggest makes it much less confusing.

- paul

At 06:17 PM 9/5/96 -0400, Curtis Villamizar wrote:

>
>How about in the RFC instead of
>
>	mandatory	discretionary
>
>we specify
>
>	mandatory	discretionary	disallowed
>
>and list IBGP and EBGP separately.
>
>	  attribute	  IBGP				EBGP
>	LOCAL_PREF    well-known mandatory        disallowed
>	MED           well-known discretionary    well-known discretionary
>	...
>
>This affects a key attribute so we could set mandatory attribute bit
>iff it is mandatory for both IBGP and EBGP and not change the protocol
>any, just make the spec more clear.
>