Re: [Idr] Opsdir early review of draft-ietf-idr-bgp-optimal-route-reflection-21

[Robert Raszuk <[e-mail]>]

Hi Dan,

Many thx for the review.

What are the consequences of this condition not being met? Are there any
> requirements or recommendations for operators in deployment? Some
> clarification
> text would be useful, did I miss something?
>

If the route reflector does not contain all eligible paths its decision may
be suboptimal in the sense of choosing the exit path still perhaps closer
in metric to logical placement of the RR (better then overall best). In
general if route reflectors even without this extension do not contain all
eligible paths for a given net and clients are connected without strict
topology awareness in basic IP hop by hop forwarding loops can easily
happen.

Original RR design was to place them in the data path (typically at or near
are boundaries or POP boundaries). With networks moving away from hop by
hop IP lookup to ingress-egress encapsulation that MUST condition or design
rule has been safely relaxed and RRs have moved to central positions.

BGP Optimal Route Reflection does not really place any additional burden on
the RR design as such. Contrary it allows to place RRs (perhaps running on
general compute x86 blades) anywhere in the network and still be able to
accomplish the optimal choice of path(s).

With all of that said I recognize that the current text may sound a bit too
scary :) I will talk with co-authors on rewording or removing it.



> 2. In Section 3.1:
>
> > In addition to the change specified in [RFC4456] section 9, the BGP
>    Decision Process Tie Breaking rules ([RFC4271] Sect.  9.1.2.2) are
>    modified as follows.
>
> Should not the document UPDATE RFC 4271 (when approved)?
>

Well I don't think so. See this is not modification to BGP protocol as such
.. just an optional functional enhancement.

Just like original route reflection RFC 4456 did not update RFC4271 even
though it also modified section 9.1.2.2 there.

Likewise Add-paths RFC 7911 did not update neither RFC4456 nor RFC4271, but
obviously does change best path selection when choosing more then best path
for advertisement irrespective of metric to the next hop.

Many thx,
Robert.