Early Review of draft-ietf-idr-vpn-prefix-orf-21
review-ietf-idr-vpn-prefix-orf-21-rtgdir-early-vainshtein-2025-09-15-00

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