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

[[e-mail]]

Alvaro,

> From: Alvaro Retana [mailto:[e-mail]]
> Sent: Friday, May 21, 2021 8:58 PM
> 
> On May 12, 2021 at 5:02:25 AM, [e-mail] wrote:
> 
> 
> Bruno:
> 
> Hi!
> 
> I'm fine with the changes (or no changes) resulting from the points
> I'm not commenting on.  Thanks for the detail in the discussion!

Again, thanks for your comments.
 
> I have a couple of comments left.  I think these can be addressed
> along with any other from the IETF LC, so I'm starting it.
> 
> Thanks!
> 
> Alvaro.
> 
> 
> 
> ...
> > > (2) Deployment Considerations. §6 says that a compliant
> > > implementation is one that allows the operator to configure "a logical
> > > location from which the best path will be computed, on the basis of
> > > either a peer, a peer group, or an entire routing instance". Please
> > > spend some time providing guidance so an operator can decide what best
> > > works for their network. [I pointed below to other places there
> > > operational guidance would be ideal.]
> >
> > OK. What about the following text:
> > Calculating routes for different IGP locations requires multiple SPF
> > calculations and multiple (subsets of) BGP Decision Processes, which
> > requires more computing resources. This document allows for different
> > granularity such as one Decision Process per route reflector, per group of
> > peers or per peer. A more fine grained granularity may translate into more
> > optimal hot potato routing at the cost of more computing power. The
> ability
> > to run fine grained computations depends on the platform/hardware
> deployed,
> > the number of peers, the number of BGP routes and the size of the IGP
> > topology. In essence, sizing considerations are similar to the deployments
> > of BGP Route Reflector.
> 
> 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...

Thanks for taking the time to propose text.
I'm afraid that I'm not sure to see the real difference between your text and my proposed text, but I'll add your text.

NEW:
    Selecting to configure an IGP location per client has the highest precision
    as each client can be associated with their ideal (own) IGP location.  However,
    doing so may have an impact on the performance (as explained
 above).  Using
    an IGP location per set of clients implies a loss of precision, but reduces the
    impact on the performance of the route reflector.  
   Similarly, if an IGP location
    is selected for the whole routing instance, the lowest precision is achieved but the performance impact is minimal (both should be equal to the RFC 4456 ones).


Notes:
- I've changed 'peer-groups' to 'set of clients' and 'peers' to 'clients' to be aligned with latest changes in the draft.
- I've remove the penultimate sentence as I don't see the difference with the first one.
- I've completed the last sentence

> 
> ...
> > > [major] "IGP location" Before I forget -- please clearly define (not
> > > in the Abstract of course) what an "IGP location" is.
> >
> > Added in section "Modifications to BGP Route Selection"
> ...
> > NEW:
> > The core of this solution is the ability for an operator to specify the IGP
> > location for which the route reflector calculates interior cost for the
> > NEXT_HOP. The IGP location is defined as a node in the IGP topology and
> may
> > be configured on a per route reflector basis, per peer/update group basis,
> > or per peer basis.
> 
> How is a "node in the IGP topology" identified?

Thanks for the clarification.
Indeed, there may be different identifiers available (router-id, name, admin tag, ISO-NET...). However that ID needs to be found in the link state IGP and ideally is independent of the IGP protocol (IS-IS, OSPFv2, OSPFv3, BGP-LS, LSVR...). Bottom line "an IP address" seems like a good choice, and that is the one chosen on the implementation that I've checked.

Proposed change
OLD:  The IGP location is defined as a node in the IGP topology and may be configured on a per route reflector basis, per set of clients, or per client basis.
NEW: The IGP location is defined as a node in the IGP topology, is identified by an IP address of this node (e.g. a loopback address), and may be configured on a per route reflector basis, per set of clients, or per client basis.

 
> 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?
> 
> Later you mentioned: "Configuration itself is out of scope (in
> particular how the location is indicated as it could be via router ID,
> loopback @, IS-IS ISO NET...)."   Can you at least provide examples?
> Maybe mention that it is protocol specific.
> 
> Not specifying how the node is identified seems like it could result
> in different implementations doing different things: for example, some
> allowing a loopback but others requiring the router-id.  The problem
> is that this could result in operational complexity (assuming that
> different implementations are used in the network and that the
> router-id is not the specific loopback)...  I'm just saying this out
> loud for the record because it makes me feel uncomfortable, but we can
> leave it out of scope.
> 
> 
> ...
> > > [major] "one or more backup locations SHOULD be allowed to be
> > > specified for redundancy"
> > >
> > > (1) §3.1 says that the "configuration of the IGP location is outside
> > > of the scope of this document". If that is true, then you can't
> > > recommend anything related to the configuration.
> >
> > Configuration itself is out of scope (in particular how the location is
> > indicated as it could be via router ID, loopback @, IS-IS ISO NET...).
> >
> > In all cases, one IGP location needs to be provisioned. Providing a backup
> > one seem like the same functional work. I don't see why the document
> could
> > talk about the former but not about the latter.
> > IOW,
> > - §3 says "an operator to specify the IGP location" and this seems ok.
> > - §4.1 says "one or more backup locations SHOULD be allowed to be
> specified
> > for redundancy" and this seem non ok although the term used seem similar
> > (IGP location, specify).
> >
> > Could you please clarify the point and if possible suggest a path for
> > clarification.
> 
> The difference is in the use of normative language (SHOULD): if the
> configuration is out of scope, then we shouldn't normatively recommend
> anything.   s/SHOULD/should

OK. The way your comment is phrased, this is indeed logical.
In the draft, I had assumed a difference between:
- HOW this is configured (out of scope)
- WHAT is configured (in scope) 
 
If that does not work, I only see two choices:
a) remove the "SHOULD"
b) remove "out of scope"

I think that the ability to indicate a second location is important for redundancy as the nominal location may "disappear" from the IGP (reads "fails"). So I feel that I can only pick "b"

Proposed change
OLD: 
In order to be able to compute the shortest path tree rooted at the
   selected IGP locations, knowledge of the IGP topology for the area/
   level that includes each of those locations is needed.  This
   knowledge can be gained with the use of the link state IGP such as
   IS-IS [ISO10589] or OSPF [RFC2328] [RFC5340] or via BGP-LS [RFC7752].

   The way the IGP location is configured is outside the scope of this
   document.  The operator may configure it manually, an implementation
   may automate it based on heuristics, or it can be computed centrally
   and configured by an external system.  One or more backup locations
   SHOULD be allowed to be specified for redundancy.

NEW: 
In order to be able to compute the shortest path tree rooted at the
   selected IGP locations, knowledge of the IGP topology for the area/
   level that includes each of those locations is needed.  This
   knowledge can be gained with the use of the link state IGP such as
   IS-IS [ISO10589] or OSPF [RFC2328] [RFC5340] or via BGP-LS [RFC7752].
   One or more backup IGP locations SHOULD be allowed to be specified for redundancy.

 
> 
> > > (2) If there were "backup locations", how would they be used?
> >
> > As backup for redundancy. I.e., used when the nominal failed and hence
> not
> > in the network topology anymore.
> 
> Related to the guidance about indicating an IGP location per-peer,
> etc.  The backup will not be as good as the primary location; sure
> there are cases where the IGP location may be one of a pair of
> redundant routers so there's not much change...but the general case
> will probably result in the backups being increasingly less optimal.

Agreed, with some significant nuances:
- The backup is less optimal compared to the nominal in the full/pre-failure IGP topology. But the full topology is not the situation we are in, therefore I don't think that's a relevant situation to compare with. What we have is the post failure IGP topology without the nominal. In this situation, the back location is the new optimal.
- How is this different to having two RFC 4456 BGP RR (locations)? Same thing: once a RR fails, the path may be less optimal than before the failure.
(-nitpicking: an IGP location for a set of peers is an average. The backup IGP location will be less optimal in average. Still some paths may turned to be more optimal with the IGP location)

> Can you please add a sentence or two about this?

What about in section " 4.  Deployment Considerations" after 

"As discussed in section 11 of [RFC4456], the IGP locations of BGP
   route reflectors is important and has routing implications.  This
   equally applies to the choice of the IGP locations configured on
   optimal route reflectors."

NEW: If a backup location is provided, it is used when the nominal IGP location disappear from the IGP (i.e. fails). Just like the failure of the nominal RFC 4456 BGP RR, this may result in changing the paths selected and advertised to the clients and in general the post-failure paths are expected to be less optimal. This is dependent on the IGP topologies and the IGP distance between the nominal and the backup location: the smaller the distance the smaller the chance to change the BGP paths.

("Nominal BGP RR" is a shortcut as BGP RR has no notion of nominal/backup. Stricto census that would be the failure of the BGP RR advertising the nominal path. I can rephrase if you prefer)
 
> 
> ...
> > Now whether or not the sentence is useful, is an open question:
> > - on one hand you expressed that comparison between solutions are never
> good
> > - on the other hand you expressed that guidance to the network operator
> is
> > useful when multiple options are offered.
> 
> Just to be clear: comparison between ORR and other solutions is not
> good.  If, when deploying ORR (this document), multiple options are
> presented, then guidance (which is different than comparison) is good.
> 8-)

This makes sense.
But in practice this may be close:
- "If the number of BGP paths is high, BGP ORR may be more suitable than BGP ADD PATH which advertise all those paths"., is very close to saying that BGP ORR scales better than BGP ADD PATH with regards to the number of paths
- same thing with the number of IGP locations (but with an opposite result)
 
> 
> 
> ...
> > > 425 7. Security Considerations
> ...
> > NEW:
> > This document does not introduce requirements for any new
> > protection measures.
> 
> I'm ok with this change.
> 
> The downside is that now the Security Considerations section is very
> short.  This is usually a red flag for the Sec ADs to look for more.
> But besides adding a reference to rfc4272 I can't think of anything
> else to add.

I agree.
We'll see the comments that we'll get.

Since we are during the IETF LC, I'll delay the update until you told me so.

Thank you

> 
> [EoR]
[EoR]

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.