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

[Robert Raszuk <[e-mail]>]

Hi Gregory,

It all depends what you goal here is ...

* If you are deep into finding semantical and syntactical specification
wording traps resulting in reasons to not implement Local_Pref as a
mandatory attribute you may find all possible mismatches between BGP
specs and perhaps get away with it.

* If on the other hand your goal is to come up with to some extend at
least interoperable BGP implementation I would highly recommend to look
at section 3.14 of BGP-4 implementation report
http://www.ietf.org/rfc/rfc4276.txt where the answer to your question is
clear. Local_Pref is send to all IBGP peers and is a mandatory bgp
attribute. It is part of best path so while one could assume missing
local_pref is equal to def value it is not the case in well known bgp
implementations I am aware of.

Cheers,
R.

> 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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/idr
> 

_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr