|
|
|
|
Found 9 records.
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.
Errata ID: 3366
Status: Reported
Type: Technical
Reported By: Shashank Tyagi
Date Reported: 2012-09-26
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.
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: 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: 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.