Subject: Cluster-Lists and Originator-ids

From: [email-masked]
Date: Wed, 18 Feb 1998 17:08:00 -0500 (EST)

Hi,

I had a couple of queries on route reflection which I was hoping someone 
here could address.

[1] RFC 1966 says

   CLUSTER_LIST

   When a RR reflects a route from its Clients to a Non-Client peer, it
   must append 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 is looped back to the
   same cluster due to mis-configuration. If the local CLUSTER_ID is
   found in the cluster-list, the advertisement will be ignored.

The RFC doesn't make a statement about attaching a cluster-id on reflecting
from a Non-Client/Client to a Client. Are there any known problems if 
the cluster-id is attached for the non-client/client to client reflections? 

[2] The use of Originator-ids is not completely clear to me - It seems that 
    they are primarily used in a bogus-update-sending-suppression capacity. 
    Is it ever the case that a misconfiguration leads to a receiving router
    discarding an update because its router-id matches the originator-id?

    On a related note, is it safe for a reflector to set the originator-id
    as follows :
    a) Don't overwrite originator-ids already attached to an update.
    b) Route from EBGP peer - set Originator id to my router-id before 
       sending it out. IBGP peers which do not understand this attribute 
       will ignore it.
    c) Route from IBGP peer - set Originator-id to the router-id of the 
       IBGP peer. Since the first reflector seeing an update knows the 
       router-id of the IBGP peer it can set this correctly.

(router-id is used to denote bgp-identifier.)

Thanks in advance for your comments.
--rohit.
#include <stdio.h>        /* Opinions mine alone ! */