RE: [Idr] Clarification on RFC4271 section 5.1.5 - is LOCAL-PREFmandatory or discretionary

IIRC, making LOCAL_PREF mandatory would have implied that LOCAL_PREF
appear in EBGP updates.

Tony

> -----Original Message-----
> From: gregory hoggarth [mailto:gregory.hoggarth@alliedtelesyn.co.nz] 
> Sent: Tuesday, July 11, 2006 4:09 PM
> To: idr@ietf.org
> Subject: [Idr] Clarification on RFC4271 section 5.1.5 - is 
> LOCAL-PREFmandatory or discretionary
> 
> 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 mailing list
Idr@ietf.org
https://www1.ietf.org/mailman/listinfo/idr