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

Enke Chen wrote:

> 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.
>
Hey Enke, that I know and my point was not that 'it does not work', it
was rather request for clarficiation of the spec to reflect reality better,
especially for ECMP ;-)

>
>
> 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.
>
agreed. A sentence explaining what can or cannot happen if you have routers
that do not understand ORIGINATOR_ID and therefore don't follow this rule
would improve the spec IMHO.

>
>
> >
> >     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.)
>
yes, agreed of course.

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

>
>
> >
> > 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).
> >
>
ok, if the official stance is still 'there is no BGP ECMP spec' then 
we're in sync I guess
since my questoin implicitly cannot be asked ;-)

    thanks much, Enke

       -- tony

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