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

[Robert Raszuk <[e-mail]>]

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.


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.

So if we say router-id we should also list nsap which router-id is only
part of. Further if we are to say this we perhaps should also specify if we
are talking about base topology or some other topology in case of mtr. And
then some may consider only to compute IGP metrics for next hops reachable
via specific flex algo topology as for some applications it could be
completely irrelevant what base topology says.

Many thx,
R.