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