I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-idr-vpn-prefix-orf-36 Reviewer: Peter Yee Review Date: 2026-04-23 IETF LC End Date: 2026-04-13 IESG Telechat date: 2026-04-30 Summary: This draft specifies a new type of Outbound Route Filter used to push back on VPN route suppliers when the receiving entity can no longer hold additional routes in its VPN Routing and Forwarding tables. I’m no expert in BGP and routing, but I found the document somewhat difficult to follow at times, as explained below. If my questions and the issues I raise make no sense, feel free to ignore them. In the meantime, I’ll deem the document Almost Ready. I can understand the concept if not all of the nuance in the document. It's definitely fine for explaining an experiment, and the contemplated promotion to Proposed Standard isn't a stretch. Sorry this took me so long to turn around. I've now read entirely too much about this topic through its references! Major issues: Minor issues: Page 3, last paragraph, 1st sentence: How is “minimum scope” defined? Page 5, section 3.5, 2nd paragraph, 1st sentence: Based on the introduction, I assume that “specific overload routes” means the newest routes are the first to be filtered. Is there any text that discusses how to select routes other than newest first? Oldest last use? Least used? Does it matter? Page 7, “Overload VPN routes process method” bullet item, 1st sentence: I find the instructions for the sender (of the VPN Prefix ORF message) in this sentence confusing. If a VRF would be overloaded by the received VPN routes to the point that it sends a VPN Prefix ORF to the BPG peer that sent the routes, why would does “SHOULD be withdrawn” make any sense in this sentence? Firstly, in my mind, the withdrawing is only done by the BGP peer upon receipt of the message. The sender of the message couldn’t hold the new (overload) routes in one of its VRFs, so I can only assume that it did not put them there, instead sending the message telling the peer to back off. There’s no withdrawing by the sender of the message. Page 7, “Overload VPN routes process method” bullet item, (newly promoted) 2nd sentence (see Nits below to understand what “newly promoted” means): In regards to “SHOULD NOT announce new overload VPN routes”, how would the receiver of the ORF know if new routes will cause an overload? It doesn't inherently know the remaining capacity in the sender's VRF, nor does it know if the VRFs usage or capacity has changed since receiving the message. Page 8, Sequence bullet item, 2nd sentence: Perhaps some hints here would useful to explain just how non-contiguous the sequence numbering should be. Page 11, section 5.1, 4th paragraph, 2nd sentence: what’s the definition of “import rules”? Should the sentence really be asking "If a route's RT is included in other VRFs,...". Also, if the VPN Prefix ORF message is not “originated” then how will the poor, overloaded receiver of the overload routes ever signal a problem to its BGP peer? And is it never allowed to make a decision that frees up VRF space by telling its peer to withdraw other, earlier received routes? Another problem with the sentence is that the “MUST NOT” is predicated on a SHOULD. What's happens if the device does not perform the non-mandatory comparison? Wouldn’t it make sense that if a message MUST NOT be originated than the SHOULD ought to be a MUST? Page 12, S01: I must admit that I'm not really pleased with the use of "VRF" in various ways throughout the document. VRF is defined as a table according to Section 2. Tables don't receive anything. They are places where things (routes that are received) are stored and retrieved. I’m not sure how to fix that, however, and I recognize the BGP VPN community may have its shorthand for these concepts. Page 12, S02: wouldn’t the parenthetical part make more sense as “(the total number of received prefixes plus the number of prefixes already in VRF v...)”? And by “received prefixes”, I mean the set of routes that triggered the VPN Prefix ORF mechanism. I make this suggestion because the VRF can’t hold more than it can hold, so “the total number of prefixes” can exceed VRF v’s configured prefix limit. Page 12, S08: How could the prefix count of VRF u exceed its prefix limit? Wouldn't an ORF be sent on VRF u’s behalf if this were the case? Thus, the right half of the “AND” is always true and therefore unnecessary. Nits/editorial comments: General: Specific: Page 1, Abstract, 2nd sentence: append a space after the period. Page 1, Abstract, 3rd sentence: Insert “the” before “VPN”. Expand the “RT” here. Page 3, section 1, 1st paragraph, 2nd sentence: change “overwhelming” to “overwhelm”. Page 3, 1st bullet item: RFC 4684 discusses the topic, but it does not define the term RTC or even use "Route Target Constraint". It doesn’t even contain the word constraint, and only used “Constrained” and “Constrain” in the title and headers, but never in the body text.\ Page 3, 2nd paragraph after the bullet items, 3rd sentence: I don’t really like the term “overload VPN routes”. I slightly prefer "VPN routes causing [the] overload" to "overload VPN routes". Alternatively, how about defining "overload VPN routes" as meaning those routes that exceed the receiver's ability to store or process, or something along those lines. “Excess VPN routes”, maybe? Also, how would the number of VPN routes in a VRF (which is a table) exceed the prefix limit anyhow? If there are too many, they just don’t fit in the table. Page 4, section 2, ASBR entry: delete the period. Page 4, section 2, MPLS entry: delete the period. Page 4, section 2, RIB entry: delete the period. Page 4, section 2, RR entry: Expand “IBGP”. This acronym is not on the RFC Editor's list of those that do not require expansion on first use. Also, although I can't determine why, "IBGP" usage changed between RFC 7606 and RFC 7705, so that newer RFCs seem to employ "iBGP". This document has inconsistent usage. Choose one and stick with it. I will note that the RFC Editor only lists "IBGP" in their abbreviations list. Page 4, section 2, VPN entry: change “Networks” to “Network”. That would match usage in the title of RFC 4364. The plural acronym would then be VPNs. Page 4, section 2, VRF definition: RFC 4364 conflictingly(?) defines this initialism as VPN Routing and Forwarding. Many other non-IETF uses say "Virtual Routing and Forwarding". I can't tell which is correct. Change the definition to have “and” between “Routing” and “Forwarding”. Either insert “a” before “VPN instance” or change that to “VPN instances”. Delete the period at the end of the definition. Page 5, section 3.4, 2nd sentence: the term “overflow” is now used for seems to be the previously used “overload”. Make them consistent unless there’s some difference in meaning. (There’s definitely a difference in usage, of course.) Overflow appears in 7 places in the document. I still don’t know how a VRF can be overloaded or overflow, as a fixed-size table, but it can certainly suffer from being supplied with too many routes to accommodate. Page 6, section 4, 1st paragraph, 2nd to last sentence: change “criteria” to “criterion”. Page 6, 2nd bullet item before Table 1, last sentence: delete “the” before “Table 1”. Page 6, Table 1: consider renaming this as “Allowed SAFI and AFI combinations” for brevity and clarity. Page 7, Action bullet item, 2nd sentence: change “contain” to “contains”. Insert “an” before the 2nd “ORF”. Page 7, “Overload VPN routes process method” bullet item, 1st sentence: append a space after the colon. Insert “the” before “VPN Prefix ORF”. Insert “a” before “message”. I find the instructions for the sender (of the VPN Prefix ORF message) in this sentence confusing. If a VRF would be overloaded by the received VPN routes to the point that it sends a VPN Prefix ORF to the BPG peer that sent the routes, why would “SHOULD be withdrawn” make any sense in this sentence? Firstly, in my mind, the withdrawing is only done by the BGP peer upon receipt of the message. The sender of the message couldn’t hold the new (overload) routes in one of its VRFs, so I can only assume that it did not put them there, instead sending the message telling the peer to back off. Change the semicolon to a period. This sentence is already overly long. Page 7, “Overload VPN routes process method” bullet item, (newly promoted) 2nd sentence: Seems to be an odd character in the sentence. Maybe a double-byte character? The period here is not the usual one. In the XML, I'm seeing "。". Page 7, “Overload VPN routes process method” bullet item, 3rd sentence: Perhaps don't use asterisks to highlight this point. Maybe use "NB," to start the sentence. Or even "Note well"! If you do retain the asterisks, delete the space before the final period. Page 7, “Reserved” bullet item: Are these bits set to zero or just ignored upon receipt? Does it matter? Page 7, last paragraph, 1st sentence: insert “a” before “type-specific”. Page 8, Sequence bullet item, 1st sentence: insert “the” before “VPN”. Page 9, section 4.1, 1st paragraph, 2nd sentence: considering changing “(SPE EC)” to “(SPE EC; see section 6)” since this term better explained there. Page 10, section 4.3, 3rd paragraph: change “supports the following type” to “is defined as”. Page 10, section 4.3, 4th paragraph (indented): move “octets” before the parenthetical part. Page 10, section 4.4, 1st paragraph: delete the space before the period. Page 10, section 4.4, 2nd paragraph: insert “the” before “Route Type TLV”. Page 10, section 4.4, 3rd paragraph (indented): change “octect” to “octet”. Page 10, section 5 title: insert “the” before “VPN”. Page 11, section 5.1, 3rd paragraph, 1st sentence: delete “reached or”. I don’t see why the VRF (table) can’t be operated 100% full but not greater than that. Page 11, section 5.1, 3rd paragraph, 2nd sentence: The user of information in this sentence is not tied to the only other use of information in the paragraph (or even in the previous paragraph), so it doesn’t make sense to use that word here. It might make sense if the definition of what goes in a VPN Prefix ORF was being discussed, but that’s not the case. Perhaps rewrite “by the information” as “in the message”. Page 11, section 5.1, 4th paragraph, 1st sentence: change “by” to “into”. If VRFs are defined as table, then they don’t import. They just store and return. Page 11, 2nd bullet entry: consider changing “in ORF entries” to “in each ORF entry”. Page 11, 3rd bullet item: consider changing “in ORF entries” to “in each ORF entry”. Page 12, bullet item: change “above mentioned” to “above-mentioned”. Page 12, S03: On the basis that a VRF can’t hold more than its configured prefix limit, insert “that were to be” before “imported”. Change “by” to “into”. Page 12, S04: change “belong to” to “were sent for incorporation into”. Page 12, S09: purely for optimization’s sake, consider a S09a that reads “break;” or whatever make sense in this pseudo-language. Page 12, S10: also, purely for optimization’s sake, considering adding S10a (“If (conflict_exists == TRUE) {“. Add S10b “break;”. And add S10c “}”. Page 12, S14: perhaps change “healthy” to “non-overloaded”. Healthy hasn’t been defined, although it was used on page 5, section 3.5. One could guess at the meaning, but why not use a more specific term? There’s one other use of “healthy” in the document as well. Page 13, section 5.1.1, last paragraph: move “in” after “provided”. Page 14, 1st paragraph: append a comma after “ASBR”. Page 14, S05: change “overwrite” to “overwrites”. Page 14, 2nd paragraph after the steps: insert “the” before “NEXT_HOP”. Page 15, S06: append a comma after “RT”. Page 15, S08: append a comma after “RT”. Page 16, 1st paragraph, 3rd sentence: append a comma after “RR”. Page 16, 1st paragraph after the first set of bullet items: consider changing “For an RR/ASBR, it” to “An RR/ASBR” if that makes sense. Page 16, last paragraph: change “behaviours” to “behaviors” to match other usage of American English in the document. Page 17, 2nd to last paragraph: change “a new PE access” to “new PE access is added” or “a new PE is added”. Page 18, 1st paragraph (the formula at the top): insert “of” before “expansion”. Insert “the” before “future” (which shouldn’t be “futures”). Page 18, 2nd paragraph: change the comma to a semicolon. Delete “the” before “operators”. Insert “the” before “management plane”. Page 18, section 7.2, item 1: append a comma after “limit” and delete the “---“. Page 18, section 7.2, item 1: change the trailing semicolon to a period. Page 18, section 7.2, 1st paragraph after the numbered items, 2nd sentence: delete the comma after “entry”. Page 18, section 7.2, last paragraph: change “misoperations” to “improper operations”. Page 19, section 8, 1st paragraph, 1st sentence: insert “the” before the first “VPN”. Page 19, section 9.1, 1st paragraph: change “entitled” to “named”. Page 19, section 9.1: at least in the ASCII version, the table is not drawn properly. Page 20, section 9.3, table headers: change “Type Vaue” to “Type Value”. Page 20, section 9.4, 1st paragraph, 1st sentence: change “needs” to “is requested”. Page 21, section 10: try to remove the excess blank lines from Shunwan Zhuang’s entry so that it matches the style of the authors’ entries. Page 24, 2nd bullet item: insert “an” before “existing”. Page 26, S05, 2nd sentence: change “proceses” to “processes”. Page 31, Gyan Mishra’s entry: delete the excess space before “MD”.