Re: [Idr] AD Review of draft-ietf-idr-bgp-optimal-route-reflection-22

[Alvaro Retana <[e-mail]>]

On May 22, 2021 at 7:43:42 AM, Robert Raszuk wrote:


Robert:

Hi!



> Hi Alvaro,
>
> Few comments on your comments ....
>
> > What I meant is: when/why would an operator select to anchor the
> > logical location based on a peer...or peer-group... I understand the
> > load considerations, but I'm looking for advantages/disadvantages
> > related to the point of view (assuming the platform can handle either
> > choice). As you say in the abstract, the precision requirements are
> > different -- but they are not explained. BTW, the new text in §6
> > doesn't address this question either.
> >
> > I'm looking for something along the lines of:
> >
> > Selecting to configure an IGP location per peer has the highest precision
> > as each peer can be associated with their ideal IGP location. However,
> > doing so may have an impact on the performance (as explained above). Using
> > an IGP location per peer-group implies a loss of precision, but reduces the
> > impact on the performance of the route reflector. If peer-groups are
> > configured taking into account the location of the route reflector clients,
> > and not just the policy, the impact of considering a non-optimal individual
> > IGP location for each peer can be reduced. Similarly, if an IGP location
> > is selected for the whole routing instance...
>
>
> Well per peer-group or per peer was something added to the draft more for
> convenience than anything else. If we were to be precise dynamic update
> groups should also be listed.
>
> The point however is that selecting a set of peers which may share IGP
> proximity from the perspective of path selection is essentially orthogonal
> to all of the above.
>
> I am not sure if this is too late in the process but I would suggest to just
> state in the draft "set of peers" and how they are grouped in the given
> implementation is out of scope.
>
> For example I may group peers just based on the fact that I am doing some
> policy on IBGP paths (say for vpnv4 routes as example). In such a case this
> may be completely orthogonal to ORR objective.
>
> So some smart implementations may build automated grouping and all operator
> needs to enter is delta IGP metric between peers which are allowed to get
> auto grouped.

All this is fine -- I don't disagree with anything.  My point is not
about selecting the peers, or how an implementation may group peers or
not.

My point is about the precision requirements mentioned in the
abstract.  In the general case, assigning an IGP location per-peer is
more precise than doing it per group (again, regardless of how that
group was determined).

I think we're talking about related but different things. :-)




> > How is a "node in the IGP topology" identified?
> >
> > I'm not asking how to configure it (you declare it out of scope later
> > on -- which is ok). I'm asking what it is? How is it represented? I
> > guess that a "node in the IGP topology" would be identified by it's
> > router-id/system-id -- is that the expectation?
>
>
> Is this really needed ?
>
> The reason why this is left out was to avoid limitations for the implementation.

Read the rest of my comments... ;-)

Sure, that's ok.  At least please mention an example.

Thanks!

Alvaro.