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

From: Tony Przygienda <[email-masked]>
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.
>
>     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
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

---

From: "Enke Chen" <[email-masked]>
Date: Thu, 21 Oct 2004 23:20:50 -0700

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
> 

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.

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

> slightly deviates from 'official' spec last I checked) especially with connection

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

> 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.
> 
> Anyone cares to clarify and I hope I don't repeat some discussion that I missed on idr list ?
> 
> 	thanks
> 
> 
> 	-- tony
>