Telechat Review of draft-ietf-idr-vpn-prefix-orf-37
review-ietf-idr-vpn-prefix-orf-37-intdir-telechat-muite-2026-04-25-00

I am the assigned int-dir reviewer for this draft. These comments were written
with the intent of improving the Internet area aspects of the IETF drafts.
Please wait for direction from your document shepherd or AD before posting a
new version of the draft. For background on int-dir, please see the
[FAQ](https://wiki.ietf.org/en/group/intdir).

Summary:
The draft proposes a mechanism to allow signaling of when too much VPN traffic
is being sent on BGP routed network. This enables the traffic to be filtered on
the sender side, thereby freeing up resources on the BGP router.  The aim of
the draft is to enable people to implement it to see if it will be helpful, so
it is classified as experimental.

Major issues:
Entries in Table 1, do not reflect content in paragraph above it.  This would
affect implementation efforts.

In Figure 1, why is the match bit required if it is always set to 1? In section
5.2, why would the MATCH bit be PERMIT?  Figure 1 indicates this should not
occur. This appears to have been extensively discussed on list, but probably am
missing something. If the match bit is needed and should always be set to 1,
this should be explained in the draft.

In section 7, why would automated removal procedures not be possible? They do
not need to be specified in the current draft, but it is conceivable that some
operators may find good ways to do this in future.

Minor issues:
There does not seem to be any reference in the draft to any initial
experiments.  Maybe a proof of concept could be done by modifying FRRouting or
similar software?  The draft would then become a basis for interoperability
testing and informed discussion of efficiency gains in resource utilization
brought about by this mechanism.

In the abstract, what does it mean for the overload to be within the minimum
range?

In the abstract, what does RT stand for?  Maybe it should be expanded. RT is
expanded as Route Target in the introduction.  It should be expanded in the
abstract where it first appears.

In sections 3.1, 3.2, 3.4 and 3.5 it would be helpful to reference associated
RFCs.

It may be helpful to expand TLV as Type-Length-Value when first introduced in
section 4, see for example
https://www.ietf.org/archive/id/draft-wang-lsr-isis-big-tlv-00.html

In section 5.2 perhaps rephrase
"The VPN Prefix ORF is used mainly to block the unwanted BGP updates"
to
"The VPN Prefix ORF is primarily used to block unwanted BGP updates"

In the acknowledgment perhaps use "We thank" or rather than "Thanks", or
rephrase the sentence to indicate "Jefferey ... are thanked for their valuable
comments on this draft."