[Idr] Clarification on RFC4271 section 5.1.5 - is LOCAL-PREF mandatory or discretionary

"gregory hoggarth" <gregory.hoggarth@alliedtelesyn.co.nz> Tue, 11 July 2006 23:09 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0RMc-0003pP-13; Tue, 11 Jul 2006 19:09:58 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0RMa-0003pC-U2 for idr@ietf.org; Tue, 11 Jul 2006 19:09:56 -0400
Received: from gate.alliedtelesyn.co.nz ([202.49.72.33]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G0RMZ-0005d7-91 for idr@ietf.org; Tue, 11 Jul 2006 19:09:56 -0400
Received: (qmail 25981 invoked from network); 11 Jul 2006 23:09:53 -0000
Received: from mailmarshall.alliedtelesyn.co.nz (10.32.18.40) by gate-int.alliedtelesyn.co.nz with SMTP; 11 Jul 2006 23:09:53 -0000
Received: from aslan.alliedtelesyn.co.nz (Not Verified[10.32.18.53]) by mailmarshall.alliedtelesyn.co.nz with NetIQ MailMarshal (v5.5.6.7) id <B0005d3afc>; Wed, 12 Jul 2006 11:09:03 +1200
Received: from CHCDOM1-MTA by aslan.alliedtelesyn.co.nz with Novell_GroupWise; Wed, 12 Jul 2006 11:09:53 +1200
Message-Id: <44B4D861.E0D5.005D.0@alliedtelesyn.co.nz>
X-Mailer: Novell GroupWise Internet Agent 7.0.1
Date: Wed, 12 Jul 2006 11:09:22 +1200
From: gregory hoggarth <gregory.hoggarth@alliedtelesyn.co.nz>
To: idr@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a
Subject: [Idr] Clarification on RFC4271 section 5.1.5 - is LOCAL-PREF mandatory or discretionary
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
Errors-To: idr-bounces@ietf.org

Hello everyone,

I've been working on a BGP implementation which is currently failing a
third-party test that is assuming that the LOCAL-PREF attribute is a
well-known mandatory attribute while the implementation is assuming that
it is discretionary. RFC4271 does not make the definition 100% clear,
especially because in RFC1771 this attribute is described as being
well-known discretionary.

Section 5.1.5 from RFC4271 states:

   LOCAL_PREF is a well-known attribute that SHALL be included in all
   UPDATE messages that a given BGP speaker sends to other internal
   peers.  A BGP speaker SHALL calculate the degree of preference for
   each external route based on the locally-configured policy, and
   include the degree of preference when advertising a route to its
   internal peers.

The SHALLs seem to make this fairly clear, however note that it merely
says "well-known attribute". Other attributes, such as ORIGIN say
"well-known mandatory attribute". Also, in the table at the top of page
25, LOCAL_PREF is listed as being "required" for IBGP, but this is never
actually defined anywhere as to what this means. Again in section 4.3 e)
on page 19, it only says "well-known attribute", whereas on the same
page NEXT_HOP is described as "well-known mandatory" and
ATOMIC_AGGREGATE is described as "well-known discretionary".

In RFC1771 LOCAL_PREF is defined on pages 15 and 23 as being
"well-known discretionary".

The current way the implementation works is based on RFC1771, but as
RFC4271 is ambiguous as to how LOCAL_PREF should be handled, I am unsure
as to whether the implementation needs to be changed.

Currently, if an update message that does not include the LOCAL_PREF
attribute arrives from an iBGP neighbour, the default or
administratively-defined LOCAL_PREF value for the receiving router is
assigned to the advertised route. This seems like a good compromise in
my opinion. The third-party test suite is expecting that in this
situation, the device will return a notification message that incidates
the attribute was not included in the update.

So, according to RFC4271, is LOCAL_PREF a mandatory attribute, at least
for iBGP peer communication? Is my current approach to the lack of this
attribute in an update sensible and acceptable?


Thanks,
Greg

NOTICE: This message contains privileged and confidential
information intended only for the use of the addressee
named above. If you are not the intended recipient of
this message you are hereby notified that you must not
disseminate, copy or take any action in reliance on it.
If you have received this message in error please
notify Allied Telesis Labs Ltd immediately.
Any views expressed in this message are those of the
individual sender, except where the sender has the
authority to issue and specifically states them to
be the views of Allied Telesis Labs.

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www1.ietf.org/mailman/listinfo/idr