BGP Optimal Route Reflection (BGP ORR)
draft-ietf-idr-bgp-optimal-route-reflection-28

[Ballot comment]
I only have one nit to add to what others have pointed out.  In Section 3.1:

* "When specifing logical location ..." -- s/specifing/specifying/

[Ballot comment]
Thanks for this document - sounds useful!  And thanks to Dan for the Ops-dir review.

May I please check, is there a YANG data model that covers this functionality?

Regards,
Rob

[Ballot comment]
Thank you for this document; it gives a clear explanation of what is to
be done and why, and I basically only have nit-level comments, with the
exception of the first remark.

Section 4

  This solution can be deployed in traditional hop-by-hop forwarding
  networks as well as in end-to-end tunneled environments.  In networks
  where there are multiple route reflectors and hop-by-hop forwarding
  without encapsulation, such optimizations SHOULD be consistently
  enabled on all route reflectors.  Otherwise, clients may receive an
  inconsistent view of the network, in turn leading to intra-domain
  forwarding loops.

The scope of "forwarding loops" as a potential problem makes me wonder
if the "SHOULD"-level requirement for this avoidance mechanism is the
right choice.

Section 5

Thank you for accepting the wording suggestion from Roman; it's a good
improvement.

I might consider reiterating that there are risks if multiple route
reflectors are present but using different policy/procedures, though the
earlier discussion may suffice.

Section 9.2

Whether RFC 7911 should be normative or informative seems potentially
subject to debate, if deployment of add-path is required in order for
correct operation of optimal route reflectors.

NITS

                                                    This ability enables
  the route reflector to send to a given set of clients routes with
  shortest distance to the next hops from the position of the selected
  IGP location.  [...]

This feels a bit like a garden-path sentence that makes the reader
backtrack to fix their parse tree; commas around "to a given set of
clients" might help but a more substantive restructuring might be
preferred.

                  This provides for freedom of route reflector physical
  location, and allows transient or permanent migration of this network
  control plane function to an arbitrary location.

Pedantically, such a migration seems like it would always have been
possible, just with a potentially significant impact on performance and
route quality; I'd suggest appending a phrase such as "with negligible
impact on performance".

  The choice of specific granularity (route reflector, set of clients,
  or client) 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.

It's not entirely clear to me how a "listed grouping of IGP location"
maps to the previous text.

Section 3.2

  If the required routing optimization is limited to the IGP cost to
  the BGP Next-Hop, only step e) and below as defined [RFC4271] section
  9.1.2.2, needs to be run multiple times.

I think maybe s/and below/and subsequent steps/, and s/as defined/as
defined in/.

Section 4

  route reflectors.  More specifically, the choice of BGP path factors
  in either the IGP cost between the client and the NEXT_HOP (rather

I suggest s/factors in/takes into account/, since "factors in" is
something of a colloquialism.

  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.

I think "step e" has to be scoped to §9.1.2.2 of RFC 4271.

                                                          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 [RFC4456] ones).  [...]

The phrasing in the parenthetical seems surpising to me -- what does
"both" refer to?  I can only see the one "performance of the
single-IGP-location-for-the-whole-routing-instance" situation, which of
course should have equivalent performance to the stock RFC 4456 case.

Section 5

  This extension provides a new metric value using additional
  information for computing routes for BGP router reflectors.  While

s/router/route/

[Ballot comment]
Thank you for the work on this document. I have a couple of very minor comments below, and a non blocking question: it seems to me that this document could have contained the "updates" header wrt RFC 4456. Was this considered by the working group?

Francesca

1. -----

FP: Please expand AS, POP, SPF, IBGP on first use.

2. -----

  The core of this solution is the ability for an operator to specify

FP: I would suggest adding the name and abbreviation BGP ORR here, otherwise it comes as a surprise in section 4.

[Ballot comment]
I'm glad to see this draft moving forward!

I have some comments below, I hope they're helpful.

1. Introduction

  [RFC4456] asserts that, because the IGP cost to a given point in the
  network will vary across routers, "the route reflection approach may
  not yield the same route selection result as that of the full IBGP
  mesh approach."  One practical implication of this assertion is that

Strictly speaking, it’s not an implication of the assertion, it’s an implication of the fact (that is being asserted). So, "... practical implication of this fact is that..." (or just "... implication of this is...").

2. Section 3.1

  One or more backup IGP locations SHOULD be allowed to be specified
  for redundancy.

Doesn’t this depend entirely on what option is chosen, of the three you’ve offered? They are, “per route reflector basis, per set of clients, or per client basis”. In the per client case, what would you use for a backup IGP location? When would you invoke the backup? (I’m imagining that the per-client case would generally use the client’s position in the IGP topology, in fact I imagine most implementations wouldn't force you to configure the IGP location when doing per-client.)

This sentence would also benefit from a forward reference to the additional discussion in Section 4, IMO.

3. Section 3.1.1

I don’t think “BGP prefix” is a term of art, especially not as you’re using it. I think “BGP route” would be better.

4. Section 3.2

The third paragraph talks about applying different policies. While it’s accurate, it’s a bit sparse. It’s very similar to what’s discussed in RFC 7947 Section 2.3, and especially Section 2.3.2.1. Might be worth informatively referencing that?

5. Section 4

When you write “hop-by-hop switching“, I think you mean forwarding, not switching, right?

  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.

That last word “Route” doesn’t need to be there.

  (both should be equal to the [RFC4456] ones)

Both *what* should be equal to the RFC4456 one *what*? Confused.

[Ballot comment]
I'm glad to see this draft moving forward!

I have some comments below, I hope they help.

1. Introduction

  [RFC4456] asserts that, because the IGP cost to a given point in the
  network will vary across routers, "the route reflection approach may
  not yield the same route selection result as that of the full IBGP
  mesh approach."  One practical implication of this assertion is that

Strictly speaking, it’s not an implication of the assertion, it’s an implication of the fact (that is being asserted). So, "... practical implication of this fact is that..." (or just "... implication of this is...").

2. Section 3.1

  One or more backup IGP locations SHOULD be allowed to be specified
  for redundancy.

Doesn’t this depend entirely on what option is chosen, of the three you’ve offered? They are, “per route reflector basis, per set of clients, or per client basis”. In the per client case, what would you use for a backup IGP location? When would you invoke the backup? (I’m imagining that the per-client case would generally use the client’s position in the IGP topology, in fact I imagine most implementations wouldn't force you to configure the IGP location when doing per-client.)

This sentence would also benefit from a forward reference to the additional discussion in Section 4, IMO.

3. Section 3.1.1

I don’t think “BGP prefix” is a term of art, especially not as you’re using it. I think “BGP route” would be better.

4. Section 3.2

The third paragraph talks about applying different policies. While it’s accurate, it’s a bit sparse. It’s very similar to what’s discussed in RFC 7947 Section 2.3, and especially Section 2.3.2.1. Might be worth informatively referencing that?

5. Section 4

When you write “hop-by-hop switching“, I think you mean forwarding, not switching, right?

  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.

That last word “Route” doesn’t need to be there.

  (both should be equal to the [RFC4456] ones)

Both *what* should be equal to the RFC4456 one *what*? Confused.

[Ballot comment]
Thank you to Linda Dunbar for the SECDIR review.

** Section 5.  Minor reframing of text

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

NEW

This extension provides a new metric using additional information for computing routes for BGP router reflectors.  While any improperly used metric could impact the resiliency of the network, this extension does not change the underlying security issues inherent in the existing IBGP per [RFC4456].

** Typos

-- Section 3. Typo. s/consists in using/consists of using/

-- Section 3.1.1.  Typo. s/can not/cannot/

[Ballot comment]
All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 1. , paragraph 5, nit:
-    Initially this model was only employed for new services, e.g.  IP
-                                                                ^
+    Initially this model was only employed for new services, e.g., IP
+                                                                ^

Section 1. , paragraph 5, nit:
-    services including IPv4 and IPv6 Internet.  In such environments, hot
+    services, including the IPv4 and IPv6 Internet.  In such environments, hot
+            +          ++++

Section 3. , paragraph 2, nit:
-    IGP topology, it is identified by an IP address of this node (e.g. a
+    IGP topology, it is identified by an IP address of this node (e.g., a
+                                                                      +

Section 3. , paragraph 5, nit:
-    o  it has a different position in the IGP topology, and
-                                                        ^^^
+    o  it has a different position in the IGP topology, or
+                                                        ^^

Section 3.1.1. , paragraph 2, nit:
-    cost to reach such next hop.  Implementations which can not inform
-                                                          -
+    cost to reach such next hop.  Implementations which cannot inform

Section 1. , paragraph 3, nit:
>  deployments of route reflectors outside of the forwarding path. Initially t
>                                  ^^^^^^^^^^
This phrase is redundant. Consider using "outside".

Section 1. , paragraph 4, nit:
> ains desirable. Route reflectors outside of the forwarding path can be placed
>                                  ^^^^^^^^^^
This phrase is redundant. Consider using "outside".

Section 3.1. , paragraph 7, nit:
> uring next hop metric comparison. However such paths MUST still be considere
>                                  ^^^^^^^
A comma may be missing after the conjunctive/linking adverb "However".

Section 3.2. , paragraph 5, nit:
> imizations SHOULD be enabled in a consistent way on all route reflectors. Ot
>                              ^^^^^^^^^^^^^^^^^^^
Consider replacing this phrase with the adverb "consistently" to avoid
wordiness.

Section 4. , paragraph 6, nit:
> f clients or per client. A more fine grained granularity may translate into m
>                                ^^^^^^^^^^^^
This word is normally spelled with a hyphen.

Section 4. , paragraph 7, nit:
> ce, the lowest precision is achieved but the performance impact is minimal (
>                                    ^^^^
Use a comma before "but" if it connects two independent clauses (unless they
are closely connected and short).

Section 4. , paragraph 7, nit:
> 4456] ones). The ability to run fine grained computations depends on the plat
>                                ^^^^^^^^^^^^
This word is normally spelled with a hyphen.

As required by RFC 4858, template: 2/24/2012

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?

Standard - Augments the bgp route selection process for
route reflectors.  No additional "on-wire" changes are made, but
the BGP route selection process is part of RFC4271, and
the route reflector specification: RFC4456

Is this type of RFC indicated in the title page header? yes

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  This document proposes a solution for BGP route reflectors to allow
  them to choose the best path for their clients that the clients
  themselves would have chosen under the same conditions, without
  requiring further state or any new features to be placed on the
  clients.  This facilitates, for example, best exit point policy (hot
  potato routing).  This solution is primarily applicable in
  deployments using centralized route reflectors.

  The solution relies upon all route reflectors learning all paths
  which are eligible for consideration.  Best path selection is
  performed in each route reflector based on a configured virtual
  location in the IGP.  The location can be the same for all clients or
  different per peer/update group or per peer.  Best path selection can
  also be performed based on user configured policies in each route
  reflector.

Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

  The WG LC was done in 2017.
  The delay in publication is due to waiting for implementatinos
  and shepherd delays.  Susan Hares picked up the draft from
John Scudder.

Document Quality

  Are there existing implementations of the protocol?
  3 implementations since 2018
  https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-optimal-route-reflection%20implementations

  Have a  significant number of vendors indicated their plan to
  implement the specification?  Cisco, Juniper, Nokia are 3 major vendors

Are there any reviewers that  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues?
  RTG-DIR (Daniele Ceccarelli): indicated only NITs.
 
Personnel
  Document Shepherd: Susan  Hares (2nd)
  John Scudder (1st),
Area Director:  Alvaro Retana
RTG-DIR QA: Daniele Ceccarelli
SEC-DIR QA: (TBD)

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

1) Nits,
2) Line by line review (editorial)
  a) editorial on text - sent via xML
  b) requirement for the security section to changer.
3) Checks on the implementation reports
4) sequence of pre-reviews with AD and author resulted in -21.txt
    The sequence of the reviews improved the document to
    include specific changes to the BGP algorithm.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No. 

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

Normal reviews during LC should be sufficient
(OPS-DIR, Sec-DIR, RTG-DIR).
Since Alvaro has a longish queue, I am asking for pre-reviews of this document.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of?

Version -21 has resolved previous concerns with the document.
Version -21 specifies clear changes to the protocol.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Robert Razuk
https://mailarchive.ietf.org/arch/msg/idr/QQGLmHms4_1RhbA-ZEG40FDqh7E

Christian Cassar
https://mailarchive.ietf.org/arch/msg/idr/rwOVV09O4Eiyo79LF0F1N-VX1kc

Erik Aman:
https://mailarchive.ietf.org/arch/msg/idr/zxNF3-mWfqKAw3P799QV9rv4YdE

Kevin Wang:
https://mailarchive.ietf.org/arch/msg/idr/pdbPwnKPAo_w-NwWoZDfDFOIssE

bruno decraene
https://mailarchive.ietf.org/arch/msg/idr/uVf5_VgKitUJKvZvBsDGQ1iQqj8

Contributors:
Stephane Litowski:
https://mailarchive.ietf.org/arch/msg/idr/W3TbSWZxk96WMkHF9CXCnO_ITXY/


Adam Chappell
(reported by John Scudder)
https://mailarchive.ietf.org/arch/msg/idr/W6o1iylmB4-YRYlKo9x_M9-5De8/



(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

IPR:
https://datatracker.ietf.org/ipr/3089/

WG discussion:
https://mailarchive.ietf.org/arch/msg/idr/zWj3pnMIEF8OCrrYYGeMD1ctbB8

WG did not have a problem with the IPR. 

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

strong.  Implementations demonstrate this is useful in the Internet.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

[no]

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

Verbose check done.  The ID nits errors
are bugs in ID NITS.


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

No formal review.

(13) Have all references within this document been identified as
either normative or informative?
yes

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

No

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

No downward normative references.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

No change to existing documents.  This is a new feature.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. 
No IANA Requests

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

No IANA requests.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

No automated reviews.

As required by RFC 4858, template: 2/24/2012

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?

Standard - Augments the bgp route selection process for
route reflectors.  No additional "on-wire" changes are made, but
the BGP route selection process is part of RFC4271, and
the route reflector specification: RFC4456

Is this type of RFC indicated in the title page header? yes

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  This document proposes a solution for BGP route reflectors to allow
  them to choose the best path for their clients that the clients
  themselves would have chosen under the same conditions, without
  requiring further state or any new features to be placed on the
  clients.  This facilitates, for example, best exit point policy (hot
  potato routing).  This solution is primarily applicable in
  deployments using centralized route reflectors.

  The solution relies upon all route reflectors learning all paths
  which are eligible for consideration.  Best path selection is
  performed in each route reflector based on a configured virtual
  location in the IGP.  The location can be the same for all clients or
  different per peer/update group or per peer.  Best path selection can
  also be performed based on user configured policies in each route
  reflector.

Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

  The WG LC was done in 2017.
  The delay in publication is due to waiting for implementatinos
  and shepherd delays.  Susan Hares picked up the draft from
John Scudder.

Document Quality

  Are there existing implementations of the protocol?
  3 implementations since 2018
  https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-optimal-route-reflection%20implementations

  Have a  significant number of vendors indicated their plan to
  implement the specification?  Cisco, Juniper, Nokia are 3 major vendors

Are there any reviewers that  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues?
  RTG-DIR (Daniele Ceccarelli): indicated only NITs.
 
Personnel
  Document Shepherd: Susan  Hares (2nd)
  John Scudder (1st),
Area Director:  Alvaro Retana
RTG-DIR QA: Daniele Ceccarelli
SEC-DIR QA: (TBD)

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

1) Nits,
2) Line by line review (editorial)
  a) editorial on text - sent via xML
  b) requirement for the security section to changer.
3) Checks on the implementation reports
4) sequence of pre-reviews with AD and author resulted in -21.txt
    The sequence of the reviews improved the document to
    include specific changes to the BGP algorithm.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No. 

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

Normal reviews during LC should be sufficient
(OPS-DIR, Sec-DIR, RTG-DIR).
Since Alvaro has a longish queue, I am asking for pre-reviews of this document.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of?

Version -21 has resolved previous concerns with the document.
Version -21 specifies clear changes to the protocol.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Robert Razuk
https://mailarchive.ietf.org/arch/msg/idr/QQGLmHms4_1RhbA-ZEG40FDqh7E

Christian Cassar
https://mailarchive.ietf.org/arch/msg/idr/rwOVV09O4Eiyo79LF0F1N-VX1kc

Erik Aman:
https://mailarchive.ietf.org/arch/msg/idr/zxNF3-mWfqKAw3P799QV9rv4YdE

Kevin Wang:
https://mailarchive.ietf.org/arch/msg/idr/pdbPwnKPAo_w-NwWoZDfDFOIssE

bruno decraene
https://mailarchive.ietf.org/arch/msg/idr/uVf5_VgKitUJKvZvBsDGQ1iQqj8

Contributors:
Stephane Litowski:
(missing)

Adam Chappell
(reported by John Scudder)
https://mailarchive.ietf.org/arch/msg/idr/W6o1iylmB4-YRYlKo9x_M9-5De8/



(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

IPR:
https://datatracker.ietf.org/ipr/3089/

WG discussion:
https://mailarchive.ietf.org/arch/msg/idr/zWj3pnMIEF8OCrrYYGeMD1ctbB8

WG did not have a problem with the IPR. 

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

strong.  Implementations demonstrate this is useful in the Internet.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

[no]

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

Verbose check done.  The ID nits errors
are bugs in ID NITS.


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

No formal review.

(13) Have all references within this document been identified as
either normative or informative?
yes

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

No

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

No downward normative references.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

No change to existing documents.  This is a new feature.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. 
No IANA Requests

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

No IANA requests.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

No automated reviews.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-idr-bgp-optimal-route-reflection-24, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2021-06-07):

From: The IESG
To: IETF-Announce
CC: John Scudder , Susan Hares , aretana.ietf@gmail.com, draft-ietf-idr-bgp-optimal-route-reflection@ietf.org, idr-chairs@ietf.org, idr@ietf.org, shares@ndzh.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (BGP Optimal Route Reflection (BGP-ORR)) to Proposed Standard


The IESG has received a request from the Inter-Domain Routing WG (idr) to
consider the following document: - 'BGP Optimal Route Reflection (BGP-ORR)'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2021-06-07. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document defines an extension to BGP route reflectors.  On route
  reflectors, BGP route selection is modified in order to choose the
  best route from the standpoint of their clients, rather than from the
  standpoint of the route reflectors.  Depending on the scaling and
  precision requirements, route selection can be specific for one
  client, common for a set of clients or common for all clients of a
  route reflector.  This solution is particularly applicable in
  deployments using centralized route reflectors, where choosing the
  best route based on the route reflector's IGP location is suboptimal.
  This facilitates, for example, best exit point policy (hot potato
  routing).

  The solution relies upon all route reflectors learning all paths
  which are eligible for consideration.  BGP Route Selection is
  performed in the route reflectors based on the IGP cost from
  configured locations in the link state IGP.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-optimal-route-reflection/


The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/3089/

Notification list changed to John Scudder <jgs@juniper.net>, Susan Hares <shares@ndzh.com>, aretana.ietf@gmail.com from John Scudder <jgs@juniper.net>, Susan Hares <shares@ndzh.com>

As required by RFC 4858, template: 2/24/2012

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?

Standard - Augments the bgp route selection process for
route reflectors.  No additional "on-wire" changes are made, but
the BGP route selection process is part of RFC4271, and
the route reflector specification: RFC4456

Is this type of RFC indicated in the title page header? yes

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  This document proposes a solution for BGP route reflectors to allow
  them to choose the best path for their clients that the clients
  themselves would have chosen under the same conditions, without
  requiring further state or any new features to be placed on the
  clients.  This facilitates, for example, best exit point policy (hot
  potato routing).  This solution is primarily applicable in
  deployments using centralized route reflectors.

  The solution relies upon all route reflectors learning all paths
  which are eligible for consideration.  Best path selection is
  performed in each route reflector based on a configured virtual
  location in the IGP.  The location can be the same for all clients or
  different per peer/update group or per peer.  Best path selection can
  also be performed based on user configured policies in each route
  reflector.

Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

  The WG LC was done in 2017.
  The delay in publication is due to waiting for implementatinos
  and shepherd delays.  Susan Hares picked up the draft from
John Scudder.

Document Quality

  Are there existing implementations of the protocol?
  3 implementations since 2018
  https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-optimal-route-reflection%20implementations

  Have a  significant number of vendors indicated their plan to
  implement the specification?  Cisco, Juniper, Nokia are 3 major vendors

Are there any reviewers that  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues?
  RTG-DIR (Daniele Ceccarelli): indicated only NITs.
 
Personnel
  Document Shepherd: Susan  Hares (2nd)
  John Scudder (1st),
Area Director:  Alvaro Retana
RTG-DIR QA: Daniele Ceccarelli
SEC-DIR QA: (TBD)

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

1) Nits,
2) Line by line review (editorial)
  a) editorial on text - sent via xML
  b) requirement for the security section to changer.
3) Checks on the implementation reports
4) sequence of pre-reviews with AD and author resulted in -21.txt
    The sequence of the reviews improved the document to
    include specific changes to the BGP algorithm.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No. 

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

Normal reviews during LC should be sufficient
(OPS-DIR, Sec-DIR, RTG-DIR).
Since Alvaro has a longish queue, I am asking for pre-reviews of this document.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of?

Version -21 has resolved previous concerns with the document.
Version -21 specifies clear changes to the protocol.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Robert Razuk
https://mailarchive.ietf.org/arch/msg/idr/QQGLmHms4_1RhbA-ZEG40FDqh7E

Keyur Patel:
https://mailarchive.ietf.org/arch/msg/idr/pdbPwnKPAo_w-NwWoZDfDFOIssE

Christian Cassar
https://mailarchive.ietf.org/arch/msg/idr/rwOVV09O4Eiyo79LF0F1N-VX1kc

Erik Aman:
https://mailarchive.ietf.org/arch/msg/idr/zxNF3-mWfqKAw3P799QV9rv4YdE

Kevin Wang:
https://mailarchive.ietf.org/arch/msg/idr/pdbPwnKPAo_w-NwWoZDfDFOIssE

bruno decraene
https://mailarchive.ietf.org/arch/msg/idr/uVf5_VgKitUJKvZvBsDGQ1iQqj8

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

IPR:
https://datatracker.ietf.org/ipr/3089/

WG discussion:
https://mailarchive.ietf.org/arch/msg/idr/zWj3pnMIEF8OCrrYYGeMD1ctbB8

WG did not have a problem with the IPR. 

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

strong.  Implementations demonstrate this is useful in the Internet.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

[no]

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

Verbose check done.  The ID nits errors
are bugs in ID NITS.


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

No formal review.

(13) Have all references within this document been identified as
either normative or informative?
yes

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

No

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

No downward normative references.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

No change to existing documents.  This is a new feature.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. 
No IANA Requests

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

No IANA requests.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

No automated reviews.

As required by RFC 4858, template: 2/24/2012

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?

Standard - Augments the bgp route selection process for
route reflectors.  No additional "on-wire" changes are made, but
the BGP route selection process is part of RFC4271, and
the route reflector specification: RFC4456

Is this type of RFC indicated in the title page header? yes

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  This document proposes a solution for BGP route reflectors to allow
  them to choose the best path for their clients that the clients
  themselves would have chosen under the same conditions, without
  requiring further state or any new features to be placed on the
  clients.  This facilitates, for example, best exit point policy (hot
  potato routing).  This solution is primarily applicable in
  deployments using centralized route reflectors.

  The solution relies upon all route reflectors learning all paths
  which are eligible for consideration.  Best path selection is
  performed in each route reflector based on a configured virtual
  location in the IGP.  The location can be the same for all clients or
  different per peer/update group or per peer.  Best path selection can
  also be performed based on user configured policies in each route
  reflector.

Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

  The WG LC was done in 2017.
  The delay in publication is due to waiting for implementatinos
  and shepherd delays.  Susan Hares picked up the draft from
John Scudder.

Document Quality

  Are there existing implementations of the protocol?
  3 implementations since 2018
  https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-optimal-route-reflection%20implementations

  Have a  significant number of vendors indicated their plan to
  implement the specification?  Cisco, Juniper, Nokia are 3 major vendors

Are there any reviewers that  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues?
  RTG-DIR (Daniele Ceccarelli): indicated only NITs.
 
Personnel
  Document Shepherd: Susan  Hares (2nd)
  John Scudder (1st),
Area Director:  Alvaro Retana
RTG-DIR QA: Daniele Ceccarelli
SEC-DIR QA: (TBD)

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

1) Nits,
2) Line by line review (editorial)
  a) editorial on text - sent via xML
  b) requirement for the security section to changer.
3) Checks on the implementation reports
4) sequence of pre-reviews with AD and author resulted in -21.txt
    The sequence of the reviews improved the document to
    include specific changes to the BGP algorithm.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No. 

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

Normal reviews during LC should be sufficient
(OPS-DIR, Sec-DIR, RTG-DIR).
Since Alvaro has a longish queue, I am asking for pre-reviews of this document.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of?

Version -21 has resolved previous concerns with the document.
Version -21 specifies clear changes to the protocol.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Robert Razuk
https://mailarchive.ietf.org/arch/msg/idr/QQGLmHms4_1RhbA-ZEG40FDqh7E

Keyur Patel:
https://mailarchive.ietf.org/arch/msg/idr/pdbPwnKPAo_w-NwWoZDfDFOIssE

Christian Cassar
https://mailarchive.ietf.org/arch/msg/idr/rwOVV09O4Eiyo79LF0F1N-VX1kc

Erik Aman:
https://mailarchive.ietf.org/arch/msg/idr/zxNF3-mWfqKAw3P799QV9rv4YdE

Kevin Wang:
https://mailarchive.ietf.org/arch/msg/idr/pdbPwnKPAo_w-NwWoZDfDFOIssE

bruno decraene
https://mailarchive.ietf.org/arch/msg/idr/uVf5_VgKitUJKvZvBsDGQ1iQqj8

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

IPR:
https://datatracker.ietf.org/ipr/3089/

WG discussion:
https://mailarchive.ietf.org/arch/msg/idr/zWj3pnMIEF8OCrrYYGeMD1ctbB8

WG did not have a problem with the IPR. 

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

strong.  Implementations demonstrate this is useful in the Internet.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

[no]

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

Verbose check done.  The ID nits errors
are bugs in ID NITS.


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

No formal review.

(13) Have all references within this document been identified as
either normative or informative?
yes

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

No

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

No downward normative references.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

No change to existing documents.  This is a new feature.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. 
No IANA Requests

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

No IANA requests.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

No automated reviews.

As required by RFC 4858, template: 2/24/2012

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?

Standard - Augments the bgp route selection process for
route reflectors.  No additional "on-wire" changes are made, but
the BGP route selection process is part of RFC4271, and
the route reflector specification: RFC4456

Is this type of RFC indicated in the title page header? yes

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  This document proposes a solution for BGP route reflectors to allow
  them to choose the best path for their clients that the clients
  themselves would have chosen under the same conditions, without
  requiring further state or any new features to be placed on the
  clients.  This facilitates, for example, best exit point policy (hot
  potato routing).  This solution is primarily applicable in
  deployments using centralized route reflectors.

  The solution relies upon all route reflectors learning all paths
  which are eligible for consideration.  Best path selection is
  performed in each route reflector based on a configured virtual
  location in the IGP.  The location can be the same for all clients or
  different per peer/update group or per peer.  Best path selection can
  also be performed based on user configured policies in each route
  reflector.

Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

  The WG LC was done in 2017.
  The delay in publication is due to waiting for implementatinos
  and shepherd delays.  Susan Hares picked up the draft from
John Scudder.

Document Quality

  Are there existing implementations of the protocol?
  3 implementations since 2018
  https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-optimal-route-reflection%20implementations

  Have a  significant number of vendors indicated their plan to
  implement the specification?  Cisco, Juniper, Nokia are 3 major vendors

Are there any reviewers that  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues?
  RTG-DIR (Daniele Ceccarelli): indicated only NITs.
 
Personnel
  Document Shepherd: Susan  Hares (2nd)
  John Scudder (1st),
Area Director:  Alvaro Retana
RTG-DIR QA: Daniele Ceccarelli
SEC-DIR QA: (TBD)

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

1) Nits,
2) Line by line review (editorial)
  a) editorial on text - sent via xML
  b) requirement for the security section to changer.
3) Checks on the implementation reports
4) sequence of pre-reviews with AD and author resulted in -21.txt
    The sequence of the reviews improved the document to
    include specific changes to the BGP algorithm.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No. 

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

Normal reviews during LC should be sufficient
(OPS-DIR, Sec-DIR, RTG-DIR).
Since Alvaro has a longish queue, I am asking for pre-reviews of this document.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of?

Version -21 has resolved previous concerns with the document.
Version -21 specifies clear changes to the protocol.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Robert Razuk
https://mailarchive.ietf.org/arch/msg/idr/QQGLmHms4_1RhbA-ZEG40FDqh7E

Keyur Patel:
https://mailarchive.ietf.org/arch/msg/idr/pdbPwnKPAo_w-NwWoZDfDFOIssE

Christian Cassar
https://mailarchive.ietf.org/arch/msg/idr/rwOVV09O4Eiyo79LF0F1N-VX1kc

Erik Aman:
https://mailarchive.ietf.org/arch/msg/idr/zxNF3-mWfqKAw3P799QV9rv4YdE

Kevin Wang:
https://mailarchive.ietf.org/arch/msg/idr/pdbPwnKPAo_w-NwWoZDfDFOIssE

bruno decraene
https://mailarchive.ietf.org/arch/msg/idr/uVf5_VgKitUJKvZvBsDGQ1iQqj8

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

IPR:
https://datatracker.ietf.org/ipr/3089/

WG discussion:
https://mailarchive.ietf.org/arch/msg/idr/zWj3pnMIEF8OCrrYYGeMD1ctbB8

WG did not have a problem with the IPR. 

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

strong.  Implementations demonstrate this is useful in the Internet.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

[no]

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

Verbose check done.  The ID nits errors
are bugs in ID NITS.


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

No formal review.

(13) Have all references within this document been identified as
either normative or informative?
yes

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

No

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

No downward normative references.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

No change to existing documents.  This is a new feature.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. 
No IANA Requests

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

No IANA requests.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

No automated reviews.

As required by RFC 4858, template: 2/24/2012

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?

Standard - Augments the bgp route selection process for
route reflectors.  No additional "on-wire" changes are made, but
the BGP route selection process is part of RFC4271, and
the route reflector specification: RFC4456

Is this type of RFC indicated in the title page header? yes

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  This document proposes a solution for BGP route reflectors to allow
  them to choose the best path for their clients that the clients
  themselves would have chosen under the same conditions, without
  requiring further state or any new features to be placed on the
  clients.  This facilitates, for example, best exit point policy (hot
  potato routing).  This solution is primarily applicable in
  deployments using centralized route reflectors.

  The solution relies upon all route reflectors learning all paths
  which are eligible for consideration.  Best path selection is
  performed in each route reflector based on a configured virtual
  location in the IGP.  The location can be the same for all clients or
  different per peer/update group or per peer.  Best path selection can
  also be performed based on user configured policies in each route
  reflector.

Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

  The WG LC was done in 2017.
  The delay in publication is due to waiting for implementatinos
  and shepherd delays.  Susan Hares picked up the draft from
John Scudder.

Document Quality

  Are there existing implementations of the protocol?
  3 implementations since 2018
  https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-optimal-route-reflection%20implementations

  Have a  significant number of vendors indicated their plan to
  implement the specification?  Cisco, Juniper, Nokia are 3 major vendors

Are there any reviewers that  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues?
  RTG-DIR (Daniele Ceccarelli): indicated only NITs.
 
Personnel
  Document Shepherd: Susan  Hares (2nd)
  John Scudder (1st),
Area Director:  Alvaro Retana
RTG-DIR QA: Daniele Ceccarelli
SEC-DIR QA: (TBD)

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

1) Nits,
2) Line by line review (editorial)
  a) editorial on text - sent via xML
  b) requirement for the security section to changer.
3) Checks on the implementation reports
4) sequence of pre-reviews with AD and author resulted in -21.txt
    The sequence of the reviews improved the document to
    include specific changes to the BGP algorithm.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No. 

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

Normal reviews during LC should be sufficient
(OPS-DIR, Sec-DIR, RTG-DIR).
Since Alvaro has a longish queue, I am asking for pre-reviews of this document.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of?

Version -21 has resolved previous concerns with the document.
Version -21 specifies clear changes to the protocol.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Robert Razuk
https://mailarchive.ietf.org/arch/msg/idr/QQGLmHms4_1RhbA-ZEG40FDqh7E

Keyur Patel:
https://mailarchive.ietf.org/arch/msg/idr/pdbPwnKPAo_w-NwWoZDfDFOIssE

Christian Cassar
https://mailarchive.ietf.org/arch/msg/idr/rwOVV09O4Eiyo79LF0F1N-VX1kc

Erik Aman:
https://mailarchive.ietf.org/arch/msg/idr/zxNF3-mWfqKAw3P799QV9rv4YdE

Kevin Wang:
https://mailarchive.ietf.org/arch/msg/idr/pdbPwnKPAo_w-NwWoZDfDFOIssE

bruno decraene
https://mailarchive.ietf.org/arch/msg/idr/uVf5_VgKitUJKvZvBsDGQ1iQqj8

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

IPR:
https://datatracker.ietf.org/ipr/3089/

WG discussion:
https://mailarchive.ietf.org/arch/msg/idr/zWj3pnMIEF8OCrrYYGeMD1ctbB8

WG did not have a problem with the IPR. 

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

strong.  Implementations demonstrate this is useful in the Internet.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

[no]

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.




(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

No formal review.

(13) Have all references within this document been identified as
either normative or informative?
yes

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

No

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

No downward normative references.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

No change to existing documents.  This is a new feature.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. 
No IANA Requests

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

No IANA requests.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

No automated reviews.

Status: Await -19 with better Security Considerations.
Send to SEC-DIR, RTG-DIR for 1 Weeek review on Security considerations.


As required by RFC 4858, template: 2/24/2012

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?

Standard - Augments the bgp route selection process for
route reflectors.  No additional "on-wire" changes are made, but
the BGP route selection process is part of RFC4271, and
the route reflector specification: RFC4456

Is this type of RFC indicated in the title page header? yes

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  This document proposes a solution for BGP route reflectors to allow
  them to choose the best path for their clients that the clients
  themselves would have chosen under the same conditions, without
  requiring further state or any new features to be placed on the
  clients.  This facilitates, for example, best exit point policy (hot
  potato routing).  This solution is primarily applicable in
  deployments using centralized route reflectors.

  The solution relies upon all route reflectors learning all paths
  which are eligible for consideration.  Best path selection is
  performed in each route reflector based on a configured virtual
  location in the IGP.  The location can be the same for all clients or
  different per peer/update group or per peer.  Best path selection can
  also be performed based on user configured policies in each route
  reflector.

Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

  The WG LC was done in 2017.
  The delay in publication is due to waiting for implementatinos
  and shepherd delays.  Susan Hares picked up the draft from
John Scudder.

Document Quality

  Are there existing implementations of the protocol?
  3 implementations since 2018
  https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-optimal-route-reflection%20implementations

  Have a  significant number of vendors indicated their plan to
  implement the specification?  Cisco, Juniper, Nokia are 3 major vendors

Are there any reviewers that  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues?
  RTG-DIR (Daniele Ceccarelli): indicated only NITs.
 
Personnel
  Document Shepherd: Susan  Hares (2nd)
  John Scudder (1st),
Area Director:  Alvaro Retana
RTG-DIR QA: Daniele Ceccarelli
SEC-DIR QA: (TBD)

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

1) Nits,
2) Line by line review (editorial)
  a) editorial on text - sent via xML
  b) requirement for the security section to changer.
3) Checks on the implementation reports (

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No.  [TBD]

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

Security section needs QA review.  [TBD version -19]

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of?

See sections on: RFC types (no bits on wire, but route selection process),
IPR claims, and implementations

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Robert Razuk
https://mailarchive.ietf.org/arch/msg/idr/QQGLmHms4_1RhbA-ZEG40FDqh7E

Keyur Patel:
https://mailarchive.ietf.org/arch/msg/idr/pdbPwnKPAo_w-NwWoZDfDFOIssE

Christian Cassar
https://mailarchive.ietf.org/arch/msg/idr/rwOVV09O4Eiyo79LF0F1N-VX1kc

Erik Aman:
https://mailarchive.ietf.org/arch/msg/idr/zxNF3-mWfqKAw3P799QV9rv4YdE

Kevin Wang:
https://mailarchive.ietf.org/arch/msg/idr/pdbPwnKPAo_w-NwWoZDfDFOIssE

bruno decraene
https://mailarchive.ietf.org/arch/msg/idr/uVf5_VgKitUJKvZvBsDGQ1iQqj8

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

IPR:
https://datatracker.ietf.org/ipr/3089/

WG discussion:
https://mailarchive.ietf.org/arch/msg/idr/zWj3pnMIEF8OCrrYYGeMD1ctbB8

WG did not have a problem with the IPR. 

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

strong. 

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

[no]

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.
NITS ok
[TBD]

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

No formal review.

(13) Have all references within this document been identified as
either normative or informative?
yes

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

No

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

No downward normative references.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

No change - an added optional feature for optimal route refresh.
Note: Configuration will indicate this process.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. 
No IANA Requests

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

No IANA requests.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

No automated reviews.

From: "John G. Scudder"
Subject: Re: [Idr] WGLC for draft-ietf-idr-bgp-optimal-route-reflection-14
Date: October 26, 2017 at 6:57:32 PM GMT+3
To: idr@ietf.org
Cc: draft-ietf-idr-bgp-optimal-route-reflection@ietf.org, Hares Susan

Hi All,

This WGLC has concluded. Based on feedback from the WG, we will forward the draft for publication as an RFC. A few notes:

- I have some editorial comments I'll forward as part of the document shepherd process.
- I think the discussion about document status between Robert and Randy didn't conclude other than with implicit agreement to disagree. There was no WG consensus to change the intended status, but I'll note it as part of the shepherd writeup for the IESG to be aware of.
- No objections to publication were raised related to the late IPR disclosure by Cisco.
- Stephane Litkowski, listed in the "authors" section (Section 2 of the draft) hasn't replied regarding IPR. I'll note this in the shepherd writeup.

Thanks,

--John

Request for posting confirmation emailed to previous authors: Robert Raszuk , Christian Cassar , idr-chairs@ietf.org, Bruno Decraene , Kevin Wang , Stephane Litkowski , Erik Aman

Request for posting confirmation emailed to previous authors: "Christian Cassar" , "Kevin Wang" , idr-chairs@ietf.org, "Stephane Litkowski" , "Bruno Decraene" , "Erik Aman" , "Robert Raszuk"