Re: [[e-mail]: Re: BGP4 stuff: Local Preference Computation]

[Curtis Villamizar <[e-mail]>]

In message <v03007829ae54ddc12183@[152.160.213.42]>2]>, "John G. Scudder" writes:
> 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:  [e-mail]
> Internet Engineering Group, LLC     phone:  [phone]
> 122 S. Main, Suite 280              fax:    [phone]
> Ann Arbor, MI  41804                www:    http://www.ieng.com


It's interesting that we came up with similar suggestions, both
involving defining mandatory and discretionary separately.

Unfortunately we're stuck with these two bit in the attribute,
well-known/optional, and mandatory/discretionary.  However we
wordsmith this we want to end up with the same value in the two bits
so we don't affect interoperability.

Curtis