RFC 4456, "BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)", April 2006Source of RFC: idr (rtg)
Errata ID: 3898
Publication Format(s) : TEXT
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.