RFC Errata

Errata Search

Source of RFC  
Summary Table Full Records

RFC 4271, "A Border Gateway Protocol 4 (BGP-4)", January 2006

Note: This RFC has been updated by RFC 6286, RFC 6608, RFC 6793, RFC 7606, RFC 7607, RFC 7705, RFC 8212, RFC 8654, RFC 9072

Source of RFC: idr (rtg)

Errata ID: 3673
Status: Rejected
Type: Technical
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:

"5.1.5. LOCAL_PREF

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,
well-known attribute."

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.

Report New Errata

Advanced Search