[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
- [Idr] Clarification on RFC4271 section 5.1.5 - is… gregory hoggarth
- Re: [Idr] Clarification on RFC4271 section 5.1.5 … Robert Raszuk
- RE: [Idr] Clarification on RFC4271 section 5.1.5 … Tony Li