Hello
I have been selected to do a routing directorate “early” review of this draft: https://datatracker.ietf.org/doc/html/draft-ietf-idr-vpn-prefix-orf-21.
The routing directorate will, on request from the working group chair, perform an “early” review of a draft before it is submitted for publication to the IESG. 
The early review can be performed at any time during the draft’s lifetime as a working group document. 
As this document is in working group last call, my focus for the review was to determine whether the document is ready to be published. Please consider my comments along with the other working group last call comments.

For more information about the Routing Directorate, please see https://wiki.ietf.org/en/group/rtg/RtgDir

Document:   https://datatracker.ietf.org/doc/html/draft-ietf-idr-vpn-prefix-orf-21.
Reviewer:  Alexander ("Sasha") Vainshtein
Review Date: 15-Sep-25
Intended Status: Experimental

Summary: I have some minor concerns about this document that I think should be resolved before it is submitted to the IESG.

Comments:

Overview:
I have been requested to review the -20 version of the draft in question, but the -21 version has been posted 5 days ago.
Therefore, my review refers to the -21 version.

The draft builds on the already published ORF documents and cannot be understood without prior knowledge and understanding of these documents.

I have noticed that originally the authors have been requesting the Standards Track status for their draft, and the intended status has been changed to Experimental due to lack of agreement between the operators on whether the proposed mechanism would be beneficial or dangerous.

I started an email discussion with the authors regarding some questions I had for the draft. The authors have been responsive, but due to lack of time this interaction was short and incomplete.

In my review I have concentrated on the examples provided in section 4.1 and the text in Section 10.1. My guess is that the title of this section ("Implementation considerations", same as the title of Section 10) is both a repetition and a misnomer. 

Major Issues:  Not found

Minor Issues:

1.	My general impression is that the draft inherently assumes presence of some "monitoring" entity that would analyze network-wide configuration based on analysis of all VPN-IP routes received by a given PE and differentiate, e.g.  between scenarios described in Section 4.1.1, 4.1.2 and 4.1.3.  If this impression is correct, an explicit definition of this entity and the logic it implements should be provided in the draft (see also issue #3 below)
2.	The mechanism defined in the draft inherently presumes existence of a management entity that would set the quotas as described in Section 10.1 and, what is even more important, request withdrawal of ORFs that have been issued by various PEs if/when they are not needed any more (according to the text in Section 8 this is the only way ORFs can be withdrawn). If this impression is correct, then, from my POV:
a.	This should be explicitly stated in the draft
b.	The draft should be augmented by a YANG module that defines the data model required for operation of this management entity (I have noticed that the need for a YANG module is mentioned also in the shepherd review) – probably in a separate document
3.	I think that the notion of intersection mentioned in Section 10 requires additional clarification. E.g., my interpretation of this notion suggests that PE1 in the example described in Section 4.1.2 could only originate an ORF with RT values set to RT1 and RT2 only if the quotas for both VPNs in this PE are exceeded. (I have sent a question about my perceived contradiction between Section 4.1.2 and Section 10.1, but the response was not clear enough (may be my personal problem)
4.	Section 8 of the draft says that the operator can "identify the entries that are needed to be withdrawn and manually trigger the withdraw process as described in [RFC5291]".  I have looked up RFC 5291 regarding withdrawal of specific ORF, but it only says:
<quote>
  If the speaker receives from the peer a ROUTE-REFRESH message without
   any ORF entries, then the speaker sends to the peer all routes from
   the Adj-RIB-Out associated with the peer whose AFI/SAFI is the same
   as what is carried in the message and taking into account the ORFs
   (if any) previously received from the peer.
<end quote>
I.e., from my POV withdrawal of specific previously issued ORFs is not specified in RFC 5291.  


Nits:
I have not run the nits check on the draft. However, to me the items below are nits.

1.	The above-mentioned repetition of the Section title (Sections 10 and 10.1) 
2.	Section 4.1.2 item "a" says: "Since VPN2 VRF requires the VPN routes with RT1" – but Figure 2 shows VPN2 as using only RT2.

Hopefully, these notes will be useful.

Regards,
Sasha