[Idr] Re: AD Evaluation of draft-ietf-idr-vpn-prefix-orf-23

[Wei Wang <[e-mail]>]

Hi Ketan,


The lastest version of draft-ietf-idr-vpn-prefix-orf has been uploaded (https://datatracker.ietf.org/doc/draft-ietf-idr-vpn-prefix-orf/) Your comments have been addressed. And please also see my inline replies with [WW].


Best Regards,
Wei
         Original
         
       
From: Ketan Talaulikar <[e-mail]&gt;
Date: 2025-12-22 13:34
To: Wei Wang <[e-mail]&gt;
Cc: idr <[e-mail]&gt;
Subject: Re: [Idr] AD Evaluation of draft-ietf-idr-vpn-prefix-orf-23



Hi Wei,


Thanks for your response. I was waiting for an update to be posted but perhaps you were waiting for my reply before&nbsp;doing so.


Please check inline below with KT for some clarifications and follow-ups. I am only replying to open items and please proceed with your changes for the ones where we have reached an agreement.




On Thu, Dec 4, 2025 at 2:30 PM Wei Wang <[e-mail]&gt; wrote:
Hi Ketan,


Thanks for your careful review and valuable comments. Please find my in-line replies with&nbsp;[WW].&nbsp;


Best Regards,
Wei


Original


From: Ketan Talaulikar <[e-mail]&gt;
Date: 2025-11-22 14:47
To: draft-ietf-idr-vpn-prefix-orf <[e-mail]&gt;
Cc: idr@ietf. org <[e-mail]&gt;
Subject: [Idr] AD Evaluation of draft-ietf-idr-vpn-prefix-orf-23



Hello Authors/WG,


I've done the review as part of AD evaluation of&nbsp;draft-ietf-idr-vpn-prefix-orf-23 and would like to share the same with you.


Summary: The document needs some more work - editorial as well technical - before it can be progressed further.


technical tldr:
1) Mischaracterization of existing solutions in this space
2) Normative procedures with BCP14 keywords provided as examples instead of standalone normative text
3) Allocating one of 5 reserved bits in ORF common header for this new type specific purpose (and not doing that via IANA registry)
4) Mix of protocol procedures, operational and deployment considerations that results in lack of clarity and important details not getting called out prominently
5) Procedures specified as pseudocode but missing several conditions and gaps in logic
6) Aspects related to manageability considerations for quotas (which might require provisioning support on routers?) and the requirements on operators for their management seem under specified


Please find below my comments in the idnits output of v23 of this document. The end of the review is marked by the tag <EoRv23&gt;


Thanks,
Ketan


2	IDR Working Group &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;W. Wang
3	Internet-Draft &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; A. Wang
4	Intended status: Experimental &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;China Telecom

<major&gt; The document is missing the rationale for why it is to be  published&nbsp;
on the experimental track as opposed to the proposed standard track.  There&nbsp;
is Appendix A that is describing the experimental topology. I assume that this
draft is describing an experiment that is to be carried out. Please correct me
if I am wrong. If it is describing an experiment, then I suggest that Appendix A
be more generalized to describing the experiment, its goals/motivation, how it
is desired to be conducted, success criteria, etc. Then, there can be a sentence
at the end of the introduction section which points to this appendix.
[WW]: Since no vendor implementations existed when the draft is adopted as a WG draft, it was approved as an experimental track following discussions. I have observed that all existing standards defining new ORF types are under the standard track, and thus I would like to inquire whether this document can be reclassified into the standard track?


KT&gt; I would bring up this topic after we have completed the changes and the discussion of this review. For now, as suggested by Keyur, please retain the track as Experimental and provide the reasons as suggested in an appendix.
&nbsp;[WW]: Thank you! This proposal has been added in appendix A.


16	Abstract

18	 &nbsp; This draft defines a new type of Outbound Route Filter (ORF), known

<major&gt; s/a new type/an experimental type ... similar in introduction
[WW]: Done.

19	 &nbsp; as the Virtual Private Network (VPN) Prefix ORF.&nbsp; The VPN Prefix ORF
20	 &nbsp; mechanism is applicable when VPN routes from different Virtual
21	 &nbsp; Routing and Forwardings (VRFs) are exchanged through a single shared

<minor&gt; s/Forwardings/Forwarding instances ?
[WW]: Done.

22	 &nbsp; Border Gateway Protocol (BGP) session.

<major&gt; The abstract should also mention the purpose of this experimental ORF
type.
[WW]: We will add the purpose in abstract as follows:
"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."


94	 &nbsp; which consequently affects the route processing performance of other
95	 &nbsp; normal VRFs (such as route dropping, processing delays, and abnormal

<minor&gt; what is "normal" here? Suggest omitting that word.
[WW]: the word "normal" will be deleted.

96	 &nbsp; customer services).&nbsp; That is to say, the excessive VPN routes
97	 &nbsp; advertisement SHOULD be controlled individually for each VRF in such
98	 &nbsp; shared BGP session.

<major&gt; This looks like an incorrect usage of a BCP14 keyword. How about:

Therefore, it is desirable that the excessive VPN routes advertisement be
controlled individually for each VRF in such a shared BGP session.
[WW]: Done.


114	 &nbsp; However, there are limitations to existing solutions:

<major-editorial&gt; Suggest to introduce a new top-level section called "Existing
Solutions" and in there create sub-sections where each of the solution is
identified (the bullet list above) along with its limitation (the text under
each numbered item below). This section can be just before the new mechanism is
described (i.e., current section 4). I believe this would improve the readability
of this document.
[WW]: We will added a new section to describe the limitations of the existing solutions.


116	 &nbsp; 1) Route Target Constraint

118	 &nbsp; RTC can only filter the VPN routes from any uninterested VRFs, if the
119	 &nbsp; "offending routes (prefixes)" come from an interested VRF, the RTC
120	 &nbsp; mechanism can't filter them.

<major&gt; Suggest to rephrase to avoid use of "offending" throughout this document.
How about "route overload" or something like that which describes the nature of
these routes in a more technical manner? "Offending" is not a technical term.
[WW]: We will modify the descriptions in -v24.


122	 &nbsp; 2) Address Prefix ORF

124	 &nbsp; Using Address Prefix ORF to filter VPN routes requires a pre-
125	 &nbsp; configuration, but it is impossible to know in advance which prefix
126	 &nbsp; MAY exceed the predefined threshold.


<major&gt; Incorrect use of BCP14 keyword. s/MAY/may
[WW]: Done.


135	 &nbsp; CP-ORF is applicable in Virtual Hub-and-Spoke[RFC7024] VPN and also
136	 &nbsp; BGP/MPLS Ethernet VPN (EVPN)[RFC7432] networks, but its primary
137	 &nbsp; function is to retrieve interested VPN prefixes and it cannot be used
138	 &nbsp; to filter overwhelmed VPN prefixes dynamically.


<minor&gt; s/overwhelmed/overload of ?
[WW]: Done.


140	 &nbsp; 4) PE-CE edge peer Maximum Prefix
141	 &nbsp; The BGP Maximum-Prefix feature is used to control how many prefixes
142	 &nbsp; can be received from a neighbor.&nbsp; By default, this feature allows a
143	 &nbsp; router to bring down a peer when the number of received prefixes from

<major&gt; This is a mischaracterization. Peer down is not the only solution. You
can check various implementations from major vendors. You can also refer to
https://www.rfc-editor.org/rfc/rfc4271.html#section-6.7

&nbsp; &nbsp;When the upper bound is reached, the
&nbsp; &nbsp;speaker, under control of local configuration, either (a) discards
&nbsp; &nbsp;new address prefixes from the neighbor (while maintaining the BGP
&nbsp; &nbsp;connection with the neighbor), or (b) terminates the BGP connection
&nbsp; &nbsp;with the neighbor.
[WW]: Thanks for your information! We will modified the content as follows:
"The BGP Maximum-Prefix feature is used to control how many prefixes can be received from a neighbor. By default, this feature allows a router to drop overloading routes or bring down a peer when the number of received prefixes from that peer exceeds the configured Maximum-Prefix limit. "


KT&gt; Sure but that is not sufficient by itself since it does not mention the part about discarding newer prefixes. So, please reword to include that behavior and then explain why the new ORF type is better than this feature.
[WW]: We have added more explainations in Section 3.4.
&nbsp;


147	 &nbsp; from different VRFs will share the common fate.&nbsp; If the number of VPN
148	 &nbsp; routes of a certain VPN exceeds the configured Maximum-Prefix limit,
149	 &nbsp; the BGP session will be shut down, which will affect the operation of
150	 &nbsp; other VPN routes transmitted via this BGP session.

<major&gt; There also seems to be a mischaracterization here. I had the impression
that this option was about putting the limit on the PE towards the CE (which
is an eBGP IPv4/IPv6 unicast afi/safi session) and is for a specific VRF/VPN.
[WW]: Actually, within this draft, the VPN Prefix ORF primarily operates between PEs and RRs, which affects routes across multiple VPNs.


KT&gt; I understand that. However, the document in this subsection claims that the max-prefix limit (which is between PE and CE) is insufficient. Please correct the text in this section and then explain why the new ORF type is better.
[WW]: We have modified the contents of Section 3.5.





152	 &nbsp; 5) Configuring the Maximum Prefix for each VRF on edge nodes

154	 &nbsp; When a VRF overflows, it stops the import of routes.&nbsp; Any additional
155	 &nbsp; VPN routes are held into its Routing Information Base (RIB).

<major&gt; This is implementation specific and may not always be the case. Perhaps
fix this text to say "... some implementations may ...".
[WW]: Done.

156	 &nbsp; However, PEs still need to parse the incoming BGP messages.&nbsp; This
157	 &nbsp; will cost CPU cycles and further burden the overflowed PE.

<major-editorial&gt; In continuation of a previous comment, the rest of this section
below belongs in the introduction. You could also put a forward reference to
the new section where analysis of existing solutions is provided.
[WW]: Done.


169	 &nbsp; The purpose of this mechanism is to control the outage within the

<minor&gt; perhaps s/outage/overload ?
[WW]: Done.


176	2.&nbsp; Conventions used in this document

178	 &nbsp; The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
179	 &nbsp; "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
180	 &nbsp; document are to be interpreted as described in [RFC2119] .

<major&gt; Please update to the latest BCP14 template and consider introducing as a
section 1.1 "Requirements Language" or something like that.
[WW]: Done.


190	 &nbsp; * &nbsp;BGP: Border Gateway Protocol, defined in [RFC4760]

<major&gt; It should be RFC4271
[WW]: Done.


215	4.&nbsp; The general procedures of VPN Prefix ORF mechanism

<major-editorial&gt; I see an issue with the organization of sections 4, 7, 8, and
10. First, there are the protocol procedures - Tx side how ORF entries are
triggered, encoded and sent, Rx side how ORF entries are handled and
corresponding actions taken for the route-refresh processing and subsequent
propagation of the VPN routes. Second, there are deployment considerations,
same/unique RD, RT usage, intra-AS, inter-AS, etc. - those can be captured
in its own section. Finally, there are the operational considerations which
is what the operator needs to bear in mind on how to provision (e.g., quotas),
design, manage (manual clearing of ORF entries), and monitor (looking at alerts).
[WW]: The structure will be adjusted in -v24.


289	 &nbsp; For intra-AS VPN deployment, there are three scenarios:

291	 &nbsp; * &nbsp;RD is allocated per VPN per PE, each VRF only import one RT (see
292	 &nbsp; &nbsp; &nbsp;Section 4.1.1).

294	 &nbsp; * &nbsp;RD is allocated per VPN per PE.&nbsp; Multiple RTs are associated with
295	 &nbsp; &nbsp; &nbsp;such VPN routes, and are imported into different VRFs in other
296	 &nbsp; &nbsp; &nbsp;devices(see Section 4.1.2).

298	 &nbsp; * &nbsp;RD is allocated per VPN, each VRF imports one/multiple RTs (see
299	 &nbsp; &nbsp; &nbsp;Section 4.1.3).

<minor&gt; Can this be simplified to say that there are 2 main RD allocation
schemes - unique RD (per VPN, per PE) and the same RD (per VPN, same on all PEs)?
[WW]: Yes. We will simplify the schemes in -v24.


304	4.1.1.&nbsp; Scenario-1 and Solution (Unique RD, One RT)

<major&gt; Sections 4.1.1, 4.1.2 and 4.1.3 are all examples but contain normative
text with BCP14 languages. This is not appropriate. Normative text on procedures
need to stand on their own. The examples can be described in an informal language
and moved into the appendix. When working on the normative text for all 3 of these
sections, I am hoping that you would see the commonalities and that there can be&nbsp;
a single normative procedure that is independent of the RD and RT design. After&nbsp;
all, in the BGP code, I am assuming there won't be any checks on whether the&nbsp;
deployment design is using same or unique RD and how RTs are used?
[WW]: We will modify the descriptions and move them into the appendix.




339	 &nbsp; If quota value is not set on PE1, and each VRF has a prefix limit on

<major&gt; What is this quota value? It is used in several places in this document
but not formally defined (closest match is in the operational considerations).
Perhaps this can be added in the Terminology section? Then, this quota mechanism
needs to be specified in this document along with its provisioning/manageability
requirements - perhaps as its own separate section and before this quota starts&nbsp;
to get used in the procedures section.
[WW]: The definition of quota is described in Operational Considerations as:"Quota is a threshold to limit the number of VPN routes under specific granularities (such as <PE&gt;, <RD, Source AS&gt;)."
We will move this definition in Terminology.


607	5.&nbsp; Source PE Extended Community

609	 &nbsp; We usually use next hop to identify the source, but it MAY NOT be
610	 &nbsp; useful in the following scenarios:

<major&gt; MAY NOT is not a valid BCP14 keyword. Perhaps s/it MAY NOT be/it is not
Also, that claim/statement is incorrect - perhaps say ... Next hop does not
always identify the source ...?
[WW]: Done.


627	 &nbsp; The AS number of source PE can be conveyed by Source AS Extended
628	 &nbsp; Community, as defined in [RFC6514]

<major&gt; Is the Source AS EC always required to be included along with the
Source PE EC? Or is it only required in multi-AS deployments where BGP RIDs are
not unique?
[WW]: Source AS EC is only required in inter-domain scenario.


KT&gt; Please clarify that.
[WW]: Done.
&nbsp;


660	 &nbsp; The SPE EC SHOULD be attached by source PE, or else the RR SHOULD
661	 &nbsp; attach it, with the value set as the router-id of source PE.&nbsp; When
662	 &nbsp; none of them attach the SPE EC, the ASBR SHOULD attach it when the
663	 &nbsp; packet leaves the source AS, with the value set as the ORIGINATOR_ID.

<minor&gt; The above paragraph is duplicating the bullet list above it. Please&nbsp;
consider consolidating both?
[WW]: We think bullet list is more clear and easy to understand, so we will delete the text below the bullets.

665	 &nbsp; This section updates route reflection procedures, which means
666	 &nbsp; [RFC4456] needs to be updated.

<major&gt; I don't think the above statement is correct. If you agree, please remove
it. Please let me know if I am missing something and if you really want this&nbsp;
document to&nbsp;update that standards track RFC.
[WW]: The behavior of RR is defined in RFC 4456. SPE EC is a new type of information that RRs are required to carry, which is not specified in RFC 4456. Therefore, we think an update to RFC 4456 is necessary.


KT&gt; It is not "updating" but "extending" the RR behavior i.e., there is nothing wrong with the RR behavior in RFC4456 but if someone wants this new feature extension then the RR needs to do something additional. Please clarify as otherwise, this document would need to have the "updates" metadata tag for RFC4456 and I don't think that is needed.
[WW]: The contents of this part has been reworded.
&nbsp;



668	6.&nbsp; VPN Prefix ORF Encoding

<major-editorial&gt; I would recommend that this section (as well section 5) before
section 4 so the reader has seen and understood the ORF type before they start
reading the procedures. Also, this will avoid repetition of the same information
(e.g., take the default ORF entry) that is repeated in both the sections.
[WW]: We will do this modification in -v24.

670	 &nbsp; In this section, we defined a new ORF type called VPN Prefix Outbound
671	 &nbsp; Route Filter (VPN Prefix ORF).&nbsp; The ORF entries are carried in the
672	 &nbsp; BGP ROUTE-REFRESH message as defined in [RFC5291].&nbsp; A BGP ROUTE-
673	 &nbsp; REFRESH message can carry one or more ORF entries.&nbsp; The ROUTE-REFRESH
674	 &nbsp; message which carries ORF entries contains the following fields:

<minor&gt; Can you please rephrase the above to indicate that none of this is new
and the description below is how the VPN Prefix ORF is encoded in the refresh
message format of RFC5291.
[WW]: The descriptions will be changed to:
"In this section, we describe the encoding of VPN Prefix ORF entries.&nbsp; The VPN Prefix ORF entries are carried in the BGP ROUTE-REFRESH message as defined in [RFC5291].&nbsp; A BGP ROUTE-REFRESH message can carry one or more ORF entries.&nbsp; The format of a ROUTE-REFRESH message which carries VPN Prefix ORF entries are as follows:"

676	 &nbsp; * &nbsp;AFI (2 octets)

678	 &nbsp; * &nbsp;SAFI (1 octet)

<minor&gt; Some of the settings of these fields are repeated further below in this
section itself. Please update that text here so that everything is in one place.
[WW]: Done.




686	 &nbsp; A VPN Prefix ORF entry contains a common part and type-specific part.
687	 &nbsp; The common part is encoded as follows:

689	 &nbsp; * &nbsp;Action (2 bits): the value is ADD, REMOVE or REMOVE-ALL

691	 &nbsp; * &nbsp;Match (1 bit): the value is PERMIT or DENY

693	 &nbsp; * &nbsp;Offending VPN routes process method (1 bit): if the value is set
694	 &nbsp; &nbsp; &nbsp;to 0, it means all offending VPN routes on the sender of VPN
695	 &nbsp; &nbsp; &nbsp;Prefix ORF message SHOULD be withdrawn; if the value is set to 1,
696	 &nbsp; &nbsp; &nbsp;it means the sender of VPN Prefix ORF message refuse to receive
697	 &nbsp; &nbsp; &nbsp;new offending VPN routes.&nbsp; The default value is 0.

<major&gt; Looks like this document is allocating one of the reserved bits from
the common part of the ORF container that would be applicable not just for this
new ORF type but all ORF types. Now RFC5291 did not create an IANA registry
for these reserved bits, but perhaps there is now a need to create an IANA
registry for this 8-bit field to perform this allocation. This is going to take
some work and might be challenging given the experimental status of this
document. Another option is to do this via signaling in the type-specific
portion below since I don't see the technical merit of burning a common
bit for something type-specific. The authors and WG will need to decide this.
[WW]: We prefer to change this draft to standard track, and create an IANA registry for this field.


KT&gt; Please create an IANA registry for this field for now. We can discuss the change to standards track further down the line as discussed above.
[WW]: Done.
&nbsp;

699	 &nbsp; * &nbsp;Reserved (4 bits)

<minor&gt; It would be very helpful if there was a figure showing all of the above
fields just like the Figure 5 below.
[WW]: Done.


762	 &nbsp; * &nbsp;If the AFI is set to L2VPN, the SAFI MUST be set to BGP EVPN.

<major&gt; The document does not specify which EVPN Route Types this ORF type is
applicable for.
[WW]: This is just an example. SAFI cannot specify the EVPN Route Types.


KT&gt; Since the document is specifying the use of this extension for EVPN, it is required to specify which of the current route types this is applicable for. e.g., is it only applicable for RT5 or also for RT2 and to specify that it only applies to the specific IP prefix fields in the NLRI for those types?
[WW]: VPN Prefix ORF mechanism is applicable for all types of EVPN routes as defined in RFC7432. This is also clarified in -v24.
&nbsp;


782	 &nbsp; Source PE TLV is defined to identify the source of the VPN routes.
783	 &nbsp; For the sender of VPN Prefix ORF, it will check the existence of SPE
784	 &nbsp; EC.&nbsp; If it exists, the sender will put it into Source PE TLV.

<minor&gt; Perhaps ... check the existence of SPE EC on the VPN route being matched.
[WW]: Done.


788	 &nbsp; The Source PE TLV SHOULD only appear once within an individual ORF
789	 &nbsp; entry.&nbsp; If one ORF entry contains multiple Source PE TLVs, it SHOULD
790	 &nbsp; be ignored.

<major&gt; all should be ignored? first considered and rest ignored?
[WW]: Multiple Source PE TLV appear in one VPN Prefix ORF entry is an error. And it's hard to determine which one shoud be considered. So we think it's better to ignore all of them.


KT&gt; Sure - either option works. I am just asking that this be clarified - e.g., perhaps ... s/it SHOULD be ignore/all MUST be ignored
[WW]: Done.
&nbsp;


792	 &nbsp; The source PE TLV contains the following types:

<major&gt; What is meant by "contains" here? Are these sub-TLVs? I assume there are
3 types of TLVs used for identifying the "source". If so, please clarify this
entire section starting with the title.
[WW]: Done.

794	 &nbsp; * &nbsp;IPv4 Source PE TLV: Type = 1 (suggested), Length = 4 octets, value
795	 &nbsp; &nbsp; &nbsp;= next hop address in IPv4 format.

<minor&gt; Since this is a new TLV space, there is no need to say "suggested" next
to each entry. This applies to all the TLVs and also in the IANA considerations.
[WW]: Done.

797	 &nbsp; * &nbsp;IPv6 Source PE TLV: Type = 2 (suggested), Length = 16 octets,
798	 &nbsp; &nbsp; &nbsp;value = next hop address in IPv6 format.

<major&gt; Only global IPv6 addresses allowed?
[WW]: All IPv6 addresses are allowed.


KT&gt; How would link-local or multicast addresses work? Does ULA work?
[WW]: We think we can constraint it to global IPv6 address.
&nbsp;


800	 &nbsp; * &nbsp;Source PE identifier TLV: Type = 3 (suggested), Length = 4 octets,
801	 &nbsp; &nbsp; &nbsp;value = the value of ORIGINATOR_ID in Source PE Extended
802	 &nbsp; &nbsp; &nbsp;Community.

<question&gt; At this point, the document is experimental. I don't see any
implementation reporting support for any of the Source PE TLVs. And I already
find 3 types of TLVs! Seems complicated to me. Why not just have the
Source PE identifier TLV alone in this experiment? If/when this becomes standard
track, you may add the other types if they are really determined to be
necessary?
[WW]: This is related to the first question. Maybe we can discuss about whether this draft can be changed to standard track before we put it forward.


KT&gt; It is not really related. The question was if all these types were found to be necessary in the experimentation done so far? If yes, it is ok to keep them. But I see no one has implemented even one of these types and hence the question if 3 types are needed.
[WW]: Since different types of address has different length (e.g. ipv4 address vs ipv6 address). I'm not sure how can we merge them into one type? To define a type with a variable lenth?
&nbsp;


818	6.3.&nbsp; Route Target TLV

820	 &nbsp; Route Target TLV is defined to identify the RT of the offending VPN
821	 &nbsp; routes.&nbsp; RT and RD can be used together to filter VPN routes when the
822	 &nbsp; source VRF contains multiple RTs, and the VPN routes with different
823	 &nbsp; RTs MAY be assigned to different VRFs on the receiver.&nbsp; The Route
824	 &nbsp; Target TLV contains the following types:

826	 &nbsp; &nbsp; &nbsp;Type = 5 (suggested), Length = 8*n (n is the number of RTs that
827	 &nbsp; &nbsp; &nbsp;the offending VPN routes attached) octets, value = the RT of the
828	 &nbsp; &nbsp; &nbsp;offending VPN routes.&nbsp; If multiple RTs are included, there MUST be
829	 &nbsp; &nbsp; &nbsp;an exact match.

<major&gt; And if only one RT is present in this TLV and there are multiple RTs on
the VPN route? Please clarify.
[WW]: If this TLV contains only one RT but multiple RTs are configured on the VPN route, the device should check whether the RT included in this TLV exists among the multiple RTs configured on the VPN route. If it exists, the device should filter out the VPN route.


KT&gt; Please clarify this in the text.
[WW]: Done.&nbsp;


831	7.&nbsp; Operation process of VPN Prefix ORF mechanism on receiver

<major&gt; This isn't an operational process but more like a protocol procedure
on the router receiving these ORF entries. The title is misleading. More
importantly, what are the similar procedures on the sending side?
[WW]: We will change the title of this section to "Protocol procedures".
The procedure of the sender is described based on three scenarios in Section 4.&nbsp;

833	 &nbsp; The VPN Prefix ORF is used mainly to block the unwanted BGP updates.
834	 &nbsp; When the receiver receives VPN Prefix ORF entry, it SHOULD check
835	 &nbsp; first whether the "Match" bit is "DENY" or not.

837	 &nbsp; If the "Match" bit is "PERMIT", and is the "default" entry (the
838	 &nbsp; offending VPN routes process method equal to 0, sequence equal to
839	 &nbsp; 0xFFFFFFFF, length is equal to 8, and Route Distinguisher is equal to
840	 &nbsp; 0), the entry SHOULD be installed.&nbsp; Otherwise, if the "Match" bit is

<major&gt; Why SHOULD and not MUST? Isn't this essential?
[WW]: Will be changed to "MUST".

841	 &nbsp; "PERMIT", the entry SHOULD be discarded and a warning SHOULD be sent
842	 &nbsp; to the operator.

<major&gt; Why SHOULD and not MUST?
[WW]: Will be changed to "MUST".

844	 &nbsp; The following procedures will only be evaluated when the "Match" bit
845	 &nbsp; is "DENY".

847	 &nbsp; The receiver of VPN Prefix ORF entries, which MAY be a RR, ASBR or

<major&gt; s/MAY/may
[WW]: Done.


848	 &nbsp; PE, when receives VPN Prefix ORF entry from its BGP peer, it does the
849	 &nbsp; following:

851	 &nbsp; S01. The receiver checks the combination of <AFI/SAFI, ORF-Type,
852	 &nbsp; &nbsp; &nbsp; &nbsp;Sequence, Route Distinguisher&gt; of the received VPN Prefix
853	 &nbsp; &nbsp; &nbsp; &nbsp;ORF entry.
854	 &nbsp; S02. If (the combination does not already exist in the ORF-Policy
855	 &nbsp; &nbsp; &nbsp; &nbsp;table) {
856	 &nbsp; S03. &nbsp; &nbsp; The receiver adds the VPN Prefix ORF entry to the
857	 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;ORF-Policy table.

<major&gt; This seems odd - what if the action was REMOVE?
[WW]: We will adjust this procedure. If the action is REMOVE, the corresponding VPN Prefix ORF entry should be removed from the ORF-Policy table.

858	 &nbsp; S04. } else {
859	 &nbsp; S05. &nbsp; &nbsp; If (Action is ADD) {
860	 &nbsp; S06. &nbsp; &nbsp; &nbsp; &nbsp; Overwrite the old VPN Prefix ORF entry with the new
861	 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;one.
862	 &nbsp; S07. &nbsp; &nbsp; else {
863	 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Remove the corresponding VPN Prefix ORF entry.

<major&gt; What about REMOVE-ALL handling?
[WW]: If the action is REMOVE-ALL, all VPN Prefix ORF entries should be removed from the ORF-Policy table.


KT&gt; Ok - please clarify in this pseudocode.
[WW]: Done.
&nbsp;


866	 &nbsp; The filtering conditions for the stored VPN Prefix ORF entries
867	 &nbsp; contain the RD and RT of the source PE.

<major&gt; You mean the contents of the TLVs are stored? If so, please state it
that way.
[WW]: Do you mean we should state it in the encoding section?


KT&gt; I would think this would be part of the procedures on the receiver side?
[WW]: This has been contained in pseudocode in Section 5.2.
&nbsp;


869	 &nbsp; If the SPE EC is not attached to the BGP Update message of the VPN
870	 &nbsp; prefixes, the receiver SHOULD use NEXT_HOP or ORIGINATOR_ID as the

<major&gt; Why not MUST?
[WW]: Will be changed to "MUST".


873	 &nbsp; After installing the filter entries for the outbound VPN prefixes,
874	 &nbsp; the RR or ASBR does the following before sending VPN routes:

<major&gt; It is not clear if the steps below are related to the route refresh
processing after getting the ORF update, or the usual VPN route propagation,
or both. The processing is different in those cases and so please clarify.
[WW]: This procedure is used for both.


KT&gt; Please clarify in the text. Change in the ORF prefixes will result in a "re-scan" followed by a "refresh" while regular individual VPN route updates will just be checked against the ORF rules.
[WW]: This has been clarified in Section 5.2.
&nbsp;





896	8.&nbsp; Withdraw of VPN Prefix ORF entries

<major&gt; Is "withdraw" the same as REMOVE or REMOVE-ALL? I am very confused.
Seems like this entire section needs to go into the operational considerations
section. This has nothing to do with protocol procedures.
[WW]: We will move this part to the operational considerations section.


931	9.&nbsp; Applicability

<major&gt; This is not applicability. Feels more like examples to me. However, there
is some normative text in this section which is confusing. For all normative
aspects, please move the text into the sections where either the encoding or
procedures are specified. If these examples need to be retained, please move them
into an informative appendix section.
[WW]: We will delete the normative texts and move this section to informative appendix.


1004	10.&nbsp; Operational Considerations

1006	10.1.&nbsp; Quota value calculation

1008	 &nbsp; Quota is a threshold to limit the number of VPN routes under specific
1009	 &nbsp; granularities (such as <PE&gt;, <RD, Source AS&gt;).

<major&gt; It is not very clear if the operator specifying these quotas via their
NMS is a prerequisite for this feature to work. There is a need for an
applicability section in this document (just before the encodings and procedures)
that describes where this feature can be deployed, for which types of VPNs,
what are the things that operators need to do (e.g., this quota provisioning), and
any other requirements and limitations.
[WW]: We will do this in -v24.


1029	11.&nbsp; Implementation Consideration

<major-editorial&gt; This section does not contain any implementation considerations.
Please remove it. The implementation status should be captured in the report
on the IDR wiki as is the WG norm. The Experimental topology can be moved into
the Appendix section describing the experiment.
[WW]: We will delete this section.


1068	13.&nbsp; IANA Considerations

<minor&gt; There are 3 actions below. Suggest to create 3 sub-sections and in each
list precisely the IANA actions requested or done.
[WW]: We will do this adjustment in -v24.


1073	 &nbsp; We would want to refer to the text from [RFC5291]: This new ORF is
1074	 &nbsp; exchanged using outbound route filtering capability defined in
1075	 &nbsp; [RFC5291] (for the sake of completeness).

1077	 &nbsp; under "BGP Outbound Route Filtering (ORF) Types"
1078	 &nbsp; Registry: "VPN Prefix Outbound Route Filter (VPN Prefix ORF)"
1079	 &nbsp; Registration Procedure(s): First Come, First Served
1080	 &nbsp; Value: 66

<major&gt; I am not able to follow the above two paragraphs. The allocation for value
66 for the new type has already been done by IANA. Simply state that. Next,
it seems like a request for creation of a new IANA registry - please say that clearly.
[WW]: We have communicated with IANA staff regarding this part of the content before the WGLC and revised it to the current version.


KT&gt; IANA team is not able to technically review specifications. Can you please clarify the text as suggested?&nbsp;
[WW]: Done.





1095	 &nbsp; &nbsp;+=====================+=============+===========================+
1096	 &nbsp; &nbsp;| Registry &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;| &nbsp; &nbsp; Type &nbsp; &nbsp;| &nbsp; &nbsp; &nbsp; Meaning &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |
1097	 &nbsp; &nbsp;+=====================+=============+===========================+
1098	 &nbsp; &nbsp;|Reserved &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; | 0(suggested)|Reserved &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |
1099	 &nbsp; &nbsp;+---------------------+-------------+---------------------------+
1100	 &nbsp; &nbsp;|IPv4 Source PE TLV &nbsp; | 1(suggested)|IPv4 address for source PE.|
1101	 &nbsp; &nbsp;+---------------------+-------------+---------------------------+
1102	 &nbsp; &nbsp;|IPv6 Source PE TLV &nbsp; | 2(suggested)|IPv6 address for source PE.|
1103	 &nbsp; &nbsp;+---------------------+-------------+---------------------------+
1104	 &nbsp; &nbsp;|Source PE Identifier | 3(suggested)|ORIGINATOR_ID in Source PE |
1105	 &nbsp; &nbsp;|TLV &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |Extended Community for &nbsp; &nbsp; |
1106	 &nbsp; &nbsp;| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; | &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |source PE &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;|
1107	 &nbsp; &nbsp;+---------------------+-------------+---------------------------+
1108	 &nbsp; &nbsp;|Source AS TLV &nbsp; &nbsp; &nbsp; &nbsp;| 4(suggested)|Source AS for source PE &nbsp; &nbsp;|
1109	 &nbsp; &nbsp;+---------------------+-------------+---------------------------+
1110	 &nbsp; &nbsp;|Route Target TLV &nbsp; &nbsp; | 5(suggested)|Route Target of the &nbsp; &nbsp; &nbsp; &nbsp;|
1111	 &nbsp; &nbsp;| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; | &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |offending VPN routes &nbsp; &nbsp; &nbsp; |
1112	 &nbsp; &nbsp;+---------------------+-------------+---------------------------+

<major&gt; The above table has initial allocations which can be done straight away.
So the "suggested" is not required. I don't think the "meaning" column is
necessary. What is required is the reference column that points to this
document.
[WW]: We will do this modification in -v24.


1114	 &nbsp; This document also requests a new Transitive Extended Community Type.
1115	 &nbsp; The new Transitive Extended Community Type name SHALL be "Source PE
1116	 &nbsp; Extended Community".

1118	 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Under "BGP Transitive Extended Community Types:"
1119	 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Registry: "Source PE Extended Community" type
1120	 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;0x0d(suggested) &nbsp; &nbsp; &nbsp; &nbsp; Source PE Extended Community

<major&gt; The above is not clear to me - exactly which registry the allocation is to
be made under and under which registry-group. You cannot make suggestions here.
If required, allocations can be done with IANA under FCFS - what is being done
here is problematic (squatting on code points?).
[WW]: This section proposes registering the "Source PE Extended Community" Registry-Group in the "BGP Transitive Extended Community Types" Registry. The Registration Procedure(s) is set to FCFS, and the suggestions on value assignments will be removed.


KT&gt; OK.


Thanks,
Ketan
&nbsp;


<EoRv23&gt;