Thanks for the updates - clearing my discuss.

Thanks to Scott K. for the SECDIR review and Keyur P. for the shepherds write up, both were very helpful.

Here are some additional comments where I think the text can be improved.


* Is the first sentence here supposed to have an `If` in the front of it?
> 502	   The receiving and sending BGP peers are iBGP peers within the same
> 503	   Autonomous System (AS).  The VPN instance identification information
> 504	   consists of the RD, and the instruction information is sent using ORF
> 505	   within the ROUTE-REFRESH message.


* This pseudo code procedure doesn’t make sense, you should never reach S10a should you?
> 552	   S07.             For each other VRF u on this device {
> 553	   S08.                 If (r is in the import RT list of VRF u) {
> 554	   S09.                     conflict_exists = TRUE;
> 555	   S09a                     break;
> 556	   S10.                 }
> 557	   S10a                 If (conflict_exists == TRUE) {
> 558	   S10b                     break;
> 559	   S10c                 }
> 560	   S11.             }
Is `S15` also effectively include a `break`?  I’m not sure what pseudo-code language is used or its rules; if its C-like that code would still fall through to `S20`, which I believe to be incorrect.


* Is there any text that could be added as to how/why this is experimental?  Is there anyway (empirical metric) that one might want to compare this approach to managing VRF resources versus the mechanisms listed in §3?

Thanks to Scott Kelly for their (early) secdir review.

Section 8 para 1:  Can the authors elaborate on the security issue that arises when the per-peer limit is reached/exceeded?  What is the consequence of ignoring all newly received entries?

Section 8, para 2:  editorial - I would reword this to say, 'Security considerations for this work are the same as what is documented in [RFC 4271]'.  I would also make this the first paragraph....

Thanks for addressing my previous blocking DISCUSS points (see: https://mailarchive.ietf.org/arch/msg/idr/1Db1NaGgmjligb-LYqZFbjNjO_o/ )

I reviewed this document and found no transport-related issues. I do have the following 3 COMMENTS:

(1) When I read it, I didn't note any requirements in section 3. Would it make sense to swap the order of sections 2 and 3?

(2) NiT: The document says both (1 bits) and (1 bit) - For me, the latter reads correct.

(3) I am curious because it looks like there is no clear normative description of how a receiver will handle the 3rd value of the 4-bit Action field: Ought this to specify the receiver processing when the field has the value 3? 

Looking at RFC5291, indeed it says:
      Action is a two-bit field.  The value of this field is 0 for ADD, 1 for REMOVE, and 2 for REMOVE-ALL.
However in RFC5291, I did later read:
" If any of the fields of an ORF entry in the message
   contains an unrecognized value, the whole specified ORF previously
   received is removed."
- which alas does not use not normative language.
Should this receiver processing be specified here explicitly?

Best wishes,
Gorry

Hi Wei, Aijun, Haibo, Gyan, and Jie, 

Thank you for the discussion and changes made so far. I updated my ballot [1][2] to reflect the changes made in 37 vs 40 and 40 vs. 42 [3].

I'm keeping the COMMENT part for which I don't see relevant changes agreed in the email discussion (search for UPDATE below):

# Keyur included the following in his write-up:

“The third version of the text was clear, but the operators were split in
their opinion on whether the functions was valuable or dangerous.”

I would expect the document to include a discussion of the potential issues that need assessment for confirmation/information as a part of the experimental work.

Can we please have such discussion in the document?

UPDATE: "[WAJ] We will try to add one additional section in section 7 "Operational Considerations" to discuss the possible challenges that are arose from this mechanism."

# Experiment Goals

I suggest to move at least appendix ”Experimental topology” to be in the main body for better visibility of the intended scope. I also suggest that text to be expanded to cover some items that will be assessed and used as objective criteria to declare success or failure. For example, it would be helpful to have some data about:

* impact on the routing stability
* impact on the CPU vs configuration
* overall efficiency 
* tune the quota formula and its optimization
* operational complications

UPDATE: "[WAJ] We will try to add one general intra-domain topology in the beginning of the section 7, and analyze the above concerns." 

## Also, the following should be part of the assessment in the exp, unless you already have data to back the claims:

   However, PEs still need to parse the incoming BGP messages,
   which consumes CPU cycles and further burdens the overloaded PE.

This is still applicable even with the feature in the draft if the peer does not honor the signal.

## The following may have implication on stability. Please consider adding assessing that impact as part of the aspects to be assessed during exp work:

CURRENT:
   Each device makes a local judgment to determine whether
   it needs to send a VPN Prefix ORF message to its upstream peer.

UPDATE: "[WAJ] The above is just "qualitative analysis", not "quantitative analysis".  Is there any inaccurate for the " qualitative analysis "?
And, if the peer does not honor the signal, it fallbacks to the existing solution and then is not the fault of the proposed VPN prefix ORF mechanism?" There is not text calling out this issue.

# Missing citation

CURRENT:
*  Provider Edge (PE) - Customer Edge (CE) edge peer Maximum Prefix

You may cite rfc9182#section-7.6.3.2 (bgp-max-prefix, warning-threshold,
violate-action).

UPDATE: "[WAJ] Will add the reference.", but I don't see it implemented.

Cheers,
Med

[1] First ballot: https://mailarchive.ietf.org/arch/msg/idr/7D3PK6tKs4_LCwHQ8604JqTKW4Y/

[2] Second ballot: https://mailarchive.ietf.org/arch/msg/idr/vxHbvtc1uRj_G6fkH4Gp5e0O8LQ/

[3] Changes since my first ballot: https://author-tools.ietf.org/iddiff?url1=draft-ietf-idr-vpn-prefix-orf-37&url2=draft-ietf-idr-vpn-prefix-orf-42&difftype=--html