errata logo graphic

Found 11 records.

Status: Verified (2)

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

Source of RFC: idr (rtg)

Errata ID: 2838

Status: Verified
Type: Technical

Reported By: Jamie Taylor
Date Reported: 2011-06-16
Verifier Name: Stewart Bryant
Date Verified: 2011-08-02

Section 8.2.2 says:

on page 72, description of the Established state:

If the HoldTimer_Expires event occurs (Event 10), the local system:
 ...[list of actions to take]...

It should say:

If the HoldTimer_Expires event occurs (Event 10), the local system:
 - deletes all routes associated with this connection
 ...[list of actions in original text]...

Notes:

All other transitions from Established to Idle explicitly state that all routes associated with the connection are deleted. This transition should as well.


Errata ID: 1633

Status: Verified
Type: Technical

Reported By: John Scudder
Date Reported: 2008-12-12
Verifier Name: Stewart Bryant
Date Verified: 2011-08-02

Section 6.3 says:

   If an optional attribute is recognized, then the value of this
   attribute MUST be checked.  If an error is detected, the attribute
   MUST be discarded, and the Error Subcode MUST be set to Optional
   Attribute Error.  The Data field MUST contain the attribute (type,
   length, and value).

It should say:

   If an optional attribute is recognized, then the value of this
   attribute MUST be checked.  If an error is detected, the Error 
   Subcode MUST be set to Optional Attribute Error.  The Data 
   field MUST contain the attribute (type, length, and value).

Notes:

This simply removes the clause "the attribute MUST be discarded", which doesn't make sense since the peering is to be terminated anyway.


Status: Held for Document Update (5)

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

Source of RFC: idr (rtg)

Errata ID: 150

Status: Held for Document Update
Type: Editorial

Reported By: Nikolai Malykh
Date Reported: 2006-01-26
Held for Document Update by: Stewart Bryant
Date Held: 2011-08-02

Section 9.1.1 says:

The Phase 1 decision function is a separate process,f which completes 
when it has no further work to do.

It should say:

The Phase 1 decision function is a separate process, which completes 
when it has no further work to do.


Errata ID: 3264

Status: Held for Document Update
Type: Editorial

Reported By: Anmol Khirbat
Date Reported: 2012-06-19
Held for Document Update by: Stewart Bryant

Section Appendix F.3 says:

Implementations that combine update messages (as described above in
Section 6.1) may prefer to see all path attributes presented in a
known order.

It should say:

Implementations that combine update messages (as described above in
Appendix F.1) may prefer to see all path attributes presented in a
known order.

Notes:

Section 6.1 does not say anything about combining update messages.


Errata ID: 3459

Status: Held for Document Update
Type: Editorial

Reported By: Lawrence Hui
Date Reported: 2013-01-16
Held for Document Update by: Stewart Bryant

Section 6.8 says:

If a pair of BGP speakers try to establish a BGP connection with each
other simultaneously, then two parallel connections well be formed.

It should say:

If a pair of BGP speakers try to establish a BGP connection with each
other simultaneously, then two parallel connections will be formed.

Notes:

This edit will replace the "well" with "will".


Errata ID: 3464

Status: Held for Document Update
Type: Editorial

Reported By: Lawrence Hui
Date Reported: 2013-01-17
Held for Document Update by: Stewart Bryant
Date Held: 2013-01-28

Section 9.1.1 says:

   The Phase 1 decision function is a separate process,f which completes
   when it has no further work to do.

It should say:

   The Phase 1 decision function is a separate process, which completes
   when it has no further work to do.

Notes:

This edit will remove the "f".

This is correct, but will not cause an interoperability issue, and thus can be fixed when the document is updated.


Errata ID: 3809

Status: Held for Document Update
Type: Editorial

Reported By: Ramakrishna DTV
Date Reported: 2013-11-21
Held for Document Update by: Stewart Bryant
Date Held: 2013-11-22

Section 6 says:

   Before the invalid routes are deleted
   from the system, it advertises, to its peers, either withdraws for
   the routes marked as invalid, or the new best routes before the
   invalid routes are deleted from the system.

It should say:

   Before the invalid routes are deleted
   from the system, it advertises, to its peers, either withdraws for
   the routes marked as invalid, or the new best routes.

Notes:

The phrase "Before the invalid routes are deleted from the system" is unnecessarily repeated in the same sentence.


Status: Rejected (4)

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

Source of RFC: idr (rtg)

Errata ID: 1332

Status: Rejected
Type: Technical

Reported By: Aaron Hughes
Date Reported: 2008-02-26
Rejected by: Stewart Bryant
Date Rejected: 2011-08-02

Section 4.5 says:

      OPEN Message Error subcodes:

               1 - Unsupported Version Number.
               2 - Bad Peer AS.
               3 - Bad BGP Identifier.
               4 - Unsupported Optional Parameter.
               5 - [Deprecated - see Appendix A].
               6 - Unacceptable Hold Time.

It should say:

      OPEN Message Error subcodes:

               1 - Unsupported Version Number.
               2 - Bad Peer AS.
               3 - Bad BGP Identifier.
               4 - Unsupported Optional Parameter.
               5 - [Deprecated - see Appendix A].
               6 - Unacceptable Hold Time.
               7 - Unsupported Capability

Notes:

7 - Unsupported Capability orig from RFC3392 seems to have accidently disappeared.

Thanks!
Aaron
--VERIFIER NOTES--
The working group debated this point and concluded the following:

The functionality (specifically, BGP Capabilities) this error code applies to does not appear anywhere in RFC 4271 (or RFC 1771). As IANA records, this error subcode is defined in RFC5492/RFC3392, along with the related functionality. The IANA registry is the final authority as to code point assignments, and is correct as written. Accordingly, this erratum is rejected.


Errata ID: 3366

Status: Rejected
Type: Technical

Reported By: Shashank Tyagi
Date Reported: 2012-09-26
Rejected by: Stewart Bryant
Date Rejected: 2013-09-20

Section 8.2.2 says:

If a TcpConnectionFails event (Event 18) is received, the local
      system:

        - closes the BGP connection,

        - restarts the ConnectRetryTimer,

        - continues to listen for a connection that may be initiated by
          the remote BGP peer, and

        - changes its state to Active.

It should say:

If a TcpConnectionFails event (Event 18) is received, the local
      system:

        - closes the BGP connection,

        - sets the HoldTimer to 0,

        - restarts the ConnectRetryTimer,

        - continues to listen for a connection that may be initiated by
          the remote BGP peer, and

        - changes its state to Active.

Notes:

HoldTimer should only be used to control time in between BGP packets.
Also in this case it can lead to case in ACTIVE state where HoldTimer expires before the ConnectRetryTimer leading to IDLE state.
--VERIFIER NOTES--
This represents a technical change to RFC4271 and is outside the scope of the errata system. The submitter is welcome to submit a draft proposing the change to RFC 4271 and work for consensus for the change in the IDR WG.


Errata ID: 3673

Status: Rejected
Type: Technical

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.

Notes:

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
peers."

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.

6.3
" 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.
--VERIFIER NOTES--
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
stage.

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.


Errata ID: 3031

Status: Rejected
Type: Editorial

Reported By: Kireeti Kompella
Date Reported: 2011-11-14
Rejected by: Stewart Bryant
Date Rejected: 2013-02-28

Section 9.1.2 says:

The Phase 2 decision function is blocked from running while the Phase
3 decision function is in process.

It should say:

The Phase 3 decision function is blocked from running while the Phase
2 decision function is in process.

Notes:

I believe that is what was intended; the text as is confuses me no end.
--VERIFIER NOTES--
It is accepted that the RFC text is confusing, but the proposed errata text is incorrect because this proposed revision implies that Phase 2 can begin running while Phase 3 is still running this contradicts other text in the RFC (9.1.2) which states that "The Phase 3 Routing Decision function is blocked from running whilst the Phase 2 decision function is in process."

It is anticipated that the IDR WG will publish material clarifying mutual exclusion in RFC4271.


Report New Errata