Summary: Document is technically sound, with minor editorial issues and Nits that need to be addressed

Comments:

  Overview:
    I was selected by the OPSAWG Directorate to review version -20 of the draft. However, by the time of my review the draft had been updated. Therefore, my comments are based on the current version -22.
    
    Overall, I find the concept and technical solution proposed in the draft to be sound and well-structured. The content is easy to comprehend. That said, there are grammatical issues throughout the text that could certainly be improved.
    
  Major Issues: Not found
  
  Minor issues:
  
  1. There are several places where the use of key words does not appear to conform to RFC 2119. I suggest reviewing and/or fixing the text accordingly.
  E.g. 
    - Section 4: "Before originating a VPN Prefix ORF message, the device *should* compare the list of RTs carried by VPN routes..."
    - Section 4: The "default" entry *should* be installed in advance in the VPN Prefixes ORF table
    - Section 5: "For the RR/ASBR, it *should* perform following"
    - Section 5: "Once set and attached to the BGP UPDATE message, its value *should not* be altered along the advertisement path"
    - Section 6: When the BGP ROUTE-REFRESH message carries VPN Prefix ORF entries, it *must* be set as follows..."
    - Section 6.1: "Otherwise, the value of Source PE TLV *should* be set to next hop address"
    - Section 6.3: "the VPN routes with different RTs *may* be assigned to different VRFs on the receiver"
    - Section 8: "The commands *must* include the unique identification information of the target ORF entry" 
  
  2. The title of section 4 says "The general procedures of VPN Prefix ORF mechanism on sender", whereas the content describes the procedures for both the sender and receiver of the ORF. Consider either removing sender from the title, or splitting the section into two, one for the sender and the other for the receiver.
  
  Nits:
  Here is a list of occurrences I found grammatically troublesome and suggest fixing. Due to time constraints, this list may be incomplete.
  Section 1. Introduction
      OLD
        there is lack of appropriate methods to control the flooding of VPN routes within one VRF to avoid overwhelming the process of VPN routes in other VRFs
      NEW
        there is a lack of appropriate methods to control the flooding of VPN routes within one VRF to avoid overwhelming the processing of VPN routes in other VRFs
      END

      OLD
        There are several solutions can be used to alleviate this problem:
      NEW
        There are several solutions that can be used to alleviate this problem:
      END
      
      OLD
        Configure the Maximum Prefix for each VRF on edge nodes
      NEW
        Configuring the Maximum Prefix for each VRF on edge nodes
      END
      
      OLD
        RTC can only filter the VPN routes from any uninterested VRFs, if the
   "offending routes (prefixes)" come from an interested VRF, RTC
   mechanism can't filter them.
      NEW
        RTC can only filter VPN routes from uninterested VRFs, if the
   "offending routes (prefixes)" come from an interested VRF, the RTC
   mechanism cannot filter them.
      END
      
      OLD
        CP-ORF is applicable in Virtual Hub-and-Spoke[RFC7024] VPN and also
   the BGP/MPLS Ethernet VPN (EVPN)[RFC7432] networks, but its main aim
   is get any interested VPN prefixes and can't be used to filter the
   overwhelmed VPN prefixes dynamically.
      NEW
        CP-ORF is applicable in Virtual Hub-and-Spoke[RFC7024] VPNs and also
   BGP/MPLS Ethernet VPN (EVPN)[RFC7432] networks, but its primary function
   is to retrieve interested VPN prefixes and it cannot be used to filter 
   overwhelmed VPN prefixes dynamically.
      END
      
      OLD
        the BGP session will be shut down, which will effect the operation...
      NEW
        the BGP session will be shut down, which will affect the operation...
      END
      s/effect/affect

      OLD
        Configure the Maximum Prefix for each VRF on edge nodes
      NEW
        Configuring the Maximum Prefix for each VRF on edge nodes
      END

      OLD
        However, PEs still need to parse the incoming BGP.
      NEW
        However, PEs still need to parse the incoming BGP messages.
      END

      OLD
        The BGP speaker
   upon receiving a VPN Prefix ORF entry from its BGP peer will filter
   and withdraw any offending VPN routes that was announced to its peer.
      NEW
        Upon receiving a VPN Prefix ORF entry from its BGP peer, the BGP speaker will filter
   and withdraw any offending VPN routes that were announced to its peer.
      END

Section 4
      s/Pefixes/Prefixes
 
      OLD
        The VPN information includes the updated VPN routes and their 
      NEW
        The VPN information includes updated VPN routes and their 
      END

      OLD
        It then checks whether the number of the
   newly added VPN routes has caused the number of total VPN routes to
   exceed the maximum route limit for the associated VPN instance.
      NEW
        It then checks whether the number of 
   newly added VPN routes has caused the total number of VPN routes to
   exceed the maximum route limit for the associated VPN instance.
      END

      OLD
        If the route limit of the VPN instance, which is identified by the
   VPN instance identification information, is reached or is exceeded,
   it will send a VPN Prefix ORF message to the sending BGP peer,
   indicating that the sending BGP peer stop sending the corresponding
   VPN routes which are identified by the VPN instance identification
   information.
      NEW
        If the route limit of the VPN instance, which is identified by the
   VPN instance identification information, is reached or exceeded,
   the receiving BGP peer will send a VPN Prefix ORF message to the sending BGP peer,
   indicating that it should stop sending the corresponding
   VPN routes which are identified by the VPN instance identification
   information.
      END

      OLD
        Before originating a VPN Prefix ORF message, the device should
   compare the list of RTs carried by VPN routes to those are imported
   by other VRFs on the device.  If the route's RT are included in the
   import rules of other VRFs, the VPN Prefix ORF message MUST NOT be
   originated.
      NEW
        Before originating a VPN Prefix ORF message, the device SHOULD
   compare the list of RTs carried by VPN routes with those imported
   by other VRFs on the device.  If the route's RT is included in the
   import rules of other VRFs, the VPN Prefix ORF message MUST NOT be
   originated.
      END

      OLD
        Before sending a VPN Prefix ORF entry, a sender SHOULD send a
   "default" entry to the VPN Prefix ORF receiver, to allow other
   allowed VPN prefixes pass the filter.  The "default" entry should be
   installed in advance in the VPN Pefixes ORF table, with the offending
   VPN routes process method equal to 0, sequence equal to 0xFFFFFFFF,
   length is equal to 8, and Route Distinguisher is equal to 0.        
      NEW
        Before sending a VPN Prefix ORF entry, a sender SHOULD send a
   "default" entry to the VPN Prefix ORF receiver, to allow other
   allowed VPN prefixes to pass the filter.  The "default" entry should be
   installed in advance in the VPN Prefixes ORF table, with the offending
   VPN routes process method set to 0, sequence set to 0xFFFFFFFF,
   length set to 8, and Route Distinguisher set to 0.
      END

      OLD
        The instruction information that sends from the receiving BGP peer
   includes the followings information:
      NEW
         The instruction information sent from the receiving BGP peer
   includes the following information:
      END

      OLD
        The ORF entries that are included in the route-refresh message.
      NEW
        The ORF entries that are included in the ROUTE-REFRESH message.
      END

      OLD
        Set the Action field in the ORF entries to the value that
      instructs adding the corresponding filter condition to the
      outbound route filter of the sending BGP peer.
      NEW
        The Action field in the ORF entries is set to a value that
      instructs the sending BGP peer to add the corresponding filter condition to its
      outbound route filter.
      END

      OLD
        Set the Match field in the ORF entries to the value that instructs
      denying the VPN routes updates that match the corresponding ORF
      entries.
      NEW
        The Match field in the ORF entries is set to a value that instructs
      the sending BGP peer to deny VPN routes updates that match the corresponding ORF
      entries.
      END

      OLD
        When multiple VRFs on a PE is receiving VPN routes with a specific
   RD
      NEW
        When multiple VRFs on a PE are receiving VPN routes with a specific
   RD
      END

      OLD
        The detail procedures for different scenarios are described below
      NEW
        The detailed procedures for different scenarios are described below
      END

   Section 5:
      OLD
        For the RR/ASBR, it should perform as following:
      NEW
        For the RR/ASBR, it SHOULD perform the following:
      END

      OLD
        This section updates route reflection procedures, which means
   [RFC4456] need to be updated.
      NEW
        This section updates route reflection procedures, which means
   [RFC4456] needs to be updated.
      END

   Section 6:
   "A BGP speaker that is willing to receive ORF entries from its peer,
   or a BGP speaker that would like to send ORF entries to its peer,
   advertises this to the peer by using the Outbound Route Filtering
   Capability defined in [RFC5291]"
     What does "this" refer to, the ORF message?

   Section 6.2:
      OLD
        The encoding of Source AS TLV is as follow
      NEW
        The encoding of Source AS TLV is as follows
      END
 
   Section 7:
   s/orignator/originator
   s/The receiver check/The receiver checks
   s/The receiver withdraw/The receiver withdraws
   s/the entries that are needed to /the entries that need to