VPN Prefix Outbound Route Filter (VPN Prefix ORF) for BGP-4
draft-ietf-idr-vpn-prefix-orf-45

[Ballot comment]
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?

[Ballot comment]
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

[Ballot discuss]
Hi Wei, Aijun, Haibo, Gyan, and Jie,

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

# Be less affirmative

I don’t think it is adequate to be affirmative about the enhancements in the spec as that need to be further assessed. I suggest to consider the various affirmative statements in the doc and make those as to be further confirmed as part of the experiment.

Example of such statements are “The VPN Prefix ORF mechanism improves upon this by enabling the ..”

UPDATE: I still see this statement in the document. I don't think we can claim this compared to controlling the load at the source  (attachment circuit level) or by policy. Whether this is an improvement or the mechanism has positive impact in general is to be assessement. That's the whole poingt of having this mechanums as Experimental. Please review such claims in the document and expresss them as "intended" rather than affirmative.

# De we really need to create new registries at this stage?

Given the current state of the technology, I don’t see appealing arguments to create new registries under the BGP registry group for a feature that need further assessment.

[Ballot comment]
# 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?

# 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

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

# The formula should be part of further investigation as part of the experimental work. You may add an item about this

CURRENT:
  To avoid frequent changes to the quota value, the value SHOULD be set
  based on the following formula:

  Quota=MIN[(Margins coefficient)**, VRF
  Prefixes Limit]

Cheers,
Med

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

[2] 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-40&difftype=--html

[Ballot comment]
I am still uncomfortable with all the machinery here and do think that there are other less intrusive ways to achieve the stated goals of the document. Having said this, as the document is experimental, I have moved my ballot to abstain, as I do not think it appropriate to hold up progression given the WG consensus to move the document forward.

[Ballot comment]
Many thanks for working on all the blocking DISCUSS's.

This is now a non-blocking ABSTAIN.

# The behavior of Internet routes and VPN routes is fundamentally different.
Internet BGP routes often originate from external sources and are outside the
operator’s control, making route scale less predictable. VPN route scale,
however, is controlled by the operator, making capacity planning and trend
analysis significantly easier.
# Also, in general, it is undesirable for one VPN operating within SLA limits to negatively impact another VPN also operating
within SLA limits. A common operational approach is to monitor the capacity of
the involved BGP VPN speakers and proactively prevent resource exhaustion on
affected components.
# The authors and the WG clearly sees the benefits proposed by the document, eventhough i do not understand why operators would prefer such mechanisms other than strict pre-emptive resource control for premium VPN
services.

My original Document Review:
https://mailarchive.ietf.org/arch/msg/idr/edlyHAjCdmjP948F8xbyeAFV3Kc/

[Ballot discuss]
Thanks to authors, IDR chairs and responsible to AD to contribute and support to resolve my open DISCUSS positions.

Open
====
DISCUSS#5 is still open.

Resolved
========
Resolved DISCUSS#3, DISCUSS#4, DISCUSS#6, DISCUSS#7
Resolved blocking DISCUSS#1 into non-blocking COMMENT#1
Resolved blocking DISCUSS#2 into non-blocking ABSTAIN#2

Relevant archived messages
==========================
https://mailarchive.ietf.org/arch/msg/idr/KWVHgwnXExuDt1S0VfsjRzMhLbA/
https://mailarchive.ietf.org/arch/msg/idr/T5GqJCvjrRj1E-BI-2CB0HB6s8M/

[Ballot discuss]
Thank you for this document. I have a few items to discuss:

1. Having read the document several times, I could not decide whether the mechanisms described therein are to resolve a theoritical problem, or a problem observed in operational networks. Noting that this technology has been successfully deployed worldwide for many years, did the WG discuss actual deployment experiences to determine that the issue was large enough to require such protocol changes?

2. I find no description that clearly lays out what the "experiment" actually is. The document reads more like a standards track document, minus the standards track designation, so this leads me to believe that the experiment is to make sure these changes do not cause large scale network outages (which I am incidentally far from convinced that they wont), and then move the document from experimental to standards track. Is this the intention of the WG? Can a detailed description of the experiment be provided?

3. According to Section 5.1 the case where an RT is imported into > 1 VRF is not supported. Specifically:
 
  Before originating a VPN Prefix ORF message, the sender MUST compare
  the list of RTs carried into the VPN routes with those imported by
  other VRFs on the sender.  If a route's RT is included in the
  configured import RTs of other VRFs, the VPN Prefix ORF message MUST
  NOT be originated.

So in this case, all of the machinery herein described does not work and the operator has to rely upon existing mechanisms. Was any analysis given to show how much or how little a problem this is?

4. In Section 5.1 the text says:

  When multiple VRFs on a PE receive VPN routes with a specific RD, the
  PE sends a VPN Prefix ORF message if one of these VRFs exceeds its
  limit for routes with that RD.  This prevents other non-exceeded VRFs
  from receiving VPN routes containing the same RD, thereby avoiding
  communication disruptions between these VRFs and the rejected VPN
  routes.  In order to more finely control VPN routing, if not all VRFs
  on a PE that are interested in VPN routes with a specific RD exceed
  the limit, the PE MUST NOT send a VPN Prefix ORF entry.

I have read this paragraph multiple times and it still seems to contradict itself. The first sentence seems to describe basic import which is driven by the RT (not the RD) and says that a Prefix ORF message will be sent if one of the importing VRFs exceeds its limit. The final sentence then says *if not all VRFs* exceed their limit then the PE MUST NOT send a Prefix ORF.

[Ballot discuss]

# Éric Vyncke INT AD comments for draft-ietf-idr-vpn-prefix-orf-37
CC @evyncke

Thank you for the work put into this document. I am disappointed to see even an experimental draft having such a poor specification...

Please find below some blocking DISCUSS points (easy to address), some non-blocking COMMENT points/nits (replies would be appreciated even if only for my own education).

Special thanks to Keyur Patel for the shepherd's honest write-up including the WG consensus and the justification of the intended status.

Other thanks to Benson Muite, the Internet directorate reviewer (at my request), please consider this int-dir review:
https://datatracker.ietf.org/doc/review-ietf-idr-vpn-prefix-orf-37-intdir-telechat-muite-2026-04-25/ (and I have seen that Wei Wang has replied but not revised I-D yet)

I hope that this review helps to improve the document,

Regards,

-éric

Note: this ballot comments follow the Markdown syntax of https://github.com/mnot/ietf-comments/tree/main, i.e., they can be processed by a tool to create github issues.

## DISCUSS (blocking)

As noted in https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/, a DISCUSS ballot is a request to have a discussion on the points below; I really think that the document would be improved with a change here, but can be convinced otherwise.

### Section 4

`This bit MUST be set to 1` what is the expected receiver behavior is this is bit is 0 ?

### Section 5

I find `receiving BGP peer` ambiguous: is it about receiving the ORF message or receiving 'too many' routes ? I guess the latter but let's be clear.

[Ballot comment]

## COMMENTS (non-blocking)

### Supporting other DISCUSS

I second Chris's DISCUSS (and Benson's point) about the table 1 and the associated text.

I also support Med's `De we really need to create new registries at this stage` let's use experimental/private use code points (if they exist).

### What is the experiment ?

Text about the scope (scale, inter- or intra-AS, duration) of the experiment should be in the draft. (Appendix A has some text about it)

### Abstract

I share Benson's point about the missing `RT` expansion.

s/This draft defines/This document proposes/ (and possibly in other places)

### Section 1

I guess that ORF needs to be at least enabled with a threshold both on the 'signaler' and on the 'prefix injector', i.e., I do not think that `This mechanism is event-driven and does not require pre-configuration.` is correct. E.g., see section 5.1 `Operators can configure...`.

Is `avoid route churn effects` the only bad consequence ? I would imagine that ressources exhaustion is more critical (e.g., section 3.5 `which consumes CPU cycles`).

The introduction should say a few words about routing stability (if some prefixes are removed, situation clears, then prefixes are injected again).

### Section 3

Adding informational references to the `existing solutions` would be beneficial for the reader.

### Section 4

Who is the "we" in `we describe` ? The authors ? The WG ? The IETF community ? Please avoid ambiguities. Possibly also in other places.

If it was not experimental, then I would have balloted DISCUSS on this point... Please add guidance for the should in `such an ORF entry SHOULD be removed` per https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/

`this bit is specific to the ORF Type introduced by this document and MUST be ignored (i.e., considered to be 0) for all other ORF Types.` did the authors/WG check the original ORF RFC for this behavior ? Does it introduce any operational issues during deployment?

`These bits are set to zero` please add the usual 'and ignored by the receiver'.

Please state the obvious that "k > 1" in `receiving sequence N then N+k`.

### Section 4.2

Why not a MUST in `The Source AS TLV SHOULD appear at most once within an individual ORF entry. If an ORF entry contains multiple Source AS TLVs, the entire entry SHOULD be ignored` ?

### Section 7.2

`a warning message will be generated and sent to the network operators` but how ?

`The withdrawal of the VPN Prefix ORF mechanism is manually triggered,` doesn't this text defeat the whole purpose of the mechanism ?

### Section 8

I fail to understand what are the security considerations of the 1st paragraph. Please add some text.

### Section 9

Suggest adding informational reference to the registries URIs.

### Section 11

An implementation section would be more useful than `Thanks Qian Wang and Penglun Zhang for their development work on the FRR-based implementation`.

## NITS (non-blocking / cosmetic)

### Use of SVG graphics

To make a much nicer HTML rendering, suggest using the aasvg tool to generate SVG graphics. It is worth a try especially if the I-D uses the Kramdown file format ;-)

[Ballot discuss]
# Gunter Van de Velde, RTG AD, comments for draft-ietf-idr-vpn-prefix-orf-37

# The line numbers used are rendered from IETF idnits tool: https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-idr-vpn-prefix-orf-37.txt

# Many thanks to the shepherd write-up from Keyur Patel and the RTGDIR review from Sasha Vainshtein

# In this review, I identified a few blocking DISCUSS items. These are intended to clarify context and highlight areas that may improve the current proposal. Additional context for some DISCUSS items is included in the comment section to explain where they apply. The COMMENTS are items i observed that could need extra input or clarifications, either to improve my own understanding or to improve the accuracy within the document

# Question to the AD or IDR chairs: When looking at the RTGDIR review on version -21 and the current document version -37 (ref https://author-tools.ietf.org/iddiff?url1=draft-ietf-idr-vpn-prefix-orf-21&url2=draft-ietf-idr-vpn-prefix-orf-37&difftype=--html), then i observe significant text changes. Is there a reason why there was no RTGDIR review requested anymore during the LC phase of this document? 

# Question for the AD: The last-call comments/discussion are still ongoing. Consensus seems not concluded (https://mailarchive.ietf.org/arch/browse/last-call/?q=draft-ietf-idr-vpn-prefix-orf). Is LC consensus confirmed?

# DISCUSS
# =======

# [DISCUSS#1]
# As agreed by WG consensus, this document is Experimental and intended to evaluate whether the described technology improves or reduces operational excellence. The shepherd write-up states: “The experimental status allows certain regional networks to proceed and obtain test results regarding this technology.”. It would benefit the community to describe the experiment scope and document intent more explicitly in the document itself. Was there WG consensus not to include such explanatory text? Based upon the current write-up, it is easy to perceive "this is a proposed internet standard" instead of "this is an experimental technology"

# [DISCUSS#2]
# The behavior of Internet routes and VPN routes is fundamentally different. Internet BGP routes often originate from external sources and are outside the operator’s control, making route scale less predictable. VPN route scale, however, is controlled by the operator, making capacity planning and trend analysis significantly easier.
# Also, in general, it is undesirable for one VPN operating within SLA limits to negatively impact another VPN also operating within SLA limits. A common operational approach is to monitor the capacity of the involved BGP VPN speakers and proactively prevent resource exhaustion on affected components.
# Could the authors clarify why operators would prefer mechanisms other than strict pre-emptive resource control for premium VPN services, and explain the deployment scenarios where the proposed mechanism provides additional operational value instead?

# [DICUSS#3]
# add a behavior when MATCH is a value not supported by the document. the received specified ORF is removed? (see comments)

# [DISCUSS#4]
# add prescribed procedure behavior when "Reserved" bits which are expected to be "0000", are different as "0000". (see comments)

# [DISCUSS#5]
# The document seems to present RD as a the VPN identifier, however standards describe the RD as "uniqueness mechanism for NLRI" and is used to make v4/v6 prefixes unique across VPNS for various reasons in the BGP procedures.

# [DISCUSS#6]
# Does this document intend to update RFC7606 for handling unrecognized optional TLVs? This draft appears to propose different behavior by discarding the complete ORF NLRI, while RFC7606 defines four alternative error-handling approaches, none of which seem to match the behavior described here. RFC7606 is published after RFC5291

# [DISCUSS#7]
# The document mentions a concept of high-priority route, but does not explain what exactly a high-priority route is. Can such context be added?

[Ballot comment]
# COMMENTS
# ========

18   This draft defines a new type of Outbound Route Filter (ORF), known
19   as the Virtual Private Network (VPN) Prefix ORF.  The VPN Prefix ORF
20   mechanism is applicable when VPN routes from different Virtual
21   Routing and Forwarding (VRF) instances are exchanged through a single
22   shared Border Gateway Protocol (BGP) session.  The purpose of the VPN
23   Prefix ORF mechanism is to control the overload of VPN routes based
24   on RT.  With this mechanism, the overload can be limited within the
25   minimum range.

GV> When reading this i get the impression that when using this technology, a first VPN has the potential to impact another VPN dynamically and unintentionally. I am not convinced such network property is desirable behavior. Such dynamics impact SLAs and operator quality experience.

103   The BGP Maximum Prefix feature [RFC4486] is often used at the network
104   boundary to control the number of prefixes injected into the network.
105   However, in scenarios where VPN routes from multiple VRFs are
106   advertised over a shared BGP session, there is a lack of appropriate
107   methods to control route flooding within one VRF.  This flooding can
108   overwhelm the processing of VPN routes in other VRFs, consequently
109   degrading their performance (e.g., causing route drops, processing
110   delays, and abnormal customer services).  Therefore, it is desirable
111   to control excessive VPN route advertisements individually for each
112   VRF within such a shared BGP session.

GV> RFC4486 does not talk about "BGP Maximum Prefix feature" but does define a NOTIFICATION message for "Maximum Number of Prefixes Reached". What does 'feature' in his aspect refer towards?

GV> [DISCUSS#2] The behavior of Internet routes and VPN routes is fundamentally different. Internet BGP routes often originate from external sources and are outside the operator’s control, making route scale less predictable. VPN route scale, however, is controlled by the operator, making capacity planning and trend analysis significantly easier.

GV> In general, it is undesirable for one VPN operating within its SLA limits to negatively impact another VPN also operating within its SLA limits. The most practical approach is to monitor the capacity of the involved BGP VPN speakers and proactively prevent resource overload conditions on any involved components. Not sure why anything less as operator full control would ever be allowed by an operator for premium business service? can authors explain or add a paragraph where the document proposal adds value in this paradigm? 

132   require pre-configuration.  When the number of VPN routes in a VRF
133   exceeds the prefix limit, the router identifies the VPN prefix (Route
134   Distinguisher (RD), Route Target (RT), source PE, etc.) of the
135   overload VPN routes (VPN routes that exceed the maximum number of
136   storable VPN routes of the corresponding VRF on the receiver and thus
137   cannot be imported.) and sends a VPN Prefix ORF message to the BGP
138   peer that announced these overload VPN routes.  Upon receiving a VPN

GV> In a VPN the number of allowed VPN routes is generally captured in a SLA contract and that should for a good service be provisionable on the available HW. 

224 3.5.  Configuring the Maximum Prefix for each VRF on edge nodes

226   When a VRF overloads, some implementations may stop importing routes.
227   Any additional VPN routes are held in the Routing Information Base
228   (RIB).  However, PEs still need to parse the incoming BGP messages,
229   which consumes CPU cycles and further burdens the overloaded PE.
230
231   The VPN Prefix ORF mechanism improves upon this by enabling the
232   overloaded PE to signal the specific overload routes back to the
233   sender.  The sender can then suppress these routes at the source,
234   eliminating wasted processing and preserving resources for non-
235   overloaded VRFs.

GV> Why can this not be avoided during VPN provisioning process?

285             +-----------------------------------------+
286             |                                        |
287             |            Action (2 bits)              |
288             |                                        |
289             +-----------------------------------------+
290             |                                        |
291             |            Match (1 bit)              |
292             |                                        |
293             +-----------------------------------------+
294             |                                        |
295             |      Overload VPN routes process        |
296             |            method (1 bit)              |
297             |                                        |
298             +-----------------------------------------+
299             |                                        |
300             |            Reserved (4 bits)            |
301             |                                        |
302             +-----------------------------------------+
303
304               Figure 1: VPN Prefix ORF type-common part encoding


GV> Why is this diagram making 1 bit and 2 or 4 bit look same size?
What about:

"
  0                  1
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action |Match| O | Reserved  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  Action    : 2 bits
  Match      : 1 bit
  O          : 1 bit  (Overload VPN routes process method)
  Reserved  : 4 bits
"

308       unrecognized value(0x11), such an ORF entry SHOULD be removed.

GV> What does removed exactly mean in BGP operation? is this the whole received specified ORF? Why would this not be a MUST? if a SHOULD, then please add a few words about the impact when the whole received ORF is not removed.

310   *  Match (1 bit): the value is PERMIT or DENY as described in
311       [RFC5291].  For the purpose of this document, only the DENY value
312       is permitted.  This bit MUST be set to 1.

GV> [DISCUSS#3] What if it is set to 0? for completeness prescribe that 1 = DENY and that 0 = PERMIT (from reading the text description)

320       SHOULD NOT announce new overload VPN routes.  The default value is

GV> is there a reason why authors prefer to use word "announce" then "advertise"

325   *  Reserved (4 bits): These bits are set to zero

GV> [DISCUSS#4] Add expected behavior when these bits are not set to 0?

363   *  Route Distinguisher: Distinguishes different user routes.  The VPN
364       Prefix ORF filters the VPN routes it intends to send based on
365       Route Distinguisher.  If the RD is set to 0, it indicates all VPN
366       prefixes.

GV> [DISCUSS#5] The RD does not define the VPN. The RD is used to make prefixes unique across all VPNs for a variety of reasons. Hence the correlation between "RD" and "all VPN prefixes" in this section feels underspecified. Can this be explained more accurately? 

368   *  Optional TLVs: Carries potential additional information to provide
369       extensibility for the VPN Prefix ORF mechanism.  Its format is
370       shown in Figure 3.  If one or more TLV(s) are unrecognized, the
371       entire VPN Prefix ORF entry SHOULD be discarded.

GV> [DISCUSS#6] When reading rfc7606 there seems to be no handling for tor the ORF NLRI To be discarded when there is a single optional TLV is not recognized. Does this draft as consequence update RFC7606? (RFC5291 pre-dates rfc7606 and was wondering if this impacts behavior in any way)

393   According to [RFC5291], if any field in a VPN Prefix ORF entry in the
394   message contains an unrecognized value, the entire specified ORF
395   previously received is removed.

GV> will the VPN Prefix ORF entry be forwarded to BGP peers? Maybe the BGP peers have upgraded code and do understand the ORF entry? in such situation, could this lead to inconsistent ORF based filtering?

411   The Source PE TLV SHOULD appear at most once within an individual ORF
412   entry.  If an ORF entry contains multiple Source PE TLVs, the entire
413   ORF entry MUST be ignored

GV> would instead of ignored the "Treat-as-withdraw" not be better fit?

448   If this TLV contains only one RT but multiple RTs are configured on
449   the VPN route, the device SHOULD check whether the RT included in
450   this TLV exists among the configured RTs.  If so, the device SHOULD
451   filter out the VPN route.

GV> clarification request: when the term 'filter out' is used, does this mean to not insert these prefixes into the local VRF RIB but can still be forwarded to BGP peers when configured as RR? or would this mean that the NLRI is removed somehow from the BGP table?

455       Type = 5, Length = 8*n octets (where n is the number of RTs
456       associated with the overloaded VPN routes), value = the RT
457       value(s) of the overload VPN routes.  If multiple RTs are
458       included, an exact match is required.

GV> clarification: does exact match mean that all RTs must match (match-all) or only a single one (math-any)

462   This TLV applies to all VPN routes containing a route type field, to
463   distinguish between different types of VPN routes and prevent the
464   filtering of higher-priority routes.

GV> [DISCUSS#7] What is a higher priority route?

GV> Can a list or reference of allowed route-types be added into the text? What if a route-type is used that does not exist or is invalid?

481   This section describes the procedures for the receiving BGP peer to
482   process VPN route information from the sending BGP peer.  The VPN
483   information includes updated VPN routes and their corresponding VPN
484   instance identification information.  Based on this identification
485   information, the receiving BGP peer determines the newly added VPN
486   routes and checks whether the number of these routes causes the total
487   number of VPN routes to exceed the maximum route limit for the
488   associated VPN instance.
489
490   If the route limit of the VPN instance (identified by the VPN
491   instance identification information) is exceeded, the receiving BGP
492   peer sends a VPN Prefix ORF message to the sending BGP peer.  This
493   message indicates that the sender SHOULD stop transmitting the
494   corresponding VPN routes identified in the message.
495
496   Before originating a VPN Prefix ORF message, the device MUST compare
497   the list of RTs carried into the VPN routes with those imported by
498   other VRFs on the device.  If a route's RT is included in the
499   configured import RTs of other VRFs, the VPN Prefix ORF message MUST
500   NOT be originated.
501
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.

GV> proposed alternative text:

"
This section specifies procedures for a receiving BGP speaker to
process VPN route information received from a sending BGP speaker.
The VPN route information includes VPN routes and associated Route
Distinguishers (RDs).  The receiving BGP speaker determines the
newly received VPN routes and evaluates whether installation of
those routes would cause the configured VPN route limit for the
associated VRF to be exceeded.

If the configured VPN route limit for a VRF is exceeded, the
receiving BGP speaker SHOULD send a VPN Prefix ORF message to the
sending BGP speaker requesting that transmission of the identified
VPN routes cease.

Before originating a VPN Prefix ORF message, the receiving BGP
speaker MUST compare the Route Targets (RTs) associated with the
affected VPN routes against the import RTs configured on other
VRFs of the device.  If any RT associated with a VPN route is also
imported by another VRF, the receiving BGP speaker MUST NOT
originate a VPN Prefix ORF message for that route.

The procedures described in this section apply to iBGP peers within
the same Autonomous System (AS).  VPN route identification is based
on the RD.  VPN Prefix ORF information is carried using ORF entries
within a ROUTE-REFRESH message.
"

507   The instruction information sent by the receiving BGP peer includes
508   the following details:
509
510   *  ORF entries that are contained in the ROUTE-REFRESH message.
511
512   *  An Action field (in each ORF entriy) set to a value that instructs
513       the sending BGP peer to add the corresponding filter condition to
514       its outbound route filter.
515
516   *  A Match field (in each ORF entry) set to a value that instructs
517       the sending BGP peer to deny VPN route updates matching the
518       corresponding ORF entries.
519
520   *  An RD value (identifying the above-mentioned VPN instance) added
521       to the type-specific part of the ORF entries.
522
523   When multiple VRFs on a PE receive VPN routes with a specific RD, the
524   PE sends a VPN Prefix ORF message if one of these VRFs exceeds its
525   limit for routes with that RD.  This prevents other non-exceeded VRFs
526   from receiving VPN routes containing the same RD, thereby avoiding
527   communication disruptions between these VRFs and the rejected VPN
528   routes.  In order to more finely control VPN routing, if not all VRFs
529   on a PE that are interested in VPN routes with a specific RD exceed
530   the limit, the PE MUST NOT send a VPN Prefix ORF entry.
531
532   When the VPN Prefix ORF mechanism is triggered, the device SHOULD
533   send alarm information to network operators.

GV> proposed alternative text:

"
The receiving BGP speaker includes the following information in the
VPN Prefix ORF message:

*  ORF entries carried within a ROUTE-REFRESH message.

*  An Action field in each ORF entry indicating that the receiving
  BGP speaker requests installation of the specified outbound route
  filter.

*  A Match field in each ORF entry indicating that VPN route updates
  matching the specified ORF entry are to be denied.

*  An RD value identifying the affected VPN routes, encoded in the
  type-specific portion of the ORF entry.

If multiple VRFs on a PE import VPN routes associated with the same
RD, and only a subset of those VRFs exceed their configured route
limits, the PE MUST NOT originate a VPN Prefix ORF entry for that
RD.

When the VPN Prefix ORF mechanism is triggered, the device SHOULD
notify the network operator.
"

535   The procedures for senders of VPN Prefix ORF entries are described
536   below:
537
538   S01. For each VRF v that receives updated VPN routes {
539   S02.    If (the total number of received prefixes + the number
540             of prefixes already inVRF v exceeds its configured
541             prefix limit) {
542   S03.        RT_set = the set of Route Targets that were to be
543                 imported into VRF v.
544   S04.        overload_RD_source_pairs = all
545                 tuples from the newly received routes that were
546                 sent for incorporation into VRF v.
547
548                 // Check if any RT in RT_set is also imported by
549                   another VRF that has NOT exceeded its limit
550   S05.        conflict_exists = FALSE;
551   S06.        For each RT r in RT_set {
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.            }
561   S12.        }
562
563   S13.        If (conflict_exists == TRUE) {
564   S14.            // Cannot send ORF: would block routes needed
565                       by non-overloaded VRFs
566   S15.            Send warning message to the operator.
567   S16.        }
568
569   S17.        // Safe to send ORF entries
570   S18.        For each  in overload_RD_source_pairs {
571   S19.            Collect all RTs carried by routes with RD=RD_x
572                     from source PE_y that are imported into VRF v.
573
574   S20.            Construct a VPN Prefix ORF entry with:
575   S21.                Action = ADD,
576   S22.                Match = DENY,
577   S23.                Overload VPN routes process method = 0,
578   S24.                Sequence = Generate unique Sequence number,
579   S25.                Route Distinguisher = RD_x,
580   S26.                Optional TLVs include:
581   S27.                    Source PE TLV = PE_y,
582   S28.                    Route Target TLV = RT_list.
583
584   S29.            Send a BGP ROUTE-REFRESH message containing this
585                     ORF entry to the upstream BGP peer (e.g., RR).
586   S30.            Send an alarm message to the operator indicating
587                     VRF v overload and ORF transmission.
588   S31.        }
589   S32.    } Else {
590   S33.        // No overload in this VRF; no ORF triggered
591   S34.        Continue normal route processing.
592   S35.    }
593   S36. }

GV> I think there is a logic error in this procedure: at S13, if conflict_exists == TRUE, the code sends a warning, but then still continues to S17 and sends the ORF entries.

It should stop ORF generation when a conflict exists.

Corrected logic:

"
S13.        If (conflict_exists == TRUE) {
S14.            Send warning message to the operator.
S15.            Continue with next VRF.
S16.        }

S17.        // Safe to send ORF entries
"

624   S01. The receiver checks the combination of  in the received VPN Prefix
626         ORF entry.
627   S02. If (the combination does not already exist in the ORF-Policy
628         table) {
629   S03.    The receiver adds the VPN Prefix ORF entry to the
630             ORF-Policy table.
631   S04. } else if (Action is set to ADD) {
632   S05.        The receiver overwrites the old VPN Prefix ORF entry
633                 with the new one.
634   S06. } else if (Action is set to REMOVE) {
635   S07.        The receiver removes the corresponding VPN Prefix ORF
636                 entry from the ORF-Policy table.
637   S07. } else {
638                 The receiver SHOULD remove all VPN Prefix ORF entries
639                 from the ORF-Policy table.
640   S08. }

GV> If the entry does not exist, the pseudocode adds it regardless of the Action value. That is only correct for ADD.
For REMOVE, a non-existing entry should normally be ignored or treated as no-op.
For REMOVE-ALL, the receiver should remove all matching entries, not add a new one.

A proposed cleaner structure:

"
If (Action == ADD) {
    If (entry exists) {
        Replace existing entry.
    } else {
        Add new entry.
    }
} else if (Action == REMOVE) {
    If (entry exists) {
        Remove entry.
    }
} else if (Action == REMOVE-ALL) {
    Remove all matching VPN Prefix ORF entries.
} else {
    Handle as malformed or unsupported Action.
}
"

642   The filtering conditions for stored VPN Prefix ORF entries include
643   the RD and RT of the source PE.
644
645   If the SPE EC is not attached to the BGP Update message for the VPN
646   prefixes, the receiver MUST use the NEXT_HOP or ORIGINATOR_ID
647   attribute as the originator of the VPN prefix to match against the
648   VPN Prefix ORF entry.
649
650   After installing the filter entries for outbound VPN prefixes, the
651   receiver performs the following actions before sending VPN routes:
652
653   S01. The receiver checks if there are matching filtering conditions
654       in the ORF-Policy table for the VPN routes.
655   S02. If (no matching filtering conditions exist) {
656   S03.    The receiver sends the VPN routes.
657   S04. } else {
658   S05.    If (the "Overload VPN routes process method" bit is set
659           to 0) {
660   S06.        The receiver withdraws all the VPN routes identified
661               by RD, RT, and any relevant information in the optional
662               TLVs within the entry, and stops sending the
663               corresponding VPN routes to the sender of the VPN
664               Prefix ORF entry.
665   S07.    } else {
666   S08.        The receiver stops sending the newly learnt matched VPN
667               routes according to the value of RD, RT, and any relevant
668               information in optional TLVs within the entry to the
669               sender of the VPN Prefix ORF entry.
670
671   S09. }

GV> The roles may appear confused. After receiving and installing ORF entries, the sender of VPN routes applies the outbound filter.

Other issues:

1. RD and RT of the source PE is unclear. RD is part of the VPN NLRI, RT is an Extended Community, and “source PE” is normally identified by a Source PE TLV, NEXT_HOP, ORIGINATOR_ID, or SPE EC. RT is not “of the source PE”.
2. If SPE EC is absent, using NEXT_HOP or ORIGINATOR_ID may be ambiguous. In route-reflector deployments, NEXT_HOP and ORIGINATOR_ID can have different semantics. The text should define precedence and exact matching rules.

3. The pseudocode ignores the Match field. If Match can be DENY/PERMIT, the logic should explicitly apply it.

4. The two methods are unclear:
* method 0: withdraw existing matched routes and stop sending future ones;
* method 1: stop sending newly learned matched routes only.

That may leave previously advertised routes active for method 1, which could contradict the overload-reduction goal unless intentional.

5. Missing closing braces around the final else block.

Suggested fix:
Calling it “the receiver” in lines 650–653 is ambiguous or wrong. Use “the BGP speaker applying the outbound ORF filter” instead of “receiver,” define exact RD/RT/source-PE matching semantics, and specify whether method 1 intentionally leaves previously advertised routes installed.

703   to transmit the identifier of the source PE.  The value of the SPE EC
704   can be set by the source PE, RR, or Autonomous System Boundary Router
705   (ASBR).  Once set and attached to a BGP UPDATE message, its value
706   SHOULD NOT be altered along the advertisement path.

GV> is this SHOULD NOT not more a MUST NOT? why would this document allow this to happen? seems undesired and forbidden for proper operation

724   *  Type: Specifies the type value assigned by IANA, now it is TBD.
725
726   *  ORIGINATOR_ID: Specifies the identifier of the source PE.
727
728   *  Reserved: MUST be set to zero on transmission.

GV> proposed to add the length of the fields in the descriptions to avoid the drawing to be normative.

"
*  Type (16 bit): Specifies the type value assigned by IANA, now it is TBD.
*  ORIGINATOR_ID (32 bit): Specifies the identifier of the source PE.
*  Reserved (16 bit): MUST be set to zero on transmission.
"

Can prescribed behavior be added what happens if the Reserved fields is not set to 0?
something like: "The sender MUST set the Reserved field to 0 and a received MUST ignore the Reserved field"

738   *  If the ORIGINATOR_ID does not exist, put the router-id of the
739       source PE into the SPE EC.

GV> can the router-id be accurately described? a single router may have multiple protocols running and hence may have multiple router-id's. These do not necessary align with the router-id intended in this document. Please accurately add a reference which router-id is intended.

757   *  Basic mode: Triggered solely by VRF-level prefix limits.  No per-
758       source quota configuration is required.  In this mode, the PE
759       sends a VPN Prefix ORF only if all VRFs that import the same Route
760       Target(s) have exceeded their respective prefix limits.

GV> i assume that this is about all VRFs on the local PE? (hence excluding the VRFs on remote PE's). Maybe clarify that this is about local PE

793   Quota=MIN[(Margins coefficient)**, VRF
795   Prefixes Limit]

GV> Clarifications: What is a "Margins coefficient"? what is meant by ? what is VRF Prefixes Limit

801 7.2.  Withdraw of VPN Prefix ORF entries
802
803   When the VPN Prefix ORF mechanism is triggered, a warning message
804   will be generated and sent to the network operators.  Operators
805   SHOULD manually configure the network to resume normal operation.
806   Since devices can record the VPN Prefix ORF entries sent by each VRF,
807   operators can identify the entries that need to be withdrawn and
808   manually trigger the withdraw process.
809
810   The withdrawal of the VPN Prefix ORF mechanism is manually triggered,
811   and its activation requires two conditions:
812
813   1.  Network operation and maintenance personnel have confirmed
814       through device alarms that the issue of "overload routes", which
815       originally caused the VRF route count to exceed the limit, has
816       been resolved.
817
818   2.  Operation and maintenance personnel have located the target ORF
819       entry to be withdrawn.  Devices record the VPN Prefix ORF entries
820       sent by each VRF, providing a basis for personnel to locate the
821       target of the withdrawal.
822
823   Operation and maintenance personnel manually configure withdrawal
824   commands on the device that triggered the ORF (typically the original
825   ORF sender, such as a PE with an exceeded route limit).  The commands
826   MUST include the unique identification information of the target ORF
827   entry and set the "Action" field of the ORF entry to "REMOVE" (for
828   removing a single entry) or "REMOVE-ALL" (for removing all entries of
829   the same type).
830
831   The withdrawal of ORF entries relies on manual intervention from a
832   management entity (e.g., NMS), and there is no automatic withdrawal
833   mechanism.  This is to prevent route disruptions caused by improper
834   operations.

GV> proposed alternative:

"
7.2.  Withdrawal of VPN Prefix ORF Entries

When the VPN Prefix ORF mechanism is triggered, the device SHOULD
notify the network operator.

Withdrawal of VPN Prefix ORF entries is manually initiated and
requires the following conditions:

1.  The network operator has confirmed that the overload condition
    causing the VRF route limit to be exceeded has been resolved.

2.  The network operator has identified the VPN Prefix ORF entry to
    be withdrawn.  Devices SHOULD maintain records of originated VPN
    Prefix ORF entries for this purpose.

To withdraw VPN Prefix ORF entries, the operator configures the
originating device to send a VPN Prefix ORF entry with the Action
field set to REMOVE or REMOVE-ALL.  The withdrawal request MUST
include sufficient information to identify the target ORF entry.

Automatic withdrawal of VPN Prefix ORF entries is not defined.
"

Many thanks for this document,

Kind Regards,
Gunter Van de Velde
Routing AD

[Ballot discuss]
Thank you for the work that went into this draft.  I have one discuss point which I hope is an easy editorial fix:

The text in section 4 doesn’t match the table that is supposed to explain the mapping.  I presume the text is correct?
> 253   *  SAFI (1 octet).  If the AFI is set to IPv4 or IPv6, the SAFI can
> 254       be set to MCAST-VPN, MCAST-VPLS, VPLS, BGP EVPN or MPLS-Labeled
> 255       VPN.  If the AFI is set to L2VPN, the SAFI MUST be set to BGP
> 256       EVPN.  It is applicable for all types of EVPN routes as mentioned
> 257       in [RFC7432].  The combination relationships between SAFI and AFI
> 258       are presented in Table 1:
>
> 260         Table 1 Allowed SAFI and AFI combinations
> 261     +-----------+-------------------------+----------------------------+
> 262     |    AFI    |          SAFI          |          Document          |
> 263     +-----------+-------------------------+----------------------------+
> 264     |IPv4(1)/  |MCAST-VPN(5)            | [RFC6514]                  |
> 265     |IPv6(2)    +-------------------------+----------------------------+
> 266     |          |MPLS-labeled VPN address | [RFC4364][RFC8277][RFC9252]|
> 267     |          |(128)                    |                            |
> 268     +-----------+-------------------------+----------------------------+
> 269     |L2VPN(25)  |BGP EVPNs(70)            | [RFC7432]                  |
> 270     |          +-------------------------+----------------------------+
> 271     |          |VPLS(65)                | [RFC4761][RFC6074]        |
> 272     |          +-------------------------+----------------------------+
> 273     |          |MCAST-VPLS(8)            | [RFC7117]                  |
> 274     +-----------+-------------------------+----------------------------+

[Ballot comment]
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?

[Ballot discuss]
To the IDR WG Chairs and responsible AD: I need your help understanding how this document fits into the approved scope of work.  The currently approved charter from 2010 is -05. 

As an experimental draft, I don’t see how it fits into the “The IDR working group will work on correctness, robustness and scalability of the BGP protocol, as well as clarity and accuracy of the BGP document set.”

In examining, bulleted list after “The group will also work on extensions beyond these areas when specifically added to the charter”, this document also doesn’t seem to fit into any of them.  There is a reference to ORF in the context of “Define AS_PATH based Outbound Route Filtering”, but that doesn’t seem to match (and there is a draft-ietf-idr-aspath-orf-13 seemingly expired from 2016 and a milestone marked as complete).

I note that there is a draft -05-00 version of the charter.  It has the scoping text of “Outbound Route Filtering (ORF) mechanisms [RFC5291][RFC5292] for policy-based control of route advertisement” which seems to fit the intent of this document. 

Perhaps this document could wait for community approval of the new chartered text.

[Ballot comment]
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....

[Ballot discuss]
Hi Wei, Aijun, Haibo, Gyan, and Jie,

Thank you for the effort put into this document. Thanks also to Keyur of the great write-up.

Thanks Aihua Guo for the OPSDIR review and to the authors for the changes made in -23.

Given the intended status, my review focuses on the overall consistency and claimed goals not much about the low level details of the procedure. Please find below some points for DISCUSSion:

# Be less affirmative

I don’t think it is adequate to be affirmative about the enhancements in the spec as that need to be further assessed. I suggest to consider the various affirmative statements in the doc and make those as to be further confirmed as part of the experiment.

Example of such statements are “The VPN Prefix ORF mechanism improves upon this by enabling the ..”

# Better than existing techniques

We say in the document:

CURRENT:
  Upon receiving a VPN
  Prefix ORF entry, the BGP speaker filters and withdraws any overload
  VPN routes that were previously announced to its peer.

## But, what if it doesn’t?

## Why we expect that it will react to this notification while the prefix max was already known to that peer?

## The statement is a bit not aligned with the informative nature of the signal in the main spec: withdraws != SHOULD withdraw:

CURRENT:
  *  Overload VPN routes process method (1 bit): if the value is set to
      0, it means the receiver of such message SHOULD withdraw all
      previously advertised overload VPN routes that match the ORF's
      type-specific part.  If the value is set to 1, it means the sender
      of the VPN Prefix ORF message will refuse to accept new overload
      VPN routes and that the receiver of the VPN Prefix ORF message
      SHOULD NOT announce new overload VPN routes.  The default value is
      0. 

# Deployment dependency

CURRENT:
  The VPN Prefix ORF mechanism improves upon this by enabling the
  overloaded PE to signal the specific overload routes back to the
  sender. 

This assumes the peer has to support this.

That needs to be agreed by some channel (e.g., L3SM). If such channel exists, why not the max indicated isn’t honored at the first place?

# Please check almost all the SHOULD uses in the document

For example, why the following is not a MUST?

CURRENT:
      If the received ORF entry contains an
      unrecognized value(0x11), such an ORF entry SHOULD be removed.
…

      The sequence number SHOULD be monotonically increasing for
      each ORF update.

and many other similar constructs.

The lack of clear language will make the comparison of experimental data difficult to compare.

Please double check your use through the document.

# I don’t quite understand why we do have the following note:

CURRENT:
      Note well, this bit is specific to the ORF Type introduced by
      this document and MUST be ignored (i.e., considered to be 0) for
      all other ORF Types.

# Internal inconsistency

      If one or more TLV(s) are unrecognized, the
      entire VPN Prefix ORF entry SHOULD be discarded.

Vs.

  If an ORF entry contains multiple Source PE TLVs, the entire
  ORF entry MUST be ignored.

Vs.

  If an ORF entry contains multiple Source AS TLVs, the entire
  entry SHOULD be ignored.

Why do we have different behaviors?

# Scope Clarity: intra vs inter

Section 4.2

  The Source AS TLV is defined to identify the source AS number of the
  source PE.  It is only required in inter-domain scenarios.

Section 7.1

  The VPN Prefix ORF mechanism is designed for intra-domain BGP/MPLS IP
  VPN [RFC4364] and BGP/MPLS Ethernet VPN (EVPN) [RFC7432] deployments

The two excerpt are conflicting. Please double check.

# De we really need to create new registries at this stage?

Given the current state of the technology, I don’t see appealing arguments to create new registries under the BGP registry group for a feature that need further assessment.

[Ballot comment]
# Clarity: Shared Session & Experimental

## Given the intended scope, make it clear in the title this is about Shared BGP Sessions + Experimental

OLD:
  VPN Prefix Outbound Route Filter (VPN Prefix ORF) for BGP-4

NEW:
  An Experimental VPN Prefix Outbound Route Filter (VPN Prefix ORF) for Shared BGP Sessions

## Also, echo that in the abstract

OLD: This draft defines a new type

NEW: This document defines an experimental new type

# 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?

# 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

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


# 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).

This is also part of site-maximum-routes in the L3SM (RFC8299).

# Device?

CURRENT:
  the device SHOULD check whether the RT included in

There are several similar uses in the document. It is not clear what are we referring to here. BGP peer, BGP speaker, ASBR, else?

# Threshold vs Maximum

CURRENT:
  S02.    If (the total number of received prefixes + the number
            of prefixes already inVRF v exceeds its configured
            prefix limit) {

## Waiting for the max to be fired may be too late

## Shouldn’t be more optimal to have a threshold (lower than the max) to anticipate new ones ?

## Should that be part of the aspects to explored in the experiments?

# A PE may have multiple ASN!

CURRENT:
  The AS number of the source PE can be conveyed by the Source AS

A PE can have multiple ASNs, including private one. Some clarity is needed here.

# The formula should be part of further investigation as part of the experimental work. You may add an item about this

CURRENT:
  To avoid frequent changes to the quota value, the value SHOULD be set
  based on the following formula:

  Quota=MIN[(Margins coefficient)**, VRF
  Prefixes Limit]

# Inappropriate use of normative language

OLD:
  It SHOULD be noted that the above formula is only an example;
  operators can use different formulas based on actual needs in the
  management plane.

NEW:
  It should be noted that the above formula is only an example;
  operators can use different formulas based on actual needs in the
  management plane.

Cheers,
Med

Request for IETF Last Call review by GENART Completed: Almost Ready. Reviewer: Peter Yee. Sent review to list. Submission of review completed at an earlier date.

[Ballot comment]
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

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-idr-vpn-prefix-orf-33. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there are four actions that we must complete.

First, in the BGP Outbound Route Filtering (ORF) Types registry in the Border Gateway Protocol (BGP) Parameters registry group located at:

https://www.iana.org/assignments/bgp-parameters/

the existing registration below will have its reference changed to [ RFC-to-be ]:

Value: 66
Description: VPN Prefix ORF

Second, a new subregistry is to be created called the VPN Prefix ORF TLV Type registry. The new registry will be located in the Border Gateway Protocol (BGP) Parameters registry group located at:

https://www.iana.org/assignments/bgp-parameters/

The registry will be managed via the following registration policies as defined in [RFC8126]:

0-127: IETF Review
128-255: First Come, First Served

There are initial registrations in the new registry as follows:

Value Description Reference
0 Reserved [ RFC-to-be ]
1 IPv4 Source PE TLV [ RFC-to-be ]
2 IPv6 Source PE TLV [ RFC-to-be ]
3 Source PE Identifier TLV [ RFC-to-be ]
4 Source AS TLV [ RFC-to-be ]
5 Route Target TLV [ RFC-to-be ]
6 Route Type TLV [ RFC-to-be ]
7-127 Unassigned
128-255 Unassigned

IANA Comments -> Which registry should this subregistry be under? If this is intended to be a standalone registry, could "subregistry" be changed to "registry"?

Third, in the BGP Transitive Extended Community Types registry in the Border Gateway Protocol (BGP) Extended Communities registry group located at:

https://www.iana.org/assignments/bgp-extended-communities/

a single new registration is to be made as follows:

Type Value: [ TBD-at-Registration ]
Name: Source PE Extended Community
Reference: [ RFC-to-be ]
Date: [ TBD-at-Registration ]

IANA notes that the authors have suggested a Type Value of 0x0d for this value.

Fourth, a new registry is to be created called the ORF Entry Bits registry. The new registry will be located in the Border Gateway Protocol (BGP) Parameters registry group located at:

https://www.iana.org/assignments/bgp-parameters/

The registration policy for the new registry will be IETF Review as defined in [RFC8126]. There are initial registrations in the new registry as follows:

Bit Position: 0-1
Name: Action
Description: The value of this field is 0 for ADD, 1 for REMOVE, and 2 for REMOVE-ALL.
Reference: RFC5291

Bit Position: 2
Name: Match
Description: The value of this field is 0 for PERMIT and 1 for DENY.
Reference: RFC5291

Bit Position: 3
Name: Overload VPN routes process method
Description: The value of this field is 0 for withdrawn all overload VPN routes, and 1 for refusing to receive new overload VPN routes.
Reference: [ RFC-to-be ]

Bit Position: 4-7
Name: Reserved
Description:
Reference: RFC5291

IANA Comments -> Same as the above comment; could the instance of "subregistry" in section 9.4 be replaced with "registry"?

We understand that these are the only actions required to be completed upon approval of this document.

NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2026-04-13):

From: The IESG
To: IETF-Announce
CC: draft-ietf-idr-vpn-prefix-orf@ietf.org, idr-chairs@ietf.org, idr@ietf.org, ketant.ietf@gmail.com, keyur@arrcus.com, shares@ndzh.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (VPN Prefix Outbound Route Filter (VPN Prefix ORF) for BGP-4) to Experimental RFC


The IESG has received a request from the Inter-Domain Routing WG (idr) to
consider the following document: - 'VPN Prefix Outbound Route Filter (VPN
Prefix ORF) for BGP-4'
  as Experimental RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2026-04-13. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This draft defines a new type of Outbound Route Filter (ORF), known
  as the Virtual Private Network (VPN) Prefix ORF.  The VPN Prefix ORF
  mechanism is applicable when VPN routes from different Virtual
  Routing and Forwarding (VRF) instances are exchanged through a single
  shared Border Gateway Protocol (BGP) session.The purpose of VPN
  Prefix ORF mechanism is to control the overload of VPN routes based
  on RT.  With this mechanism, the overload can be limited within the
  minimum range.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-idr-vpn-prefix-orf/


The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/5064/
  https://datatracker.ietf.org/ipr/4579/

# Document Shepherd Write-Up for Group Documents (*This version is dated 4 July 2022)
Status: Report based on adoption calls:

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

Adoption: closed on 1/16/2023, Call: 7/29 to 9/2/2022 (extension to 9/26/2022).
Adoption had contention with the IDR WG chairs deciding to adopt as experimental.
https://mailarchive.ietf.org/arch/msg/idr/JTbTOaC-CyonElboVz8-iF_UxHo/

Third WG adoption call:
https://mailarchive.ietf.org/arch/msg/idr/nC4qxff8w7R2Wsrv2lZUGa-QSLk/
The third version of the text was clear, but the operators were split in
their opinion on whether the functions was valuable or dangerous.
The experimental status allows the certain regional networks to proceed to
obtain tests results regarding this technology.

Final WG LC was done in January 2026:
https://mailarchive.ietf.org/arch/msg/idr/ffvYHJy2mmoekMVMg9CSBBpiyxM/

The consensus was to leave the draft status to "Experimental" as there was
no strong support for "Proposed Standard".

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

Adoption: The operators were split in their opinions on
whether the functions was valuable or dangerous.
The experimental status allows the certain regional networks to proceed to
obtain tests results regarding this technology.

After the recent round of reviews, the draft text has been simplified enough for functions to be streamlined from the deployment pov.

There was also a bit of discussion on the usage of the overload bit. Keeping
the experimental aspects in mind, and the fact that the overload bit does not seem
to impose any issues at present (other than filtering based on route limits), the draft
was allowed to keep the overload bit usage.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No appeals, but discussion on whether this draft should go to experimental.
See IDR wiki for additional details on 3 adoptions.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

Yes. Implementations exist.
https://wiki.ietf.org/group/idr/implementations/draft-ietf-idr-vpn-prefix-orf


## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

No.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

Yang module additions for enabling this function MAY be needed.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

No Yang module.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

Multiple reviews has been done for this documents. Chairs have reviewed it extensively as well.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

N/A.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Experimental.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Adoption IPR:
Wei Wang
https://mailarchive.ietf.org/arch/msg/idr/xNhAms6d_xxGX0F-eX1N6FVsK1g/
Aijun Wang:
https://mailarchive.ietf.org/arch/msg/idr/yMrrLg9kzMHsOmMRGS2FBtwauNo/
Haibo Wang:
https://mailarchive.ietf.org/arch/msg/idr/H8RtLJVB_xniMzuwkqbtM9vdiuQ/
Zhuangshunwan:
https://mailarchive.ietf.org/arch/msg/idr/U0aBYsj4TAl1YrJAOgAkOjA62Rs/
Gyan Mishra
https://mailarchive.ietf.org/arch/msg/idr/RjIK3Jk_4yBz3SzpmNwaLzacZG0/
Jie Dong:
https://mailarchive.ietf.org/arch/msg/idr/MBCiL5CjLfJxucim5fYb4Tb2xPM/




13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

All the nits and warnings have been cleaned up.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

N/A.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

This document defines a new IANA ORF Filter type known as a VPN Prefix ORF, TLV values for VPN Prefix ORF, and a new Extended Community known as a Source PE Extended Community.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

This document also defines a new VPN Prefix ORF TLV that's lists the new TLV values (and its registry) defined in this document. These TLVs are defined under Border Gateway Protocol (BGP) Parameters for Registry type: VPN Prefix ORF TLV.


[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents (*This version is dated 4 July 2022)
Status: Report based on adoption calls:

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

Adoption: closed on 1/16/2023, Call: 7/29 to 9/2/2022 (extension to 9/26/2022).
Adoption had contention with the IDR WG chairs deciding to adopt as experimental.
https://mailarchive.ietf.org/arch/msg/idr/JTbTOaC-CyonElboVz8-iF_UxHo/

Third WG adoption call:
https://mailarchive.ietf.org/arch/msg/idr/nC4qxff8w7R2Wsrv2lZUGa-QSLk/
The third version of the text was clear, but the operators were split in
their opinion on whether the functions was valuable or dangerous.
The experimental status allows the certain regional networks to proceed to
obtain tests results regarding this technology.

Final WG LC was done in January 2026:
https://mailarchive.ietf.org/arch/msg/idr/ffvYHJy2mmoekMVMg9CSBBpiyxM/

The consensus was to leave the draft status to "Experimental" as there was
no strong support for "Proposed Standard".


2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

Adoption: The operators were split in their opinions on
whether the functions was valuable or dangerous.
The experimental status allows the certain regional networks to proceed to
obtain tests results regarding this technology.

After the recent round of reviews, the draft text has been simplified enough for functions to be streamlined from the deployment pov.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No appeals, but discussion on whether this draft should go to experimental.
See IDR wiki for additional details on 3 adoptions.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

Yes. Implementations exist.
https://wiki.ietf.org/group/idr/implementations/draft-ietf-idr-vpn-prefix-orf


## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

No.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

Yang module additions for enabling this function MAY be needed.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

No Yang module.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

Multiple reviews has been done for this documents. Chairs have reviewed it extensively as well.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

N/A.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Experimental.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Adoption IPR:
Wei Wang
https://mailarchive.ietf.org/arch/msg/idr/xNhAms6d_xxGX0F-eX1N6FVsK1g/
Aijun Wang:
https://mailarchive.ietf.org/arch/msg/idr/yMrrLg9kzMHsOmMRGS2FBtwauNo/
Haibo Wang:
https://mailarchive.ietf.org/arch/msg/idr/H8RtLJVB_xniMzuwkqbtM9vdiuQ/
Zhuangshunwan:
https://mailarchive.ietf.org/arch/msg/idr/U0aBYsj4TAl1YrJAOgAkOjA62Rs/
Gyan Mishra
https://mailarchive.ietf.org/arch/msg/idr/RjIK3Jk_4yBz3SzpmNwaLzacZG0/
Jie Dong:
https://mailarchive.ietf.org/arch/msg/idr/MBCiL5CjLfJxucim5fYb4Tb2xPM/




13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

All the nits and warnings have been cleaned up.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

N/A.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

This document defines a new IANA ORF Filter type known as a VPN Prefix ORF, TLV values for VPN Prefix ORF, and a new Extended Community known as a Source PE Extended Community.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

This document also defines a new VPN Prefix ORF TLV that's lists the new TLV values (and its registry) defined in this document. These TLVs are defined under Border Gateway Protocol (BGP) Parameters for Registry type: VPN Prefix ORF TLV.


[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents (*This version is dated 4 July 2022)
Status: Report based on adoption calls:

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

Adoption: closed on 1/16/2023, Call: 7/29 to 9/2/2022 (extension to 9/26/2022).
Adoption had contention with the IDR WG chairs deciding to adopt as experimental.
https://mailarchive.ietf.org/arch/msg/idr/JTbTOaC-CyonElboVz8-iF_UxHo/

Third WG adoption call:
https://mailarchive.ietf.org/arch/msg/idr/nC4qxff8w7R2Wsrv2lZUGa-QSLk/
The third version of the text was clear, but the operators were split in
their opinion on whether the functions was valuable or dangerous.
The experimental status allows the certain regional networks to proceed to
obtain tests results regarding this technology.


2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

Adoption: The operators were split in their opinions on
whether the functions was valuable or dangerous.
The experimental status allows the certain regional networks to proceed to
obtain tests results regarding this technology.

After the recent round of reviews, the draft text has been simplified enough for functions to be streamlined from the deployment pov.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No appeals, but discussion on whether this draft should go to experimental.
See IDR wiki for additional details on 3 adoptions.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

Yes. Implementations exist.
https://wiki.ietf.org/group/idr/implementations/draft-ietf-idr-vpn-prefix-orf


## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

No.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

Yang module additions for enabling this function MAY be needed.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

No Yang module.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

Multiple reviews has been done for this documents. Chairs have reviewed it extensively as well.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

N/A.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Experimental.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Adoption IPR:
Wei Wang
https://mailarchive.ietf.org/arch/msg/idr/xNhAms6d_xxGX0F-eX1N6FVsK1g/
Aijun Wang:
https://mailarchive.ietf.org/arch/msg/idr/yMrrLg9kzMHsOmMRGS2FBtwauNo/
Haibo Wang:
https://mailarchive.ietf.org/arch/msg/idr/H8RtLJVB_xniMzuwkqbtM9vdiuQ/
Zhuangshunwan:
https://mailarchive.ietf.org/arch/msg/idr/U0aBYsj4TAl1YrJAOgAkOjA62Rs/
Gyan Mishra
https://mailarchive.ietf.org/arch/msg/idr/RjIK3Jk_4yBz3SzpmNwaLzacZG0/
Jie Dong:
https://mailarchive.ietf.org/arch/msg/idr/MBCiL5CjLfJxucim5fYb4Tb2xPM/




13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

All the nits and warnings have been cleaned up.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

N/A.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

This document defines a new IANA ORF Filter type known as a VPN Prefix ORF, TLV values for VPN Prefix ORF, and a new Extended Community known as a Source PE Extended Community.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

This document also defines a new VPN Prefix ORF TLV that's lists the new TLV values (and its registry) defined in this document. These TLVs are defined under Border Gateway Protocol (BGP) Parameters for Registry type: VPN Prefix ORF TLV.


[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

Returning this document to the WG for doing WGLC after closure of the early directorate reviews requested by the WG chairs. See for details - https://mailarchive.ietf.org/arch/msg/idr/o63oj6409EXRkCkgCga2mNr0tsA/

# Document Shepherd Write-Up for Group Documents (*This version is dated 4 July 2022)
Status: Report based on adoption calls:

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

Adoption: closed on 1/16/2023, Call: 7/29 to 9/2/2022 (extension to 9/26/2022).
Adoption had contention with the IDR WG chairs deciding to adopt as experimental.
https://mailarchive.ietf.org/arch/msg/idr/JTbTOaC-CyonElboVz8-iF_UxHo/

Third WG adoption call:
https://mailarchive.ietf.org/arch/msg/idr/nC4qxff8w7R2Wsrv2lZUGa-QSLk/
The third version of the text was clear, but the operators were split in
their opinion on whether the functions was valuable or dangerous.
The experimental status allows the certain regional networks to proceed to
obtain tests results regarding this technology.


2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

Adoption: The operators were split in their opinions on
whether the functions was valuable or dangerous.
The experimental status allows the certain regional networks to proceed to
obtain tests results regarding this technology.

After the recent round of reviews, the draft text has been simplified enough for functions to be streamlined from the deployment pov.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No appeals, but discussion on whether this draft should go to experimental.
See IDR wiki for additional details on 3 adoptions.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

Yes. Implementations exist.
https://wiki.ietf.org/group/idr/implementations/draft-ietf-idr-vpn-prefix-orf


## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

No.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

Yang module additions for enabling this function MAY be needed.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

No Yang module.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

Multiple reviews has been done for this documents. Chairs have reviewed it extensively as well.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

N/A.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Experimental.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Adoption IPR:
Wei Wang
https://mailarchive.ietf.org/arch/msg/idr/xNhAms6d_xxGX0F-eX1N6FVsK1g/
Aijun Wang:
https://mailarchive.ietf.org/arch/msg/idr/yMrrLg9kzMHsOmMRGS2FBtwauNo/
Haibo Wang:
https://mailarchive.ietf.org/arch/msg/idr/H8RtLJVB_xniMzuwkqbtM9vdiuQ/
Zhuangshunwan:
https://mailarchive.ietf.org/arch/msg/idr/U0aBYsj4TAl1YrJAOgAkOjA62Rs/
Gyan Mishra
https://mailarchive.ietf.org/arch/msg/idr/RjIK3Jk_4yBz3SzpmNwaLzacZG0/
Jie Dong:
https://mailarchive.ietf.org/arch/msg/idr/MBCiL5CjLfJxucim5fYb4Tb2xPM/




13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

All the nits and warnings have been cleaned up.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

N/A.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

This document defines a new IANA ORF Filter type known as a VPN Prefix ORF, TLV values for VPN Prefix ORF, and a new Extended Community known as a Source PE Extended Community.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

This document also defines a new VPN Prefix ORF TLV that's lists the new TLV values (and its registry) defined in this document. These TLVs are defined under Border Gateway Protocol (BGP) Parameters for Registry type: VPN Prefix ORF TLV.


[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents (*This version is dated 4 July 2022)
Status: Report based on adoption calls:

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

Adoption: closed on 1/16/2023, Call: 7/29 to 9/2/2022 (extension to 9/26/2022).
Adoption had contention with the IDR WG chairs deciding to adopt as experimental.
https://mailarchive.ietf.org/arch/msg/idr/JTbTOaC-CyonElboVz8-iF_UxHo/

Third WG adoption call:
https://mailarchive.ietf.org/arch/msg/idr/nC4qxff8w7R2Wsrv2lZUGa-QSLk/
The third version of the text was clear, but the operators were split in
their opinion on whether the functions was valuable or dangerous.
The experimental status allows the certain regional networks to proceed to
obtain tests results regarding this technology.


2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

Adoption: The operators were split in their opinions on
whether the functions was valuable or dangerous.
The experimental status allows the certain regional networks to proceed to
obtain tests results regarding this technology.

After the recent round of reviews, the draft text has been simplified enough for functions to be streamlined from the deployment pov.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No appeals, but discussion on whether this draft should go to experimental.
See IDR wiki for additional details on 3 adoptions.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

Yes. Implementations exist.
https://wiki.ietf.org/group/idr/implementations/draft-ietf-idr-vpn-prefix-orf


## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

No.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

Yang module additions for enabling this function MAY be needed.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

No Yang module.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

Multiple reviews has been done for this documents. Chairs have reviewed it extensively as well.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

N/A.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Experimental.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Adoption IPR:
Wei Wang
https://mailarchive.ietf.org/arch/msg/idr/xNhAms6d_xxGX0F-eX1N6FVsK1g/
Aijun Wang:
https://mailarchive.ietf.org/arch/msg/idr/yMrrLg9kzMHsOmMRGS2FBtwauNo/
Haibo Wang:
https://mailarchive.ietf.org/arch/msg/idr/H8RtLJVB_xniMzuwkqbtM9vdiuQ/
Zhuangshunwan:
https://mailarchive.ietf.org/arch/msg/idr/U0aBYsj4TAl1YrJAOgAkOjA62Rs/
Gyan Mishra
https://mailarchive.ietf.org/arch/msg/idr/RjIK3Jk_4yBz3SzpmNwaLzacZG0/
Jie Dong:
https://mailarchive.ietf.org/arch/msg/idr/MBCiL5CjLfJxucim5fYb4Tb2xPM/




13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

All the nits and warnings have been cleaned up.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

N/A.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

This document defines a new IANA ORF Filter type known as a VPN Prefix ORF, TLV values for VPN Prefix ORF, and a new Extended Community known as a Source PE Extended Community.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

This document also defines a new VPN Prefix ORF TLV that's lists the new TLV values (and its registry) defined in this document. These TLVs are defined under Border Gateway Protocol (BGP) Parameters for Registry type: VPN Prefix ORF TLV.


[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents (*This version is dated 4 July 2022)
Status: Report based on adoption calls:

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

Adoption: closed on 1/16/2023, Call: 7/29 to 9/2/2022 (extension to 9/26/2022).
Adoption had contention with the IDR WG chairs deciding to adopt as experimental.
https://mailarchive.ietf.org/arch/msg/idr/JTbTOaC-CyonElboVz8-iF_UxHo/

Third WG adoption call:
https://mailarchive.ietf.org/arch/msg/idr/nC4qxff8w7R2Wsrv2lZUGa-QSLk/
The third version of the text was clear, but the operators were split in
their opinion on whether the functions was valuable or dangerous.
The experimental status allows the Chinese/Asian networks to proceed to
obtain tests results regarding this technology.


2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

Adoption: The operators were split in their opinions on
whether the functions was valuable or dangerous.
The experimental status allows the Chinese/Asian networks to proceed to
obtain tests results regarding this technology.

After the recent round of reviews, the draft text has been simplified enough for functions to be streamlined from the deployment pov.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No appeals, but discussion on whether this draft should go to experimental.
See IDR wiki for additional details on 3 adoptions.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

Yes. Implementations exist.
https://wiki.ietf.org/group/idr/implementations/draft-ietf-idr-vpn-prefix-orf


## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

No.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

Yang module additions for enabling this function MAY be needed.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

No Yang module.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

Multiple reviews has been done for this documents. Chairs have reviewed it extensively as well.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

N/A.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Experimental.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Adoption IPR:
Wei Wang
https://mailarchive.ietf.org/arch/msg/idr/xNhAms6d_xxGX0F-eX1N6FVsK1g/
Aijun Wang:
https://mailarchive.ietf.org/arch/msg/idr/yMrrLg9kzMHsOmMRGS2FBtwauNo/
Haibo Wang:
https://mailarchive.ietf.org/arch/msg/idr/H8RtLJVB_xniMzuwkqbtM9vdiuQ/
Zhuangshunwan:
https://mailarchive.ietf.org/arch/msg/idr/U0aBYsj4TAl1YrJAOgAkOjA62Rs/
Gyan Mishra
https://mailarchive.ietf.org/arch/msg/idr/RjIK3Jk_4yBz3SzpmNwaLzacZG0/
Jie Dong:
https://mailarchive.ietf.org/arch/msg/idr/MBCiL5CjLfJxucim5fYb4Tb2xPM/




13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

Minor nits and warnings exist. Otherwise is ok.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

N/A.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

This document defines a new IANA ORF Filter type known as a VPN Prefix ORF, TLV values for VPN Prefix ORF, and a new Extended Community known as a Source PE Extended Community.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

This document also defines a new VPN Prefix ORF TLV that's lists the new TLV values defined in this document. This TLV is defined under Border Gateway Protocol (BGP) Parameters.


[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

Request for posting confirmation emailed to previous authors: Aijun Wang , Gyan Mishra , Haibo Wang , Jie Dong , Shunwan Zhuang , Wei Wang , idr-chairs@ietf.org

# Document Shepherd Write-Up for Group Documents (*This version is dated 4 July 2022)
Status: Report based on adoption calls:

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

Adoption: closed on 1/16/2023, Call: 7/29 to 9/2/2022 (extension to 9/26/2022).
Adoption had contention with the IDR WG chairs deciding to adopt as experimental.
https://mailarchive.ietf.org/arch/msg/idr/JTbTOaC-CyonElboVz8-iF_UxHo/

Third WG adoption call:
https://mailarchive.ietf.org/arch/msg/idr/nC4qxff8w7R2Wsrv2lZUGa-QSLk/
The third version of the text was clear, but the operators were split in
their opinion on whether the functions was valuable or dangerous.
The experimental status allows the Chinese/Asian networks to proceed to
obtain tests results regarding this technology.


2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

Adoption: The operators were split in their opinions on
whether the functions was valuable or dangerous.
The experimental status allows the Chinese/Asian networks to proceed to
obtain tests results regarding this technology.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No appeals, but discussion on whether this draft should go to experimental.
See IDR wiki for additional details on 3 adoptions.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

Adoption:
The ORF functionality is basic function of BGP.  If this draft receives enough
reports to warrant WG LC, the Grow, Spring, and BESS groups should be queried.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

Adoption:  Yang module additions for this function may need to be added on ORF functionality.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

No Yang module.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Adoption IPR:
Wei Wang
https://mailarchive.ietf.org/arch/msg/idr/xNhAms6d_xxGX0F-eX1N6FVsK1g/
Aijun Wang:
https://mailarchive.ietf.org/arch/msg/idr/yMrrLg9kzMHsOmMRGS2FBtwauNo/
Haibo Wang:
https://mailarchive.ietf.org/arch/msg/idr/H8RtLJVB_xniMzuwkqbtM9vdiuQ/
Zhuangshunwan:
https://mailarchive.ietf.org/arch/msg/idr/U0aBYsj4TAl1YrJAOgAkOjA62Rs/
Gyan Mishra
https://mailarchive.ietf.org/arch/msg/idr/RjIK3Jk_4yBz3SzpmNwaLzacZG0/
Jie Dong:
https://mailarchive.ietf.org/arch/msg/idr/MBCiL5CjLfJxucim5fYb4Tb2xPM/




13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents (*This version is dated 4 July 2022)
Status: Report based on adoption calls:

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

Adoption: closed on 1/16/2023, Call: 7/29 to 9/2/2022 (extension to 9/26/2022).
Adoption had contention with the IDR WG chairs deciding to adopt as experimental.
https://mailarchive.ietf.org/arch/msg/idr/JTbTOaC-CyonElboVz8-iF_UxHo/

Third WG adoption call:
https://mailarchive.ietf.org/arch/msg/idr/nC4qxff8w7R2Wsrv2lZUGa-QSLk/
The third version of the text was clear, but the operators were split in
their opinion on whether the functions was valuable or dangerous.
The experimental status allows the Chinese/Asian networks to proceed to
obtain tests results regarding this technology.


2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

Adoption: The operators were split in their opinions on
whether the functions was valuable or dangerous.
The experimental status allows the Chinese/Asian networks to proceed to
obtain tests results regarding this technology.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No appeals, but discussion on whether this draft should go to experimental.
See IDR wiki for additional details on 3 adoptions.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

Adoption:
The ORF functionality is basic function of BGP.  If this draft receives enough
reports to warrant WG LC, the Grow, Spring, and BESS groups should be queried.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

Adoption:  Yang module additions for this function may need to be added on ORF functionality.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

No Yang module.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Adoption IPR:
Wei Wang
(missing -03)
Aijun Wang:
https://mailarchive.ietf.org/arch/msg/idr/yMrrLg9kzMHsOmMRGS2FBtwauNo/
Haibo Wang:
https://mailarchive.ietf.org/arch/msg/idr/H8RtLJVB_xniMzuwkqbtM9vdiuQ/
Zhuangshunwan:
https://mailarchive.ietf.org/arch/msg/idr/U0aBYsj4TAl1YrJAOgAkOjA62Rs/
Gyan Mishra
https://mailarchive.ietf.org/arch/msg/idr/RjIK3Jk_4yBz3SzpmNwaLzacZG0/
Jie Dong:
https://mailarchive.ietf.org/arch/msg/idr/MBCiL5CjLfJxucim5fYb4Tb2xPM/




13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents (*This version is dated 4 July 2022)
Status: Report based on adoption calls:

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

Adoption: closed on 1/16/2023, Call: 7/29 to 9/2/2022 (extension to 9/26/2022).
Adoption had contention with the IDR WG chairs deciding to adopt as experimental.
https://mailarchive.ietf.org/arch/msg/idr/JTbTOaC-CyonElboVz8-iF_UxHo/

Third WG adoption call:
https://mailarchive.ietf.org/arch/msg/idr/nC4qxff8w7R2Wsrv2lZUGa-QSLk/
The third version of the text was clear, but the operators were split in
their opinion on whether the functions was valuable or dangerous.
The experimental status allows the Chinese/Asian networks to proceed to
obtain tests results regarding this technology.


2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

Adoption: The operators were split in their opinions on
whether the functions was valuable or dangerous.
The experimental status allows the Chinese/Asian networks to proceed to
obtain tests results regarding this technology.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No appeals, but discussion on whether this draft should go to experimental.
See IDR wiki for additional details on 3 adoptions.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

Adoption:
The ORF functionality is basic function of BGP.  If this draft receives enough
reports to warrant WG LC, the Grow, Spring, and BESS groups should be queried.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

Adoption:  Yang module additions for this function may need to be added on ORF functionality.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

No Yang module.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Adoption IPR:
Wei Wang
(missing -03)
Aijun Wang:
https://mailarchive.ietf.org/arch/msg/idr/yMrrLg9kzMHsOmMRGS2FBtwauNo/
Haibo Wang:
https://mailarchive.ietf.org/arch/msg/idr/H8RtLJVB_xniMzuwkqbtM9vdiuQ/
Zhuangshunwan:
https://mailarchive.ietf.org/arch/msg/idr/U0aBYsj4TAl1YrJAOgAkOjA62Rs/
Gyan Mishra
https://mailarchive.ietf.org/arch/msg/idr/RjIK3Jk_4yBz3SzpmNwaLzacZG0/
Jie Dong:
https://mailarchive.ietf.org/arch/msg/idr/MBCiL5CjLfJxucim5fYb4Tb2xPM/




13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents (*This version is dated 4 July 2022)
Status: Report based on adoption calls:

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

Adoption: closed on 1/16/2023, Call: 7/29 to 9/2/2022 (extension to 9/26/2022).
Adoption had contention with the IDR WG chairs deciding to adopt as experimental.
https://mailarchive.ietf.org/arch/msg/idr/JTbTOaC-CyonElboVz8-iF_UxHo/

Third WG adoption call:
https://mailarchive.ietf.org/arch/msg/idr/nC4qxff8w7R2Wsrv2lZUGa-QSLk/
The third version of the text was clear, but the operators were split in
their opinion on whether the functions was valuable or dangerous.
The experimental status allows the Chinese/Asian networks to proceed to
obtain tests results regarding this technology.


2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

Adoption: The operators were split in their opinions on
whether the functions was valuable or dangerous.
The experimental status allows the Chinese/Asian networks to proceed to
obtain tests results regarding this technology.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No appeals, but discussion on whether this draft should go to experimental.
See IDR wiki for additional details on 3 adoptions.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

Adoption:
The ORF functionality is basic function of BGP.  If this draft receives enough
reports to warrant WG LC, the Grow, Spring, and BESS groups should be queried.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

Adoption:  Yang module additions for this function may need to be added on ORF functionality.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

No Yang module.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Adoption IPR:
Wei Wang
(missing -03)
Aijun Wang:
https://mailarchive.ietf.org/arch/msg/idr/yMrrLg9kzMHsOmMRGS2FBtwauNo/
Haibo Wang:
(missing-03)
Zhuangshunwan:
https://mailarchive.ietf.org/arch/msg/idr/U0aBYsj4TAl1YrJAOgAkOjA62Rs/
Gyan Mishra
(missing -03)
Jie Dong:
(missing -03)




13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents (*This version is dated 4 July 2022)
Status: Report based on adoption calls:

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

Adoption:
Adoption had contention with the IDR WG chairs deciding to adopt as experimental.
https://mailarchive.ietf.org/arch/msg/idr/JTbTOaC-CyonElboVz8-iF_UxHo/

Third WG adoption call:
https://mailarchive.ietf.org/arch/msg/idr/nC4qxff8w7R2Wsrv2lZUGa-QSLk/
The third version of the text was clear, but the operators were split in
their opinion on whether the functions was valuable or dangerous.
The experimental status allows the Chinese/Asian networks to proceed to
obtain tests results regarding this technology.


2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

Adoption: The operators were split in their opinions on
whether the functions was valuable or dangerous.
The experimental status allows the Chinese/Asian networks to proceed to
obtain tests results regarding this technology.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No appeals, but discussion on whether this draft should go to experimental.
See IDR wiki for additional details on 3 adoptions.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

Adoption:
The ORF functionality is basic function of BGP.  If this draft receives enough
reports to warrant WG LC, the Grow, Spring, and BESS groups should be queried.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

Adoption:  Yang module additions for this function may need to be added on ORF functionality.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

No Yang module.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Adoption IPR:
Wei Wang
(missing -03)
Aijun Wang:
https://mailarchive.ietf.org/arch/msg/idr/yMrrLg9kzMHsOmMRGS2FBtwauNo/
Haibo Wang:
(missing-03)
Zhuangshunwan:
https://mailarchive.ietf.org/arch/msg/idr/U0aBYsj4TAl1YrJAOgAkOjA62Rs/
Gyan Mishra
(missing -03)
Jie Dong:
(missing -03)




13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

Request for posting confirmation emailed  to submitter and authors: Aijun Wang , Gyan Mishra , Haibo Wang , Jie Dong , Shunwan Zhuang , Wei Wang