IETF Logo Mail Archive

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

"NITTMANN Michael (MSMail)" <MNittmann@shl.com> Fri, 06 September 1996 16:46 UTC

Received: from ietf.org by ietf.org id aa10071; 6 Sep 96 12:46 EDT
Received: from cnri by ietf.org id aa10067; 6 Sep 96 12:46 EDT
Received: from merit.edu by CNRI.Reston.VA.US id aa10761; 6 Sep 96 12:46 EDT
Received: (from daemon@localhost) by merit.edu (8.7.5/merit-2.0) id LAA17191 for idr-outgoing; Fri, 6 Sep 1996 11:58:20 -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 LAA17186 for <bgp@merit.edu>; Fri, 6 Sep 1996 11:58:17 -0400 (EDT)
Received: by interlock.ans.net id AA25973 (InterLock SMTP Gateway 3.0 for bgp@ans.net); Fri, 6 Sep 1996 11:58:15 -0400
Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 6 Sep 1996 11:58:15 -0400
Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 6 Sep 1996 11:58:15 -0400
Message-Id: <c=US%a=_%p=SHL%l=SHL/CANADAW/001B5934@cocms1.calwdc.shl.com>
Sender: ietf-archive-request@ietf.org
From: "NITTMANN Michael (MSMail)" <MNittmann@shl.com>
To: "curtis@ans.net" <curtis@ans.net>, "John G. Scudder" <jgs@ieng.com>
Cc: "bgp@ans.net" <bgp@ans.net>, Yakov Rekhter <yakov@cisco.com>
Subject: RE: [curtis@ans.net: Re: BGP4 stuff: Local Preference Computation]
Date: Fri, 6 Sep 1996 08:46:21 -0600
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.837.3
Encoding: 59 TEXT
X-Orig-Sender: owner-idr@merit.edu
Precedence: bulk

I would not even think of a bit for discretionary since it is not necessary. 
Basic protocol design: optional parameters may be ignored, ignoring optional 
parameters may not cause the emitting system to fail.

Mike

----------
From:  John G. Scudder[SMTP:jgs@ieng.com]
Sent:  Donnerstag, 5. September 1996 18:04
To:  curtis@ans.net
Cc:  Yakov Rekhter; bgp@ans.net
Subject:  Re: [curtis@ans.net: Re: BGP4 stuff: Local Preference Computation]

At 6:27 PM -0400 9/5/96, Curtis Villamizar wrote:
>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.

I don't follow.  There are just four flag bits:

Bit 0:  Optional/Well-Known
Bit 1:  Transitive/Non-Transitive
Bit 2:  Partial/(not)
Bit 3:  Extended Length/(not)

(Note that the def'n of bit 1 says "For well-known attributes, the
Transitive bit must be set to 1."  But, LOCAL_PREF is both well-known (per
the RFC) and clearly not transitive.  So I think that the quoted sentence
should be deleted.)

There isn't a flag for mandatory/discretionary (not even sort-of), so I'm
not worried about changing (or deleting) the term.

I think that the bits do not in fact say anything about whether an
attribute is mandatory or not.  Well-known I take to mean whether the
attribute is required to be supported.  Transitive is what it says.

So I think that textual changes can fix this problem.

By the way, the path attribute def'ns in 4.3 also cunningly don't mention
whether they are transitive or not (I guess it is supposed to be
"obvious").

Regards,

--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

v2.8.7 | Report a Bug | By Email