RFC 4271, "A Border Gateway Protocol 4 (BGP-4)", January 2006Source of RFC: idr (rtg)
Errata ID: 3673
Publication Format(s) : TEXT
Reported By: William McCall
Date Reported: 2013-06-28
Rejected by: Stewart Bryant
Date Rejected: 2013-10-04
Section 5 says:
Path attributes fall into four separate categories: 1. Well-known mandatory. 2. Well-known discretionary. 3. Optional transitive. 4. Optional non-transitive.
It should say:
Path attributes fall into five separate categories: 1. Well-known mandatory. 2. Well-known discretionary. 3. Well-known. 4. Optional transitive. 5. Optional non-transitive.
Local pref is only a "well-known" attribute as it fails the definition for the behavior as a mandatory attribute and it is not exactly discretionary per 5.1.5's definition of local pref and section 5's definition of discretionary which 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
Section 5's definition of discretionary:
" [...]Others are discretionary and MAY
or MAY NOT be sent in a particular UPDATE message."
As a well-known mandatory attribute would result in a NOTIFICATION per section 6.3, it cannot be well-known mandatory because it is only for internal peers. Thus, it is a separate category.
" If any of the well-known mandatory attributes are not present, then
the Error Subcode MUST be set to Missing Well-known Attribute. The
Data field MUST contain the Attribute Type Code of the missing,
In a future revision, a new term would probably be best to describe this. However, the categorization of attributes is misleading for now and the simplest approach is to add the new category already used by 5.1.5.
This erratum was discussed on the IDR list.
The consensus was that whilst an alternative is to revert
from OpenSent to Idle on event 18 at that point, this was not
what was decided when RFC4271 was being produced, and
no one saw a good engineering reason to change it at this
On a matter of process, this proposal is not an Erratum
as the IETF sees it but an engineering change.
The submitter is, of course, welcome to submit a draft
proposing this change to RFC 4271 and the to discuss the
merits of the change with the IDR Working Group.