Found 2 records.
Errata ID: 3778
Status: Held for Document Update
Reported By: Ramakrishna DTV
Date Reported: 2013-10-30
Held for Document Update by: Stewart Bryant
Date Held: 2013-10-31
Section 5 says:
The Non-Client peer must be fully meshed but the Client peers need not be fully meshed.
It should say:
The Non-Client peers must be fully meshed but the Client peers need not be fully meshed.
This is a typo. Figure 4 shows multiple Non-Client peers.
But the text is referring to "The Non-Client peer". It should be
"The Non-Client peers".
Errata ID: 3898
Reported By: Gunjan Bansal
Date Reported: 2014-02-23
Rejected by: Stewart Bryant
Date Rejected: 2014-03-02
Section 8 says:
ORIGINATOR_ID ORIGINATOR_ID is a new optional, non-transitive BGP attribute of Type code 9. This attribute is 4 bytes long and it will be created by an RR in reflecting a route. This attribute will carry the BGP Identifier of the originator of the route in the local AS. A BGP speaker SHOULD NOT create an ORIGINATOR_ID attribute if one already exists. A router that recognizes the ORIGINATOR_ID attribute SHOULD ignore a route received with its BGP Identifier as the ORIGINATOR_ID. CLUSTER_LIST CLUSTER_LIST is a new, optional, non-transitive BGP attribute of Type code 10. It is a sequence of CLUSTER_ID values representing the reflection path that the route has passed. When an RR reflects a route, it MUST prepend the local CLUSTER_ID to the CLUSTER_LIST. If the CLUSTER_LIST is empty, it MUST create a new one. Using this attribute an RR can identify if the routing information has looped back to the same cluster due to misconfiguration. If the local CLUSTER_ID is found in the CLUSTER_LIST, the advertisement received SHOULD be ignored.
Although the guideline exists for the "egress" reflected routes (RR should create ORIGINATOR_ID if none exists, prepend its own ClusterId in CLUSTER_LIST), there is no guideline on how the routes received from iBGP peers be treated if "only one" attribute (ORIGINATOR_ID or CLUSTER_LIST) is present.
Should such routes be dropped (Considering them as a malformed routes ?)
This is a question that should be addressed to the IDR WG.
Any new guideline that results should be considered for publication in an RFC. Technical changes of the type requested are outside the scope of the Errata process.
Report New Errata