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

Hi, Tony:

In general these rules are necessary for route reflection to function properly,
and they have been widely deployed for at least 6 or 7 years.

Please see my comments inline.

>     * To: idr at ietf.org
>     * Subject: [Idr] draft-ietf-idr-rfc2796bis-01: what's the exact tie-breaking rules
>     * From: Tony Przygienda <prz at xebeo.com>
>     * Date: Tue, 19 Oct 2004 09:55:24 +0200
> 
> 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.
>

This requirement probably should be a MUST.  Route selection for IBGP paths
must be consistent to avoid forwarding loops.  Thus, routers within an AS must
have a consistent view with respect to the BGP Identifier of the router that
sources the route in the AS. (BGP Identifier impacts route selection.)

Forwarding loop can occur if RR is used in a network and some routers do not
follow this rule.

> 
>     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.

When the redundent RRs within a cluster are not configured with the same cluster-id,
a RR may receive a route from its client directly, and from the other RR. With the
right combinations of peering addresses, without this rule a RR may select the one
from the other RR as the best path (and then withdraw its own advertisement), and
routing may not converge. The rule is necessary to deal with this corner case.

As long as routing converges, forwarding loops wouldn't form even if some
routers do not follow this rule. (The routes being compared are of the same
BGP Identifier, and thus the same next-hop anyway.)

> 
> 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'

I am not aware of the existence of the "offical" spec for IBGP ECMP. (Well I
hacked up the limited support for IBGP ECMP several years ago, and that seemed
to have propagated ... :-(

The first rule is important regardless of IBGP ECMP. The 2nd rule does not seem
to have any bearing on IBGP ECMP.

Regards,

-- Enke

> 
> 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
> 