[Idr] draft-ietf-idr-rfc2796bis-01: what's the exact tie-breaking rules

Reading through bis of the RR draft stumbled over

>9. Impact on Route Selection
>
>   The BGP Decision Process Tie Breaking rules (Sect. 9.1.2.2, [1]) are
>   modified as follows:
>
>     If a route carries the ORIGINATOR_ID attribute, then in Step f)
>     the ORIGINATOR_ID SHOULD be treated as the BGP Identifier of
>     the BGP speaker that has advertised the route.
>
>     In addition, the following rule SHOULD be inserted between Steps
>     f) and g): a BGP Speaker SHOULD prefer a route with the shorter
>     CLUSTER_LIST length. The CLUSTER_LIST length is zero if a route
>     does not carry the CLUSTER_LIST attribute.

Now, the question comes up what to do with ECMP (which in many implementations
slightly deviates from 'official' spec last I checked) especially with connection
to the 'SHOULD' 

Many implementations ignore the router_id for ECMP purposes & load-balance
that way and it is interesting now to think whether we can still do that when

a) one route has an  ORIGINATOR_ID and the other none
b) one route has an  ORIGINATOR_ID_1 != ROUTER_ID_1 and ORIGINATOR_ID_1 != ORIGINATOR_ID_2 
	BUT   ROUTER_ID_1 == ORIGINATOR_ID_2   [I admit, pathological but possible]

and so on.

Are we sure a mix of implementations old-style (ignoring the SHOULD) and 
implementations of new-style (take ORIGINATOR_ID always [or only sometimes] as 
ROUTER_ID) will not form loops with ECMP implementations ? 

The whole thing looks like another partial order in BGP route ordering (the first 
infamous one lead to quite a couple of med-this and med-other ... options in many
vendors) and I wonder whether there is enough reason to do the same here.

Same for CLUSTER_LIST length (albeit here I understand the scenario that led to the 
rule & it makes sense). 

Anyone cares to clarify and I hope I don't repeat some discussion that I missed on 
idr list ? 

	thanks

	-- tony

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www1.ietf.org/mailman/listinfo/idr