Re: [curtis@ans.net: Re: BGP4 stuff: Local Preference Computation
rwoundy@vnet.ibm.com Thu, 05 September 1996 22:09 UTC
Received: from ietf.org by ietf.org id aa13414; 5 Sep 96 18:09 EDT
Received: from cnri by ietf.org id aa13409; 5 Sep 96 18:09 EDT
Received: from merit.edu by CNRI.Reston.VA.US id aa16971; 5 Sep 96 18:09 EDT
Received: (from daemon@localhost) by merit.edu (8.7.5/merit-2.0) id RAA00548
for idr-outgoing; Thu, 5 Sep 1996 17:27:04 -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 RAA00543 for <bgp@merit.edu>;
Thu, 5 Sep 1996 17:27:00 -0400 (EDT)
Sender: ietf-archive-request@ietf.org
From: rwoundy@vnet.ibm.com
Received: by interlock.ans.net id AA03732
(InterLock SMTP Gateway 3.0 for bgp@ans.net);
Thu, 5 Sep 1996 17:26:59 -0400
Message-Id: <199609052126.AA03732@interlock.ans.net>
Received: by interlock.ans.net (Internal Mail Agent-1);
Thu, 5 Sep 1996 17:26:59 -0400
Date: Thu, 05 Sep 96 17:27:03 EDT
To: yakov@cisco.com, jgs@ieng.com, bgp@ans.net
Subject: Re: [curtis@ans.net: Re: BGP4 stuff: Local Preference Computation
X-Orig-Sender: owner-idr@merit.edu
Precedence: bulk
*** Resending note of 09/05/96 15:47 Subject: Re: [curtis@ans.net: Re: BGP4 stuff: Local Preference Computation Yakov, How about "Well-known non-transitive" as a new path attribute category in section 5 for LOCAL_PREF? Well-known non-transitive attributes must be included in every UPDATE message sent to internal peers, but must not be included in any UPDATE message sent to peers in neighboring ASs. We'll need to fix the sentence in section 5 that states: All well-known attributes must be passed along (after proper updating, if necessary) to other BGP peers. (We obviously do not want to send LOCAL_PREFs to neighbor ASs.) Instead, we could say: All well-known mandatory and discretionary attributes must be passed along (after proper updating, if necessary) to other BGP peers. I'm only afraid that this is bordering on the obvious... -- Richard Woundy, IBM >> This should be fixed by reclassifying LOCAL_PREF as well-known mandatory. >"Mandatory" means that it *always* has to be present. LOCAL_PREF is not >carried between external peers - just among the internal peers. >> [Other than the text being just plain wrong, the other possibility is that >> "discretionary" is being used to mean something like "this is only >> mandatory in some cases". This is a terrible misuse of the language >> if true, and should still be fixed, if necessary by inventing some new term >> like "well-known sometimes-mandatory" or something. (Note that the >> RFC nowhere defines "discretionary" so we are left with the dictionary >> definition, e.g. "left to discretion: exercised at one's own discretion".)] >Suggestions for better terminology area always appreciated (especially >if accompanied by a "rough consensus").