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

"John G. Scudder" <jgs@ieng.com> Thu, 05 September 1996 20:55 UTC

Received: from ietf.org by ietf.org id aa11673; 5 Sep 96 16:55 EDT
Received: from cnri by ietf.org id aa11669; 5 Sep 96 16:55 EDT
Received: from merit.edu by CNRI.Reston.VA.US id aa15430; 5 Sep 96 16:55 EDT
Received: (from daemon@localhost) by merit.edu (8.7.5/merit-2.0) id QAA28209 for idr-outgoing; Thu, 5 Sep 1996 16:12:26 -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 QAA28204 for <bgp@merit.edu>; Thu, 5 Sep 1996 16:12:23 -0400 (EDT)
Received: by interlock.ans.net id AA01529 (InterLock SMTP Gateway 3.0 for bgp@ans.net); Thu, 5 Sep 1996 16:12:21 -0400
Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 5 Sep 1996 16:12:21 -0400
Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 5 Sep 1996 16:12:21 -0400
Message-Id: <v03007829ae54ddc12183@[152.160.213.42]>
In-Reply-To: <199609051944.MAA08071@hubbub.cisco.com>
References: Your message of "Thu, 05 Sep 96 15:25:49 EDT." <v03007823ae54d65762ae@[152.160.213.42]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 5 Sep 1996 16:07:34 -0400
To: Yakov Rekhter <yakov@cisco.com>
Sender: ietf-archive-request@ietf.org
From: "John G. Scudder" <jgs@ieng.com>
Subject: Re: [curtis@ans.net: Re: BGP4 stuff: Local Preference Computation]
Cc: bgp@ans.net
X-Orig-Sender: owner-idr@merit.edu
Precedence: bulk

At 12:40 PM -0700 9/5/96, Yakov Rekhter wrote:
>John,
>
>> 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").
>
>Yakov.

Well, we have ample evidence that the current terminology doesn't work, so
here are some options:

First option -- introduce a new category, "well-known
circumstantial-mandatory."  The (obvious) description is that
"circumstantial-mandatory" may be required in some circumstances (and
forbidden in others).

The real problem is in trying to use excessively terse language to capture
a relatively involved concept.  I would be OK with just getting rid of all
this terminology and having a table instead (second option):

			   Type of Connection
	Attribute	Internal	External
	---------	--------	--------
	ORIGIN		mandatory	mandatory
	AS_PATH		mandatory	mandatory
	NEXT_HOP	mandatory	mandatory
	MED		optional	optional
	LOCAL_PREF	mandatory	forbidden
	ATOMIC_AGG	*		*
	AGGREGATOR	optional	optional

[*] ATOMIC_AGGREGATE is actually mandatory in some circumstances.  Even the
table doesn't capture this correctly.  It's mandatory if you have formed an
atomic aggregate (duh).

I would be happiest with getting rid of the deceptively simple descriptive
terms for LOCAL_PREF and ATOMIC_AGGREGATE and just explaining them in
English (third option):

         e) LOCAL_PREF (Type Code 5):

            LOCAL_PREF is a non-negative integer.  It is mandatory on
            internal connections and forbidden on external connections.
            It is used by a BGP speaker to inform other BGP speakers in
            its own autonomous  system of the originating speaker's
            degree of preference for  an advertised route. Usage of this
            attribute is described in 5.1.5.

         f) ATOMIC_AGGREGATE (Type Code 6)

            ATOMIC_AGGREGATE is a well-known attribute of length 0.
            It is mandatory under certain circumstances,  described
            in 5.1.6.  It is used by a BGP speaker to inform other BGP
            speakers that the local system selected a less specific
            route without selecting a more specific route which is
            included in it. Usage of this attribute is described in
            5.1.6.

The other option (fourth) I can see is to include a description of
"discretionary":

	Note that the term "discretionary" may mean that the attribute
	is truly discretionary, i.e. that it may be sent or not sent
	at the discretion of the implementor (or user).  However, it
	may also mean that the attribute is mandatory under some
	circumstances and forbidden (or optional) under others.  Caveat
	emptor!

Obviously I don't like this option one bit.

Yours for telling it like it is,

--John

--
John Scudder                        email:  jgs@ieng.com
Internet Engineering Group, LLC     phone:  (313) 669-8800
122 S. Main, Suite 280              fax:    (313) 669-8661
Ann Arbor, MI  41804                www:    http://www.ieng.com