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
- [curtis@ans.net: Re: BGP4 stuff: Local Preference… Cristina Radulescu-Banu
- Re: [curtis@ans.net: Re: BGP4 stuff: Local Prefer… Curtis Villamizar
- Re: [curtis@ans.net: Re: BGP4 stuff: Local Prefer… John G. Scudder
- Re: [curtis@ans.net: Re: BGP4 stuff: Local Prefer… Yakov Rekhter
- Re: [curtis@ans.net: Re: BGP4 stuff: Local Prefer… John G. Scudder
- Re: [curtis@ans.net: Re: BGP4 stuff: Local Prefer… Curtis Villamizar
- Re: [curtis@ans.net: Re: BGP4 stuff: Local Prefer… John G. Scudder
- Re: [curtis@ans.net: Re: BGP4 stuff: Local Prefer… Curtis Villamizar
- Re: [curtis@ans.net: Re: BGP4 stuff: Local Prefer… Curtis Villamizar
- Re: [curtis@ans.net: Re: BGP4 stuff: Local Prefer… Paul Ferguson
- RE: [curtis@ans.net: Re: BGP4 stuff: Local Prefer… NITTMANN Michael (MSMail)
- Re: [curtis@ans.net: Re: BGP4 stuff: Local Prefer… John G. Scudder
- Re: [curtis@ans.net: Re: BGP4 stuff: Local Prefer… John G. Scudder
- Re: [curtis@ans.net: Re: BGP4 stuff: Local Prefer… Curtis Villamizar
- Re: [curtis@ans.net: Re: BGP4 stuff: Local Prefer… Curtis Villamizar
- RE: [curtis@ans.net: Re: BGP4 stuff: Local Prefer… NITTMANN Michael (MSMail)
- RE: [curtis@ans.net: Re: BGP4 stuff: Local Prefer… NITTMANN Michael (MSMail)
- RE: [curtis@ans.net: Re: BGP4 stuff: Local Prefer… NITTMANN Michael (MSMail)
- Re: [curtis@ans.net: Re: BGP4 stuff: Local Prefer… Curtis Villamizar
- RE: [curtis@ans.net: Re: BGP4 stuff: Local Prefer… NITTMANN Michael (MSMail)
- RE: [curtis@ans.net: Re: BGP4 stuff: Local Prefer… John G. Scudder
- RE: [curtis@ans.net: Re: BGP4 stuff: Local Prefer… NITTMANN Michael (MSMail)
- Re: [curtis@ans.net: Re: BGP4 stuff: Local Prefer… Curtis Villamizar