AD Review of draft-ietf-idr-bgp-optimal-route-reflection-22

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

AD Review of draft-ietf-idr-bgp-optimal-route-reflection-22

Alvaro Retana-2
Dear authors:


Thank you for your work on this document.  I know that the draft and
the related ideas have been around for a long time.

I have a couple of significant issues that I want to highlight
upfront, and many comments inline (see below).  In general, my focus
is to make sure that the specification of this mechanism is clear, not
just to the experienced reader, but to the casual one as well.  I
believe that all the issues should be easy to resolve.

(1) Terminology.  Please use the terminology already defined in
rfc4271/rfc4456 instead of creating new one by indirection.  My first
inline comment is about the use of "best path", which is not what
rfc4271 uses -- there are other occurrences later on.

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

(3) I don't think that §5 (CPU and Memory Scalability) and Appendix A
(alternative solutions with limited applicability) should be part of
this document.  To start, comparisons are never good and the work has
already been through the WG so there's no need to keep justifying it
by comparing it to other work.  Both sections contain several claims
(e.g. "extra cost in terms of CPU", "implemented efficiently",
"expected to be higher but comparable", "large amount of BGP state and
churn", "result in tens of paths for each prefix") that don't have
references, and could be considered subjective because they are
clearly relative and can change depending on the specific deployment
and configuration of the network.  I am not saying that the claims are
false, simply requesting to take these two sections out.


Thanks!

Alvaro.


[Line numbers from idnits.]

...
17 Abstract

19   This document defines an extension to BGP route reflectors.  On route
20   reflectors, BGP route selection is modified in order to choose the
21   best path from the standpoint of their clients, rather than from the
22   standpoint of the route reflectors.  Multiple types of granularity
23   are proposed, from a per client BGP route selection or to a per peer
24   group, depending on the scaling and precision requirements on route
25   selection.  This solution is particularly applicable in deployments
26   using centralized route reflectors, where choosing the best route
27   based on the route reflector IGP location is suboptimal.  This
28   facilitates, for example, best exit point policy (hot potato
29   routing).

[major] "best path"  rfc4271 doesn't use the term "best path".  The
terminology used in this document should, at the very least, match
what the base spec defines.  Let's please not create new terminology
by indirection using the "definition of terms" section.


[minor] "proposed"  This document is in line to be come an RFC; we're
far beyond proposing things.  There are a couple of places later on
where this same wording is used.  Please change it to specified or at
least described (the latter probably fits best in this specific case).


[nit] s/from a per client BGP route selection or to a per peer
group/from per client BGP route selection or per peer group


[nit] s/precision requirements on route selection./precision requirements.


[nit] s/route reflector IGP location/route reflector's IGP location


[major] "IGP location"  Before I forget -- please clearly define (not
in the Abstract of course) what an "IGP location" is.


...
70   1.  Definitions of Terms Used in This Memo  . . . . . . . . . . .   2
71   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3

[nit] It would be nice if the Introduction came up before the terminology.


...
91 1.  Definitions of Terms Used in This Memo

[minor] To avoid repeating some terms, it is good practice to indicate
which other RFCs the reader should be familiar with.  In this case
rfc4271 and rfc4456 come to mind.


...
132 2.  Introduction
...
153   Section 11 of [RFC4456] describes a deployment approach and a set of
154   constraints which, if satisfied, would result in the deployment of
155   route reflection yielding the same results as the IBGP full mesh
156   approach.  This deployment approach makes route reflection compatible
157   with the application of hot potato routing policy.  In accordance
158   with these design rules, route reflectors have traditionally often
159   been deployed in the forwarding path and carefully placed on the POP
160   to core boundaries.

[nit] s/have traditionally often/have often
Redundant...


162   The evolving model of intra-domain network design has enabled
163   deployments of route reflectors outside of the forwarding path.
164   Initially this model was only employed for new address families, e.g.
165   L3VPNs and L2VPNs, however it has been gradually extended to other
166   BGP address families including IPv4 and IPv6 Internet using either
167   native routing or 6PE.  In such environments, hot potato routing
168   policy remains desirable.

[minor] "new address families, e.g. L3VPNs and L2VPNs"  These are not
the name of the AFs.  Maybe call them new services.


[minor] "IPv4 and IPv6 Internet"  The name of the AF is IP/IP6; again,
you probably mean service/application.


[nit] "native routing or 6PE"  Not 4PE applications?  ;-)   It seems
to me that you can save some ink by ending the sentence after
"Internet".


...
194 3.  Modifications to BGP Best Path selection

196   The core of this solution is the ability for an operator to specify
197   the IGP location for which the route reflector should calculate
198   routes.  This can be done on a per route reflector basis, per peer/
199   update group basis, or per peer basis.  This ability enables the
200   route reflector to send to a given set of clients routes with
201   shortest distance to the next hops from the position of the selected
202   IGP location.  This provides for freedom of route reflector physical
203   location, and allows transient or permanent migration of this network
204   control plane function to an arbitrary location.

[major] "ability for an operator to specify the IGP location for which
the route reflector should calculate routes.  This can be done on a
per route reflector basis, per peer/update group basis, or per peer
basis."

When should an operator choose per RR vs per peer group vs per peer?
Choice is good, but providing guidance for the deployment is much
better.  Please consider adding text to §6 about the considerations to
chose one or the other.


[minor] "peer/update group"  Where is this defined?  Is there a
reference to a non-implementation-specific definition?  Can it be
called "a group of peers"?  Maybe you also want to include it in the
definitions in §1.


...
215   o  it can, and usually will, have a different position in the IGP
216      topology, and

[] "usually will"   The position in the topology will *always* be different!


...
222   This document defines, on BGP Route Reflectors [RFC4456], two changes
223   to the BGP Best Path selection algorithm:

[nit] s/defines, on BGP Route Reflectors/defines, for BGP Route Reflectors


...
235   A route reflector can implement either or both of the modifications
236   in order to allow it to choose the best path for its clients that the
237   clients themselves would have chosen given the same set of candidate
238   paths.

[major] Please provide guidance for the operator to consider then one
or both should be used in their network.


240   A significant advantage of these approaches is that the route
241   reflector clients do not need to run new software or hardware.

[nit] s/do not need to run new software or hardware./do not need to be modified.


243 3.1.  Best Path Selection from a different IGP location

245   In this approach, optimal refers to the decision made during best
246   path selection at the IGP metric to BGP next hop comparison step.  It
247   does not apply to path selection preference based on other policy
248   steps and provisions.

[major] Please be specific about what is the "IGP metric to BGP next
hop comparison step".  There is no step with that name, or even a
string match in rfc4271.  Later you talk about the step e) tie-breaker
-- don't wait to be specific!


...
263      e) Remove from consideration any routes with less-preferred
264      interior cost.  The interior cost of a route is determined by
265      calculating the metric from the selected IGP location to the
266      NEXT_HOP for the route using the shortest IGP path tree rooted at
267      the selected IGP location.

[major] Note that the specification talks about "interior cost", but
the descriptions in this document uses "IGP cost" and "IGP metric" to
refer to the same thing.  Please be consistent with existing
terminology!


[major] Related to the definition of "IGP location" and its
configuration.  How does the IGP location (and thus the calculation of
the interior cost, as above) change when the configuration is done per
peer/update groups instead than per peer?  This is another point where
operators could benefit from guidance (for the peer/update-group and
whole RR cases, of course).


...
275   The configuration of the IGP location is outside of the scope of this
276   document.  The operator may configure it manually, an implementation
277   may automate it based on heuristics, or it can be computed centrally
278   and configured by an external system.

[nit] s/outside of the scope/outside the scope

[major] There are several places later on that talk about the
configuration, even making it a requirement for compliance (§6).  I
think that you don't mean the configuration itself, but the way in
which the configuration is instantiated in the router (which could be
considered an implementation detail).  As written, the text is not
clear.


280   This solution does not require any change (BGP or IGP) on the
281   clients, as all required changes are limited to the route reflector.

[] This was also claimed before.


283   This solution applies to NLRIs of all address families that can be
284   route reflected.

[] Are there AFs that cannot be reflected?  Just wondering if you
really need to say this.


286 3.1.1.  Restriction when BGP next hop is BGP prefix

288   In situations where the BGP next hop is a BGP prefix itself, the IGP
289   metric of a route used for its resolution SHOULD be the final IGP
290   cost to reach such next hop.  Implementations which can not inform
291   BGP of the final IGP metric to a recursive next hop SHOULD treat such
292   paths as least preferred during next hop metric comparison.  However
293   such paths SHOULD still be considered valid for best path selection.

[major] The recursive resolution is already covered in rfc4271
(§5.1.3/§9.1.2.1).  Why isn't that enough?

There seems to be a difference: if an implementation "can not inform
BGP of the final IGP metric to a recursive next hop...SHOULD still be
considered valid for best path selection."  rfc4271 treats these
routes as unresolvable.  Do you want to consider unresolvable routes?

Finally, there are a lot of SHOULDs in this paragraph.  Under which
conditions is it ok to not perform the actions?  IOW, why are these
actions recommended and not required?


295 3.2.  Multiple Best Path Selections

297   BGP Route Reflector as per [RFC4456] runs a single best path
298   selection.  Optimal route reflection may require calculation of
299   multiple best path selections or subsets of best path selection in
300   order to consider different IGP locations or BGP policies for
301   different sets of clients.

[] It hasn't been mentioned before, but the talk about policy made me
think about this:   Can a client be present on different sets?  How is
that handled in terms of BGP sessions?  Do we need multiple sessions?
Or is add-path required?


303   If the required routing optimization is limited to the IGP cost to
304   the BGP Next-Hop, only step e) as defined [RFC4271] section 9.1.2.2,
305   needs to be duplicated.

[major] I'm not sure if this paragraph is referencing §3.1 (where step
e) was just modified), or or you're saying that for each subset (from
the last paragraph) only step e) is considered, or something else.  ??


307   If the routing optimization requires the use of different BGP
308   policies for different sets of clients, a larger part of the decision
309   process needs to be duplicated, up to the whole decision process as
310   defined in section 9.1 of [RFC4271].  This is for example the case
311   when there is a need to use different policies to compute different
312   degree of preference during Phase 1.  This is needed for use cases
313   involving traffic engineering or dedicating certain exit points for
314   certain clients.  In the latter case, the user MAY specify and apply
315   a general policy on the route reflector for a set of clients.  For a
316   given set of clients, the policy SHOULD in that case allow the
317   operator to select different candidate exit points for different
318   address families.  Regular path selection, including IGP perspective
319   for a set of clients as per Section 3.1, is then applied to the
320   candidate paths to select the final paths to advertise to the
321   clients.

[] Similar comment as before...   The use of "duplicated" is confusing me.


[major] "the user MAY specify..."  s/MAY/may   It seems to me that
you're simply stating a fact (the user can do this), and not
specifying an optional behavior.


[major] "...the policy SHOULD in that case allow the operator to
select different candidate exit points for different address
families."  There's no interoperable action that "the policy" can
execute.  It sounds as if you're recommending that specific knobs
("allow the operator to...") be implemented.  Please reword.


[] You use "IGP perspective" I guess as equivalent to "IGP location"
-- is that right?


323 4.  Implementation considerations

325 4.1.  Likely Deployments and need for backup

[nit] Do we really need a sub-section if all the text for §4 is in it?


327   With IGP based optimal route reflection, even though the IGP location
328   could be specified on a per route reflector basis or per peer/update
329   group basis or per peer basis, in reality, it's most likely to be
330   specified per peer/update group basis.  All clients with the same or
331   similar IGP location can be grouped into the same peer/update group.
332   An IGP location is then specified for the peer/update group.  The
333   location is usually specified as the location of one of the clients
334   from the peer group or an ABR to the area where clients are located.
335   Also, one or more backup locations SHOULD be allowed to be specified
336   for redundancy.  Implementations may wish to take advantage of peer
337   group mechanisms in order to provide for better scalability of
338   optimal route reflector client groups with similar properties.

[major] "IGP based optimal route reflection"

This is the first time you use "IGP based optimal route reflection"; I
peeked forward and see that §5 also mentions "policy based optimal
route reflection".  But you didn't define them anywhere -- in fact,
the description before now focuses on the IGP location, which makes me
think about "IGP based".

I could guess that the "policy based" version is related to §3.2, but
(1) no one should have to guess (!), and (2) the end of that section
says that "IGP perspective...is then applied", making it also "IGP
based".  ??

Please either define these types of ORR earlier in the text, or
(better yet) don't use the terms.  Instead, and given that the names
are used just a couple of times, change "policy based" to "the case
where a policy is applied"...


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

(2) If there were "backup locations", how would they be used?


[minor] This is the only time that "optimal route reflector client
groups" is used.  I had been assuming that a group of clients would
correspond to a specific peer/update group (as mentioned many times
before).  Is there a difference between a "client group" and grouping
clients to correspond to a peer/update group?


[] "for better scalability of optimal route reflector client groups"
What exactly does this mean?  I asked before about
references/definitions for peer/update groups; this point may be
related.


...
373 6.  Advantages and Deployment Considerations

375   The solutions described provide a model for integrating the client
376   perspective into the best path computation for route reflectors.
377   More specifically, the choice of BGP path factors in either the IGP
378   cost between the client and the nexthop (rather than the IGP cost
379   from the route reflector to the nexthop) or other user configured
380   policies.

[] "solutions"?   I only see one, where the "second" one simply adds
policy, which is a pervasive tool in BGP.


382   The achievement of optimal routing relies upon all route reflectors
383   learning all paths that are eligible for consideration.  In order to
384   satisfy this requirement, path diversity enhancing mechanisms such as
385   BGP add-path [RFC7911] may need to be deployed between route
386   reflectors.

[mayor] "path diversity enhancing mechanisms...may need to be deployed
between route reflectors"  Given that this is the Deployment
Considerations section, please provide guidance on when these
mechanisms are needed, and when they're not.


[minor] "path diversity enhancing mechanisms such as BGP add-path
[RFC7911]"  Just out of curiosity, what other mechanisms are you
thinking of?  Are there deployment considerations, when using ORR, to
prefer one?


388   Implementations considered compliant with this document allow the
389   configuration of a logical location from which the best path will be
390   computed, on the basis of either a peer, a peer group, or an entire
391   routing instance.

[] I guess that "logical location" is another name for IGP location...


[major] §3.1 says that the "configuration of the IGP location is
outside of the scope of this document".  If that is true, then the
configuration cannot be a consideration for compliance.

A better wording for compliance would be: "An implementation MUST
allow the configuration..."


393   These solutions can be deployed in traditional hop-by-hop forwarding
394   networks as well as in end-to-end tunneled environments.  In networks
395   where there are multiple route reflectors and hop-by-hop forwarding
396   without encapsulation, such optimizations SHOULD be enabled in a
397   consistent way on all route reflectors.  Otherwise, clients may
398   receive an inconsistent view of the network, in turn leading to
399   intra-domain forwarding loops.

[major] "optimizations SHOULD be enabled in a consistent way on all
route reflectors"

Is "a consistent way" different than "on all"?   s/.../optimizations
SHOULD be enabled on all route reflectors

When is it ok for all RRs not to be enabled with the optimizations?
IOW, why is it recommended and not required?  Avoiding "intra-domain
forwarding loops" sounds like a good reason to require it.


...
406   As per above, these approaches reduce the amount of state which needs
407   to be pushed to the edge of the network in order to perform hot
408   potato routing.  The memory and CPU resources required at the edge of
409   the network to provide hot potato routing using these approaches is
410   lower than what would be required to achieve the same level of
411   optimality by pushing and retaining all available paths (potentially
412   10s) per each prefix at the edge.

[] This paragraph sounds very speculative and doesn't seem necessary.
In line with §5.


414   The solutions above allow for a fast and safe transition to a BGP
415   control plane using centralized route reflection, without
416   compromising an operator's closest exit operational principle.  This
417   enables edge-to-edge LSP/IP encapsulation for traffic to IPv4 and
418   IPv6 prefixes.

[] "allow for a fast and safe transition"  Besides this statement
sounding like a marketing brochure, if you're going to talk about
transition, please talk about it in detail.  Please take a look at
§2/rfc5706 and include details about the transition and how it is
"fast and safe".


420   Regarding Best Path Selection from a different IGP location, it
421   should be self evident that this solution does not interfere with
422   policies enforced above IGP tie-breaking in the BGP best path
423   algorithm.

[minor] Don't assume anything is self evident to anyone.

Suggestion (maybe more appropriate in §3.1)>
   The modification specified in Section 3.1 does not impact any previous
   considerations in the BGP Decision Process.


425 7.  Security Considerations

427   Similarly to [RFC4456], this extension to BGP does not change the
428   underlying security issues inherent in the existing IBGP [RFC4456].

[minor] No need to reference rfc4456 twice in the same sentence.


430   It however enables the deployment of base BGP Route Reflection as
431   described in [RFC4456] to be possible using virtual compute
432   environments without any negative consequence on the BGP routing path
433   optimality.

[] I'm not sure how this relates to the specification itself (platform
independent), but I'm sure the Security ADs will have a lot of
questions about the security of "virtual compute environments" -- and
where the details are included in this document.   IOW, that sounds
like an unnecessary assertion.


[major] "without any negative consequence"  The new functionality
specified in this document is having the RR run the client's selection
for them (even specific policy) -- there are risks related to the
duplication of the policy, the location of the RRs and the blind trust
that the clients need to have.  Or should the clients rerun the policy
locally?

This behavior is not necessarily different from normal RR, but the
instantiation is different.   It would be very easy for a rogue RR to
propagate incorrect routing information to its clients -- specially if
policy is offloaded to them.

In the worst case the result would be a sub-optimal route (maybe even
worse than what the clients get today), but probably not a "real"
security issue.  It is probably a good idea to explain why it is not a
security risk.


435   This document does not introduce requirements for any new protection
436   measures, but it also does not relax best operational practices for
437   keeping the IGP network stable or to pace rate of policy based IGP
438   cost to next hops such that it does not have any substantial effect
439   on BGP path changes and their propagation to route reflection
440   clients.

[major] "best operational practices"  Like what?  It would be good to
provide (at least) informational references.


[major] "to pace rate of policy based IGP cost to next hops such that
it does not have any substantial effect on BGP path changes"   You
will have to explain this further because the operation of an IGP is
not mentioned anywhere else.

IMHO, there's no need to go into IGP operational details in this
document.  There is nothing special/different about the operation of
an IGP.


[End of Review]

_______________________________________________
Idr mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/idr
Reply | Threaded
Open this post in threaded view
|

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

Alvaro Retana-2
Ping!

On March 18, 2021 at 3:32:01 PM, Alvaro Retana ([hidden email]) wrote:


Dear authors:


Thank you for your work on this document.  I know that the draft and the related ideas have been around for a long time.

I have a couple of significant issues that I want to highlight upfront, and many comments inline (see below).  In general, my focus is to make sure that the specification of this mechanism is clear, not just to the experienced reader, but to the casual one as well.  I believe that all the issues should be easy to resolve.

(1) Terminology.  Please use the terminology already defined in rfc4271/rfc4456 instead of creating new one by indirection.  My first inline comment is about the use of "best path", which is not what rfc4271 uses -- there are other occurrences later on.

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

(3) I don't think that §5 (CPU and Memory Scalability) and Appendix A (alternative solutions with limited applicability) should be part of this document.  To start, comparisons are never good and the work has already been through the WG so there's no need to keep justifying it by comparing it to other work.  Both sections contain several claims (e.g. "extra cost in terms of CPU", "implemented efficiently", "expected to be higher but comparable", "large amount of BGP state and churn", "result in tens of paths for each prefix") that don't have references, and could be considered subjective because they are clearly relative and can change depending on the specific deployment and configuration of the network.  I am not saying that the claims are false, simply requesting to take these two sections out.


Thanks!

Alvaro.


[Line numbers from idnits.]

...
17 Abstract

19   This document defines an extension to BGP route reflectors.  On route
20   reflectors, BGP route selection is modified in order to choose the
21   best path from the standpoint of their clients, rather than from the
22   standpoint of the route reflectors.  Multiple types of granularity
23   are proposed, from a per client BGP route selection or to a per peer
24   group, depending on the scaling and precision requirements on route
25   selection.  This solution is particularly applicable in deployments
26   using centralized route reflectors, where choosing the best route
27   based on the route reflector IGP location is suboptimal.  This
28   facilitates, for example, best exit point policy (hot potato
29   routing).

[major] "best path"  rfc4271 doesn't use the term "best path".  The terminology used in this document should, at the very least, match what the base spec defines.  Let's please not create new terminology by indirection using the "definition of terms" section.


[minor] "proposed"  This document is in line to be come an RFC; we're far beyond proposing things.  There are a couple of places later on where this same wording is used.  Please change it to specified or at least described (the latter probably fits best in this specific case).


[nit] s/from a per client BGP route selection or to a per peer group/from per client BGP route selection or per peer group


[nit] s/precision requirements on route selection./precision requirements.


[nit] s/route reflector IGP location/route reflector's IGP location


[major] "IGP location"  Before I forget -- please clearly define (not in the Abstract of course) what an "IGP location" is.


...
70   1.  Definitions of Terms Used in This Memo  . . . . . . . . . . .   2
71   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3

[nit] It would be nice if the Introduction came up before the terminology.


...
91 1.  Definitions of Terms Used in This Memo

[minor] To avoid repeating some terms, it is good practice to indicate which other RFCs the reader should be familiar with.  In this case rfc4271 and rfc4456 come to mind.


...
132 2.  Introduction
...
153   Section 11 of [RFC4456] describes a deployment approach and a set of
154   constraints which, if satisfied, would result in the deployment of
155   route reflection yielding the same results as the IBGP full mesh
156   approach.  This deployment approach makes route reflection compatible
157   with the application of hot potato routing policy.  In accordance
158   with these design rules, route reflectors have traditionally often
159   been deployed in the forwarding path and carefully placed on the POP
160   to core boundaries.

[nit] s/have traditionally often/have often
Redundant...


162   The evolving model of intra-domain network design has enabled
163   deployments of route reflectors outside of the forwarding path.
164   Initially this model was only employed for new address families, e.g.
165   L3VPNs and L2VPNs, however it has been gradually extended to other
166   BGP address families including IPv4 and IPv6 Internet using either
167   native routing or 6PE.  In such environments, hot potato routing
168   policy remains desirable.

[minor] "new address families, e.g. L3VPNs and L2VPNs"  These are not the name of the AFs.  Maybe call them new services.


[minor] "IPv4 and IPv6 Internet"  The name of the AF is IP/IP6; again, you probably mean service/application.


[nit] "native routing or 6PE"  Not 4PE applications?  ;-)   It seems to me that you can save some ink by ending the sentence after "Internet".


...
194 3.  Modifications to BGP Best Path selection

196   The core of this solution is the ability for an operator to specify
197   the IGP location for which the route reflector should calculate
198   routes.  This can be done on a per route reflector basis, per peer/
199   update group basis, or per peer basis.  This ability enables the
200   route reflector to send to a given set of clients routes with
201   shortest distance to the next hops from the position of the selected
202   IGP location.  This provides for freedom of route reflector physical
203   location, and allows transient or permanent migration of this network
204   control plane function to an arbitrary location.

[major] "ability for an operator to specify the IGP location for which the route reflector should calculate routes.  This can be done on a per route reflector basis, per peer/update group basis, or per peer basis."

When should an operator choose per RR vs per peer group vs per peer?  Choice is good, but providing guidance for the deployment is much better.  Please consider adding text to §6 about the considerations to chose one or the other.


[minor] "peer/update group"  Where is this defined?  Is there a reference to a non-implementation-specific definition?  Can it be called "a group of peers"?  Maybe you also want to include it in the definitions in §1.


...
215   o  it can, and usually will, have a different position in the IGP
216      topology, and

[] "usually will"   The position in the topology will *always* be different!


...
222   This document defines, on BGP Route Reflectors [RFC4456], two changes
223   to the BGP Best Path selection algorithm:

[nit] s/defines, on BGP Route Reflectors/defines, for BGP Route Reflectors


...
235   A route reflector can implement either or both of the modifications
236   in order to allow it to choose the best path for its clients that the
237   clients themselves would have chosen given the same set of candidate
238   paths.

[major] Please provide guidance for the operator to consider then one or both should be used in their network.


240   A significant advantage of these approaches is that the route
241   reflector clients do not need to run new software or hardware.

[nit] s/do not need to run new software or hardware./do not need to be modified.


243 3.1.  Best Path Selection from a different IGP location

245   In this approach, optimal refers to the decision made during best
246   path selection at the IGP metric to BGP next hop comparison step.  It
247   does not apply to path selection preference based on other policy
248   steps and provisions.

[major] Please be specific about what is the "IGP metric to BGP next hop comparison step".  There is no step with that name, or even a string match in rfc4271.  Later you talk about the step e) tie-breaker -- don't wait to be specific!


...
263      e) Remove from consideration any routes with less-preferred
264      interior cost.  The interior cost of a route is determined by
265      calculating the metric from the selected IGP location to the
266      NEXT_HOP for the route using the shortest IGP path tree rooted at
267      the selected IGP location.

[major] Note that the specification talks about "interior cost", but the descriptions in this document uses "IGP cost" and "IGP metric" to refer to the same thing.  Please be consistent with existing terminology!


[major] Related to the definition of "IGP location" and its configuration.  How does the IGP location (and thus the calculation of the interior cost, as above) change when the configuration is done per peer/update groups instead than per peer?  This is another point where operators could benefit from guidance (for the peer/update-group and whole RR cases, of course).


...
275   The configuration of the IGP location is outside of the scope of this
276   document.  The operator may configure it manually, an implementation
277   may automate it based on heuristics, or it can be computed centrally
278   and configured by an external system.

[nit] s/outside of the scope/outside the scope

[major] There are several places later on that talk about the configuration, even making it a requirement for compliance (§6).  I think that you don't mean the configuration itself, but the way in which the configuration is instantiated in the router (which could be considered an implementation detail).  As written, the text is not clear.


280   This solution does not require any change (BGP or IGP) on the
281   clients, as all required changes are limited to the route reflector.

[] This was also claimed before.


283   This solution applies to NLRIs of all address families that can be
284   route reflected.

[] Are there AFs that cannot be reflected?  Just wondering if you really need to say this.


286 3.1.1.  Restriction when BGP next hop is BGP prefix

288   In situations where the BGP next hop is a BGP prefix itself, the IGP
289   metric of a route used for its resolution SHOULD be the final IGP
290   cost to reach such next hop.  Implementations which can not inform
291   BGP of the final IGP metric to a recursive next hop SHOULD treat such
292   paths as least preferred during next hop metric comparison.  However
293   such paths SHOULD still be considered valid for best path selection.

[major] The recursive resolution is already covered in rfc4271 (§5.1.3/§9.1.2.1).  Why isn't that enough?

There seems to be a difference: if an implementation "can not inform BGP of the final IGP metric to a recursive next hop...SHOULD still be considered valid for best path selection."  rfc4271 treats these routes as unresolvable.  Do you want to consider unresolvable routes?

Finally, there are a lot of SHOULDs in this paragraph.  Under which conditions is it ok to not perform the actions?  IOW, why are these actions recommended and not required?


295 3.2.  Multiple Best Path Selections

297   BGP Route Reflector as per [RFC4456] runs a single best path
298   selection.  Optimal route reflection may require calculation of
299   multiple best path selections or subsets of best path selection in
300   order to consider different IGP locations or BGP policies for
301   different sets of clients.

[] It hasn't been mentioned before, but the talk about policy made me think about this:   Can a client be present on different sets?  How is that handled in terms of BGP sessions?  Do we need multiple sessions?  Or is add-path required?


303   If the required routing optimization is limited to the IGP cost to
304   the BGP Next-Hop, only step e) as defined [RFC4271] section 9.1.2.2,
305   needs to be duplicated.

[major] I'm not sure if this paragraph is referencing §3.1 (where step e) was just modified), or or you're saying that for each subset (from the last paragraph) only step e) is considered, or something else.  ??


307   If the routing optimization requires the use of different BGP
308   policies for different sets of clients, a larger part of the decision
309   process needs to be duplicated, up to the whole decision process as
310   defined in section 9.1 of [RFC4271].  This is for example the case
311   when there is a need to use different policies to compute different
312   degree of preference during Phase 1.  This is needed for use cases
313   involving traffic engineering or dedicating certain exit points for
314   certain clients.  In the latter case, the user MAY specify and apply
315   a general policy on the route reflector for a set of clients.  For a
316   given set of clients, the policy SHOULD in that case allow the
317   operator to select different candidate exit points for different
318   address families.  Regular path selection, including IGP perspective
319   for a set of clients as per Section 3.1, is then applied to the
320   candidate paths to select the final paths to advertise to the
321   clients.

[] Similar comment as before...   The use of "duplicated" is confusing me.


[major] "the user MAY specify..."  s/MAY/may   It seems to me that you're simply stating a fact (the user can do this), and not specifying an optional behavior.


[major] "...the policy SHOULD in that case allow the operator to select different candidate exit points for different address families."  There's no interoperable action that "the policy" can execute.  It sounds as if you're recommending that specific knobs ("allow the operator to...") be implemented.  Please reword.


[] You use "IGP perspective" I guess as equivalent to "IGP location" -- is that right?


323 4.  Implementation considerations

325 4.1.  Likely Deployments and need for backup

[nit] Do we really need a sub-section if all the text for §4 is in it?


327   With IGP based optimal route reflection, even though the IGP location
328   could be specified on a per route reflector basis or per peer/update
329   group basis or per peer basis, in reality, it's most likely to be
330   specified per peer/update group basis.  All clients with the same or
331   similar IGP location can be grouped into the same peer/update group.
332   An IGP location is then specified for the peer/update group.  The
333   location is usually specified as the location of one of the clients
334   from the peer group or an ABR to the area where clients are located.
335   Also, one or more backup locations SHOULD be allowed to be specified
336   for redundancy.  Implementations may wish to take advantage of peer
337   group mechanisms in order to provide for better scalability of
338   optimal route reflector client groups with similar properties.

[major] "IGP based optimal route reflection"

This is the first time you use "IGP based optimal route reflection"; I peeked forward and see that §5 also mentions "policy based optimal route reflection".  But you didn't define them anywhere -- in fact, the description before now focuses on the IGP location, which makes me think about "IGP based".

I could guess that the "policy based" version is related to §3.2, but (1) no one should have to guess (!), and (2) the end of that section says that "IGP perspective...is then applied", making it also "IGP based".  ??

Please either define these types of ORR earlier in the text, or (better yet) don't use the terms.  Instead, and given that the names are used just a couple of times, change "policy based" to "the case where a policy is applied"...


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

(2) If there were "backup locations", how would they be used?


[minor] This is the only time that "optimal route reflector client groups" is used.  I had been assuming that a group of clients would correspond to a specific peer/update group (as mentioned many times before).  Is there a difference between a "client group" and grouping clients to correspond to a peer/update group?


[] "for better scalability of optimal route reflector client groups"  What exactly does this mean?  I asked before about references/definitions for peer/update groups; this point may be related.


...
373 6.  Advantages and Deployment Considerations

375   The solutions described provide a model for integrating the client
376   perspective into the best path computation for route reflectors.
377   More specifically, the choice of BGP path factors in either the IGP
378   cost between the client and the nexthop (rather than the IGP cost
379   from the route reflector to the nexthop) or other user configured
380   policies.

[] "solutions"?   I only see one, where the "second" one simply adds policy, which is a pervasive tool in BGP.


382   The achievement of optimal routing relies upon all route reflectors
383   learning all paths that are eligible for consideration.  In order to
384   satisfy this requirement, path diversity enhancing mechanisms such as
385   BGP add-path [RFC7911] may need to be deployed between route
386   reflectors.

[mayor] "path diversity enhancing mechanisms...may need to be deployed between route reflectors"  Given that this is the Deployment Considerations section, please provide guidance on when these mechanisms are needed, and when they're not.


[minor] "path diversity enhancing mechanisms such as BGP add-path [RFC7911]"  Just out of curiosity, what other mechanisms are you thinking of?  Are there deployment considerations, when using ORR, to prefer one?


388   Implementations considered compliant with this document allow the
389   configuration of a logical location from which the best path will be
390   computed, on the basis of either a peer, a peer group, or an entire
391   routing instance.

[] I guess that "logical location" is another name for IGP location...


[major] §3.1 says that the "configuration of the IGP location is outside of the scope of this document".  If that is true, then the configuration cannot be a consideration for compliance.

A better wording for compliance would be: "An implementation MUST allow the configuration..."


393   These solutions can be deployed in traditional hop-by-hop forwarding
394   networks as well as in end-to-end tunneled environments.  In networks
395   where there are multiple route reflectors and hop-by-hop forwarding
396   without encapsulation, such optimizations SHOULD be enabled in a
397   consistent way on all route reflectors.  Otherwise, clients may
398   receive an inconsistent view of the network, in turn leading to
399   intra-domain forwarding loops.

[major] "optimizations SHOULD be enabled in a consistent way on all route reflectors"

Is "a consistent way" different than "on all"?   s/.../optimizations SHOULD be enabled on all route reflectors

When is it ok for all RRs not to be enabled with the optimizations?  IOW, why is it recommended and not required?  Avoiding "intra-domain forwarding loops" sounds like a good reason to require it.


...
406   As per above, these approaches reduce the amount of state which needs
407   to be pushed to the edge of the network in order to perform hot
408   potato routing.  The memory and CPU resources required at the edge of
409   the network to provide hot potato routing using these approaches is
410   lower than what would be required to achieve the same level of
411   optimality by pushing and retaining all available paths (potentially
412   10s) per each prefix at the edge.

[] This paragraph sounds very speculative and doesn't seem necessary.  In line with §5.


414   The solutions above allow for a fast and safe transition to a BGP
415   control plane using centralized route reflection, without
416   compromising an operator's closest exit operational principle.  This
417   enables edge-to-edge LSP/IP encapsulation for traffic to IPv4 and
418   IPv6 prefixes.

[] "allow for a fast and safe transition"  Besides this statement sounding like a marketing brochure, if you're going to talk about transition, please talk about it in detail.  Please take a look at §2/rfc5706 and include details about the transition and how it is "fast and safe".


420   Regarding Best Path Selection from a different IGP location, it
421   should be self evident that this solution does not interfere with
422   policies enforced above IGP tie-breaking in the BGP best path
423   algorithm.

[minor] Don't assume anything is self evident to anyone.

Suggestion (maybe more appropriate in §3.1)>
   The modification specified in Section 3.1 does not impact any previous
   considerations in the BGP Decision Process.


425 7.  Security Considerations

427   Similarly to [RFC4456], this extension to BGP does not change the
428   underlying security issues inherent in the existing IBGP [RFC4456].

[minor] No need to reference rfc4456 twice in the same sentence.


430   It however enables the deployment of base BGP Route Reflection as
431   described in [RFC4456] to be possible using virtual compute
432   environments without any negative consequence on the BGP routing path
433   optimality.

[] I'm not sure how this relates to the specification itself (platform independent), but I'm sure the Security ADs will have a lot of questions about the security of "virtual compute environments" -- and where the details are included in this document.   IOW, that sounds like an unnecessary assertion.


[major] "without any negative consequence"  The new functionality specified in this document is having the RR run the client's selection for them (even specific policy) -- there are risks related to the duplication of the policy, the location of the RRs and the blind trust that the clients need to have.  Or should the clients rerun the policy locally?

This behavior is not necessarily different from normal RR, but the instantiation is different.   It would be very easy for a rogue RR to propagate incorrect routing information to its clients -- specially if policy is offloaded to them.

In the worst case the result would be a sub-optimal route (maybe even worse than what the clients get today), but probably not a "real" security issue.  It is probably a good idea to explain why it is not a security risk.


435   This document does not introduce requirements for any new protection
436   measures, but it also does not relax best operational practices for
437   keeping the IGP network stable or to pace rate of policy based IGP
438   cost to next hops such that it does not have any substantial effect
439   on BGP path changes and their propagation to route reflection
440   clients.

[major] "best operational practices"  Like what?  It would be good to provide (at least) informational references.


[major] "to pace rate of policy based IGP cost to next hops such that it does not have any substantial effect on BGP path changes"   You will have to explain this further because the operation of an IGP is not mentioned anywhere else.

IMHO, there's no need to go into IGP operational details in this document.  There is nothing special/different about the operation of an IGP.


[End of Review]




_______________________________________________
Idr mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/idr
Reply | Threaded
Open this post in threaded view
|

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

Robert Raszuk-3
Ack ! 

Work in progress ... 

On Tue, Apr 20, 2021 at 9:29 PM Alvaro Retana <[hidden email]> wrote:
Ping!

On March 18, 2021 at 3:32:01 PM, Alvaro Retana ([hidden email]) wrote:


Dear authors:


Thank you for your work on this document.  I know that the draft and the related ideas have been around for a long time.

I have a couple of significant issues that I want to highlight upfront, and many comments inline (see below).  In general, my focus is to make sure that the specification of this mechanism is clear, not just to the experienced reader, but to the casual one as well.  I believe that all the issues should be easy to resolve.

(1) Terminology.  Please use the terminology already defined in rfc4271/rfc4456 instead of creating new one by indirection.  My first inline comment is about the use of "best path", which is not what rfc4271 uses -- there are other occurrences later on.

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

(3) I don't think that §5 (CPU and Memory Scalability) and Appendix A (alternative solutions with limited applicability) should be part of this document.  To start, comparisons are never good and the work has already been through the WG so there's no need to keep justifying it by comparing it to other work.  Both sections contain several claims (e.g. "extra cost in terms of CPU", "implemented efficiently", "expected to be higher but comparable", "large amount of BGP state and churn", "result in tens of paths for each prefix") that don't have references, and could be considered subjective because they are clearly relative and can change depending on the specific deployment and configuration of the network.  I am not saying that the claims are false, simply requesting to take these two sections out.


Thanks!

Alvaro.


[Line numbers from idnits.]

...
17 Abstract

19   This document defines an extension to BGP route reflectors.  On route
20   reflectors, BGP route selection is modified in order to choose the
21   best path from the standpoint of their clients, rather than from the
22   standpoint of the route reflectors.  Multiple types of granularity
23   are proposed, from a per client BGP route selection or to a per peer
24   group, depending on the scaling and precision requirements on route
25   selection.  This solution is particularly applicable in deployments
26   using centralized route reflectors, where choosing the best route
27   based on the route reflector IGP location is suboptimal.  This
28   facilitates, for example, best exit point policy (hot potato
29   routing).

[major] "best path"  rfc4271 doesn't use the term "best path".  The terminology used in this document should, at the very least, match what the base spec defines.  Let's please not create new terminology by indirection using the "definition of terms" section.


[minor] "proposed"  This document is in line to be come an RFC; we're far beyond proposing things.  There are a couple of places later on where this same wording is used.  Please change it to specified or at least described (the latter probably fits best in this specific case).


[nit] s/from a per client BGP route selection or to a per peer group/from per client BGP route selection or per peer group


[nit] s/precision requirements on route selection./precision requirements.


[nit] s/route reflector IGP location/route reflector's IGP location


[major] "IGP location"  Before I forget -- please clearly define (not in the Abstract of course) what an "IGP location" is.


...
70   1.  Definitions of Terms Used in This Memo  . . . . . . . . . . .   2
71   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3

[nit] It would be nice if the Introduction came up before the terminology.


...
91 1.  Definitions of Terms Used in This Memo

[minor] To avoid repeating some terms, it is good practice to indicate which other RFCs the reader should be familiar with.  In this case rfc4271 and rfc4456 come to mind.


...
132 2.  Introduction
...
153   Section 11 of [RFC4456] describes a deployment approach and a set of
154   constraints which, if satisfied, would result in the deployment of
155   route reflection yielding the same results as the IBGP full mesh
156   approach.  This deployment approach makes route reflection compatible
157   with the application of hot potato routing policy.  In accordance
158   with these design rules, route reflectors have traditionally often
159   been deployed in the forwarding path and carefully placed on the POP
160   to core boundaries.

[nit] s/have traditionally often/have often
Redundant...


162   The evolving model of intra-domain network design has enabled
163   deployments of route reflectors outside of the forwarding path.
164   Initially this model was only employed for new address families, e.g.
165   L3VPNs and L2VPNs, however it has been gradually extended to other
166   BGP address families including IPv4 and IPv6 Internet using either
167   native routing or 6PE.  In such environments, hot potato routing
168   policy remains desirable.

[minor] "new address families, e.g. L3VPNs and L2VPNs"  These are not the name of the AFs.  Maybe call them new services.


[minor] "IPv4 and IPv6 Internet"  The name of the AF is IP/IP6; again, you probably mean service/application.


[nit] "native routing or 6PE"  Not 4PE applications?  ;-)   It seems to me that you can save some ink by ending the sentence after "Internet".


...
194 3.  Modifications to BGP Best Path selection

196   The core of this solution is the ability for an operator to specify
197   the IGP location for which the route reflector should calculate
198   routes.  This can be done on a per route reflector basis, per peer/
199   update group basis, or per peer basis.  This ability enables the
200   route reflector to send to a given set of clients routes with
201   shortest distance to the next hops from the position of the selected
202   IGP location.  This provides for freedom of route reflector physical
203   location, and allows transient or permanent migration of this network
204   control plane function to an arbitrary location.

[major] "ability for an operator to specify the IGP location for which the route reflector should calculate routes.  This can be done on a per route reflector basis, per peer/update group basis, or per peer basis."

When should an operator choose per RR vs per peer group vs per peer?  Choice is good, but providing guidance for the deployment is much better.  Please consider adding text to §6 about the considerations to chose one or the other.


[minor] "peer/update group"  Where is this defined?  Is there a reference to a non-implementation-specific definition?  Can it be called "a group of peers"?  Maybe you also want to include it in the definitions in §1.


...
215   o  it can, and usually will, have a different position in the IGP
216      topology, and

[] "usually will"   The position in the topology will *always* be different!


...
222   This document defines, on BGP Route Reflectors [RFC4456], two changes
223   to the BGP Best Path selection algorithm:

[nit] s/defines, on BGP Route Reflectors/defines, for BGP Route Reflectors


...
235   A route reflector can implement either or both of the modifications
236   in order to allow it to choose the best path for its clients that the
237   clients themselves would have chosen given the same set of candidate
238   paths.

[major] Please provide guidance for the operator to consider then one or both should be used in their network.


240   A significant advantage of these approaches is that the route
241   reflector clients do not need to run new software or hardware.

[nit] s/do not need to run new software or hardware./do not need to be modified.


243 3.1.  Best Path Selection from a different IGP location

245   In this approach, optimal refers to the decision made during best
246   path selection at the IGP metric to BGP next hop comparison step.  It
247   does not apply to path selection preference based on other policy
248   steps and provisions.

[major] Please be specific about what is the "IGP metric to BGP next hop comparison step".  There is no step with that name, or even a string match in rfc4271.  Later you talk about the step e) tie-breaker -- don't wait to be specific!


...
263      e) Remove from consideration any routes with less-preferred
264      interior cost.  The interior cost of a route is determined by
265      calculating the metric from the selected IGP location to the
266      NEXT_HOP for the route using the shortest IGP path tree rooted at
267      the selected IGP location.

[major] Note that the specification talks about "interior cost", but the descriptions in this document uses "IGP cost" and "IGP metric" to refer to the same thing.  Please be consistent with existing terminology!


[major] Related to the definition of "IGP location" and its configuration.  How does the IGP location (and thus the calculation of the interior cost, as above) change when the configuration is done per peer/update groups instead than per peer?  This is another point where operators could benefit from guidance (for the peer/update-group and whole RR cases, of course).


...
275   The configuration of the IGP location is outside of the scope of this
276   document.  The operator may configure it manually, an implementation
277   may automate it based on heuristics, or it can be computed centrally
278   and configured by an external system.

[nit] s/outside of the scope/outside the scope

[major] There are several places later on that talk about the configuration, even making it a requirement for compliance (§6).  I think that you don't mean the configuration itself, but the way in which the configuration is instantiated in the router (which could be considered an implementation detail).  As written, the text is not clear.


280   This solution does not require any change (BGP or IGP) on the
281   clients, as all required changes are limited to the route reflector.

[] This was also claimed before.


283   This solution applies to NLRIs of all address families that can be
284   route reflected.

[] Are there AFs that cannot be reflected?  Just wondering if you really need to say this.


286 3.1.1.  Restriction when BGP next hop is BGP prefix

288   In situations where the BGP next hop is a BGP prefix itself, the IGP
289   metric of a route used for its resolution SHOULD be the final IGP
290   cost to reach such next hop.  Implementations which can not inform
291   BGP of the final IGP metric to a recursive next hop SHOULD treat such
292   paths as least preferred during next hop metric comparison.  However
293   such paths SHOULD still be considered valid for best path selection.

[major] The recursive resolution is already covered in rfc4271 (§5.1.3/§9.1.2.1).  Why isn't that enough?

There seems to be a difference: if an implementation "can not inform BGP of the final IGP metric to a recursive next hop...SHOULD still be considered valid for best path selection."  rfc4271 treats these routes as unresolvable.  Do you want to consider unresolvable routes?

Finally, there are a lot of SHOULDs in this paragraph.  Under which conditions is it ok to not perform the actions?  IOW, why are these actions recommended and not required?


295 3.2.  Multiple Best Path Selections

297   BGP Route Reflector as per [RFC4456] runs a single best path
298   selection.  Optimal route reflection may require calculation of
299   multiple best path selections or subsets of best path selection in
300   order to consider different IGP locations or BGP policies for
301   different sets of clients.

[] It hasn't been mentioned before, but the talk about policy made me think about this:   Can a client be present on different sets?  How is that handled in terms of BGP sessions?  Do we need multiple sessions?  Or is add-path required?


303   If the required routing optimization is limited to the IGP cost to
304   the BGP Next-Hop, only step e) as defined [RFC4271] section 9.1.2.2,
305   needs to be duplicated.

[major] I'm not sure if this paragraph is referencing §3.1 (where step e) was just modified), or or you're saying that for each subset (from the last paragraph) only step e) is considered, or something else.  ??


307   If the routing optimization requires the use of different BGP
308   policies for different sets of clients, a larger part of the decision
309   process needs to be duplicated, up to the whole decision process as
310   defined in section 9.1 of [RFC4271].  This is for example the case
311   when there is a need to use different policies to compute different
312   degree of preference during Phase 1.  This is needed for use cases
313   involving traffic engineering or dedicating certain exit points for
314   certain clients.  In the latter case, the user MAY specify and apply
315   a general policy on the route reflector for a set of clients.  For a
316   given set of clients, the policy SHOULD in that case allow the
317   operator to select different candidate exit points for different
318   address families.  Regular path selection, including IGP perspective
319   for a set of clients as per Section 3.1, is then applied to the
320   candidate paths to select the final paths to advertise to the
321   clients.

[] Similar comment as before...   The use of "duplicated" is confusing me.


[major] "the user MAY specify..."  s/MAY/may   It seems to me that you're simply stating a fact (the user can do this), and not specifying an optional behavior.


[major] "...the policy SHOULD in that case allow the operator to select different candidate exit points for different address families."  There's no interoperable action that "the policy" can execute.  It sounds as if you're recommending that specific knobs ("allow the operator to...") be implemented.  Please reword.


[] You use "IGP perspective" I guess as equivalent to "IGP location" -- is that right?


323 4.  Implementation considerations

325 4.1.  Likely Deployments and need for backup

[nit] Do we really need a sub-section if all the text for §4 is in it?


327   With IGP based optimal route reflection, even though the IGP location
328   could be specified on a per route reflector basis or per peer/update
329   group basis or per peer basis, in reality, it's most likely to be
330   specified per peer/update group basis.  All clients with the same or
331   similar IGP location can be grouped into the same peer/update group.
332   An IGP location is then specified for the peer/update group.  The
333   location is usually specified as the location of one of the clients
334   from the peer group or an ABR to the area where clients are located.
335   Also, one or more backup locations SHOULD be allowed to be specified
336   for redundancy.  Implementations may wish to take advantage of peer
337   group mechanisms in order to provide for better scalability of
338   optimal route reflector client groups with similar properties.

[major] "IGP based optimal route reflection"

This is the first time you use "IGP based optimal route reflection"; I peeked forward and see that §5 also mentions "policy based optimal route reflection".  But you didn't define them anywhere -- in fact, the description before now focuses on the IGP location, which makes me think about "IGP based".

I could guess that the "policy based" version is related to §3.2, but (1) no one should have to guess (!), and (2) the end of that section says that "IGP perspective...is then applied", making it also "IGP based".  ??

Please either define these types of ORR earlier in the text, or (better yet) don't use the terms.  Instead, and given that the names are used just a couple of times, change "policy based" to "the case where a policy is applied"...


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

(2) If there were "backup locations", how would they be used?


[minor] This is the only time that "optimal route reflector client groups" is used.  I had been assuming that a group of clients would correspond to a specific peer/update group (as mentioned many times before).  Is there a difference between a "client group" and grouping clients to correspond to a peer/update group?


[] "for better scalability of optimal route reflector client groups"  What exactly does this mean?  I asked before about references/definitions for peer/update groups; this point may be related.


...
373 6.  Advantages and Deployment Considerations

375   The solutions described provide a model for integrating the client
376   perspective into the best path computation for route reflectors.
377   More specifically, the choice of BGP path factors in either the IGP
378   cost between the client and the nexthop (rather than the IGP cost
379   from the route reflector to the nexthop) or other user configured
380   policies.

[] "solutions"?   I only see one, where the "second" one simply adds policy, which is a pervasive tool in BGP.


382   The achievement of optimal routing relies upon all route reflectors
383   learning all paths that are eligible for consideration.  In order to
384   satisfy this requirement, path diversity enhancing mechanisms such as
385   BGP add-path [RFC7911] may need to be deployed between route
386   reflectors.

[mayor] "path diversity enhancing mechanisms...may need to be deployed between route reflectors"  Given that this is the Deployment Considerations section, please provide guidance on when these mechanisms are needed, and when they're not.


[minor] "path diversity enhancing mechanisms such as BGP add-path [RFC7911]"  Just out of curiosity, what other mechanisms are you thinking of?  Are there deployment considerations, when using ORR, to prefer one?


388   Implementations considered compliant with this document allow the
389   configuration of a logical location from which the best path will be
390   computed, on the basis of either a peer, a peer group, or an entire
391   routing instance.

[] I guess that "logical location" is another name for IGP location...


[major] §3.1 says that the "configuration of the IGP location is outside of the scope of this document".  If that is true, then the configuration cannot be a consideration for compliance.

A better wording for compliance would be: "An implementation MUST allow the configuration..."


393   These solutions can be deployed in traditional hop-by-hop forwarding
394   networks as well as in end-to-end tunneled environments.  In networks
395   where there are multiple route reflectors and hop-by-hop forwarding
396   without encapsulation, such optimizations SHOULD be enabled in a
397   consistent way on all route reflectors.  Otherwise, clients may
398   receive an inconsistent view of the network, in turn leading to
399   intra-domain forwarding loops.

[major] "optimizations SHOULD be enabled in a consistent way on all route reflectors"

Is "a consistent way" different than "on all"?   s/.../optimizations SHOULD be enabled on all route reflectors

When is it ok for all RRs not to be enabled with the optimizations?  IOW, why is it recommended and not required?  Avoiding "intra-domain forwarding loops" sounds like a good reason to require it.


...
406   As per above, these approaches reduce the amount of state which needs
407   to be pushed to the edge of the network in order to perform hot
408   potato routing.  The memory and CPU resources required at the edge of
409   the network to provide hot potato routing using these approaches is
410   lower than what would be required to achieve the same level of
411   optimality by pushing and retaining all available paths (potentially
412   10s) per each prefix at the edge.

[] This paragraph sounds very speculative and doesn't seem necessary.  In line with §5.


414   The solutions above allow for a fast and safe transition to a BGP
415   control plane using centralized route reflection, without
416   compromising an operator's closest exit operational principle.  This
417   enables edge-to-edge LSP/IP encapsulation for traffic to IPv4 and
418   IPv6 prefixes.

[] "allow for a fast and safe transition"  Besides this statement sounding like a marketing brochure, if you're going to talk about transition, please talk about it in detail.  Please take a look at §2/rfc5706 and include details about the transition and how it is "fast and safe".


420   Regarding Best Path Selection from a different IGP location, it
421   should be self evident that this solution does not interfere with
422   policies enforced above IGP tie-breaking in the BGP best path
423   algorithm.

[minor] Don't assume anything is self evident to anyone.

Suggestion (maybe more appropriate in §3.1)>
   The modification specified in Section 3.1 does not impact any previous
   considerations in the BGP Decision Process.


425 7.  Security Considerations

427   Similarly to [RFC4456], this extension to BGP does not change the
428   underlying security issues inherent in the existing IBGP [RFC4456].

[minor] No need to reference rfc4456 twice in the same sentence.


430   It however enables the deployment of base BGP Route Reflection as
431   described in [RFC4456] to be possible using virtual compute
432   environments without any negative consequence on the BGP routing path
433   optimality.

[] I'm not sure how this relates to the specification itself (platform independent), but I'm sure the Security ADs will have a lot of questions about the security of "virtual compute environments" -- and where the details are included in this document.   IOW, that sounds like an unnecessary assertion.


[major] "without any negative consequence"  The new functionality specified in this document is having the RR run the client's selection for them (even specific policy) -- there are risks related to the duplication of the policy, the location of the RRs and the blind trust that the clients need to have.  Or should the clients rerun the policy locally?

This behavior is not necessarily different from normal RR, but the instantiation is different.   It would be very easy for a rogue RR to propagate incorrect routing information to its clients -- specially if policy is offloaded to them.

In the worst case the result would be a sub-optimal route (maybe even worse than what the clients get today), but probably not a "real" security issue.  It is probably a good idea to explain why it is not a security risk.


435   This document does not introduce requirements for any new protection
436   measures, but it also does not relax best operational practices for
437   keeping the IGP network stable or to pace rate of policy based IGP
438   cost to next hops such that it does not have any substantial effect
439   on BGP path changes and their propagation to route reflection
440   clients.

[major] "best operational practices"  Like what?  It would be good to provide (at least) informational references.


[major] "to pace rate of policy based IGP cost to next hops such that it does not have any substantial effect on BGP path changes"   You will have to explain this further because the operation of an IGP is not mentioned anywhere else.

IMHO, there's no need to go into IGP operational details in this document.  There is nothing special/different about the operation of an IGP.


[End of Review]




_______________________________________________
Idr mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/idr
Reply | Threaded
Open this post in threaded view
|

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

bruno.decraene-2
In reply to this post by Alvaro Retana-2
Dear Alvaro,

Many thanks for your review and comments.
Please see inline

> From: Alvaro Retana [mailto:[hidden email]]
> Sent: Thursday, March 18, 2021 8:32 PM
>
> Dear authors:
>
>
> Thank you for your work on this document.  I know that the draft and
> the related ideas have been around for a long time.
>
> I have a couple of significant issues that I want to highlight
> upfront, and many comments inline (see below).  In general, my focus
> is to make sure that the specification of this mechanism is clear, not
> just to the experienced reader, but to the casual one as well.  I
> believe that all the issues should be easy to resolve.
>
> (1) Terminology.  Please use the terminology already defined in
> rfc4271/rfc4456 instead of creating new one by indirection.  My first
> inline comment is about the use of "best path", which is not what
> rfc4271 uses -- there are other occurrences later on.

Agreed. Thanks

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

>
> (3) I don't think that §5 (CPU and Memory Scalability) and Appendix A
> (alternative solutions with limited applicability) should be part of
> this document.  To start, comparisons are never good and the work has
> already been through the WG so there's no need to keep justifying it
> by comparing it to other work.  Both sections contain several claims
> (e.g. "extra cost in terms of CPU", "implemented efficiently",
> "expected to be higher but comparable", "large amount of BGP state and
> churn", "result in tens of paths for each prefix") that don't have
> references, and could be considered subjective because they are
> clearly relative and can change depending on the specific deployment
> and configuration of the network.  I am not saying that the claims are
> false, simply requesting to take these two sections out.

Appendix A removed.
§5 removed but first paragraph moved to deployment consideration sections.
(IMHO, even without references I believe some points are straightforward if not obvious: computing N (N>1) SPF is likely to require more CPU compared to computing 1 SPF.)


>
> Thanks!
>
> Alvaro.
>
>
> [Line numbers from idnits.]
>
> ...
> 17    Abstract
>
> 19       This document defines an extension to BGP route reflectors.  On
> route
> 20       reflectors, BGP route selection is modified in order to choose the
> 21       best path from the standpoint of their clients, rather than from the
> 22       standpoint of the route reflectors.  Multiple types of granularity
> 23       are proposed, from a per client BGP route selection or to a per peer
> 24       group, depending on the scaling and precision requirements on
> route
> 25       selection.  This solution is particularly applicable in deployments
> 26       using centralized route reflectors, where choosing the best route
> 27       based on the route reflector IGP location is suboptimal.  This
> 28       facilitates, for example, best exit point policy (hot potato
> 29       routing).
>
> [major] "best path"  rfc4271 doesn't use the term "best path".  The
> terminology used in this document should, at the very least, match
> what the base spec defines.  Let's please not create new terminology
> by indirection using the "definition of terms" section.

This document is primarily about BGP Route Reflection and RFC 4456 does use the term "best path" hence this document does not create this new term.

That been said I agree with the general statement:
- terminology section has been simplified to only points to RFC4271 & RFC4456 (which are the two technical normative references).
- when a term is used in the text (e.g., 6PE) a reference has been added to first occurrence of the term.
- some of the different terms have been removed in favour of RFC4271 terminology. (e.g. "best path computation", "best path algorithm", "best path selection" have been removed)
- the draft used one occurrence of the term "best route" while 4456 use the term best path. --> changed in the document
- many occurrences of the term "best route" have been removed.

>
> [minor] "proposed"  This document is in line to be come an RFC; we're
> far beyond proposing things.  There are a couple of places later on
> where this same wording is used.  Please change it to specified or at
> least described (the latter probably fits best in this specific case).

Changed to "defined".
(single occurrence. The other occurrence was in Appendix A which is now removed as per your comments)

>
> [nit] s/from a per client BGP route selection or to a per peer
> group/from per client BGP route selection or per peer group

Ack.

> [nit] s/precision requirements on route selection./precision requirements.

Ack.

> [nit] s/route reflector IGP location/route reflector's IGP location

Ack.

> [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"

OLD:
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.
This can be done on a per route reflector basis, per peer/update group basis,
or per peer basis.

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.

>
>
> ...
> 70       1.  Definitions of Terms Used in This Memo  . . . . . . . . . . .   2
> 71       2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
>
> [nit] It would be nice if the Introduction came up before the terminology.

Agreed. Swapped.


> ...
> 91    1.  Definitions of Terms Used in This Memo
>
> [minor] To avoid repeating some terms, it is good practice to indicate
> which other RFCs the reader should be familiar with.  In this case
> rfc4271 and rfc4456 come to mind.

Agreed.
Terminology section has been stripped down by:
- Adding those 2 references " This memo makes use of the terms defined in <xref target="RFC4271"> and <xref target="RFC4456">"
- Adding a reference when the term is first used.

> ...
> 132   2.  Introduction
> ...
> 153      Section 11 of [RFC4456] describes a deployment approach and a set
> of
> 154      constraints which, if satisfied, would result in the deployment of
> 155      route reflection yielding the same results as the IBGP full mesh
> 156      approach.  This deployment approach makes route reflection
> compatible
> 157      with the application of hot potato routing policy.  In accordance
> 158      with these design rules, route reflectors have traditionally often
> 159      been deployed in the forwarding path and carefully placed on the
> POP
> 160      to core boundaries.
>
> [nit] s/have traditionally often/have often
> Redundant...

Ack.

> 162      The evolving model of intra-domain network design has enabled
> 163      deployments of route reflectors outside of the forwarding path.
> 164      Initially this model was only employed for new address families, e.g.
> 165      L3VPNs and L2VPNs, however it has been gradually extended to
> other
> 166      BGP address families including IPv4 and IPv6 Internet using either
> 167      native routing or 6PE.  In such environments, hot potato routing
> 168      policy remains desirable.
>
> [minor] "new address families, e.g. L3VPNs and L2VPNs"  These are not
> the name of the AFs.  Maybe call them new services.
>
>
> [minor] "IPv4 and IPv6 Internet"  The name of the AF is IP/IP6; again,
> you probably mean service/application.

Ack (*2)

> [nit] "native routing or 6PE"  Not 4PE applications?  ;-)   It seems
> to me that you can save some ink by ending the sentence after
> "Internet".

Agreed. Done

> ...
> 194   3.  Modifications to BGP Best Path selection
>
> 196      The core of this solution is the ability for an operator to specify
> 197      the IGP location for which the route reflector should calculate
> 198      routes.  This can be done on a per route reflector basis, per peer/
> 199      update group basis, or per peer basis.  This ability enables the
> 200      route reflector to send to a given set of clients routes with
> 201      shortest distance to the next hops from the position of the selected
> 202      IGP location.  This provides for freedom of route reflector physical
> 203      location, and allows transient or permanent migration of this
> network
> 204      control plane function to an arbitrary location.
>
> [major] "ability for an operator to specify the IGP location for which
> the route reflector should calculate routes.  This can be done on a
> per route reflector basis, per peer/update group basis, or per peer
> basis."
>
> When should an operator choose per RR vs per peer group vs per peer?
> Choice is good, but providing guidance for the deployment is much
> better.  Please consider adding text to §6 about the considerations to
> chose one or the other.

Added in §6:

As discussed in section 11 of <xref target="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. After selecting suitable IGP locations, an operator may let one or multiple route reflectors handle route selection for all of them. The operator may alternatively deploy one or multiple route reflector for each IGP location or create any design in between. This choice may depend on operational model (centralized vs per region), acceptable blast radius in case of failure, acceptable number of IBGP sessions for the mesh between the route reflectors, performance and configuration granularity of the equipment.

>
> [minor] "peer/update group"  Where is this defined?  Is there a
> reference to a non-implementation-specific definition?  Can it be
> called "a group of peers"?  Maybe you also want to include it in the
> definitions in §1.

AFAIK, "peer group" is an implementation specific consideration and is not defined in standards. I would prefer not to define it, so text has been changed to "group of peers" as you suggested.
However there is one sentence where this change is not possible. It's in "Implementation considerations" section " Implementations may wish to take advantage of
peer group mechanisms in order to provide for better scalability of optimal route reflector client groups with similar properties."
I'm seeing two options:
- remove this sentence and leave it to implementations
- keep it unchanged.

Both are fine to me.
As per your comment, I'm inclined to remove it. If you prefer otherwise, please say so.

>
> ...
> 215      o  it can, and usually will, have a different position in the IGP
> 216         topology, and
>
> [] "usually will"   The position in the topology will *always* be different!

Ack.
Changed to:
 o it has a different position in the IGP topology, and

>
> ...
> 222      This document defines, on BGP Route Reflectors [RFC4456], two
> changes
> 223      to the BGP Best Path selection algorithm:
>
> [nit] s/defines, on BGP Route Reflectors/defines, for BGP Route Reflectors

Ack.

> ...
> 235      A route reflector can implement either or both of the modifications
> 236      in order to allow it to choose the best path for its clients that the
> 237      clients themselves would have chosen given the same set of
> candidate
> 238      paths.
>
> [major] Please provide guidance for the operator to consider then one
> or both should be used in their network.

Actually this points belongs to section 3.2.
Cf version -20 https://tools.ietf.org/html/draft-ietf-idr-bgp-optimal-route-reflection-20#section-4
I missed moving it to section 3.2 when the document has been refactored to map changes to RFC4271 as per one of you earlier comment.

I believe this address your above comment as the two previous sections spell out the two (use) cases:
- Decision process change related to the IGP cost (Phase 2 - Tie-breaking), when there is a need to optimize for the IGP cost
- Decision process change related to BGP Policy (Phase 1), when there is a need to have different BGP policy/route preference per set of clients.

Please say so if this does not cover your point.

> 240      A significant advantage of these approaches is that the route
> 241      reflector clients do not need to run new software or hardware.
>
> [nit] s/do not need to run new software or hardware./do not need to be
> modified.

Ack.

> 243   3.1.  Best Path Selection from a different IGP location
>
> 245      In this approach, optimal refers to the decision made during best
> 246      path selection at the IGP metric to BGP next hop comparison
> step.  It
> 247      does not apply to path selection preference based on other policy
> 248      steps and provisions.
>
> [major] Please be specific about what is the "IGP metric to BGP next
> hop comparison step".  There is no step with that name, or even a
> string match in rfc4271.  Later you talk about the step e) tie-breaker
> -- don't wait to be specific!

First sentence changed to
In this approach, optimal refers to the decision where the interior cost of a route is determined during step e) of <xref target="RFC4271" /> section 9.1.2.2 "Breaking Ties (Phase 2)". It does not apply to path selection preference based on other policy steps and provisions.

> ...
> 263         e) Remove from consideration any routes with less-preferred
> 264         interior cost.  The interior cost of a route is determined by
> 265         calculating the metric from the selected IGP location to the
> 266         NEXT_HOP for the route using the shortest IGP path tree rooted
> at
> 267         the selected IGP location.
>
> [major] Note that the specification talks about "interior cost", but
> the descriptions in this document uses "IGP cost" and "IGP metric" to
> refer to the same thing.  Please be consistent with existing
> terminology!

1) From the general standpoint of this document

RFC 4271 refers to interior cost
RFC 4456 refers to IGP metrics.
So change and hence inconsistency seem to predates this document. At this point, I think that we need to live with it as I don't see what path you would propose to follow
- IMHO, nowdays we mostly refers to IGP metric rather than interior cost and since this document is about RR, I think it makes sense to use RFC 4456 as a base.
- In a previous set of comments you asked to cite the part of 4271 which is changed, hence the quote with the term interior cost. Also in the previous comment, when "IGP metric" was used, you commented that this term does not exist in RFC 4271 decision process.

2) From the specific standpoint of the quoted text.
- The two sentences from 4271 already refers to both "interior cost" and "metric".
- I think it makes sense to use the "IGP" term as it's already used in RFC4456 and that this document requires the use of a link state IGP, and refers multiple time to an IGP location.

Bottom line, it's not clear to me what specific change you are asking for. Could you please be more specific/propose change?

> [major] Related to the definition of "IGP location" and its
> configuration.  How does the IGP location (and thus the calculation of
> the interior cost, as above) change when the configuration is done per
> peer/update groups instead than per peer?

No change. The IGP location is a node in the IGP topology.

>  This is another point where
> operators could benefit from guidance (for the peer/update-group and
> whole RR cases, of course).

I'm not seeing anything new compared to RFC 4456.
With RFC 4456, the Route Reflector function runs on a specific node/IGP location. This documents refers to the same IGP location. Routing considerations are the same and detailed in section 11 of RFC 4456.

Let's take a specific example.
- Before BGP ORR: The SP runs a BGP RR on node A.
- With BGP ORR: The SP choose run  function on a more centralized node/a x86 server. The IGP location is the same node A. Nothing change : same node A, same routing., same considerations


> ...
> 275      The configuration of the IGP location is outside of the scope of this
> 276      document.  The operator may configure it manually, an
> implementation
> 277      may automate it based on heuristics, or it can be computed
> centrally
> 278      and configured by an external system.
>
> [nit] s/outside of the scope/outside the scope

Ack.

> [major] There are several places later on that talk about the
> configuration, even making it a requirement for compliance (§6).  I
> think that you don't mean the configuration itself, but the way in
> which the configuration is instantiated in the router (which could be
> considered an implementation detail).  As written, the text is not
> clear.

What about:
OLD: The configuration of the IGP location is outside the scope of this document.
NEW: The way the IGP location is configured is outside the scope of this document.


>
> 280      This solution does not require any change (BGP or IGP) on the
> 281      clients, as all required changes are limited to the route reflector.
>
> [] This was also claimed before.

Correct. Removed

> 283      This solution applies to NLRIs of all address families that can be
> 284      route reflected.
>
> [] Are there AFs that cannot be reflected?  Just wondering if you
> really need to say this.

I can't talk about the future.
In theory, an NLRI may require a direct IBGP session without route reflector. E.g., Segment Routing policies advertised in BGP requires to be directed to a specific source node. Cf Introduction section of draft-ietf-idr-segment-routing-te-policy, text starting with " In some situations, it is undesirable for a controller or BGP egress router to have a BGP session to each policy head-end."

That been said, I don't think that we really need to say this if we assume that this document introduces a change to BGP RR hence only applies when there is a BGP RR.

Text removed.

> 286   3.1.1.  Restriction when BGP next hop is BGP prefix
>
> 288      In situations where the BGP next hop is a BGP prefix itself, the IGP
> 289      metric of a route used for its resolution SHOULD be the final IGP
> 290      cost to reach such next hop.  Implementations which can not inform
> 291      BGP of the final IGP metric to a recursive next hop SHOULD treat
> such
> 292      paths as least preferred during next hop metric
> comparison.  However
> 293      such paths SHOULD still be considered valid for best path selection.
>
> [major] The recursive resolution is already covered in rfc4271
> (§5.1.3/§9.1.2.1).  Why isn't that enough?

Note that this point has been specifically raised by an IDR contributor (implementor IIRC).

In the absent of specific quotes, I think that RFC4271 discusses recursive resolution in the context of next hop resolution (resolvable or not resolvable.)

From a BGP decision process perspective,
- RFC4271 determines the internal cost using the Routing Table. I guess this works if the route to the NH is not learned by IGP
- BGP ORR determines the internal cost using an additional computation from link state IGP. If the BGP Next-Hop is not in the IGP, the text does not specifically cover this.

However, TBH, I'm not finding RFC4271 text crystal on this. It says:
" Remove from consideration any routes with less-preferred
         interior cost.  The interior cost of a route is determined by
         calculating the metric to the NEXT_HOP for the route using the
         Routing Table.  If the NEXT_HOP hop for a route is reachable,
         but no cost can be determined, then this step should be skipped
         (equivalently, consider all routes to have equal costs)."

Text primarily refers to the "interior cost" but then refers to "metric using the Routing Table" (which may be populated by a non-interior protocols, e.g. BGP, in which case this is not any more an interior cost.)

> There seems to be a difference: if an implementation "can not inform
> BGP of the final IGP metric to a recursive next hop...SHOULD still be
> considered valid for best path selection."  rfc4271 treats these
> routes as unresolvable.  Do you want to consider unresolvable routes?

In this specific case, as per above quote my reading is that RFC 4271 calls for skipping this tie-breaking criteria but still uses this route.
BGP ORR equally calls for using this route. The text on the metric to be used is different which may be seen as debatable, but may be a bit late to change.
Then 4271 uses "should" while BGP ORR uses "SHOULD".  "SHOULD" seems more appropriate to le.

> Finally, there are a lot of SHOULDs in this paragraph.  Under which
> conditions is it ok to not perform the actions?  IOW, why are these
> actions recommended and not required?

I tend to agree with you and would find MUST as more appropriate. Except for the first SHOULD where the text proposes a different behaviour under some conditions
That been said, RFC4271 uses "should". (If the NEXT_HOP hop for a route is reachable, but no cost can be determined, then this step should be skipped)
Changing the latest two SHOULD into a MUST, except the WG is expressing disagreement on this.

>
> 295   3.2.  Multiple Best Path Selections
>
> 297      BGP Route Reflector as per [RFC4456] runs a single best path
> 298      selection.  Optimal route reflection may require calculation of
> 299      multiple best path selections or subsets of best path selection in
> 300      order to consider different IGP locations or BGP policies for
> 301      different sets of clients.
>
> [] It hasn't been mentioned before, but the talk about policy made me
> think about this:   Can a client be present on different sets?

No.
Text says " use of different BGP policies for different sets of clients". Is there a need to say that any intersection of sets is null?

> How is
> that handled in terms of BGP sessions?  Do we need multiple sessions?
> Or is add-path required?
>
>
> 303      If the required routing optimization is limited to the IGP cost to
> 304      the BGP Next-Hop, only step e) as defined [RFC4271] section
> 9.1.2.2,
> 305      needs to be duplicated.
>
> [major] I'm not sure if this paragraph is referencing §3.1 (where step
> e) was just modified), or or you're saying that for each subset (from
> the last paragraph) only step e) is considered, or something else.  ??

I'm not sure to see the issue.
Previous sections says:
"BGP Route Reflector as per <xref target="RFC4456" /> runs a single BGP Decision Process. Optimal route reflection may require calculation of multiple BGP Decision Process or subsets of the Decision Process in order to consider different IGP locations or BGP policies for different sets of clients."

The sentence you quoted is a precision on " Optimal route reflection may require calculation of multiple BGP Decision Process or subsets of the Decision Process". It's only a precision that only the part "A" of the Decision Process which is specific per group of clients, need to be run multiple times. The parts of the decision process which are before "A", are hence common to all sets of clients and do not need to be run multiple times.

- In this paragraph, the part "A" of the decision process corresponds to " step e) as defined <xref target="RFC4271" /> section 9.1.2.2"
- In the next paragraph (cf below), the part "A" corresponds to a step much sooner. In the general case, one "Phase 1: Calculation of Degree of Preference" needs to be run per sets of clients. Hence the whole Decision Process needs to be run per sets of clients.

If "duplicated" is confusing (as per you below comment) it could be replaced by "ran multiple times, one per sets of clients"


> 307      If the routing optimization requires the use of different BGP
> 308      policies for different sets of clients, a larger part of the decision
> 309      process needs to be duplicated, up to the whole decision process as
> 310      defined in section 9.1 of [RFC4271].  This is for example the case
> 311      when there is a need to use different policies to compute different
> 312      degree of preference during Phase 1.  This is needed for use cases
> 313      involving traffic engineering or dedicating certain exit points for
> 314      certain clients.  In the latter case, the user MAY specify and apply
> 315      a general policy on the route reflector for a set of clients.  For a
> 316      given set of clients, the policy SHOULD in that case allow the
> 317      operator to select different candidate exit points for different
> 318      address families.  Regular path selection, including IGP perspective
> 319      for a set of clients as per Section 3.1, is then applied to the
> 320      candidate paths to select the final paths to advertise to the
> 321      clients.
>
> [] Similar comment as before...   The use of "duplicated" is confusing me.

Same as above.

> [major] "the user MAY specify..."  s/MAY/may   It seems to me that
> you're simply stating a fact (the user can do this), and not
> specifying an optional behavior.

Correct. Changed.


> [major] "...the policy SHOULD in that case allow the operator to
> select different candidate exit points for different address
> families."  There's no interoperable action that "the policy" can
> execute.  It sounds as if you're recommending that specific knobs
> ("allow the operator to...") be implemented.  Please reword.

"the policy" is the one from RFC 4271 ("applying the policies in the local Policy Information Base (PIB) to the routes stored in its Adj-RIBs-In."). There is no change except that the policy is per set of clients.
I'd propose to remove that sentence.


>
> [] You use "IGP perspective" I guess as equivalent to "IGP location"
> -- is that right?

Yes. Sentence has a reference to the related section of the draft. Doing more/change is needed in the text or what is only a clarification question?
 More generally the IGP perspective during BGP Decision process, i.e.   tie-breaking step e).

>
> 323   4.  Implementation considerations
>
> 325   4.1.  Likely Deployments and need for backup
>
> [nit] Do we really need a sub-section if all the text for §4 is in it?

Agreed. Removed.
I've moved the point related to backup IGP locations to section 3.1 " Route Selection from a different IGP location" as this is the section where IGP computation from a different IGP location is defined. Given this, the other sentences are mostly redundant and hence the section " Implementation considerations" can be removed.

> 327      With IGP based optimal route reflection, even though the IGP
> location
> 328      could be specified on a per route reflector basis or per peer/update
> 329      group basis or per peer basis, in reality, it's most likely to be
> 330      specified per peer/update group basis.  All clients with the same or
> 331      similar IGP location can be grouped into the same peer/update
> group.
> 332      An IGP location is then specified for the peer/update group.  The
> 333      location is usually specified as the location of one of the clients
> 334      from the peer group or an ABR to the area where clients are
> located.
> 335      Also, one or more backup locations SHOULD be allowed to be
> specified
> 336      for redundancy.  Implementations may wish to take advantage of
> peer
> 337      group mechanisms in order to provide for better scalability of
> 338      optimal route reflector client groups with similar properties.
>
> [major] "IGP based optimal route reflection"
>
> This is the first time you use "IGP based optimal route reflection";

Changed to " Route Selection from a different IGP location"

> I
> peeked forward and see that §5 also mentions "policy based optimal
> route reflection".  But you didn't define them anywhere -- in fact,
> the description before now focuses on the IGP location, which makes me
> think about "IGP based".
>
> I could guess that the "policy based" version is related to §3.2, but
> (1) no one should have to guess (!), and (2) the end of that section
> says that "IGP perspective...is then applied", making it also "IGP
> based".  ??
>
> Please either define these types of ORR earlier in the text, or
> (better yet) don't use the terms.  Instead, and given that the names
> are used just a couple of times, change "policy based" to "the case
> where a policy is applied"...

§5 removed as per your request. So discussion on §5 is now moot.

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

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


> [minor] This is the only time that "optimal route reflector client
> groups" is used.  I had been assuming that a group of clients would
> correspond to a specific peer/update group (as mentioned many times
> before).  Is there a difference between a "client group" and grouping
> clients to correspond to a peer/update group?
>
>
> [] "for better scalability of optimal route reflector client groups"
> What exactly does this mean?  I asked before about
> references/definitions for peer/update groups; this point may be
> related.

Yes indeed this point is related. As per your previous comment I removed that sentence which is implementation specific.

> ...
> 373   6.  Advantages and Deployment Considerations
>
> 375      The solutions described provide a model for integrating the client
> 376      perspective into the best path computation for route reflectors
> 377      More specifically, the choice of BGP path factors in either the IGP
> 378      cost between the client and the nexthop (rather than the IGP cost
> 379      from the route reflector to the nexthop) or other user configured
> 380      policies.
>
> [] "solutions"?   I only see one, where the "second" one simply adds
> policy, which is a pervasive tool in BGP.

OK, corrected.
:s/ The solutions described provide /BGP Optimal Route Reflection provides

> 382      The achievement of optimal routing relies upon all route reflectors
> 383      learning all paths that are eligible for consideration.  In order to
> 384      satisfy this requirement, path diversity enhancing mechanisms such
> as
> 385      BGP add-path [RFC7911] may need to be deployed between route
> 386      reflectors.
>
> [mayor] "path diversity enhancing mechanisms...may need to be deployed
> between route reflectors"  Given that this is the Deployment
> Considerations section, please provide guidance on when these
> mechanisms are needed, and when they're not.

In the general case, if (full) optimal routing is needed, path diversity needs to be provided between RR.
One could dig into more details, in particular to consider deflection in case of IP packet routed hop by hop (vs tunnelled). But the term deflection does not seem to be covered by 4456 so this would require quite some digression.
Please find below a suggested change.

> [minor] "path diversity enhancing mechanisms such as BGP add-path
> [RFC7911]"  Just out of curiosity, what other mechanisms are you
> thinking of?

I guess Robert would cite https://tools.ietf.org/html/rfc6774


> Are there deployment considerations, when using ORR, to
> prefer one?

ADD-PATH is more general and "just work".  "Diverse paths" (RFC6774) requires N sessions with N dependent on the topology, number of paths.
I'm not sure what change you may/will have in mind:
- removing "such as"  and mandating add-path is an easy change but could be seen as not 100% correct technically
- I'm not inclined to discuss the relative merits of RFC6774 and RFC7911

I'm not seen as request to add/change text but this may be your next move, so let's avoid one RTT.
I'm applying the below change, assuming that this may ease your still not expressed request for change:
OLD:
The achievement of optimal routing relies upon all route reflectors learning all paths
that are eligible for consideration. In order to satisfy this requirement,
path diversity enhancing mechanisms such as
BGP add-path <xref target="RFC7911" /> may need to be deployed between route
reflectors.

NEW:
The achievement of optimal routing relies upon all route reflectors learning all paths
that are eligible for consideration. In order to satisfy this requirement,
BGP add-path <xref target="RFC7911" /> needs to be deployed between route
reflectors.


Any comment is obviously welcome.

>
> 388      Implementations considered compliant with this document allow
> the
> 389      configuration of a logical location from which the best path will be
> 390      computed, on the basis of either a peer, a peer group, or an entire
> 391      routing instance.
>
> [] I guess that "logical location" is another name for IGP location...

Yes.
That point was duplicated and hence that sentence removed.
The other sentence uses the term IGP location:

"The choice of specific granularity (route reflector,
group of peer, or peer) is
configured by the network operator. An implementation
is considered compliant with this document if it supports
at least one listed grouping of IGP location."

>
> [major] §3.1 says that the "configuration of the IGP location is
> outside of the scope of this document".  If that is true, then the
> configuration cannot be a consideration for compliance.

Ok. Reworded as above (with no reference to configuration)

> A better wording for compliance would be: "An implementation MUST
> allow the configuration..."
>
>
> 393      These solutions can be deployed in traditional hop-by-hop
> forwarding
> 394      networks as well as in end-to-end tunneled environments.  In
> networks
> 395      where there are multiple route reflectors and hop-by-hop
> forwarding
> 396      without encapsulation, such optimizations SHOULD be enabled in a
> 397      consistent way on all route reflectors.  Otherwise, clients may
> 398      receive an inconsistent view of the network, in turn leading to
> 399      intra-domain forwarding loops.
>
> [major] "optimizations SHOULD be enabled in a consistent way on all
> route reflectors"
>
> Is "a consistent way" different than "on all"?   s/.../optimizations
> SHOULD be enabled on all route reflectors

Yes.

> When is it ok for all RRs not to be enabled with the optimizations?
> IOW, why is it recommended and not required?  Avoiding "intra-domain
> forwarding loops" sounds like a good reason to require it.

It's ok to only enable the optimization where this is required.
e.g. in state/region 1 but not in state/region 2. For example because of the IGP topology, BGP interconnections or customers' requirements specific to region 1.
Just like with RFC 4456, one could use BGP RR only in one POP, and BGP RR + local IBGP in another POP.
To me this is not really specific to BGP ORR but already exists in RFC 4456. Cf §11:
"To prevent routing loops and maintain consistent routing view, it is
   essential that the network topology be carefully considered in
   designing a route reflection topology.  In general, the route
   reflection topology should be congruent with the network topology
   when there exist multiple paths for a prefix."

> ...
> 406      As per above, these approaches reduce the amount of state which
> needs
> 407      to be pushed to the edge of the network in order to perform hot
> 408      potato routing.  The memory and CPU resources required at the
> edge of
> 409      the network to provide hot potato routing using these approaches
> is
> 410      lower than what would be required to achieve the same level of
> 411      optimality by pushing and retaining all available paths (potentially
> 412      10s) per each prefix at the edge.
>
> [] This paragraph sounds very speculative and doesn't seem necessary.
> In line with §5.

Sentence was meant to say "Compared to full deployment of ADD-PATH...." .
With this, this does not sound speculative to me as ADD-PATH advertises more paths hence more states.

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.

This sentence is specifically in the deployment consideration section. Up to you. I can live with both. So far, I've tried to accommodate both points:

OLD:
As per above, these approaches reduce the amount of state which needs
   to be pushed to the edge of the network in order to perform hot
   potato routing.  The memory and CPU resources required at the edge of
   the network to provide hot potato routing using these approaches is
   lower than what would be required to achieve the same level of
   optimality by pushing and retaining all available paths (potentially
   10s) per each prefix at the edge.

NEW:
As per above, compared with a deployment of ADD-PATH on all those, BGP ORR reduces the amount of state which needs to
be pushed to the edge of the network in order to perform hot potato routing.

>
> 414      The solutions above allow for a fast and safe transition to a BGP
> 415      control plane using centralized route reflection, without
> 416      compromising an operator's closest exit operational principle.  This
> 417      enables edge-to-edge LSP/IP encapsulation for traffic to IPv4 and
> 418      IPv6 prefixes.
>
> [] "allow for a fast and safe transition"  Besides this statement
> sounding like a marketing brochure, if you're going to talk about
> transition, please talk about it in detail.  Please take a look at
> §2/rfc5706 and include details about the transition and how it is
> "fast and safe".

Agreed on the marketing sounding.
The issues with transitions is that there are many flavours depending on your starting and end point, so transitions may be a draft in itself.
The statement was meant to cover the ability for a network operator to move the BGP RR function to a different location, which may be more centralized or out of the packet path. BGP ORR allows this by moving the BGP RR function elsewhere with no change/considerations on routing by configuring the BGP ORR IGP location of the existing/old BGP RR. That sounds much easier to me compared to having to study the impact on routing when moving the location of the BGP RR.
Proposal

OLD:
The solutions above allow for a fast and safe transition to a BGP control
plane using centralized route reflection, without compromising an
operator's closest exit operational principle.

NEW:
BGP ORR allows to move an existing BGP RR to a different node (e.g. centralized or off packet path) with no impact on routing paths.


> 420      Regarding Best Path Selection from a different IGP location, it
> 421      should be self evident that this solution does not interfere with
> 422      policies enforced above IGP tie-breaking in the BGP best path
> 423      algorithm.
>
> [minor] Don't assume anything is self evident to anyone.
>
> Suggestion (maybe more appropriate in §3.1)>
>    The modification specified in Section 3.1 does not impact any previous
>    considerations in the BGP Decision Process.

Thanks for the suggestion.
Changed to:
Modifying the IGP location of BGP ORR does not interfere with policies enforced before IGP tie-breaking (step e) in the BGP Decision Process Route.


The text was meant for network operation so is located in the deployment consideration section.
>
> 425   7.  Security Considerations
>
> 427      Similarly to [RFC4456], this extension to BGP does not change the
> 428      underlying security issues inherent in the existing IBGP [RFC4456].
>
> [minor] No need to reference rfc4456 twice in the same sentence.

Ack.


> 430      It however enables the deployment of base BGP Route Reflection
> as
> 431      described in [RFC4456] to be possible using virtual compute
> 432      environments without any negative consequence on the BGP
> routing path
> 433      optimality.
>
> [] I'm not sure how this relates to the specification itself (platform
> independent), but I'm sure the Security ADs will have a lot of
> questions about the security of "virtual compute environments" -- and
> where the details are included in this document.   IOW, that sounds
> like an unnecessary assertion.

OK removed.
(Plus, the use of virtual compute environment is orthogonal to ORR as a regular BGP RR may be equally run on a virtual compute. BGP ORR allows for the easier move of the BGP RR function on different IGP location, typically more centralized but not necessarily as I have opposition use case in mind.)

>
> [major] "without any negative consequence"  The new functionality
> specified in this document is having the RR run the client's selection
> for them (even specific policy) -- there are risks related to the
> duplication of the policy, the location of the RRs and the blind trust
> that the clients need to have.  Or should the clients rerun the policy
> locally?

Regarding the IGP location, BGP RR already runs this policy on behalf of the client. No change.
Regarding BGP policies, BGP RR would also runs the policy as the RR only distributes a single path which is post policy. BGP ORR allows for a finer grained policy: per group of clients rather than per RR. I'm not seen a fundamental change.

> This behavior is not necessarily different from normal RR,

Agreed.

> but the
> instantiation is different.

In the BGP ORR we are talking about IBGP policies, not EBGP policies. E.g. clients 1 to 5 are restricted to existing points ASBR A & B in POP NYC. That policy would typically be on the BGP RR, or implemented with additional direct IBGP sessions to the allowed ASBR.
In the use cases I have in mind, the policy would not be on the client since it would be a burden to bring all ASBR/path to the client for the client to choose for itself.


>  It would be very easy for a rogue RR to
> propagate incorrect routing information to its clients -- specially if
> policy is offloaded to them.

I'd say that your statement is true regardless of policy, but definitely regardless of BGP ORR as in the absence of BGP ORR a regular BGP RR would equally apply the policy. The different is that the network operator would need 1 RR (2 for redundancy) per policy, which may be more expensive and less convenient.

> In the worst case the result would be a sub-optimal route (maybe even
> worse than what the clients get today), but probably not a "real"
> security issue.  It is probably a good idea to explain why it is not a
> security risk.

I don't see why this is specific to BGP ORR. Cf above: a rogue non-ORR BGP RR could do the same.


> 435      This document does not introduce requirements for any new
> protection
> 436      measures, but it also does not relax best operational practices for
> 437      keeping the IGP network stable or to pace rate of policy based IGP
> 438      cost to next hops such that it does not have any substantial effect
> 439      on BGP path changes and their propagation to route reflection
> 440      clients.
>
> [major] "best operational practices"  Like what?  It would be good to
> provide (at least) informational references.

Likes the ones applicable to BGP routes and BGP RR.
I'm not aware that the IETF have documented those.

As we seem to agree that there is no change introduced by this document, I'm proposing the following edit:

OLD:
This document does not introduce requirements for any new
protection measures, but it also does not relax best operational
practices for keeping the IGP network stable or to pace rate of policy
based IGP cost to next hops such that it does not have any substantial
effect on BGP path changes and their propagation to route reflection
clients.

NEW:
This document does not introduce requirements for any new
protection measures.


>
> [major] "to pace rate of policy based IGP cost to next hops such that
> it does not have any substantial effect on BGP path changes"   You
> will have to explain this further because the operation of an IGP is
> not mentioned anywhere else.
>
> IMHO, there's no need to go into IGP operational details in this
> document.  There is nothing special/different about the operation of
> an IGP.

Agreed. Removed as per above.



> [End of Review]
Ack. FYI the email I received stopped at draft line 376

Thank you for your review and comments

--Bruno on behalf of all authors

_________________________________________________________________________________________________________________________

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.

_______________________________________________
Idr mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/idr
Reply | Threaded
Open this post in threaded view
|

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

Alvaro Retana-2
On May 12, 2021 at 5:02:25 AM, [hidden email] 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!

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


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

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


> > (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.
Can you please add a sentence or two about this?


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



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


[EoR]

_______________________________________________
Idr mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/idr
Reply | Threaded
Open this post in threaded view
|

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

Robert Raszuk-3
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.


_______________________________________________
Idr mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/idr
Reply | Threaded
Open this post in threaded view
|

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

Gyan Mishra
In reply to this post by Alvaro Retana-2
Dear Authors 

I have a few comments on this draft.

This is a historical well known issue exists where a RR will compute the best path based on IGP topology metric least cost to the exit point and will advertise those paths based on the topological position of the RR to the exit point.  The major issue is the best path reflected by the RR should be based on the Clients IGP shortest path to exit point and the RRs shortest path.  

A workaround to this issue is RFC 7911 add paths where all paths are advertised to all Client PEs as well as all RR as mentioned in section 4 deployment considerations.  What is missing in the Section 4 verbiage is the add path to both RRs and all clients so advertisement of all paths are advertised  to all clients as well as RR.  So to  resolve the issue with the RR making the best path decision the RR must have add paths send / receive MP Reach capability enabled to all clients and must select and advertise all paths to all clients so that each client can now make the best path decision based on its best path lowest IGP metric to the exit point.   

Using RFC 7911 add paths to all clients the hot potato issue is resolved.

The caveat with add paths is if you have many RRs and many exist points you end up with many paths per prefix in the BGP RIB.  

With modern high end routers these days this does not impact scalability issues that I am aware of.

With this draft it seems the goal is to only advertise the pertinent paths based on the client IGP location rooted topological path to the exit point and not advertise all paths.  This would cut down on the number of paths advertised by the RR so all paths are not flooded to the clients as the current solution today to the hot potato issue.

Am I reading this correctly?

Kind Regards 

Gyan 

On Thu, Mar 18, 2021 at 3:32 PM Alvaro Retana <[hidden email]> wrote:
Dear authors:


Thank you for your work on this document.  I know that the draft and
the related ideas have been around for a long time.

I have a couple of significant issues that I want to highlight
upfront, and many comments inline (see below).  In general, my focus
is to make sure that the specification of this mechanism is clear, not
just to the experienced reader, but to the casual one as well.  I
believe that all the issues should be easy to resolve.

(1) Terminology.  Please use the terminology already defined in
rfc4271/rfc4456 instead of creating new one by indirection.  My first
inline comment is about the use of "best path", which is not what
rfc4271 uses -- there are other occurrences later on.

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

(3) I don't think that §5 (CPU and Memory Scalability) and Appendix A
(alternative solutions with limited applicability) should be part of
this document.  To start, comparisons are never good and the work has
already been through the WG so there's no need to keep justifying it
by comparing it to other work.  Both sections contain several claims
(e.g. "extra cost in terms of CPU", "implemented efficiently",
"expected to be higher but comparable", "large amount of BGP state and
churn", "result in tens of paths for each prefix") that don't have
references, and could be considered subjective because they are
clearly relative and can change depending on the specific deployment
and configuration of the network.  I am not saying that the claims are
false, simply requesting to take these two sections out.


Thanks!

Alvaro.


[Line numbers from idnits.]

...
17      Abstract

19         This document defines an extension to BGP route reflectors.  On route
20         reflectors, BGP route selection is modified in order to choose the
21         best path from the standpoint of their clients, rather than from the
22         standpoint of the route reflectors.  Multiple types of granularity
23         are proposed, from a per client BGP route selection or to a per peer
24         group, depending on the scaling and precision requirements on route
25         selection.  This solution is particularly applicable in deployments
26         using centralized route reflectors, where choosing the best route
27         based on the route reflector IGP location is suboptimal.  This
28         facilitates, for example, best exit point policy (hot potato
29         routing).

[major] "best path"  rfc4271 doesn't use the term "best path".  The
terminology used in this document should, at the very least, match
what the base spec defines.  Let's please not create new terminology
by indirection using the "definition of terms" section.


[minor] "proposed"  This document is in line to be come an RFC; we're
far beyond proposing things.  There are a couple of places later on
where this same wording is used.  Please change it to specified or at
least described (the latter probably fits best in this specific case).


[nit] s/from a per client BGP route selection or to a per peer
group/from per client BGP route selection or per peer group


[nit] s/precision requirements on route selection./precision requirements.


[nit] s/route reflector IGP location/route reflector's IGP location


[major] "IGP location"  Before I forget -- please clearly define (not
in the Abstract of course) what an "IGP location" is.


...
70         1.  Definitions of Terms Used in This Memo  . . . . . . . . . . .   2
71         2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3

[nit] It would be nice if the Introduction came up before the terminology.


...
91      1.  Definitions of Terms Used in This Memo

[minor] To avoid repeating some terms, it is good practice to indicate
which other RFCs the reader should be familiar with.  In this case
rfc4271 and rfc4456 come to mind.


...
132     2.  Introduction
...
153        Section 11 of [RFC4456] describes a deployment approach and a set of
154        constraints which, if satisfied, would result in the deployment of
155        route reflection yielding the same results as the IBGP full mesh
156        approach.  This deployment approach makes route reflection compatible
157        with the application of hot potato routing policy.  In accordance
158        with these design rules, route reflectors have traditionally often
159        been deployed in the forwarding path and carefully placed on the POP
160        to core boundaries.

[nit] s/have traditionally often/have often
Redundant...


162        The evolving model of intra-domain network design has enabled
163        deployments of route reflectors outside of the forwarding path.
164        Initially this model was only employed for new address families, e.g.
165        L3VPNs and L2VPNs, however it has been gradually extended to other
166        BGP address families including IPv4 and IPv6 Internet using either
167        native routing or 6PE.  In such environments, hot potato routing
168        policy remains desirable.

[minor] "new address families, e.g. L3VPNs and L2VPNs"  These are not
the name of the AFs.  Maybe call them new services.


[minor] "IPv4 and IPv6 Internet"  The name of the AF is IP/IP6; again,
you probably mean service/application.


[nit] "native routing or 6PE"  Not 4PE applications?  ;-)   It seems
to me that you can save some ink by ending the sentence after
"Internet".


...
194     3.  Modifications to BGP Best Path selection

196        The core of this solution is the ability for an operator to specify
197        the IGP location for which the route reflector should calculate
198        routes.  This can be done on a per route reflector basis, per peer/
199        update group basis, or per peer basis.  This ability enables the
200        route reflector to send to a given set of clients routes with
201        shortest distance to the next hops from the position of the selected
202        IGP location.  This provides for freedom of route reflector physical
203        location, and allows transient or permanent migration of this network
204        control plane function to an arbitrary location.

[major] "ability for an operator to specify the IGP location for which
the route reflector should calculate routes.  This can be done on a
per route reflector basis, per peer/update group basis, or per peer
basis."

When should an operator choose per RR vs per peer group vs per peer?
Choice is good, but providing guidance for the deployment is much
better.  Please consider adding text to §6 about the considerations to
chose one or the other.


[minor] "peer/update group"  Where is this defined?  Is there a
reference to a non-implementation-specific definition?  Can it be
called "a group of peers"?  Maybe you also want to include it in the
definitions in §1.


...
215        o  it can, and usually will, have a different position in the IGP
216           topology, and

[] "usually will"   The position in the topology will *always* be different!


...
222        This document defines, on BGP Route Reflectors [RFC4456], two changes
223        to the BGP Best Path selection algorithm:

[nit] s/defines, on BGP Route Reflectors/defines, for BGP Route Reflectors


...
235        A route reflector can implement either or both of the modifications
236        in order to allow it to choose the best path for its clients that the
237        clients themselves would have chosen given the same set of candidate
238        paths.

[major] Please provide guidance for the operator to consider then one
or both should be used in their network.


240        A significant advantage of these approaches is that the route
241        reflector clients do not need to run new software or hardware.

[nit] s/do not need to run new software or hardware./do not need to be modified.


243     3.1.  Best Path Selection from a different IGP location

245        In this approach, optimal refers to the decision made during best
246        path selection at the IGP metric to BGP next hop comparison step.  It
247        does not apply to path selection preference based on other policy
248        steps and provisions.

[major] Please be specific about what is the "IGP metric to BGP next
hop comparison step".  There is no step with that name, or even a
string match in rfc4271.  Later you talk about the step e) tie-breaker
-- don't wait to be specific!


...
263           e) Remove from consideration any routes with less-preferred
264           interior cost.  The interior cost of a route is determined by
265           calculating the metric from the selected IGP location to the
266           NEXT_HOP for the route using the shortest IGP path tree rooted at
267           the selected IGP location.

[major] Note that the specification talks about "interior cost", but
the descriptions in this document uses "IGP cost" and "IGP metric" to
refer to the same thing.  Please be consistent with existing
terminology!


[major] Related to the definition of "IGP location" and its
configuration.  How does the IGP location (and thus the calculation of
the interior cost, as above) change when the configuration is done per
peer/update groups instead than per peer?  This is another point where
operators could benefit from guidance (for the peer/update-group and
whole RR cases, of course).


...
275        The configuration of the IGP location is outside of the scope of this
276        document.  The operator may configure it manually, an implementation
277        may automate it based on heuristics, or it can be computed centrally
278        and configured by an external system.

[nit] s/outside of the scope/outside the scope

[major] There are several places later on that talk about the
configuration, even making it a requirement for compliance (§6).  I
think that you don't mean the configuration itself, but the way in
which the configuration is instantiated in the router (which could be
considered an implementation detail).  As written, the text is not
clear.


280        This solution does not require any change (BGP or IGP) on the
281        clients, as all required changes are limited to the route reflector.

[] This was also claimed before.


283        This solution applies to NLRIs of all address families that can be
284        route reflected.

[] Are there AFs that cannot be reflected?  Just wondering if you
really need to say this.


286     3.1.1.  Restriction when BGP next hop is BGP prefix

288        In situations where the BGP next hop is a BGP prefix itself, the IGP
289        metric of a route used for its resolution SHOULD be the final IGP
290        cost to reach such next hop.  Implementations which can not inform
291        BGP of the final IGP metric to a recursive next hop SHOULD treat such
292        paths as least preferred during next hop metric comparison.  However
293        such paths SHOULD still be considered valid for best path selection.

[major] The recursive resolution is already covered in rfc4271
(§5.1.3/§9.1.2.1).  Why isn't that enough?

There seems to be a difference: if an implementation "can not inform
BGP of the final IGP metric to a recursive next hop...SHOULD still be
considered valid for best path selection."  rfc4271 treats these
routes as unresolvable.  Do you want to consider unresolvable routes?

Finally, there are a lot of SHOULDs in this paragraph.  Under which
conditions is it ok to not perform the actions?  IOW, why are these
actions recommended and not required?


295     3.2.  Multiple Best Path Selections

297        BGP Route Reflector as per [RFC4456] runs a single best path
298        selection.  Optimal route reflection may require calculation of
299        multiple best path selections or subsets of best path selection in
300        order to consider different IGP locations or BGP policies for
301        different sets of clients.

[] It hasn't been mentioned before, but the talk about policy made me
think about this:   Can a client be present on different sets?  How is
that handled in terms of BGP sessions?  Do we need multiple sessions?
Or is add-path required?


303        If the required routing optimization is limited to the IGP cost to
304        the BGP Next-Hop, only step e) as defined [RFC4271] section 9.1.2.2,
305        needs to be duplicated.

[major] I'm not sure if this paragraph is referencing §3.1 (where step
e) was just modified), or or you're saying that for each subset (from
the last paragraph) only step e) is considered, or something else.  ??


307        If the routing optimization requires the use of different BGP
308        policies for different sets of clients, a larger part of the decision
309        process needs to be duplicated, up to the whole decision process as
310        defined in section 9.1 of [RFC4271].  This is for example the case
311        when there is a need to use different policies to compute different
312        degree of preference during Phase 1.  This is needed for use cases
313        involving traffic engineering or dedicating certain exit points for
314        certain clients.  In the latter case, the user MAY specify and apply
315        a general policy on the route reflector for a set of clients.  For a
316        given set of clients, the policy SHOULD in that case allow the
317        operator to select different candidate exit points for different
318        address families.  Regular path selection, including IGP perspective
319        for a set of clients as per Section 3.1, is then applied to the
320        candidate paths to select the final paths to advertise to the
321        clients.

[] Similar comment as before...   The use of "duplicated" is confusing me.


[major] "the user MAY specify..."  s/MAY/may   It seems to me that
you're simply stating a fact (the user can do this), and not
specifying an optional behavior.


[major] "...the policy SHOULD in that case allow the operator to
select different candidate exit points for different address
families."  There's no interoperable action that "the policy" can
execute.  It sounds as if you're recommending that specific knobs
("allow the operator to...") be implemented.  Please reword.


[] You use "IGP perspective" I guess as equivalent to "IGP location"
-- is that right?


323     4.  Implementation considerations

325     4.1.  Likely Deployments and need for backup

[nit] Do we really need a sub-section if all the text for §4 is in it?


327        With IGP based optimal route reflection, even though the IGP location
328        could be specified on a per route reflector basis or per peer/update
329        group basis or per peer basis, in reality, it's most likely to be
330        specified per peer/update group basis.  All clients with the same or
331        similar IGP location can be grouped into the same peer/update group.
332        An IGP location is then specified for the peer/update group.  The
333        location is usually specified as the location of one of the clients
334        from the peer group or an ABR to the area where clients are located.
335        Also, one or more backup locations SHOULD be allowed to be specified
336        for redundancy.  Implementations may wish to take advantage of peer
337        group mechanisms in order to provide for better scalability of
338        optimal route reflector client groups with similar properties.

[major] "IGP based optimal route reflection"

This is the first time you use "IGP based optimal route reflection"; I
peeked forward and see that §5 also mentions "policy based optimal
route reflection".  But you didn't define them anywhere -- in fact,
the description before now focuses on the IGP location, which makes me
think about "IGP based".

I could guess that the "policy based" version is related to §3.2, but
(1) no one should have to guess (!), and (2) the end of that section
says that "IGP perspective...is then applied", making it also "IGP
based".  ??

Please either define these types of ORR earlier in the text, or
(better yet) don't use the terms.  Instead, and given that the names
are used just a couple of times, change "policy based" to "the case
where a policy is applied"...


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

(2) If there were "backup locations", how would they be used?


[minor] This is the only time that "optimal route reflector client
groups" is used.  I had been assuming that a group of clients would
correspond to a specific peer/update group (as mentioned many times
before).  Is there a difference between a "client group" and grouping
clients to correspond to a peer/update group?


[] "for better scalability of optimal route reflector client groups"
What exactly does this mean?  I asked before about
references/definitions for peer/update groups; this point may be
related.


...
373     6.  Advantages and Deployment Considerations

375        The solutions described provide a model for integrating the client
376        perspective into the best path computation for route reflectors.
377        More specifically, the choice of BGP path factors in either the IGP
378        cost between the client and the nexthop (rather than the IGP cost
379        from the route reflector to the nexthop) or other user configured
380        policies.

[] "solutions"?   I only see one, where the "second" one simply adds
policy, which is a pervasive tool in BGP.


382        The achievement of optimal routing relies upon all route reflectors
383        learning all paths that are eligible for consideration.  In order to
384        satisfy this requirement, path diversity enhancing mechanisms such as
385        BGP add-path [RFC7911] may need to be deployed between route
386        reflectors.

[mayor] "path diversity enhancing mechanisms...may need to be deployed
between route reflectors"  Given that this is the Deployment
Considerations section, please provide guidance on when these
mechanisms are needed, and when they're not.


[minor] "path diversity enhancing mechanisms such as BGP add-path
[RFC7911]"  Just out of curiosity, what other mechanisms are you
thinking of?  Are there deployment considerations, when using ORR, to
prefer one?


388        Implementations considered compliant with this document allow the
389        configuration of a logical location from which the best path will be
390        computed, on the basis of either a peer, a peer group, or an entire
391        routing instance.

[] I guess that "logical location" is another name for IGP location...


[major] §3.1 says that the "configuration of the IGP location is
outside of the scope of this document".  If that is true, then the
configuration cannot be a consideration for compliance.

A better wording for compliance would be: "An implementation MUST
allow the configuration..."


393        These solutions can be deployed in traditional hop-by-hop forwarding
394        networks as well as in end-to-end tunneled environments.  In networks
395        where there are multiple route reflectors and hop-by-hop forwarding
396        without encapsulation, such optimizations SHOULD be enabled in a
397        consistent way on all route reflectors.  Otherwise, clients may
398        receive an inconsistent view of the network, in turn leading to
399        intra-domain forwarding loops.

[major] "optimizations SHOULD be enabled in a consistent way on all
route reflectors"

Is "a consistent way" different than "on all"?   s/.../optimizations
SHOULD be enabled on all route reflectors

When is it ok for all RRs not to be enabled with the optimizations?
IOW, why is it recommended and not required?  Avoiding "intra-domain
forwarding loops" sounds like a good reason to require it.


...
406        As per above, these approaches reduce the amount of state which needs
407        to be pushed to the edge of the network in order to perform hot
408        potato routing.  The memory and CPU resources required at the edge of
409        the network to provide hot potato routing using these approaches is
410        lower than what would be required to achieve the same level of
411        optimality by pushing and retaining all available paths (potentially
412        10s) per each prefix at the edge.

[] This paragraph sounds very speculative and doesn't seem necessary.
In line with §5.


414        The solutions above allow for a fast and safe transition to a BGP
415        control plane using centralized route reflection, without
416        compromising an operator's closest exit operational principle.  This
417        enables edge-to-edge LSP/IP encapsulation for traffic to IPv4 and
418        IPv6 prefixes.

[] "allow for a fast and safe transition"  Besides this statement
sounding like a marketing brochure, if you're going to talk about
transition, please talk about it in detail.  Please take a look at
§2/rfc5706 and include details about the transition and how it is
"fast and safe".


420        Regarding Best Path Selection from a different IGP location, it
421        should be self evident that this solution does not interfere with
422        policies enforced above IGP tie-breaking in the BGP best path
423        algorithm.

[minor] Don't assume anything is self evident to anyone.

Suggestion (maybe more appropriate in §3.1)>
   The modification specified in Section 3.1 does not impact any previous
   considerations in the BGP Decision Process.


425     7.  Security Considerations

427        Similarly to [RFC4456], this extension to BGP does not change the
428        underlying security issues inherent in the existing IBGP [RFC4456].

[minor] No need to reference rfc4456 twice in the same sentence.


430        It however enables the deployment of base BGP Route Reflection as
431        described in [RFC4456] to be possible using virtual compute
432        environments without any negative consequence on the BGP routing path
433        optimality.

[] I'm not sure how this relates to the specification itself (platform
independent), but I'm sure the Security ADs will have a lot of
questions about the security of "virtual compute environments" -- and
where the details are included in this document.   IOW, that sounds
like an unnecessary assertion.


[major] "without any negative consequence"  The new functionality
specified in this document is having the RR run the client's selection
for them (even specific policy) -- there are risks related to the
duplication of the policy, the location of the RRs and the blind trust
that the clients need to have.  Or should the clients rerun the policy
locally?

This behavior is not necessarily different from normal RR, but the
instantiation is different.   It would be very easy for a rogue RR to
propagate incorrect routing information to its clients -- specially if
policy is offloaded to them.

In the worst case the result would be a sub-optimal route (maybe even
worse than what the clients get today), but probably not a "real"
security issue.  It is probably a good idea to explain why it is not a
security risk.


435        This document does not introduce requirements for any new protection
436        measures, but it also does not relax best operational practices for
437        keeping the IGP network stable or to pace rate of policy based IGP
438        cost to next hops such that it does not have any substantial effect
439        on BGP path changes and their propagation to route reflection
440        clients.

[major] "best operational practices"  Like what?  It would be good to
provide (at least) informational references.


[major] "to pace rate of policy based IGP cost to next hops such that
it does not have any substantial effect on BGP path changes"   You
will have to explain this further because the operation of an IGP is
not mentioned anywhere else.

IMHO, there's no need to go into IGP operational details in this
document.  There is nothing special/different about the operation of
an IGP.


[End of Review]

_______________________________________________
Idr mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/idr
--


Gyan Mishra

Network Solutions Architect 

Email [hidden email]

M 301 502-1347



_______________________________________________
Idr mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/idr
Reply | Threaded
Open this post in threaded view
|

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

Gyan Mishra

For VPN SAFI 128 can this solution be applied as with unique RD all paths get advertised by the RR and this solution would cut down on the paths advertised to help with scalability and with many RRs and many exit points.

Thanks 

Gyan

On Sat, May 22, 2021 at 6:11 PM Gyan Mishra <[hidden email]> wrote:
Dear Authors 

I have a few comments on this draft.

This is a historical well known issue exists where a RR will compute the best path based on IGP topology metric least cost to the exit point and will advertise those paths based on the topological position of the RR to the exit point.  The major issue is the best path reflected by the RR should be based on the Clients IGP shortest path to exit point and the RRs shortest path.  

A workaround to this issue is RFC 7911 add paths where all paths are advertised to all Client PEs as well as all RR as mentioned in section 4 deployment considerations.  What is missing in the Section 4 verbiage is the add path to both RRs and all clients so advertisement of all paths are advertised  to all clients as well as RR.  So to  resolve the issue with the RR making the best path decision the RR must have add paths send / receive MP Reach capability enabled to all clients and must select and advertise all paths to all clients so that each client can now make the best path decision based on its best path lowest IGP metric to the exit point.   

Using RFC 7911 add paths to all clients the hot potato issue is resolved.

The caveat with add paths is if you have many RRs and many exist points you end up with many paths per prefix in the BGP RIB.  

With modern high end routers these days this does not impact scalability issues that I am aware of.

With this draft it seems the goal is to only advertise the pertinent paths based on the client IGP location rooted topological path to the exit point and not advertise all paths.  This would cut down on the number of paths advertised by the RR so all paths are not flooded to the clients as the current solution today to the hot potato issue.

Am I reading this correctly?

Kind Regards 

Gyan 

On Thu, Mar 18, 2021 at 3:32 PM Alvaro Retana <[hidden email]> wrote:
Dear authors:


Thank you for your work on this document.  I know that the draft and
the related ideas have been around for a long time.

I have a couple of significant issues that I want to highlight
upfront, and many comments inline (see below).  In general, my focus
is to make sure that the specification of this mechanism is clear, not
just to the experienced reader, but to the casual one as well.  I
believe that all the issues should be easy to resolve.

(1) Terminology.  Please use the terminology already defined in
rfc4271/rfc4456 instead of creating new one by indirection.  My first
inline comment is about the use of "best path", which is not what
rfc4271 uses -- there are other occurrences later on.

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

(3) I don't think that §5 (CPU and Memory Scalability) and Appendix A
(alternative solutions with limited applicability) should be part of
this document.  To start, comparisons are never good and the work has
already been through the WG so there's no need to keep justifying it
by comparing it to other work.  Both sections contain several claims
(e.g. "extra cost in terms of CPU", "implemented efficiently",
"expected to be higher but comparable", "large amount of BGP state and
churn", "result in tens of paths for each prefix") that don't have
references, and could be considered subjective because they are
clearly relative and can change depending on the specific deployment
and configuration of the network.  I am not saying that the claims are
false, simply requesting to take these two sections out.


Thanks!

Alvaro.


[Line numbers from idnits.]

...
17      Abstract

19         This document defines an extension to BGP route reflectors.  On route
20         reflectors, BGP route selection is modified in order to choose the
21         best path from the standpoint of their clients, rather than from the
22         standpoint of the route reflectors.  Multiple types of granularity
23         are proposed, from a per client BGP route selection or to a per peer
24         group, depending on the scaling and precision requirements on route
25         selection.  This solution is particularly applicable in deployments
26         using centralized route reflectors, where choosing the best route
27         based on the route reflector IGP location is suboptimal.  This
28         facilitates, for example, best exit point policy (hot potato
29         routing).

[major] "best path"  rfc4271 doesn't use the term "best path".  The
terminology used in this document should, at the very least, match
what the base spec defines.  Let's please not create new terminology
by indirection using the "definition of terms" section.


[minor] "proposed"  This document is in line to be come an RFC; we're
far beyond proposing things.  There are a couple of places later on
where this same wording is used.  Please change it to specified or at
least described (the latter probably fits best in this specific case).


[nit] s/from a per client BGP route selection or to a per peer
group/from per client BGP route selection or per peer group


[nit] s/precision requirements on route selection./precision requirements.


[nit] s/route reflector IGP location/route reflector's IGP location


[major] "IGP location"  Before I forget -- please clearly define (not
in the Abstract of course) what an "IGP location" is.


...
70         1.  Definitions of Terms Used in This Memo  . . . . . . . . . . .   2
71         2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3

[nit] It would be nice if the Introduction came up before the terminology.


...
91      1.  Definitions of Terms Used in This Memo

[minor] To avoid repeating some terms, it is good practice to indicate
which other RFCs the reader should be familiar with.  In this case
rfc4271 and rfc4456 come to mind.


...
132     2.  Introduction
...
153        Section 11 of [RFC4456] describes a deployment approach and a set of
154        constraints which, if satisfied, would result in the deployment of
155        route reflection yielding the same results as the IBGP full mesh
156        approach.  This deployment approach makes route reflection compatible
157        with the application of hot potato routing policy.  In accordance
158        with these design rules, route reflectors have traditionally often
159        been deployed in the forwarding path and carefully placed on the POP
160        to core boundaries.

[nit] s/have traditionally often/have often
Redundant...


162        The evolving model of intra-domain network design has enabled
163        deployments of route reflectors outside of the forwarding path.
164        Initially this model was only employed for new address families, e.g.
165        L3VPNs and L2VPNs, however it has been gradually extended to other
166        BGP address families including IPv4 and IPv6 Internet using either
167        native routing or 6PE.  In such environments, hot potato routing
168        policy remains desirable.

[minor] "new address families, e.g. L3VPNs and L2VPNs"  These are not
the name of the AFs.  Maybe call them new services.


[minor] "IPv4 and IPv6 Internet"  The name of the AF is IP/IP6; again,
you probably mean service/application.


[nit] "native routing or 6PE"  Not 4PE applications?  ;-)   It seems
to me that you can save some ink by ending the sentence after
"Internet".


...
194     3.  Modifications to BGP Best Path selection

196        The core of this solution is the ability for an operator to specify
197        the IGP location for which the route reflector should calculate
198        routes.  This can be done on a per route reflector basis, per peer/
199        update group basis, or per peer basis.  This ability enables the
200        route reflector to send to a given set of clients routes with
201        shortest distance to the next hops from the position of the selected
202        IGP location.  This provides for freedom of route reflector physical
203        location, and allows transient or permanent migration of this network
204        control plane function to an arbitrary location.

[major] "ability for an operator to specify the IGP location for which
the route reflector should calculate routes.  This can be done on a
per route reflector basis, per peer/update group basis, or per peer
basis."

When should an operator choose per RR vs per peer group vs per peer?
Choice is good, but providing guidance for the deployment is much
better.  Please consider adding text to §6 about the considerations to
chose one or the other.


[minor] "peer/update group"  Where is this defined?  Is there a
reference to a non-implementation-specific definition?  Can it be
called "a group of peers"?  Maybe you also want to include it in the
definitions in §1.


...
215        o  it can, and usually will, have a different position in the IGP
216           topology, and

[] "usually will"   The position in the topology will *always* be different!


...
222        This document defines, on BGP Route Reflectors [RFC4456], two changes
223        to the BGP Best Path selection algorithm:

[nit] s/defines, on BGP Route Reflectors/defines, for BGP Route Reflectors


...
235        A route reflector can implement either or both of the modifications
236        in order to allow it to choose the best path for its clients that the
237        clients themselves would have chosen given the same set of candidate
238        paths.

[major] Please provide guidance for the operator to consider then one
or both should be used in their network.


240        A significant advantage of these approaches is that the route
241        reflector clients do not need to run new software or hardware.

[nit] s/do not need to run new software or hardware./do not need to be modified.


243     3.1.  Best Path Selection from a different IGP location

245        In this approach, optimal refers to the decision made during best
246        path selection at the IGP metric to BGP next hop comparison step.  It
247        does not apply to path selection preference based on other policy
248        steps and provisions.

[major] Please be specific about what is the "IGP metric to BGP next
hop comparison step".  There is no step with that name, or even a
string match in rfc4271.  Later you talk about the step e) tie-breaker
-- don't wait to be specific!


...
263           e) Remove from consideration any routes with less-preferred
264           interior cost.  The interior cost of a route is determined by
265           calculating the metric from the selected IGP location to the
266           NEXT_HOP for the route using the shortest IGP path tree rooted at
267           the selected IGP location.

[major] Note that the specification talks about "interior cost", but
the descriptions in this document uses "IGP cost" and "IGP metric" to
refer to the same thing.  Please be consistent with existing
terminology!


[major] Related to the definition of "IGP location" and its
configuration.  How does the IGP location (and thus the calculation of
the interior cost, as above) change when the configuration is done per
peer/update groups instead than per peer?  This is another point where
operators could benefit from guidance (for the peer/update-group and
whole RR cases, of course).


...
275        The configuration of the IGP location is outside of the scope of this
276        document.  The operator may configure it manually, an implementation
277        may automate it based on heuristics, or it can be computed centrally
278        and configured by an external system.

[nit] s/outside of the scope/outside the scope

[major] There are several places later on that talk about the
configuration, even making it a requirement for compliance (§6).  I
think that you don't mean the configuration itself, but the way in
which the configuration is instantiated in the router (which could be
considered an implementation detail).  As written, the text is not
clear.


280        This solution does not require any change (BGP or IGP) on the
281        clients, as all required changes are limited to the route reflector.

[] This was also claimed before.


283        This solution applies to NLRIs of all address families that can be
284        route reflected.

[] Are there AFs that cannot be reflected?  Just wondering if you
really need to say this.


286     3.1.1.  Restriction when BGP next hop is BGP prefix

288        In situations where the BGP next hop is a BGP prefix itself, the IGP
289        metric of a route used for its resolution SHOULD be the final IGP
290        cost to reach such next hop.  Implementations which can not inform
291        BGP of the final IGP metric to a recursive next hop SHOULD treat such
292        paths as least preferred during next hop metric comparison.  However
293        such paths SHOULD still be considered valid for best path selection.

[major] The recursive resolution is already covered in rfc4271
(§5.1.3/§9.1.2.1).  Why isn't that enough?

There seems to be a difference: if an implementation "can not inform
BGP of the final IGP metric to a recursive next hop...SHOULD still be
considered valid for best path selection."  rfc4271 treats these
routes as unresolvable.  Do you want to consider unresolvable routes?

Finally, there are a lot of SHOULDs in this paragraph.  Under which
conditions is it ok to not perform the actions?  IOW, why are these
actions recommended and not required?


295     3.2.  Multiple Best Path Selections

297        BGP Route Reflector as per [RFC4456] runs a single best path
298        selection.  Optimal route reflection may require calculation of
299        multiple best path selections or subsets of best path selection in
300        order to consider different IGP locations or BGP policies for
301        different sets of clients.

[] It hasn't been mentioned before, but the talk about policy made me
think about this:   Can a client be present on different sets?  How is
that handled in terms of BGP sessions?  Do we need multiple sessions?
Or is add-path required?


303        If the required routing optimization is limited to the IGP cost to
304        the BGP Next-Hop, only step e) as defined [RFC4271] section 9.1.2.2,
305        needs to be duplicated.

[major] I'm not sure if this paragraph is referencing §3.1 (where step
e) was just modified), or or you're saying that for each subset (from
the last paragraph) only step e) is considered, or something else.  ??


307        If the routing optimization requires the use of different BGP
308        policies for different sets of clients, a larger part of the decision
309        process needs to be duplicated, up to the whole decision process as
310        defined in section 9.1 of [RFC4271].  This is for example the case
311        when there is a need to use different policies to compute different
312        degree of preference during Phase 1.  This is needed for use cases
313        involving traffic engineering or dedicating certain exit points for
314        certain clients.  In the latter case, the user MAY specify and apply
315        a general policy on the route reflector for a set of clients.  For a
316        given set of clients, the policy SHOULD in that case allow the
317        operator to select different candidate exit points for different
318        address families.  Regular path selection, including IGP perspective
319        for a set of clients as per Section 3.1, is then applied to the
320        candidate paths to select the final paths to advertise to the
321        clients.

[] Similar comment as before...   The use of "duplicated" is confusing me.


[major] "the user MAY specify..."  s/MAY/may   It seems to me that
you're simply stating a fact (the user can do this), and not
specifying an optional behavior.


[major] "...the policy SHOULD in that case allow the operator to
select different candidate exit points for different address
families."  There's no interoperable action that "the policy" can
execute.  It sounds as if you're recommending that specific knobs
("allow the operator to...") be implemented.  Please reword.


[] You use "IGP perspective" I guess as equivalent to "IGP location"
-- is that right?


323     4.  Implementation considerations

325     4.1.  Likely Deployments and need for backup

[nit] Do we really need a sub-section if all the text for §4 is in it?


327        With IGP based optimal route reflection, even though the IGP location
328        could be specified on a per route reflector basis or per peer/update
329        group basis or per peer basis, in reality, it's most likely to be
330        specified per peer/update group basis.  All clients with the same or
331        similar IGP location can be grouped into the same peer/update group.
332        An IGP location is then specified for the peer/update group.  The
333        location is usually specified as the location of one of the clients
334        from the peer group or an ABR to the area where clients are located.
335        Also, one or more backup locations SHOULD be allowed to be specified
336        for redundancy.  Implementations may wish to take advantage of peer
337        group mechanisms in order to provide for better scalability of
338        optimal route reflector client groups with similar properties.

[major] "IGP based optimal route reflection"

This is the first time you use "IGP based optimal route reflection"; I
peeked forward and see that §5 also mentions "policy based optimal
route reflection".  But you didn't define them anywhere -- in fact,
the description before now focuses on the IGP location, which makes me
think about "IGP based".

I could guess that the "policy based" version is related to §3.2, but
(1) no one should have to guess (!), and (2) the end of that section
says that "IGP perspective...is then applied", making it also "IGP
based".  ??

Please either define these types of ORR earlier in the text, or
(better yet) don't use the terms.  Instead, and given that the names
are used just a couple of times, change "policy based" to "the case
where a policy is applied"...


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

(2) If there were "backup locations", how would they be used?


[minor] This is the only time that "optimal route reflector client
groups" is used.  I had been assuming that a group of clients would
correspond to a specific peer/update group (as mentioned many times
before).  Is there a difference between a "client group" and grouping
clients to correspond to a peer/update group?


[] "for better scalability of optimal route reflector client groups"
What exactly does this mean?  I asked before about
references/definitions for peer/update groups; this point may be
related.


...
373     6.  Advantages and Deployment Considerations

375        The solutions described provide a model for integrating the client
376        perspective into the best path computation for route reflectors.
377        More specifically, the choice of BGP path factors in either the IGP
378        cost between the client and the nexthop (rather than the IGP cost
379        from the route reflector to the nexthop) or other user configured
380        policies.

[] "solutions"?   I only see one, where the "second" one simply adds
policy, which is a pervasive tool in BGP.


382        The achievement of optimal routing relies upon all route reflectors
383        learning all paths that are eligible for consideration.  In order to
384        satisfy this requirement, path diversity enhancing mechanisms such as
385        BGP add-path [RFC7911] may need to be deployed between route
386        reflectors.

[mayor] "path diversity enhancing mechanisms...may need to be deployed
between route reflectors"  Given that this is the Deployment
Considerations section, please provide guidance on when these
mechanisms are needed, and when they're not.


[minor] "path diversity enhancing mechanisms such as BGP add-path
[RFC7911]"  Just out of curiosity, what other mechanisms are you
thinking of?  Are there deployment considerations, when using ORR, to
prefer one?


388        Implementations considered compliant with this document allow the
389        configuration of a logical location from which the best path will be
390        computed, on the basis of either a peer, a peer group, or an entire
391        routing instance.

[] I guess that "logical location" is another name for IGP location...


[major] §3.1 says that the "configuration of the IGP location is
outside of the scope of this document".  If that is true, then the
configuration cannot be a consideration for compliance.

A better wording for compliance would be: "An implementation MUST
allow the configuration..."


393        These solutions can be deployed in traditional hop-by-hop forwarding
394        networks as well as in end-to-end tunneled environments.  In networks
395        where there are multiple route reflectors and hop-by-hop forwarding
396        without encapsulation, such optimizations SHOULD be enabled in a
397        consistent way on all route reflectors.  Otherwise, clients may
398        receive an inconsistent view of the network, in turn leading to
399        intra-domain forwarding loops.

[major] "optimizations SHOULD be enabled in a consistent way on all
route reflectors"

Is "a consistent way" different than "on all"?   s/.../optimizations
SHOULD be enabled on all route reflectors

When is it ok for all RRs not to be enabled with the optimizations?
IOW, why is it recommended and not required?  Avoiding "intra-domain
forwarding loops" sounds like a good reason to require it.


...
406        As per above, these approaches reduce the amount of state which needs
407        to be pushed to the edge of the network in order to perform hot
408        potato routing.  The memory and CPU resources required at the edge of
409        the network to provide hot potato routing using these approaches is
410        lower than what would be required to achieve the same level of
411        optimality by pushing and retaining all available paths (potentially
412        10s) per each prefix at the edge.

[] This paragraph sounds very speculative and doesn't seem necessary.
In line with §5.


414        The solutions above allow for a fast and safe transition to a BGP
415        control plane using centralized route reflection, without
416        compromising an operator's closest exit operational principle.  This
417        enables edge-to-edge LSP/IP encapsulation for traffic to IPv4 and
418        IPv6 prefixes.

[] "allow for a fast and safe transition"  Besides this statement
sounding like a marketing brochure, if you're going to talk about
transition, please talk about it in detail.  Please take a look at
§2/rfc5706 and include details about the transition and how it is
"fast and safe".


420        Regarding Best Path Selection from a different IGP location, it
421        should be self evident that this solution does not interfere with
422        policies enforced above IGP tie-breaking in the BGP best path
423        algorithm.

[minor] Don't assume anything is self evident to anyone.

Suggestion (maybe more appropriate in §3.1)>
   The modification specified in Section 3.1 does not impact any previous
   considerations in the BGP Decision Process.


425     7.  Security Considerations

427        Similarly to [RFC4456], this extension to BGP does not change the
428        underlying security issues inherent in the existing IBGP [RFC4456].

[minor] No need to reference rfc4456 twice in the same sentence.


430        It however enables the deployment of base BGP Route Reflection as
431        described in [RFC4456] to be possible using virtual compute
432        environments without any negative consequence on the BGP routing path
433        optimality.

[] I'm not sure how this relates to the specification itself (platform
independent), but I'm sure the Security ADs will have a lot of
questions about the security of "virtual compute environments" -- and
where the details are included in this document.   IOW, that sounds
like an unnecessary assertion.


[major] "without any negative consequence"  The new functionality
specified in this document is having the RR run the client's selection
for them (even specific policy) -- there are risks related to the
duplication of the policy, the location of the RRs and the blind trust
that the clients need to have.  Or should the clients rerun the policy
locally?

This behavior is not necessarily different from normal RR, but the
instantiation is different.   It would be very easy for a rogue RR to
propagate incorrect routing information to its clients -- specially if
policy is offloaded to them.

In the worst case the result would be a sub-optimal route (maybe even
worse than what the clients get today), but probably not a "real"
security issue.  It is probably a good idea to explain why it is not a
security risk.


435        This document does not introduce requirements for any new protection
436        measures, but it also does not relax best operational practices for
437        keeping the IGP network stable or to pace rate of policy based IGP
438        cost to next hops such that it does not have any substantial effect
439        on BGP path changes and their propagation to route reflection
440        clients.

[major] "best operational practices"  Like what?  It would be good to
provide (at least) informational references.


[major] "to pace rate of policy based IGP cost to next hops such that
it does not have any substantial effect on BGP path changes"   You
will have to explain this further because the operation of an IGP is
not mentioned anywhere else.

IMHO, there's no need to go into IGP operational details in this
document.  There is nothing special/different about the operation of
an IGP.


[End of Review]

_______________________________________________
Idr mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/idr
--


Gyan Mishra

Network Solutions Architect 

Email [hidden email]

M 301 502-1347


--


Gyan Mishra

Network Solutions Architect 

Email [hidden email]

M 301 502-1347



_______________________________________________
Idr mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/idr
Reply | Threaded
Open this post in threaded view
|

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

Alvaro Retana-2
In reply to this post by Robert Raszuk-3
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.

_______________________________________________
Idr mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/idr
Reply | Threaded
Open this post in threaded view
|

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

Robert Raszuk-3
In reply to this post by Gyan Mishra
Gyan,

This solution selects optimal paths for a given net. As RD is part of the net we would not select paths between nets. 

Note that tp the best of my knowledge we still have a day one option-B problem where two or more ASBRs may give us same net and VPNv4 RRs may choose single one only before advertising to peers. ORR may help here a bit to give different paths to different clients. 

To your other comment sure ORR is not required if we use "add-paths all" or have full IBGP mesh. But I know about networks where for each net there is 100s of paths hence add-path all is not a practical starter. 

Cheers,
R.

On Sun, May 23, 2021 at 12:40 AM Gyan Mishra <[hidden email]> wrote:
For VPN SAFI 128 can this solution be applied as with unique RD all paths
get advertised by the RR and this solution would cut down on the paths
advertised to help with scalability and with many RRs and many exit points.

Thanks
Gyan

On Sat, May 22, 2021 at 6:11 PM Gyan Mishra <[hidden email]> wrote:

> Dear Authors
>
> I have a few comments on this draft.
>
> This is a historical well known issue exists where a RR will compute the
> best path based on IGP topology metric least cost to the exit point and
> will advertise those paths based on the topological position of the RR to
> the exit point.  The major issue is the best path reflected by the RR
> should be based on the Clients IGP shortest path to exit point and the RRs
> shortest path.
>
> A workaround to this issue is RFC 7911 add paths where all paths are
> advertised to all Client PEs as well as all RR as mentioned in section 4
> deployment considerations.  What is missing in the Section 4 verbiage is
> the add path to both RRs and all clients so advertisement of all paths are
> advertised  to all clients as well as RR.  So to  resolve the issue with
> the RR making the best path decision the RR must have add paths send /
> receive MP Reach capability enabled to all clients and must select and
> advertise all paths to all clients so that each client can now make the
> best path decision based on its best path lowest IGP metric to the exit
> point.
>
> Using RFC 7911 add paths to all clients the hot potato issue is resolved.
>
> The caveat with add paths is if you have many RRs and many exist points
> you end up with many paths per prefix in the BGP RIB.
>
> With modern high end routers these days this does not impact scalability
> issues that I am aware of.
>
> With this draft it seems the goal is to only advertise the pertinent paths
> based on the client IGP location rooted topological path to the exit point
> and not advertise all paths.  This would cut down on the number of paths
> advertised by the RR so all paths are not flooded to the clients as the
> current solution today to the hot potato issue.
>
> Am I reading this correctly?
>
> Kind Regards
>
> Gyan
>
> On Thu, Mar 18, 2021 at 3:32 PM Alvaro Retana <[hidden email]>
> wrote:
>
>> Dear authors:
>>
>>
>> Thank you for your work on this document.  I know that the draft and
>> the related ideas have been around for a long time.
>>
>> I have a couple of significant issues that I want to highlight
>> upfront, and many comments inline (see below).  In general, my focus
>> is to make sure that the specification of this mechanism is clear, not
>> just to the experienced reader, but to the casual one as well.  I
>> believe that all the issues should be easy to resolve.
>>
>> (1) Terminology.  Please use the terminology already defined in
>> rfc4271/rfc4456 instead of creating new one by indirection.  My first
>> inline comment is about the use of "best path", which is not what
>> rfc4271 uses -- there are other occurrences later on.
>>
>> (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.]
>>
>> (3) I don't think that §5 (CPU and Memory Scalability) and Appendix A
>> (alternative solutions with limited applicability) should be part of
>> this document.  To start, comparisons are never good and the work has
>> already been through the WG so there's no need to keep justifying it
>> by comparing it to other work.  Both sections contain several claims
>> (e.g. "extra cost in terms of CPU", "implemented efficiently",
>> "expected to be higher but comparable", "large amount of BGP state and
>> churn", "result in tens of paths for each prefix") that don't have
>> references, and could be considered subjective because they are
>> clearly relative and can change depending on the specific deployment
>> and configuration of the network.  I am not saying that the claims are
>> false, simply requesting to take these two sections out.
>>
>>
>> Thanks!
>>
>> Alvaro.
>>
>>
>> [Line numbers from idnits.]
>>
>> ...
>> 17      Abstract
>>
>> 19         This document defines an extension to BGP route reflectors.
>> On route
>> 20         reflectors, BGP route selection is modified in order to choose
>> the
>> 21         best path from the standpoint of their clients, rather than
>> from the
>> 22         standpoint of the route reflectors.  Multiple types of
>> granularity
>> 23         are proposed, from a per client BGP route selection or to a
>> per peer
>> 24         group, depending on the scaling and precision requirements on
>> route
>> 25         selection.  This solution is particularly applicable in
>> deployments
>> 26         using centralized route reflectors, where choosing the best
>> route
>> 27         based on the route reflector IGP location is suboptimal.  This
>> 28         facilitates, for example, best exit point policy (hot potato
>> 29         routing).
>>
>> [major] "best path"  rfc4271 doesn't use the term "best path".  The
>> terminology used in this document should, at the very least, match
>> what the base spec defines.  Let's please not create new terminology
>> by indirection using the "definition of terms" section.
>>
>>
>> [minor] "proposed"  This document is in line to be come an RFC; we're
>> far beyond proposing things.  There are a couple of places later on
>> where this same wording is used.  Please change it to specified or at
>> least described (the latter probably fits best in this specific case).
>>
>>
>> [nit] s/from a per client BGP route selection or to a per peer
>> group/from per client BGP route selection or per peer group
>>
>>
>> [nit] s/precision requirements on route selection./precision requirements.
>>
>>
>> [nit] s/route reflector IGP location/route reflector's IGP location
>>
>>
>> [major] "IGP location"  Before I forget -- please clearly define (not
>> in the Abstract of course) what an "IGP location" is.
>>
>>
>> ...
>> 70         1.  Definitions of Terms Used in This Memo  . . . . . . . . .
>> . .   2
>> 71         2.  Introduction  . . . . . . . . . . . . . . . . . . . . . .
>> . .   3
>>
>> [nit] It would be nice if the Introduction came up before the terminology.
>>
>>
>> ...
>> 91      1.  Definitions of Terms Used in This Memo
>>
>> [minor] To avoid repeating some terms, it is good practice to indicate
>> which other RFCs the reader should be familiar with.  In this case
>> rfc4271 and rfc4456 come to mind.
>>
>>
>> ...
>> 132     2.  Introduction
>> ...
>> 153        Section 11 of [RFC4456] describes a deployment approach and a
>> set of
>> 154        constraints which, if satisfied, would result in the
>> deployment of
>> 155        route reflection yielding the same results as the IBGP full
>> mesh
>> 156        approach.  This deployment approach makes route reflection
>> compatible
>> 157        with the application of hot potato routing policy.  In
>> accordance
>> 158        with these design rules, route reflectors have traditionally
>> often
>> 159        been deployed in the forwarding path and carefully placed on
>> the POP
>> 160        to core boundaries.
>>
>> [nit] s/have traditionally often/have often
>> Redundant...
>>
>>
>> 162        The evolving model of intra-domain network design has enabled
>> 163        deployments of route reflectors outside of the forwarding path.
>> 164        Initially this model was only employed for new address
>> families, e.g.
>> 165        L3VPNs and L2VPNs, however it has been gradually extended to
>> other
>> 166        BGP address families including IPv4 and IPv6 Internet using
>> either
>> 167        native routing or 6PE.  In such environments, hot potato
>> routing
>> 168        policy remains desirable.
>>
>> [minor] "new address families, e.g. L3VPNs and L2VPNs"  These are not
>> the name of the AFs.  Maybe call them new services.
>>
>>
>> [minor] "IPv4 and IPv6 Internet"  The name of the AF is IP/IP6; again,
>> you probably mean service/application.
>>
>>
>> [nit] "native routing or 6PE"  Not 4PE applications?  ;-)   It seems
>> to me that you can save some ink by ending the sentence after
>> "Internet".
>>
>>
>> ...
>> 194     3.  Modifications to BGP Best Path selection
>>
>> 196        The core of this solution is the ability for an operator to
>> specify
>> 197        the IGP location for which the route reflector should calculate
>> 198        routes.  This can be done on a per route reflector basis, per
>> peer/
>> 199        update group basis, or per peer basis.  This ability enables
>> the
>> 200        route reflector to send to a given set of clients routes with
>> 201        shortest distance to the next hops from the position of the
>> selected
>> 202        IGP location.  This provides for freedom of route reflector
>> physical
>> 203        location, and allows transient or permanent migration of this
>> network
>> 204        control plane function to an arbitrary location.
>>
>> [major] "ability for an operator to specify the IGP location for which
>> the route reflector should calculate routes.  This can be done on a
>> per route reflector basis, per peer/update group basis, or per peer
>> basis."
>>
>> When should an operator choose per RR vs per peer group vs per peer?
>> Choice is good, but providing guidance for the deployment is much
>> better.  Please consider adding text to §6 about the considerations to
>> chose one or the other.
>>
>>
>> [minor] "peer/update group"  Where is this defined?  Is there a
>> reference to a non-implementation-specific definition?  Can it be
>> called "a group of peers"?  Maybe you also want to include it in the
>> definitions in §1.
>>
>>
>> ...
>> 215        o  it can, and usually will, have a different position in the
>> IGP
>> 216           topology, and
>>
>> [] "usually will"   The position in the topology will *always* be
>> different!
>>
>>
>> ...
>> 222        This document defines, on BGP Route Reflectors [RFC4456], two
>> changes
>> 223        to the BGP Best Path selection algorithm:
>>
>> [nit] s/defines, on BGP Route Reflectors/defines, for BGP Route Reflectors
>>
>>
>> ...
>> 235        A route reflector can implement either or both of the
>> modifications
>> 236        in order to allow it to choose the best path for its clients
>> that the
>> 237        clients themselves would have chosen given the same set of
>> candidate
>> 238        paths.
>>
>> [major] Please provide guidance for the operator to consider then one
>> or both should be used in their network.
>>
>>
>> 240        A significant advantage of these approaches is that the route
>> 241        reflector clients do not need to run new software or hardware

_______________________________________________
Idr mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/idr
Reply | Threaded
Open this post in threaded view
|

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

UTTARO, JAMES (ATTSI)

Add-paths practicality depends upon how many paths should be advertised into the topology. Some options for selecting which addpath approach is written in:

 

https://datatracker.ietf.org/doc/html/draft-uttaro-idr-add-paths-guidelines

 

Based upon the placement of the virtual RRs in the topology none of the options listed above may be sufficient..

 

Thanks,

              Jim Uttaro

 

From: Idr <[hidden email]> On Behalf Of Robert Raszuk
Sent: Monday, May 24, 2021 12:26 PM
To: Gyan Mishra <[hidden email]>
Cc: IDR List <[hidden email]>; [hidden email]; [hidden email]; Susan Hares <[hidden email]>
Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-optimal-route-reflection-22

 

Gyan,

 

This solution selects optimal paths for a given net. As RD is part of the net we would not select paths between nets. 

 

Note that tp the best of my knowledge we still have a day one option-B problem where two or more ASBRs may give us same net and VPNv4 RRs may choose single one only before advertising to peers. ORR may help here a bit to give different paths to different clients. 

 

To your other comment sure ORR is not required if we use "add-paths all" or have full IBGP mesh. But I know about networks where for each net there is 100s of paths hence add-path all is not a practical starter. 

 

Cheers,

R.

 

On Sun, May 23, 2021 at 12:40 AM Gyan Mishra <[hidden email]> wrote:

For VPN SAFI 128 can this solution be applied as with unique RD all paths
get advertised by the RR and this solution would cut down on the paths
advertised to help with scalability and with many RRs and many exit points.

Thanks
Gyan

On Sat, May 22, 2021 at 6:11 PM Gyan Mishra <[hidden email]> wrote:

> Dear Authors
>
> I have a few comments on this draft.
>
> This is a historical well known issue exists where a RR will compute the
> best path based on IGP topology metric least cost to the exit point and
> will advertise those paths based on the topological position of the RR to
> the exit point.  The major issue is the best path reflected by the RR
> should be based on the Clients IGP shortest path to exit point and the RRs
> shortest path.
>
> A workaround to this issue is RFC 7911 add paths where all paths are
> advertised to all Client PEs as well as all RR as mentioned in section 4
> deployment considerations.  What is missing in the Section 4 verbiage is
> the add path to both RRs and all clients so advertisement of all paths are
> advertised  to all clients as well as RR.  So to  resolve the issue with
> the RR making the best path decision the RR must have add paths send /
> receive MP Reach capability enabled to all clients and must select and
> advertise all paths to all clients so that each client can now make the
> best path decision based on its best path lowest IGP metric to the exit
> point.
>
> Using RFC 7911 add paths to all clients the hot potato issue is resolved.
>
> The caveat with add paths is if you have many RRs and many exist points
> you end up with many paths per prefix in the BGP RIB.
>
> With modern high end routers these days this does not impact scalability
> issues that I am aware of.
>
> With this draft it seems the goal is to only advertise the pertinent paths
> based on the client IGP location rooted topological path to the exit point
> and not advertise all paths.  This would cut down on the number of paths
> advertised by the RR so all paths are not flooded to the clients as the
> current solution today to the hot potato issue.
>
> Am I reading this correctly?
>
> Kind Regards
>
> Gyan
>
> On Thu, Mar 18, 2021 at 3:32 PM Alvaro Retana <[hidden email]>
> wrote:
>
>> Dear authors:
>>
>>
>> Thank you for your work on this document.  I know that the draft and
>> the related ideas have been around for a long time.
>>
>> I have a couple of significant issues that I want to highlight
>> upfront, and many comments inline (see below).  In general, my focus
>> is to make sure that the specification of this mechanism is clear, not
>> just to the experienced reader, but to the casual one as well.  I
>> believe that all the issues should be easy to resolve.
>>
>> (1) Terminology.  Please use the terminology already defined in
>> rfc4271/rfc4456 instead of creating new one by indirection.  My first
>> inline comment is about the use of "best path", which is not what
>> rfc4271 uses -- there are other occurrences later on.
>>
>> (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.]
>>
>> (3) I don't think that §5 (CPU and Memory Scalability) and Appendix A
>> (alternative solutions with limited applicability) should be part of
>> this document.  To start, comparisons are never good and the work has
>> already been through the WG so there's no need to keep justifying it
>> by comparing it to other work.  Both sections contain several claims
>> (e.g. "extra cost in terms of CPU", "implemented efficiently",
>> "expected to be higher but comparable", "large amount of BGP state and
>> churn", "result in tens of paths for each prefix") that don't have
>> references, and could be considered subjective because they are
>> clearly relative and can change depending on the specific deployment
>> and configuration of the network.  I am not saying that the claims are
>> false, simply requesting to take these two sections out.
>>
>>
>> Thanks!
>>
>> Alvaro.
>>
>>
>> [Line numbers from idnits.]
>>
>> ...
>> 17      Abstract
>>
>> 19         This document defines an extension to BGP route reflectors.
>> On route
>> 20         reflectors, BGP route selection is modified in order to choose
>> the
>> 21         best path from the standpoint of their clients, rather than
>> from the
>> 22         standpoint of the route reflectors.  Multiple types of
>> granularity
>> 23         are proposed, from a per client BGP route selection or to a
>> per peer
>> 24         group, depending on the scaling and precision requirements on
>> route
>> 25         selection.  This solution is particularly applicable in
>> deployments
>> 26         using centralized route reflectors, where choosing the best
>> route
>> 27         based on the route reflector IGP location is suboptimal.  This
>> 28         facilitates, for example, best exit point policy (hot potato
>> 29         routing).
>>
>> [major] "best path"  rfc4271 doesn't use the term "best path".  The
>> terminology used in this document should, at the very least, match
>> what the base spec defines.  Let's please not create new terminology
>> by indirection using the "definition of terms" section.
>>
>>
>> [minor] "proposed"  This document is in line to be come an RFC; we're
>> far beyond proposing things.  There are a couple of places later on
>> where this same wording is used.  Please change it to specified or at
>> least described (the latter probably fits best in this specific case).
>>
>>
>> [nit] s/from a per client BGP route selection or to a per peer
>> group/from per client BGP route selection or per peer group
>>
>>
>> [nit] s/precision requirements on route selection./precision requirements.
>>
>>
>> [nit] s/route reflector IGP location/route reflector's IGP location
>>
>>
>> [major] "IGP location"  Before I forget -- please clearly define (not
>> in the Abstract of course) what an "IGP location" is.
>>
>>
>> ...
>> 70         1.  Definitions of Terms Used in This Memo  . . . . . . . . .
>> . .   2
>> 71         2.  Introduction  . . . . . . . . . . . . . . . . . . . . . .
>> . .   3
>>
>> [nit] It would be nice if the Introduction came up before the terminology.
>>
>>
>> ...
>> 91      1.  Definitions of Terms Used in This Memo
>>
>> [minor] To avoid repeating some terms, it is good practice to indicate
>> which other RFCs the reader should be familiar with.  In this case
>> rfc4271 and rfc4456 come to mind.
>>
>>
>> ...
>> 132     2.  Introduction
>> ...
>> 153        Section 11 of [RFC4456] describes a deployment approach and a
>> set of
>> 154        constraints which, if satisfied, would result in the
>> deployment of
>> 155        route reflection yielding the same results as the IBGP full
>> mesh
>> 156        approach.  This deployment approach makes route reflection
>> compatible
>> 157        with the application of hot potato routing policy.  In
>> accordance
>> 158        with these design rules, route reflectors have traditionally
>> often
>> 159        been deployed in the forwarding path and carefully placed on
>> the POP
>> 160        to core boundaries.
>>
>> [nit] s/have traditionally often/have often
>> Redundant...
>>
>>
>> 162        The evolving model of intra-domain network design has enabled
>> 163        deployments of route reflectors outside of the forwarding path.
>> 164        Initially this model was only employed for new address
>> families, e.g.
>> 165        L3VPNs and L2VPNs, however it has been gradually extended to
>> other
>> 166        BGP address families including IPv4 and IPv6 Internet using
>> either
>> 167        native routing or 6PE.  In such environments, hot potato
>> routing
>> 168        policy remains desirable.
>>
>> [minor] "new address families, e.g. L3VPNs and L2VPNs"  These are not
>> the name of the AFs.  Maybe call them new services.
>>
>>
>> [minor] "IPv4 and IPv6 Internet"  The name of the AF is IP/IP6; again,
>> you probably mean service/application.
>>
>>
>> [nit] "native routing or 6PE"  Not 4PE applications?  ;-)   It seems
>> to me that you can save some ink by ending the sentence after
>> "Internet".
>>
>>
>> ...
>> 194     3.  Modifications to BGP Best Path selection
>>
>> 196        The core of this solution is the ability for an operator to
>> specify
>> 197        the IGP location for which the route reflector should calculate
>> 198        routes.  This can be done on a per route reflector basis, per
>> peer/
>> 199        update group basis, or per peer basis.  This ability enables
>> the
>> 200        route reflector to send to a given set of clients routes with
>> 201        shortest distance to the next hops from the position of the
>> selected
>> 202        IGP location.  This provides for freedom of route reflector
>> physical
>> 203        location, and allows transient or permanent migration of this
>> network
>> 204        control plane function to an arbitrary location.
>>
>> [major] "ability for an operator to specify the IGP location for which
>> the route reflector should calculate routes.  This can be done on a
>> per route reflector basis, per peer/update group basis, or per peer
>> basis."
>>
>> When should an operator choose per RR vs per peer group vs per peer?
>> Choice is good, but providing guidance for the deployment is much
>> better.  Please consider adding text to §6 about the considerations to
>> chose one or the other.
>>
>>
>> [minor] "peer/update group"  Where is this defined?  Is there a
>> reference to a non-implementation-specific definition?  Can it be
>> called "a group of peers"?  Maybe you also want to include it in the
>> definitions in §1.
>>
>>
>> ...
>> 215        o  it can, and usually will, have a different position in the
>> IGP
>> 216           topology, and
>>
>> [] "usually will"   The position in the topology will *always* be
>> different!
>>
>>
>> ...
>> 222        This document defines, on BGP Route Reflectors [RFC4456], two
>> changes
>> 223        to the BGP Best Path selection algorithm:
>>
>> [nit] s/defines, on BGP Route Reflectors/defines, for BGP Route Reflectors
>>
>>
>> ...
>> 235        A route reflector can implement either or both of the
>> modifications
>> 236        in order to allow it to choose the best path for its clients
>> that the
>> 237        clients themselves would have chosen given the same set of
>> candidate
>> 238        paths.
>>
>> [major] Please provide guidance for the operator to consider then one
>> or both should be used in their network.
>>
>>
>> 240        A significant advantage of these approaches is that the route
>> 241        reflector clients do not need to run new software or hardware


_______________________________________________
Idr mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/idr
Reply | Threaded
Open this post in threaded view
|

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

Gyan Mishra
In reply to this post by Robert Raszuk-3

Hi Robert

This is an excellent optimization concept for RR scalability as well as limiting the number of paths per prefix reflected to the clients which can be enormous.

Verizon as well as other internet providers can take advantage of this solution and help reduce the number of paths being reflected to clients.

I support advancement of this draft.

Minor comments on the draft text below:

Introduction paragraph 4 -
I don’t think hot potato routing is ever desirable where the RR is making the best path decision instead of the client is ever better in the case where the RR is not in the forwarding plane.

The evolving model of intra-domain network design has enabled deployments of route reflectors outside of the forwarding path.
   Initially this model was only employed for new services, e.g.  IP
   VPNs [RFC4364], however it has been gradually       extended to other BGP services including IPv4 and IPv6 Internet.  In such environments, hot
   potato routing policy remains desirable.


Has this feature been implemented by any vendor to test the viability and CPU resources necessary related to multiple decision processes due to IGP location change?

Thanks 

Gyan 
On Mon, May 24, 2021 at 12:25 PM Robert Raszuk <[hidden email]> wrote:
Gyan,

This solution selects optimal paths for a given net. As RD is part of the net we would not select paths between nets. 

Note that tp the best of my knowledge we still have a day one option-B problem where two or more ASBRs may give us same net and VPNv4 RRs may choose single one only before advertising to peers. ORR may help here a bit to give different paths to different clients. 

To your other comment sure ORR is not required if we use "add-paths all" or have full IBGP mesh. But I know about networks where for each net there is 100s of paths hence add-path all is not a practical starter. 

Cheers,
R.

On Sun, May 23, 2021 at 12:40 AM Gyan Mishra <[hidden email]> wrote:
For VPN SAFI 128 can this solution be applied as with unique RD all paths
get advertised by the RR and this solution would cut down on the paths
advertised to help with scalability and with many RRs and many exit points.

Thanks
Gyan

On Sat, May 22, 2021 at 6:11 PM Gyan Mishra <[hidden email]> wrote:

> Dear Authors
>
> I have a few comments on this draft.
>
> This is a historical well known issue exists where a RR will compute the
> best path based on IGP topology metric least cost to the exit point and
> will advertise those paths based on the topological position of the RR to
> the exit point.  The major issue is the best path reflected by the RR
> should be based on the Clients IGP shortest path to exit point and the RRs
> shortest path.
>
> A workaround to this issue is RFC 7911 add paths where all paths are
> advertised to all Client PEs as well as all RR as mentioned in section 4
> deployment considerations.  What is missing in the Section 4 verbiage is
> the add path to both RRs and all clients so advertisement of all paths are
> advertised  to all clients as well as RR.  So to  resolve the issue with
> the RR making the best path decision the RR must have add paths send /
> receive MP Reach capability enabled to all clients and must select and
> advertise all paths to all clients so that each client can now make the
> best path decision based on its best path lowest IGP metric to the exit
> point.
>
> Using RFC 7911 add paths to all clients the hot potato issue is resolved.
>
> The caveat with add paths is if you have many RRs and many exist points
> you end up with many paths per prefix in the BGP RIB.
>
> With modern high end routers these days this does not impact scalability
> issues that I am aware of.
>
> With this draft it seems the goal is to only advertise the pertinent paths
> based on the client IGP location rooted topological path to the exit point
> and not advertise all paths.  This would cut down on the number of paths
> advertised by the RR so all paths are not flooded to the clients as the
> current solution today to the hot potato issue.
>
> Am I reading this correctly?
>
> Kind Regards
>
> Gyan
>
> On Thu, Mar 18, 2021 at 3:32 PM Alvaro Retana <[hidden email]>
> wrote:
>
>> Dear authors:
>>
>>
>> Thank you for your work on this document.  I know that the draft and
>> the related ideas have been around for a long time.
>>
>> I have a couple of significant issues that I want to highlight
>> upfront, and many comments inline (see below).  In general, my focus
>> is to make sure that the specification of this mechanism is clear, not
>> just to the experienced reader, but to the casual one as well.  I
>> believe that all the issues should be easy to resolve.
>>
>> (1) Terminology.  Please use the terminology already defined in
>> rfc4271/rfc4456 instead of creating new one by indirection.  My first
>> inline comment is about the use of "best path", which is not what
>> rfc4271 uses -- there are other occurrences later on.
>>
>> (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.]
>>
>> (3) I don't think that §5 (CPU and Memory Scalability) and Appendix A
>> (alternative solutions with limited applicability) should be part of
>> this document.  To start, comparisons are never good and the work has
>> already been through the WG so there's no need to keep justifying it
>> by comparing it to other work.  Both sections contain several claims
>> (e.g. "extra cost in terms of CPU", "implemented efficiently",
>> "expected to be higher but comparable", "large amount of BGP state and
>> churn", "result in tens of paths for each prefix") that don't have
>> references, and could be considered subjective because they are
>> clearly relative and can change depending on the specific deployment
>> and configuration of the network.  I am not saying that the claims are
>> false, simply requesting to take these two sections out.
>>
>>
>> Thanks!
>>
>> Alvaro.
>>
>>
>> [Line numbers from idnits.]
>>
>> ...
>> 17      Abstract
>>
>> 19         This document defines an extension to BGP route reflectors.
>> On route
>> 20         reflectors, BGP route selection is modified in order to choose
>> the
>> 21         best path from the standpoint of their clients, rather than
>> from the
>> 22         standpoint of the route reflectors.  Multiple types of
>> granularity
>> 23         are proposed, from a per client BGP route selection or to a
>> per peer
>> 24         group, depending on the scaling and precision requirements on
>> route
>> 25         selection.  This solution is particularly applicable in
>> deployments
>> 26         using centralized route reflectors, where choosing the best
>> route
>> 27         based on the route reflector IGP location is suboptimal.  This
>> 28         facilitates, for example, best exit point policy (hot potato
>> 29         routing).
>>
>> [major] "best path"  rfc4271 doesn't use the term "best path".  The
>> terminology used in this document should, at the very least, match
>> what the base spec defines.  Let's please not create new terminology
>> by indirection using the "definition of terms" section.
>>
>>
>> [minor] "proposed"  This document is in line to be come an RFC; we're
>> far beyond proposing things.  There are a couple of places later on
>> where this same wording is used.  Please change it to specified or at
>> least described (the latter probably fits best in this specific case).
>>
>>
>> [nit] s/from a per client BGP route selection or to a per peer
>> group/from per client BGP route selection or per peer group
>>
>>
>> [nit] s/precision requirements on route selection./precision requirements.
>>
>>
>> [nit] s/route reflector IGP location/route reflector's IGP location
>>
>>
>> [major] "IGP location"  Before I forget -- please clearly define (not
>> in the Abstract of course) what an "IGP location" is.
>>
>>
>> ...
>> 70         1.  Definitions of Terms Used in This Memo  . . . . . . . . .
>> . .   2
>> 71         2.  Introduction  . . . . . . . . . . . . . . . . . . . . . .
>> . .   3
>>
>> [nit] It would be nice if the Introduction came up before the terminology.
>>
>>
>> ...
>> 91      1.  Definitions of Terms Used in This Memo
>>
>> [minor] To avoid repeating some terms, it is good practice to indicate
>> which other RFCs the reader should be familiar with.  In this case
>> rfc4271 and rfc4456 come to mind.
>>
>>
>> ...
>> 132     2.  Introduction
>> ...
>> 153        Section 11 of [RFC4456] describes a deployment approach and a
>> set of
>> 154        constraints which, if satisfied, would result in the
>> deployment of
>> 155        route reflection yielding the same results as the IBGP full
>> mesh
>> 156        approach.  This deployment approach makes route reflection
>> compatible
>> 157        with the application of hot potato routing policy.  In
>> accordance
>> 158        with these design rules, route reflectors have traditionally
>> often
>> 159        been deployed in the forwarding path and carefully placed on
>> the POP
>> 160        to core boundaries.
>>
>> [nit] s/have traditionally often/have often
>> Redundant...
>>
>>
>> 162        The evolving model of intra-domain network design has enabled
>> 163        deployments of route reflectors outside of the forwarding path.
>> 164        Initially this model was only employed for new address
>> families, e.g.
>> 165        L3VPNs and L2VPNs, however it has been gradually extended to
>> other
>> 166        BGP address families including IPv4 and IPv6 Internet using
>> either
>> 167        native routing or 6PE.  In such environments, hot potato
>> routing
>> 168        policy remains desirable.
>>
>> [minor] "new address families, e.g. L3VPNs and L2VPNs"  These are not
>> the name of the AFs.  Maybe call them new services.
>>
>>
>> [minor] "IPv4 and IPv6 Internet"  The name of the AF is IP/IP6; again,
>> you probably mean service/application.
>>
>>
>> [nit] "native routing or 6PE"  Not 4PE applications?  ;-)   It seems
>> to me that you can save some ink by ending the sentence after
>> "Internet".
>>
>>
>> ...
>> 194     3.  Modifications to BGP Best Path selection
>>
>> 196        The core of this solution is the ability for an operator to
>> specify
>> 197        the IGP location for which the route reflector should calculate
>> 198        routes.  This can be done on a per route reflector basis, per
>> peer/
>> 199        update group basis, or per peer basis.  This ability enables
>> the
>> 200        route reflector to send to a given set of clients routes with
>> 201        shortest distance to the next hops from the position of the
>> selected
>> 202        IGP location.  This provides for freedom of route reflector
>> physical
>> 203        location, and allows transient or permanent migration of this
>> network
>> 204        control plane function to an arbitrary location.
>>
>> [major] "ability for an operator to specify the IGP location for which
>> the route reflector should calculate routes.  This can be done on a
>> per route reflector basis, per peer/update group basis, or per peer
>> basis."
>>
>> When should an operator choose per RR vs per peer group vs per peer?
>> Choice is good, but providing guidance for the deployment is much
>> better.  Please consider adding text to §6 about the considerations to
>> chose one or the other.
>>
>>
>> [minor] "peer/update group"  Where is this defined?  Is there a
>> reference to a non-implementation-specific definition?  Can it be
>> called "a group of peers"?  Maybe you also want to include it in the
>> definitions in §1.
>>
>>
>> ...
>> 215        o  it can, and usually will, have a different position in the
>> IGP
>> 216           topology, and
>>
>> [] "usually will"   The position in the topology will *always* be
>> different!
>>
>>
>> ...
>> 222        This document defines, on BGP Route Reflectors [RFC4456], two
>> changes
>> 223        to the BGP Best Path selection algorithm:
>>
>> [nit] s/defines, on BGP Route Reflectors/defines, for BGP Route Reflectors
>>
>>
>> ...
>> 235        A route reflector can implement either or both of the
>> modifications
>> 236        in order to allow it to choose the best path for its clients
>> that the
>> 237        clients themselves would have chosen given the same set of
>> candidate
>> 238        paths.
>>
>> [major] Please provide guidance for the operator to consider then one
>> or both should be used in their network.
>>
>>
>> 240        A significant advantage of these approaches is that the route
>> 241        reflector clients do not need to run new software or hardware
--


Gyan Mishra

Network Solutions Architect 

Email [hidden email]

M 301 502-1347



_______________________________________________
Idr mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/idr
Reply | Threaded
Open this post in threaded view
|

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

Robert Raszuk-3
Hi Gyan,

>  Has this feature been implemented by any vendor
  


>  I don’t think hot potato routing is ever desirable where the RR is making the best 
> path decision instead of the client is ever better in the case where the RR is not 
> in the forwarding plane.  

The reason for this comment is that traditionally (or I should rather say historically) when networks were doing hop by hop IP lookup Rs were strictly placed either in the POPs or on the IGP paths to the POPs (or areas). That sort of assured optimal enough path selection. 

However the moment RRs were moved to central locations - or moving to run as logical slices in the cloud this is were ORR really helps to make them distributed optimal paths to clients. 

Thx,
R.

On Tue, May 25, 2021 at 5:22 PM Gyan Mishra <[hidden email]> wrote:

Hi Robert

This is an excellent optimization concept for RR scalability as well as limiting the number of paths per prefix reflected to the clients which can be enormous.

Verizon as well as other internet providers can take advantage of this solution and help reduce the number of paths being reflected to clients.

I support advancement of this draft.

Minor comments on the draft text below:

Introduction paragraph 4 -
I don’t think hot potato routing is ever desirable where the RR is making the best path decision instead of the client is ever better in the case where the RR is not in the forwarding plane.

The evolving model of intra-domain network design has enabled deployments of route reflectors outside of the forwarding path.
   Initially this model was only employed for new services, e.g.  IP
   VPNs [RFC4364], however it has been gradually       extended to other BGP services including IPv4 and IPv6 Internet.  In such environments, hot
   potato routing policy remains desirable.


Has this feature been implemented by any vendor to test the viability and CPU resources necessary related to multiple decision processes due to IGP location change?

Thanks 

Gyan 
On Mon, May 24, 2021 at 12:25 PM Robert Raszuk <[hidden email]> wrote:
Gyan,

This solution selects optimal paths for a given net. As RD is part of the net we would not select paths between nets. 

Note that tp the best of my knowledge we still have a day one option-B problem where two or more ASBRs may give us same net and VPNv4 RRs may choose single one only before advertising to peers. ORR may help here a bit to give different paths to different clients. 

To your other comment sure ORR is not required if we use "add-paths all" or have full IBGP mesh. But I know about networks where for each net there is 100s of paths hence add-path all is not a practical starter. 

Cheers,
R.

On Sun, May 23, 2021 at 12:40 AM Gyan Mishra <[hidden email]> wrote:
For VPN SAFI 128 can this solution be applied as with unique RD all paths
get advertised by the RR and this solution would cut down on the paths
advertised to help with scalability and with many RRs and many exit points.

Thanks
Gyan

On Sat, May 22, 2021 at 6:11 PM Gyan Mishra <[hidden email]> wrote:

> Dear Authors
>
> I have a few comments on this draft.
>
> This is a historical well known issue exists where a RR will compute the
> best path based on IGP topology metric least cost to the exit point and
> will advertise those paths based on the topological position of the RR to
> the exit point.  The major issue is the best path reflected by the RR
> should be based on the Clients IGP shortest path to exit point and the RRs
> shortest path.
>
> A workaround to this issue is RFC 7911 add paths where all paths are
> advertised to all Client PEs as well as all RR as mentioned in section 4
> deployment considerations.  What is missing in the Section 4 verbiage is
> the add path to both RRs and all clients so advertisement of all paths are
> advertised  to all clients as well as RR.  So to  resolve the issue with
> the RR making the best path decision the RR must have add paths send /
> receive MP Reach capability enabled to all clients and must select and
> advertise all paths to all clients so that each client can now make the
> best path decision based on its best path lowest IGP metric to the exit
> point.
>
> Using RFC 7911 add paths to all clients the hot potato issue is resolved.
>
> The caveat with add paths is if you have many RRs and many exist points
> you end up with many paths per prefix in the BGP RIB.
>
> With modern high end routers these days this does not impact scalability
> issues that I am aware of.
>
> With this draft it seems the goal is to only advertise the pertinent paths
> based on the client IGP location rooted topological path to the exit point
> and not advertise all paths.  This would cut down on the number of paths
> advertised by the RR so all paths are not flooded to the clients as the
> current solution today to the hot potato issue.
>
> Am I reading this correctly?
>
> Kind Regards
>
> Gyan
>
> On Thu, Mar 18, 2021 at 3:32 PM Alvaro Retana <[hidden email]>
> wrote:
>
>> Dear authors:
>>
>>
>> Thank you for your work on this document.  I know that the draft and
>> the related ideas have been around for a long time.
>>
>> I have a couple of significant issues that I want to highlight
>> upfront, and many comments inline (see below).  In general, my focus
>> is to make sure that the specification of this mechanism is clear, not
>> just to the experienced reader, but to the casual one as well.  I
>> believe that all the issues should be easy to resolve.
>>
>> (1) Terminology.  Please use the terminology already defined in
>> rfc4271/rfc4456 instead of creating new one by indirection.  My first
>> inline comment is about the use of "best path", which is not what
>> rfc4271 uses -- there are other occurrences later on.
>>
>> (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.]
>>
>> (3) I don't think that §5 (CPU and Memory Scalability) and Appendix A
>> (alternative solutions with limited applicability) should be part of
>> this document.  To start, comparisons are never good and the work has
>> already been through the WG so there's no need to keep justifying it
>> by comparing it to other work.  Both sections contain several claims
>> (e.g. "extra cost in terms of CPU", "implemented efficiently",
>> "expected to be higher but comparable", "large amount of BGP state and
>> churn", "result in tens of paths for each prefix") that don't have
>> references, and could be considered subjective because they are
>> clearly relative and can change depending on the specific deployment
>> and configuration of the network.  I am not saying that the claims are
>> false, simply requesting to take these two sections out.
>>
>>
>> Thanks!
>>
>> Alvaro.
>>
>>
>> [Line numbers from idnits.]
>>
>> ...
>> 17      Abstract
>>
>> 19         This document defines an extension to BGP route reflectors.
>> On route
>> 20         reflectors, BGP route selection is modified in order to choose
>> the
>> 21         best path from the standpoint of their clients, rather than
>> from the
>> 22         standpoint of the route reflectors.  Multiple types of
>> granularity
>> 23         are proposed, from a per client BGP route selection or to a
>> per peer
>> 24         group, depending on the scaling and precision requirements on
>> route
>> 25         selection.  This solution is particularly applicable in
>> deployments
>> 26         using centralized route reflectors, where choosing the best
>> route
>> 27         based on the route reflector IGP location is suboptimal.  This
>> 28         facilitates, for example, best exit point policy (hot potato
>> 29         routing).
>>
>> [major] "best path"  rfc4271 doesn't use the term "best path".  The
>> terminology used in this document should, at the very least, match
>> what the base spec defines.  Let's please not create new terminology
>> by indirection using the "definition of terms" section.
>>
>>
>> [minor] "proposed"  This document is in line to be come an RFC; we're
>> far beyond proposing things.  There are a couple of places later on
>> where this same wording is used.  Please change it to specified or at
>> least described (the latter probably fits best in this specific case).
>>
>>
>> [nit] s/from a per client BGP route selection or to a per peer
>> group/from per client BGP route selection or per peer group
>>
>>
>> [nit] s/precision requirements on route selection./precision requirements.
>>
>>
>> [nit] s/route reflector IGP location/route reflector's IGP location
>>
>>
>> [major] "IGP location"  Before I forget -- please clearly define (not
>> in the Abstract of course) what an "IGP location" is.
>>
>>
>> ...
>> 70         1.  Definitions of Terms Used in This Memo  . . . . . . . . .
>> . .   2
>> 71         2.  Introduction  . . . . . . . . . . . . . . . . . . . . . .
>> . .   3
>>
>> [nit] It would be nice if the Introduction came up before the terminology.
>>
>>
>> ...
>> 91      1.  Definitions of Terms Used in This Memo
>>
>> [minor] To avoid repeating some terms, it is good practice to indicate
>> which other RFCs the reader should be familiar with.  In this case
>> rfc4271 and rfc4456 come to mind.
>>
>>
>> ...
>> 132     2.  Introduction
>> ...
>> 153        Section 11 of [RFC4456] describes a deployment approach and a
>> set of
>> 154        constraints which, if satisfied, would result in the
>> deployment of
>> 155        route reflection yielding the same results as the IBGP full
>> mesh
>> 156        approach.  This deployment approach makes route reflection
>> compatible
>> 157        with the application of hot potato routing policy.  In
>> accordance
>> 158        with these design rules, route reflectors have traditionally
>> often
>> 159        been deployed in the forwarding path and carefully placed on
>> the POP
>> 160        to core boundaries.
>>
>> [nit] s/have traditionally often/have often
>> Redundant...
>>
>>
>> 162        The evolving model of intra-domain network design has enabled
>> 163        deployments of route reflectors outside of the forwarding path.
>> 164        Initially this model was only employed for new address
>> families, e.g.
>> 165        L3VPNs and L2VPNs, however it has been gradually extended to
>> other
>> 166        BGP address families including IPv4 and IPv6 Internet using
>> either
>> 167        native routing or 6PE.  In such environments, hot potato
>> routing
>> 168        policy remains desirable.
>>
>> [minor] "new address families, e.g. L3VPNs and L2VPNs"  These are not
>> the name of the AFs.  Maybe call them new services.
>>
>>
>> [minor] "IPv4 and IPv6 Internet"  The name of the AF is IP/IP6; again,
>> you probably mean service/application.
>>
>>
>> [nit] "native routing or 6PE"  Not 4PE applications?  ;-)   It seems
>> to me that you can save some ink by ending the sentence after
>> "Internet".
>>
>>
>> ...
>> 194     3.  Modifications to BGP Best Path selection
>>
>> 196        The core of this solution is the ability for an operator to
>> specify
>> 197        the IGP location for which the route reflector should calculate
>> 198        routes.  This can be done on a per route reflector basis, per
>> peer/
>> 199        update group basis, or per peer basis.  This ability enables
>> the
>> 200        route reflector to send to a given set of clients routes with
>> 201        shortest distance to the next hops from the position of the
>> selected
>> 202        IGP location.  This provides for freedom of route reflector
>> physical
>> 203        location, and allows transient or permanent migration of this
>> network
>> 204        control plane function to an arbitrary location.
>>
>> [major] "ability for an operator to specify the IGP location for which
>> the route reflector should calculate routes.  This can be done on a
>> per route reflector basis, per peer/update group basis, or per peer
>> basis."
>>
>> When should an operator choose per RR vs per peer group vs per peer?
>> Choice is good, but providing guidance for the deployment is much
>> better.  Please consider adding text to §6 about the considerations to
>> chose one or the other.
>>
>>
>> [minor] "peer/update group"  Where is this defined?  Is there a
>> reference to a non-implementation-specific definition?  Can it be
>> called "a group of peers"?  Maybe you also want to include it in the
>> definitions in §1.
>>
>>
>> ...
>> 215        o  it can, and usually will, have a different position in the
>> IGP
>> 216           topology, and
>>
>> [] "usually will"   The position in the topology will *always* be
>> different!
>>
>>
>> ...
>> 222        This document defines, on BGP Route Reflectors [RFC4456], two
>> changes
>> 223        to the BGP Best Path selection algorithm:
>>
>> [nit] s/defines, on BGP Route Reflectors/defines, for BGP Route Reflectors
>>
>>
>> ...
>> 235        A route reflector can implement either or both of the
>> modifications
>> 236        in order to allow it to choose the best path for its clients
>> that the
>> 237        clients themselves would have chosen given the same set of
>> candidate
>> 238        paths.
>>
>> [major] Please provide guidance for the operator to consider then one
>> or both should be used in their network.
>>
>>
>> 240        A significant advantage of these approaches is that the route
>> 241        reflector clients do not need to run new software or hardware
--


Gyan Mishra

Network Solutions Architect 

Email [hidden email]

M 301 502-1347



_______________________________________________
Idr mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/idr
Reply | Threaded
Open this post in threaded view
|

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

Gyan Mishra

Makes sense.  

Looks like ORR has already been implemented by vendors.  Good news!! 👍😀



Kind Regards 

Gyan

On Tue, May 25, 2021 at 11:35 AM Robert Raszuk <[hidden email]> wrote:
Hi Gyan,

>  Has this feature been implemented by any vendor
  


>  I don’t think hot potato routing is ever desirable where the RR is making the best 
> path decision instead of the client is ever better in the case where the RR is not 
> in the forwarding plane.  

The reason for this comment is that traditionally (or I should rather say historically) when networks were doing hop by hop IP lookup Rs were strictly placed either in the POPs or on the IGP paths to the POPs (or areas). That sort of assured optimal enough path selection. 

However the moment RRs were moved to central locations - or moving to run as logical slices in the cloud this is were ORR really helps to make them distributed optimal paths to clients. 

Thx,
R.

On Tue, May 25, 2021 at 5:22 PM Gyan Mishra <[hidden email]> wrote:

Hi Robert

This is an excellent optimization concept for RR scalability as well as limiting the number of paths per prefix reflected to the clients which can be enormous.

Verizon as well as other internet providers can take advantage of this solution and help reduce the number of paths being reflected to clients.

I support advancement of this draft.

Minor comments on the draft text below:

Introduction paragraph 4 -
I don’t think hot potato routing is ever desirable where the RR is making the best path decision instead of the client is ever better in the case where the RR is not in the forwarding plane.

The evolving model of intra-domain network design has enabled deployments of route reflectors outside of the forwarding path.
   Initially this model was only employed for new services, e.g.  IP
   VPNs [RFC4364], however it has been gradually       extended to other BGP services including IPv4 and IPv6 Internet.  In such environments, hot
   potato routing policy remains desirable.


Has this feature been implemented by any vendor to test the viability and CPU resources necessary related to multiple decision processes due to IGP location change?

Thanks 

Gyan 
On Mon, May 24, 2021 at 12:25 PM Robert Raszuk <[hidden email]> wrote:
Gyan,

This solution selects optimal paths for a given net. As RD is part of the net we would not select paths between nets. 

Note that tp the best of my knowledge we still have a day one option-B problem where two or more ASBRs may give us same net and VPNv4 RRs may choose single one only before advertising to peers. ORR may help here a bit to give different paths to different clients. 

To your other comment sure ORR is not required if we use "add-paths all" or have full IBGP mesh. But I know about networks where for each net there is 100s of paths hence add-path all is not a practical starter. 

Cheers,
R.

On Sun, May 23, 2021 at 12:40 AM Gyan Mishra <[hidden email]> wrote:
For VPN SAFI 128 can this solution be applied as with unique RD all paths
get advertised by the RR and this solution would cut down on the paths
advertised to help with scalability and with many RRs and many exit points.

Thanks
Gyan

On Sat, May 22, 2021 at 6:11 PM Gyan Mishra <[hidden email]> wrote:

> Dear Authors
>
> I have a few comments on this draft.
>
> This is a historical well known issue exists where a RR will compute the
> best path based on IGP topology metric least cost to the exit point and
> will advertise those paths based on the topological position of the RR to
> the exit point.  The major issue is the best path reflected by the RR
> should be based on the Clients IGP shortest path to exit point and the RRs
> shortest path.
>
> A workaround to this issue is RFC 7911 add paths where all paths are
> advertised to all Client PEs as well as all RR as mentioned in section 4
> deployment considerations.  What is missing in the Section 4 verbiage is
> the add path to both RRs and all clients so advertisement of all paths are
> advertised  to all clients as well as RR.  So to  resolve the issue with
> the RR making the best path decision the RR must have add paths send /
> receive MP Reach capability enabled to all clients and must select and
> advertise all paths to all clients so that each client can now make the
> best path decision based on its best path lowest IGP metric to the exit
> point.
>
> Using RFC 7911 add paths to all clients the hot potato issue is resolved.
>
> The caveat with add paths is if you have many RRs and many exist points
> you end up with many paths per prefix in the BGP RIB.
>
> With modern high end routers these days this does not impact scalability
> issues that I am aware of.
>
> With this draft it seems the goal is to only advertise the pertinent paths
> based on the client IGP location rooted topological path to the exit point
> and not advertise all paths.  This would cut down on the number of paths
> advertised by the RR so all paths are not flooded to the clients as the
> current solution today to the hot potato issue.
>
> Am I reading this correctly?
>
> Kind Regards
>
> Gyan
>
> On Thu, Mar 18, 2021 at 3:32 PM Alvaro Retana <[hidden email]>
> wrote:
>
>> Dear authors:
>>
>>
>> Thank you for your work on this document.  I know that the draft and
>> the related ideas have been around for a long time.
>>
>> I have a couple of significant issues that I want to highlight
>> upfront, and many comments inline (see below).  In general, my focus
>> is to make sure that the specification of this mechanism is clear, not
>> just to the experienced reader, but to the casual one as well.  I
>> believe that all the issues should be easy to resolve.
>>
>> (1) Terminology.  Please use the terminology already defined in
>> rfc4271/rfc4456 instead of creating new one by indirection.  My first
>> inline comment is about the use of "best path", which is not what
>> rfc4271 uses -- there are other occurrences later on.
>>
>> (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.]
>>
>> (3) I don't think that §5 (CPU and Memory Scalability) and Appendix A
>> (alternative solutions with limited applicability) should be part of
>> this document.  To start, comparisons are never good and the work has
>> already been through the WG so there's no need to keep justifying it
>> by comparing it to other work.  Both sections contain several claims
>> (e.g. "extra cost in terms of CPU", "implemented efficiently",
>> "expected to be higher but comparable", "large amount of BGP state and
>> churn", "result in tens of paths for each prefix") that don't have
>> references, and could be considered subjective because they are
>> clearly relative and can change depending on the specific deployment
>> and configuration of the network.  I am not saying that the claims are
>> false, simply requesting to take these two sections out.
>>
>>
>> Thanks!
>>
>> Alvaro.
>>
>>
>> [Line numbers from idnits.]
>>
>> ...
>> 17      Abstract
>>
>> 19         This document defines an extension to BGP route reflectors.
>> On route
>> 20         reflectors, BGP route selection is modified in order to choose
>> the
>> 21         best path from the standpoint of their clients, rather than
>> from the
>> 22         standpoint of the route reflectors.  Multiple types of
>> granularity
>> 23         are proposed, from a per client BGP route selection or to a
>> per peer
>> 24         group, depending on the scaling and precision requirements on
>> route
>> 25         selection.  This solution is particularly applicable in
>> deployments
>> 26         using centralized route reflectors, where choosing the best
>> route
>> 27         based on the route reflector IGP location is suboptimal.  This
>> 28         facilitates, for example, best exit point policy (hot potato
>> 29         routing).
>>
>> [major] "best path"  rfc4271 doesn't use the term "best path".  The
>> terminology used in this document should, at the very least, match
>> what the base spec defines.  Let's please not create new terminology
>> by indirection using the "definition of terms" section.
>>
>>
>> [minor] "proposed"  This document is in line to be come an RFC; we're
>> far beyond proposing things.  There are a couple of places later on
>> where this same wording is used.  Please change it to specified or at
>> least described (the latter probably fits best in this specific case).
>>
>>
>> [nit] s/from a per client BGP route selection or to a per peer
>> group/from per client BGP route selection or per peer group
>>
>>
>> [nit] s/precision requirements on route selection./precision requirements.
>>
>>
>> [nit] s/route reflector IGP location/route reflector's IGP location
>>
>>
>> [major] "IGP location"  Before I forget -- please clearly define (not
>> in the Abstract of course) what an "IGP location" is.
>>
>>
>> ...
>> 70         1.  Definitions of Terms Used in This Memo  . . . . . . . . .
>> . .   2
>> 71         2.  Introduction  . . . . . . . . . . . . . . . . . . . . . .
>> . .   3
>>
>> [nit] It would be nice if the Introduction came up before the terminology.
>>
>>
>> ...
>> 91      1.  Definitions of Terms Used in This Memo
>>
>> [minor] To avoid repeating some terms, it is good practice to indicate
>> which other RFCs the reader should be familiar with.  In this case
>> rfc4271 and rfc4456 come to mind.
>>
>>
>> ...
>> 132     2.  Introduction
>> ...
>> 153        Section 11 of [RFC4456] describes a deployment approach and a
>> set of
>> 154        constraints which, if satisfied, would result in the
>> deployment of
>> 155        route reflection yielding the same results as the IBGP full
>> mesh
>> 156        approach.  This deployment approach makes route reflection
>> compatible
>> 157        with the application of hot potato routing policy.  In
>> accordance
>> 158        with these design rules, route reflectors have traditionally
>> often
>> 159        been deployed in the forwarding path and carefully placed on
>> the POP
>> 160        to core boundaries.
>>
>> [nit] s/have traditionally often/have often
>> Redundant...
>>
>>
>> 162        The evolving model of intra-domain network design has enabled
>> 163        deployments of route reflectors outside of the forwarding path.
>> 164        Initially this model was only employed for new address
>> families, e.g.
>> 165        L3VPNs and L2VPNs, however it has been gradually extended to
>> other
>> 166        BGP address families including IPv4 and IPv6 Internet using
>> either
>> 167        native routing or 6PE.  In such environments, hot potato
>> routing
>> 168        policy remains desirable.
>>
>> [minor] "new address families, e.g. L3VPNs and L2VPNs"  These are not
>> the name of the AFs.  Maybe call them new services.
>>
>>
>> [minor] "IPv4 and IPv6 Internet"  The name of the AF is IP/IP6; again,
>> you probably mean service/application.
>>
>>
>> [nit] "native routing or 6PE"  Not 4PE applications?  ;-)   It seems
>> to me that you can save some ink by ending the sentence after
>> "Internet".
>>
>>
>> ...
>> 194     3.  Modifications to BGP Best Path selection
>>
>> 196        The core of this solution is the ability for an operator to
>> specify
>> 197        the IGP location for which the route reflector should calculate
>> 198        routes.  This can be done on a per route reflector basis, per
>> peer/
>> 199        update group basis, or per peer basis.  This ability enables
>> the
>> 200        route reflector to send to a given set of clients routes with
>> 201        shortest distance to the next hops from the position of the
>> selected
>> 202        IGP location.  This provides for freedom of route reflector
>> physical
>> 203        location, and allows transient or permanent migration of this
>> network
>> 204        control plane function to an arbitrary location.
>>
>> [major] "ability for an operator to specify the IGP location for which
>> the route reflector should calculate routes.  This can be done on a
>> per route reflector basis, per peer/update group basis, or per peer
>> basis."
>>
>> When should an operator choose per RR vs per peer group vs per peer?
>> Choice is good, but providing guidance for the deployment is much
>> better.  Please consider adding text to §6 about the considerations to
>> chose one or the other.
>>
>>
>> [minor] "peer/update group"  Where is this defined?  Is there a
>> reference to a non-implementation-specific definition?  Can it be
>> called "a group of peers"?  Maybe you also want to include it in the
>> definitions in §1.
>>
>>
>> ...
>> 215        o  it can, and usually will, have a different position in the
>> IGP
>> 216           topology, and
>>
>> [] "usually will"   The position in the topology will *always* be
>> different!
>>
>>
>> ...
>> 222        This document defines, on BGP Route Reflectors [RFC4456], two
>> changes
>> 223        to the BGP Best Path selection algorithm:
>>
>> [nit] s/defines, on BGP Route Reflectors/defines, for BGP Route Reflectors
>>
>>
>> ...
>> 235        A route reflector can implement either or both of the
>> modifications
>> 236        in order to allow it to choose the best path for its clients
>> that the
>> 237        clients themselves would have chosen given the same set of
>> candidate
>> 238        paths.
>>
>> [major] Please provide guidance for the operator to consider then one
>> or both should be used in their network.
>>
>>
>> 240        A significant advantage of these approaches is that the route
>> 241        reflector clients do not need to run new software or hardware
--


Gyan Mishra

Network Solutions Architect 

Email [hidden email]

M 301 502-1347


--


Gyan Mishra

Network Solutions Architect 

Email [hidden email]

M 301 502-1347



_______________________________________________
Idr mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/idr
Reply | Threaded
Open this post in threaded view
|

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

bruno.decraene-2
In reply to this post by Alvaro Retana-2
Alvaro,

> From: Alvaro Retana [mailto:[hidden email]]
> Sent: Friday, May 21, 2021 8:58 PM
>
> On May 12, 2021 at 5:02:25 AM, [hidden email] 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.

_______________________________________________
Idr mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/idr
Reply | Threaded
Open this post in threaded view
|

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

Alvaro Retana-2
On May 28, 2021 at 9:29:20 AM, [hidden email] wrote:


Bruno:

Hi!

I just have a couple of minor comments -- I think we're ready to move
forward. :-)

Thanks!

Alvaro.



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

[nit] s/is identified/it is identified


...

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

Suggestion>

   If a backup location is provided, it is used when the primary IGP location
   disappears from the IGP (i.e. fails). Just like the failure of a RR
   [RFC4456], it 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 primary and the backup IGP locations: the smaller the distance
   the smaller the potential impact.


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

Feel free to submit it whenever you're ready.

_______________________________________________
Idr mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/idr
Reply | Threaded
Open this post in threaded view
|

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

bruno.decraene-2
Alvaro,

Thank you for your comments and suggestions.

Both included in -24 just posted.

Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-optimal-route-reflection
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgp-optimal-route-reflection-24

Regards,
--Bruno

> -----Original Message-----
> From: Alvaro Retana [mailto:[hidden email]]
> Sent: Friday, May 28, 2021 7:58 PM
> To: DECRAENE Bruno TGI/OLN <[hidden email]>
> Cc: Susan Hares <[hidden email]>; [hidden email]; draft-ietf-idr-bgp-
> [hidden email]; IDR List <[hidden email]>
> Subject: RE: AD Review of draft-ietf-idr-bgp-optimal-route-reflection-22
>
> On May 28, 2021 at 9:29:20 AM, [hidden email] wrote:
>
>
> Bruno:
>
> Hi!
>
> I just have a couple of minor comments -- I think we're ready to move
> forward. :-)
>
> Thanks!
>
> Alvaro.
>
>
>
> ...
> > 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.
>
> [nit] s/is identified/it is identified
>
>
> ...
> > 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)
>
> Suggestion>
>
>    If a backup location is provided, it is used when the primary IGP location
>    disappears from the IGP (i.e. fails). Just like the failure of a RR
>    [RFC4456], it 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 primary and the backup IGP locations: the smaller the
> distance
>    the smaller the potential impact.
>
>
> ...
> > Since we are during the IETF LC, I'll delay the update until you told me so.
>
> Feel free to submit it whenever you're ready.

_________________________________________________________________________________________________________________________

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.

_______________________________________________
Idr mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/idr