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

["NITTMANN Michael (MSMail)" <[e-mail]>]

I like the table, but would like to change a little detail:

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

make the MED exchange for mutually set MEDs mandatory for the routes that 
are concerned, i.e. if I am in AS 1 and peer with AS 2, all AS 2 routes 
announced to me must carry the MED value assigned to them by AS 2 towards 
me, AS 1, or -1 if there is no MED set.

Mike


----------
From:  John G. Scudder[SMTP:[e-mail]]
Sent:  Donnerstag, 5. September 1996 15:08
To:  Yakov Rekhter
Cc:  [e-mail]
Subject:  Re: [[e-mail]: Re: BGP4 stuff: Local Preference Computation]

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