Return-Path: X-Original-To: idr@mail2.ietf.org Delivered-To: idr@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id D8CB48E8083A for ; Fri, 21 Nov 2025 22:47:29 -0800 (PST) X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SkUpKf_OT4tv for ; Fri, 21 Nov 2025 22:47:27 -0800 (PST) Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 758C28E80828 for ; Fri, 21 Nov 2025 22:47:27 -0800 (PST) Received: by mail-pl1-x630.google.com with SMTP id d9443c01a7336-297dd95ffe4so23847095ad.3 for ; Fri, 21 Nov 2025 22:47:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1763794040; x=1764398840; darn=ietf.org; h=cc:to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=3SHWD2fQdXtBxwGtDadjXb8LqBbBOczwQU/qdZJYPqw=; b=dDDcY+4fSPww3DGHvw7M601bNpgzpVTcD4c0HSwiWlN/N4id1An/FgwXO+pjYmUdso 2hRwiPQHzB9ppMDoTnmXfTAcKEijVAxuyvCVvpLub5WI6vfU2ySU1S7Qf41lkVkgnGY+ cOMK8vMlYVoLTCXYuMWFa84Ui0GSZEmZvqWywyeLaOmgj9eVygeDA0kqj11xwoOor5ko 6ONGQtG6d8glUTUvKBL+DzXbN0B+sIrBYxTxUfo+s1mS8TkMX7DKvf/BzNiGmEmF13Wn l602Yb8EY/jfLrentnipM5JcGkh7mGcr9p+GaR5ie7cjpAT1pJodRD4/swgpdRtxYbE1 bXMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763794040; x=1764398840; h=cc:to:subject:message-id:date:from:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=3SHWD2fQdXtBxwGtDadjXb8LqBbBOczwQU/qdZJYPqw=; b=ViawGmauaKg/OE+WCc0kbez33I0dxc5berydmUhk+BW6iuOhjF84Jm3kfirVC7wXeP AcMyHOvEwneC14g+wKYQTOrJuLER5XrSwy8RKG4Q9RD7oXl8VcW/pGVLtqA0igHcwbEt waxtOeR+GuUD8ONF8MYB9jF7gUvVZm6G/9sI1gol2mDklA+cgrDLg5DjdpwgViC2a9Gf e8nC5M69YFUIIQ25SPX2tYeKtr4ZpeUJ7Sm7D6SEW90kPp8bVqnia0yETsjNHvLCDLL4 PSFGT1NrQvhmqGBZt5GDAY+B2WhvId5J6Lw9xs0/MYKMQ/HPTn0mkVqoPuNmE5UaRIvH RbTA== X-Gm-Message-State: AOJu0YzydF82hRhVtlP4SgAu9eHddJiI09LJPyzwofqxpVNohzFRdNT2 rD7GeikIxFMKqhWvUXRUTDEYt3wwzrCKuUiGdv6rByInVqh/RGdUgP7CZuaPho7BaM5LsSKrrMU nGCzDq/R1Fr/TwoMNKdLOHE31Ivf/XgA= X-Gm-Gg: ASbGncsORmvePdnxI9phD1OwOoL/o4WRM24MZBvIhtDIqNGvlQC5nH+qcM/p14GwpeP sGcOKfyAinWLbfUSI4dEn87IerDjpBQIr5tmUZ9mVpZ6q2e9CGzePhn4ysoXzlPdxT0HZZp8UD3 Ns28PrPY+0XzA5SusGBfGwFq2m1pYrdE+3zetBkZ9h7EwXiiDdJ1BORCRlFXbNDQ/pb3bDnI/ff aBqf+Ggvv9TXS2NbfgF3y2zr776Fxop6m00cCrqocAOBUo83KupVndR3xEOYmDgaQylp8VBAvd1 XsKG0eXGoIWMYPuMyzo39gPLk/AEPuxg94UDIrI= X-Google-Smtp-Source: AGHT+IETM8IhIjUO1MiawkjOmR/gVBiAeRnSqmHb21NeHk0onP2fgjAaEu8G4x2WbiwEmeHxVA08ZHotqIvw+m1G0q0= X-Received: by 2002:a17:903:3d0e:b0:29b:6750:c65f with SMTP id d9443c01a7336-29b6be8c8b0mr59817495ad.10.1763794040049; Fri, 21 Nov 2025 22:47:20 -0800 (PST) MIME-Version: 1.0 From: Ketan Talaulikar Date: Sat, 22 Nov 2025 12:17:07 +0530 X-Gm-Features: AWmQ_bnLzwVk6hgbx2etadF4P2OZ2qyCHlEGi25yrNkMplY6xuTkATfAq2U6F-Q Message-ID: To: draft-ietf-idr-vpn-prefix-orf@ietf.org Content-Type: multipart/alternative; boundary="00000000000036d44a0644294dd7" Message-ID-Hash: 7QM53XYR4CZTDTGE76OS3EVDJ2SEE4VR X-Message-ID-Hash: 7QM53XYR4CZTDTGE76OS3EVDJ2SEE4VR X-MailFrom: ketant.ietf@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-idr.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: "idr@ietf. org" X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5BIdr=5D_AD_Evaluation_of_draft-ietf-idr-vpn-prefix-orf-23?= List-Id: Inter-Domain Routing Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --00000000000036d44a0644294dd7 Content-Type: text/plain; charset="UTF-8" Hello Authors/WG, I've done the review as part of AD evaluation of 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 Thanks, Ketan 2 IDR Working Group W. Wang 3 Internet-Draft A. Wang 4 Intended status: Experimental China Telecom The document is missing the rationale for why it is to be published on the experimental track as opposed to the proposed standard track. There 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. 16 Abstract 18 This draft defines a new type of Outbound Route Filter (ORF), known s/a new type/an experimental type ... similar in introduction 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 Forwardings (VRFs) are exchanged through a single shared s/Forwardings/Forwarding instances ? 22 Border Gateway Protocol (BGP) session. The abstract should also mention the purpose of this experimental ORF type. 94 which consequently affects the route processing performance of other 95 normal VRFs (such as route dropping, processing delays, and abnormal what is "normal" here? Suggest omitting that word. 96 customer services). That is to say, the excessive VPN routes 97 advertisement SHOULD be controlled individually for each VRF in such 98 shared BGP session. 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. 114 However, there are limitations to existing solutions: 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. 116 1) Route Target Constraint 118 RTC can only filter the VPN routes from any uninterested VRFs, if the 119 "offending routes (prefixes)" come from an interested VRF, the RTC 120 mechanism can't filter them. 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. 122 2) Address Prefix ORF 124 Using Address Prefix ORF to filter VPN routes requires a pre- 125 configuration, but it is impossible to know in advance which prefix 126 MAY exceed the predefined threshold. Incorrect use of BCP14 keyword. s/MAY/may 135 CP-ORF is applicable in Virtual Hub-and-Spoke[RFC7024] VPN and also 136 BGP/MPLS Ethernet VPN (EVPN)[RFC7432] networks, but its primary 137 function is to retrieve interested VPN prefixes and it cannot be used 138 to filter overwhelmed VPN prefixes dynamically. s/overwhelmed/overload of ? 140 4) PE-CE edge peer Maximum Prefix 141 The BGP Maximum-Prefix feature is used to control how many prefixes 142 can be received from a neighbor. By default, this feature allows a 143 router to bring down a peer when the number of received prefixes from 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 When the upper bound is reached, the speaker, under control of local configuration, either (a) discards new address prefixes from the neighbor (while maintaining the BGP connection with the neighbor), or (b) terminates the BGP connection with the neighbor. 147 from different VRFs will share the common fate. If the number of VPN 148 routes of a certain VPN exceeds the configured Maximum-Prefix limit, 149 the BGP session will be shut down, which will affect the operation of 150 other VPN routes transmitted via this BGP session. 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. 152 5) Configuring the Maximum Prefix for each VRF on edge nodes 154 When a VRF overflows, it stops the import of routes. Any additional 155 VPN routes are held into its Routing Information Base (RIB). This is implementation specific and may not always be the case. Perhaps fix this text to say "... some implementations may ...". 156 However, PEs still need to parse the incoming BGP messages. This 157 will cost CPU cycles and further burden the overflowed PE. 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. 169 The purpose of this mechanism is to control the outage within the perhaps s/outage/overload ? 176 2. Conventions used in this document 178 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 179 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 180 document are to be interpreted as described in [RFC2119] . Please update to the latest BCP14 template and consider introducing as a section 1.1 "Requirements Language" or something like that. 190 * BGP: Border Gateway Protocol, defined in [RFC4760] It should be RFC4271 215 4. The general procedures of VPN Prefix ORF mechanism 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). 289 For intra-AS VPN deployment, there are three scenarios: 291 * RD is allocated per VPN per PE, each VRF only import one RT (see 292 Section 4.1.1). 294 * RD is allocated per VPN per PE. Multiple RTs are associated with 295 such VPN routes, and are imported into different VRFs in other 296 devices(see Section 4.1.2). 298 * RD is allocated per VPN, each VRF imports one/multiple RTs (see 299 Section 4.1.3). 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)? 304 4.1.1. Scenario-1 and Solution (Unique RD, One RT) 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 a single normative procedure that is independent of the RD and RT design. After all, in the BGP code, I am assuming there won't be any checks on whether the deployment design is using same or unique RD and how RTs are used? 339 If quota value is not set on PE1, and each VRF has a prefix limit on 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 to get used in the procedures section. 607 5. Source PE Extended Community 609 We usually use next hop to identify the source, but it MAY NOT be 610 useful in the following scenarios: 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 ...? 627 The AS number of source PE can be conveyed by Source AS Extended 628 Community, as defined in [RFC6514] 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? 660 The SPE EC SHOULD be attached by source PE, or else the RR SHOULD 661 attach it, with the value set as the router-id of source PE. When 662 none of them attach the SPE EC, the ASBR SHOULD attach it when the 663 packet leaves the source AS, with the value set as the ORIGINATOR_ID. The above paragraph is duplicating the bullet list above it. Please consider consolidating both? 665 This section updates route reflection procedures, which means 666 [RFC4456] needs to be updated. 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 document to update that standards track RFC. 668 6. VPN Prefix ORF Encoding 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. 670 In this section, we defined a new ORF type called VPN Prefix Outbound 671 Route Filter (VPN Prefix ORF). The ORF entries are carried in the 672 BGP ROUTE-REFRESH message as defined in [RFC5291]. A BGP ROUTE- 673 REFRESH message can carry one or more ORF entries. The ROUTE-REFRESH 674 message which carries ORF entries contains the following fields: 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. 676 * AFI (2 octets) 678 * SAFI (1 octet) 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. 686 A VPN Prefix ORF entry contains a common part and type-specific part. 687 The common part is encoded as follows: 689 * Action (2 bits): the value is ADD, REMOVE or REMOVE-ALL 691 * Match (1 bit): the value is PERMIT or DENY 693 * Offending VPN routes process method (1 bit): if the value is set 694 to 0, it means all offending VPN routes on the sender of VPN 695 Prefix ORF message SHOULD be withdrawn; if the value is set to 1, 696 it means the sender of VPN Prefix ORF message refuse to receive 697 new offending VPN routes. The default value is 0. 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. 699 * Reserved (4 bits) It would be very helpful if there was a figure showing all of the above fields just like the Figure 5 below. 762 * If the AFI is set to L2VPN, the SAFI MUST be set to BGP EVPN. The document does not specify which EVPN Route Types this ORF type is applicable for. 782 Source PE TLV is defined to identify the source of the VPN routes. 783 For the sender of VPN Prefix ORF, it will check the existence of SPE 784 EC. If it exists, the sender will put it into Source PE TLV. Perhaps ... check the existence of SPE EC on the VPN route being matched. 788 The Source PE TLV SHOULD only appear once within an individual ORF 789 entry. If one ORF entry contains multiple Source PE TLVs, it SHOULD 790 be ignored. all should be ignored? first considered and rest ignored? 792 The source PE TLV contains the following types: 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. 794 * IPv4 Source PE TLV: Type = 1 (suggested), Length = 4 octets, value 795 = next hop address in IPv4 format. 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. 797 * IPv6 Source PE TLV: Type = 2 (suggested), Length = 16 octets, 798 value = next hop address in IPv6 format. Only global IPv6 addresses allowed? 800 * Source PE identifier TLV: Type = 3 (suggested), Length = 4 octets, 801 value = the value of ORIGINATOR_ID in Source PE Extended 802 Community. 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? 818 6.3. Route Target TLV 820 Route Target TLV is defined to identify the RT of the offending VPN 821 routes. RT and RD can be used together to filter VPN routes when the 822 source VRF contains multiple RTs, and the VPN routes with different 823 RTs MAY be assigned to different VRFs on the receiver. The Route 824 Target TLV contains the following types: 826 Type = 5 (suggested), Length = 8*n (n is the number of RTs that 827 the offending VPN routes attached) octets, value = the RT of the 828 offending VPN routes. If multiple RTs are included, there MUST be 829 an exact match. And if only one RT is present in this TLV and there are multiple RTs on the VPN route? Please clarify. 831 7. Operation process of VPN Prefix ORF mechanism on receiver 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? 833 The VPN Prefix ORF is used mainly to block the unwanted BGP updates. 834 When the receiver receives VPN Prefix ORF entry, it SHOULD check 835 first whether the "Match" bit is "DENY" or not. 837 If the "Match" bit is "PERMIT", and is the "default" entry (the 838 offending VPN routes process method equal to 0, sequence equal to 839 0xFFFFFFFF, length is equal to 8, and Route Distinguisher is equal to 840 0), the entry SHOULD be installed. Otherwise, if the "Match" bit is Why SHOULD and not MUST? Isn't this essential? 841 "PERMIT", the entry SHOULD be discarded and a warning SHOULD be sent 842 to the operator. Why SHOULD and not MUST? 844 The following procedures will only be evaluated when the "Match" bit 845 is "DENY". 847 The receiver of VPN Prefix ORF entries, which MAY be a RR, ASBR or s/MAY/may 848 PE, when receives VPN Prefix ORF entry from its BGP peer, it does the 849 following: 851 S01. The receiver checks the combination of of the received VPN Prefix 853 ORF entry. 854 S02. If (the combination does not already exist in the ORF-Policy 855 table) { 856 S03. The receiver adds the VPN Prefix ORF entry to the 857 ORF-Policy table. This seems odd - what if the action was REMOVE? 858 S04. } else { 859 S05. If (Action is ADD) { 860 S06. Overwrite the old VPN Prefix ORF entry with the new 861 one. 862 S07. else { 863 Remove the corresponding VPN Prefix ORF entry. What about REMOVE-ALL handling? 866 The filtering conditions for the stored VPN Prefix ORF entries 867 contain the RD and RT of the source PE. You mean the contents of the TLVs are stored? If so, please state it that way. 869 If the SPE EC is not attached to the BGP Update message of the VPN 870 prefixes, the receiver SHOULD use NEXT_HOP or ORIGINATOR_ID as the Why not MUST? 873 After installing the filter entries for the outbound VPN prefixes, 874 the RR or ASBR does the following before sending VPN routes: 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. 896 8. Withdraw of VPN Prefix ORF entries 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. 931 9. Applicability 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. 1004 10. Operational Considerations 1006 10.1. Quota value calculation 1008 Quota is a threshold to limit the number of VPN routes under specific 1009 granularities (such as , ). 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. 1029 11. Implementation Consideration 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. 1068 13. IANA Considerations There are 3 actions below. Suggest to create 3 sub-sections and in each list precisely the IANA actions requested or done. 1073 We would want to refer to the text from [RFC5291]: This new ORF is 1074 exchanged using outbound route filtering capability defined in 1075 [RFC5291] (for the sake of completeness). 1077 under "BGP Outbound Route Filtering (ORF) Types" 1078 Registry: "VPN Prefix Outbound Route Filter (VPN Prefix ORF)" 1079 Registration Procedure(s): First Come, First Served 1080 Value: 66 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. 1095 +=====================+=============+===========================+ 1096 | Registry | Type | Meaning | 1097 +=====================+=============+===========================+ 1098 |Reserved | 0(suggested)|Reserved | 1099 +---------------------+-------------+---------------------------+ 1100 |IPv4 Source PE TLV | 1(suggested)|IPv4 address for source PE.| 1101 +---------------------+-------------+---------------------------+ 1102 |IPv6 Source PE TLV | 2(suggested)|IPv6 address for source PE.| 1103 +---------------------+-------------+---------------------------+ 1104 |Source PE Identifier | 3(suggested)|ORIGINATOR_ID in Source PE | 1105 |TLV | |Extended Community for | 1106 | | |source PE | 1107 +---------------------+-------------+---------------------------+ 1108 |Source AS TLV | 4(suggested)|Source AS for source PE | 1109 +---------------------+-------------+---------------------------+ 1110 |Route Target TLV | 5(suggested)|Route Target of the | 1111 | | |offending VPN routes | 1112 +---------------------+-------------+---------------------------+ 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. 1114 This document also requests a new Transitive Extended Community Type. 1115 The new Transitive Extended Community Type name SHALL be "Source PE 1116 Extended Community". 1118 Under "BGP Transitive Extended Community Types:" 1119 Registry: "Source PE Extended Community" type 1120 0x0d(suggested) Source PE Extended Community 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?). --00000000000036d44a0644294dd7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Authors/WG,

I've done the rev= iew as part of AD evaluation of=C2=A0draft-ietf-idr-vpn-prefix-orf-23 and w= ould like to share the same with you.

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

technical tldr:
1) Mischaracterization of existing solutions in this space
2) No= rmative procedures with BCP14 keywords provided as examples instead of stan= dalone normative text
3) Allocating one of 5 reserved bits in ORF= common header for this new type specific purpose (and not doing that via I= ANA registry)
4) Mix of protocol procedures, operational and depl= oyment considerations that results in lack of clarity and important details= not getting called out prominently
5) Procedures specified as ps= eudocode but missing several conditions and gaps in logic
6) Aspe= cts related to manageability considerations for quotas (which might require= provisioning support on routers?) and the requirements on operators for th= eir management seem under specified

Please find be= low my comments in the idnits output of v23 of this document. The end of th= e review is marked by the tag <EoRv23>

Thank= s,
Ketan

2 IDR = Working Group =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0W. Wang
3 Internet-Draft =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 A. Wang
4 Intended status: Experimental =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0China Telecom

<major> The document is missing the= rationale for why it is to be=C2=A0 published=C2=A0
on the experimental track as opposed to the proposed standard= track.=C2=A0 There=C2=A0
is Appendix A that is describing the experimental topology. I ass= ume that this
draft is describing an experiment that is to be carried ou= t. Please correct me
if I am wrong. If it is describing an experiment, t= hen I suggest that Appendix A
be more generalized to describing the exp= eriment, its goals/motivation, how it
is desired to be conducted, succe= ss criteria, etc. Then, there can be a sentence
at the end of the introd= uction section which points to this appendix.

16 Abstract
18 =C2=A0 This draft defines a new type of Outbound Route Filter (OR= F), known

<major> s/a new type/an experimental type ... simila= r in introduction

19 =C2=A0 = as the Virtual Private Network (VPN) Prefix ORF.=C2=A0 The VPN Prefix ORF20 =C2=A0 mechanism is applicable when VPN routes from different Virtual=
21 =C2=A0 Routing and Forwardings (VRFs) are exchanged through a singl= e shared

<minor> s/Forwardings/Forwarding instances ?

2= 2 =C2=A0 Border Gateway Protocol (BGP) session.

<major> The a= bstract should also mention the purpose of this experimental ORF
type.

94 =C2=A0 which consequently affects the route processing p= erformance of other
95 =C2=A0 normal VRFs (such as route dropping, proc= essing delays, and abnormal

<minor> what is "normal"= here? Suggest omitting that word.

96 =C2=A0 customer services).=C2= =A0 That is to say, the excessive VPN routes
97 =C2=A0 advertisement SH= OULD be controlled individually for each VRF in such
98 =C2=A0 shared B= GP session.

<major> This looks like an incorrect usage of a BC= P14 keyword. How about:

Therefore, it is desirable that the excessiv= e VPN routes advertisement be
controlled individually for each VRF in s= uch a shared BGP session.
114 =C2=A0 However, there are = limitations to existing solutions:

<major-editorial> Suggest t= o introduce a new top-level section called "Existing
Solutions"= ; and in there create sub-sections where each of the solution is
identi= fied (the bullet list above) along with its limitation (the text under
e= ach numbered item below). This section can be just before the new mechanism= is
described (i.e., current section 4). I believe this would improve th= e readability
of this document.

116 =C2=A0 1) Route Targe= t Constraint

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

<major> Suggest to rephrase to avoid use of &= quot;offending" throughout this document.
How about "route ove= rload" or something like that which describes the nature of
these = routes in a more technical manner? "Offending" is not a technical= term.

122 =C2=A0 2) Address Prefix ORF

124 =C2=A0 Using = Address Prefix ORF to filter VPN routes requires a pre-
125 =C2=A0 conf= iguration, but it is impossible to know in advance which prefix
126 =C2= =A0 MAY exceed the predefined threshold.

<major> Incorrect use of BCP14 keyword. s/MAY/may

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

<minor> s/overwhel= med/overload of ?

140 =C2=A0 4) PE-CE edge peer Maximum Pref= ix
141 =C2=A0 The BGP Maximum-Prefix = feature is used to control how many prefixes
142 =C2=A0 can be received= from a neighbor.=C2=A0 By default, this feature allows a
143 =C2=A0 ro= uter to bring down a peer when the number of received prefixes from

= <major> This is a mischaracterization. Peer down is not the only solu= tion. You
can check various implementations from major vendors. You can = also refer to
https://www.rfc-editor.org/rfc/rfc4271.html#section-6.7
=C2=A0 =C2=A0When the upper bound is reached, the
=C2=A0 =C2=A0speaker= , under control of local configuration, either (a) discards
=C2=A0 =C2= =A0new address prefixes from the neighbor (while maintaining the BGP
=C2= =A0 =C2=A0connection with the neighbor), or (b) terminates the BGP connecti= on
=C2=A0 =C2=A0with the neighbor.


147 =C2=A0 from different VRFs will share the common= fate.=C2=A0 If the number of VPN
148 =C2=A0 routes of a certain VPN ex= ceeds the configured Maximum-Prefix limit,
149 =C2=A0 the BGP session w= ill be shut down, which will affect the operation of
150 =C2=A0 other V= PN routes transmitted via this BGP session.

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

152 =C2=A0 5) Configuring the Maximum Prefix for each VRF on e= dge nodes

154 =C2=A0 When a VRF overflows, it stops the import of r= outes.=C2=A0 Any additional
155 =C2=A0 VPN routes are held into its Rou= ting Information Base (RIB).

<major> This is implementation sp= ecific and may not always be the case. Perhaps
fix this text to say &quo= t;... some implementations may ...".

156 =C2=A0 However, PEs s= till need to parse the incoming BGP messages.=C2=A0 This
157 =C2=A0 wil= l cost CPU cycles and further burden the overflowed PE.

<major-ed= itorial> In continuation of a previous comment, the rest of this section=
below belongs in the introduction. You could also put a forward referen= ce to
the new section where analysis of existing solutions is provided.<= /font>

169 =C2=A0 The purpose of this mechanism is to control the = outage within the

<minor> perhaps s/outage/overload ?

176 2.=C2=A0 Conventions used in this document

178 =C2=A0 The= key words "MUST", "MUST NOT", "REQUIRED", &q= uot;SHALL", "SHALL NOT",
179 =C2=A0 "SHOULD", = "SHOULD NOT", "RECOMMENDED", "MAY", and "= ;OPTIONAL" in this
180 =C2=A0 document are to be interpreted as de= scribed in [RFC2119] .

<major> Please update to the latest BCP= 14 template and consider introducing as a
section 1.1 "Requirements= Language" or something like that.

190 =C2=A0 * =C2=A0B= GP: Border Gateway Protocol, defined in [RFC4760]

<major> It s= hould be RFC4271

215 4.=C2=A0 The general procedures of VPN P= refix ORF mechanism

<major-editorial> 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 t= he route-refresh processing and subsequent
propagation of the VPN route= s. Second, there are deployment considerations,
same/unique RD, RT usage= , intra-AS, inter-AS, etc. - those can be captured
in its own section. F= inally, there are the operational considerations which
is what the opera= tor needs to bear in mind on how to provision (e.g., quotas),
design, ma= nage (manual clearing of ORF entries), and monitor (looking at alerts).

289 =C2=A0 For intra-AS VPN deployment, there are three scenari= os:

291 =C2=A0 * =C2=A0RD is allocated per VPN per PE, each VRF onl= y import one RT (see
292 =C2=A0 =C2=A0 =C2=A0Section 4.1.1).

294= =C2=A0 * =C2=A0RD is allocated per VPN per PE.=C2=A0 Multiple RTs are ass= ociated with
295 =C2=A0 =C2=A0 =C2=A0such VPN routes, and are imported = into different VRFs in other
296 =C2=A0 =C2=A0 =C2=A0devices(see Sectio= n 4.1.2).

298 =C2=A0 * =C2=A0RD is allocated per VPN, each VRF impo= rts one/multiple RTs (see
299 =C2=A0 =C2=A0 =C2=A0Section 4.1.3).
<minor> Can this be simplified to say that there are 2 main RD allo= cation
schemes - unique RD (per VPN, per PE) and the same RD (per VPN, s= ame on all PEs)?

304 4.1.1.=C2=A0 Scenario-1 and Solution (Un= ique RD, One RT)

<major> Sections 4.1.1, 4.1.2 and 4.1.3 are a= ll examples but contain normative
text with BCP14 languages. This is not= appropriate. Normative text on procedures
need to stand on their own. T= he examples can be described in an informal language
and moved into the = appendix.=C2=A0When working=C2= =A0on the normative text for a= ll 3 of these
sectio= ns, I am hoping that you would=C2=A0see the commonalities and that there can be=C2=A0
a single normative procedure that=C2=A0= is independent of the RD and R= T design. After=C2=A0
all, in the BGP code, I am=C2=A0assuming there won't be any checks on whether the=C2=A0
deployment design is using=C2= =A0same or unique RD and how R= Ts are used?

339 =C2=A0 If quota value is not set on PE1, an= d each VRF has a prefix limit on

<major> What is this quota va= lue? It is used in several places in this document
but not formally defi= ned (closest match is in the operational considerations).
Perhaps this = can be added in the Terminology section? Then, this quota mechanism
need= s to be specified in this document along with its provisioning/manageabilit= y
requirements - perhaps as its o= wn separate section and before this quota starts=C2=A0
to get used in the procedures section.

= 607 5.=C2=A0 Source PE Extended Community

609 =C2=A0 We usually use= next hop to identify the source, but it MAY NOT be
610 =C2=A0 useful i= n the following scenarios:

<major> MAY NOT is not a valid BCP1= 4 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 so= urce ...?

<= font face=3D"monospace">627 =C2=A0 The AS number of source PE can be conve= yed by Source AS Extended
628 =C2=A0 Community, as defined in [RFC6514]=

<major> Is the Source AS EC always required to be included al= ong with the
Source PE EC? Or is it only required in multi-AS deployment= s where BGP RIDs are
not unique?

660 =C2=A0 The SPE E= C SHOULD be attached by source PE, or else the RR SHOULD
661 =C2=A0 att= ach it, with the value set as the router-id of source PE.=C2=A0 When
662= =C2=A0 none of them attach the SPE EC, the ASBR SHOULD attach it when the=
663 =C2=A0 packet leaves the source AS, with the value set as the ORIG= INATOR_ID.

<minor> The above paragraph is duplicating the bull= et list above it. Please=C2=A0
co= nsider consolidating both?

665 =C2=A0 This section updates route re= flection procedures, which means
666 =C2=A0 [RFC4456] needs to be updat= ed.

<major> I don't think the above statement is correct. = If you agree, please remove
it. Please let me know if I am missing somet= hing and if you really want this=C2=A0
document to=C2=A0update that standards track RFC.

668 6.=C2=A0= VPN Prefix ORF Encoding

<major-editorial> I would recommend t= hat this section (as well section 5) before
section 4 so the reader has = seen and understood the ORF type before they start
reading the procedure= s. Also, this will avoid repetition of the same information
(e.g., take = the default ORF entry) that is repeated in both the sections.

670 = =C2=A0 In this section, we defined a new ORF type called VPN Prefix Outboun= d
671 =C2=A0 Route Filter (VPN Prefix ORF).=C2=A0 The ORF entries are c= arried in the
672 =C2=A0 BGP ROUTE-REFRESH message as defined in [RFC52= 91].=C2=A0 A BGP ROUTE-
673 =C2=A0 REFRESH message can carry one or mor= e ORF entries.=C2=A0 The ROUTE-REFRESH
674 =C2=A0 message which carries= ORF entries contains the following fields:

<minor> Can you pl= ease rephrase the above to indicate that none of this is new
and the de= scription below is how the VPN Prefix ORF is encoded in the refresh
mes= sage format of RFC5291.

676 =C2=A0 * =C2=A0AFI (2 octets)

67= 8 =C2=A0 * =C2=A0SAFI (1 octet)

<minor> Some of the settings = of these fields are repeated further below in this
section itself. Pleas= e update that text here so that everything is in one place.

<= /div>

686 =C2=A0 A VPN Prefix ORF entry contains a common part and type-s= pecific part.
687 =C2=A0 The common part is encoded as follows:

= 689 =C2=A0 * =C2=A0Action (2 bits): the value is ADD, REMOVE or REMOVE-ALL=

691 =C2=A0 * =C2=A0Match (1 bit): the value is PERMIT or DENY
<= br>693 =C2=A0 * =C2=A0Offending VPN routes process method (1 bit): if the = value is set
694 =C2=A0 =C2=A0 =C2=A0to 0, it means all offending VPN r= outes on the sender of VPN
695 =C2=A0 =C2=A0 =C2=A0Prefix ORF message S= HOULD be withdrawn; if the value is set to 1,
696 =C2=A0 =C2=A0 =C2=A0i= t means the sender of VPN Prefix ORF message refuse to receive
697 =C2= =A0 =C2=A0 =C2=A0new offending VPN routes.=C2=A0 The default value is 0.
<major> Looks like this document is allocating one of the reserv= ed bits from
the common part of the ORF container that would be applicab= le 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 th= is 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-speci= fic. The authors and WG will need to decide this.


699 = =C2=A0 * =C2=A0Reserved (4 bits)

<minor> It would be very help= ful if there was a figure showing all of the above
fields just like the = Figure 5 below.


762 =C2=A0 * =C2=A0If the AFI is se= t to L2VPN, the SAFI MUST be set to BGP EVPN.

<major> The docu= ment does not specify which EVPN Route Types this ORF type is
applicable= for.


782 =C2= =A0 Source PE TLV is defined to identify the source of the VPN routes.
7= 83 =C2=A0 For the sender of VPN Prefix ORF, it will check the existence of= SPE
784 =C2=A0 EC.=C2=A0 If it exists, the sender will put it into Sou= rce PE TLV.

<minor> Perhaps ... check the existence of SPE EC = on the VPN route being matched.
<= br>

788 =C2=A0 The Source PE TLV SHOULD only appear once wit= hin an individual ORF
789 =C2=A0 entr= y.=C2=A0 If one ORF entry contains multiple Source PE TLVs, it SHOULD
79= 0 =C2=A0 be ignored.

<major> all should be ignored? first con= sidered and rest ignored?

792 =C2=A0 The source PE TLV contains the= following types:

<major> 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 s= ection starting with the title.

794 =C2=A0 * =C2=A0IPv4 Source PE T= LV: Type =3D 1 (suggested), Length =3D 4 octets, value
795 =C2=A0 =C2= =A0 =C2=A0=3D next hop address in IPv4 format.

<minor> Since t= his 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 consid= erations.

797 =C2=A0 * =C2=A0IPv6 Source PE TLV: Type =3D 2 (sugges= ted), Length =3D 16 octets,
798 =C2=A0 =C2=A0 =C2=A0value =3D next hop = address in IPv6 format.

<major> Only global IPv6 addresses all= owed?

800 =C2=A0 * =C2=A0Source PE identifier TLV: Type =3D 3 (sugg= ested), Length =3D 4 octets,
801 =C2=A0 =C2=A0 =C2=A0value =3D the valu= e of ORIGINATOR_ID in Source PE Extended
802 =C2=A0 =C2=A0 =C2=A0Commun= ity.

<question> At this point, the document is experimental. I= don't see any
implementation reporting support for any of the Sourc= e 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 the= y are really determined to be
necessary?

818 6.3.=C2=A0 Route Ta= rget TLV

820 =C2=A0 Route Target TLV is defined to identify the RT = of the offending VPN
821 =C2=A0 routes.=C2=A0 RT and RD can be used tog= ether to filter VPN routes when the
822 =C2=A0 source VRF contains mult= iple RTs, and the VPN routes with different
823 =C2=A0 RTs MAY be assig= ned to different VRFs on the receiver.=C2=A0 The Route
824 =C2=A0 Targe= t TLV contains the following types:

826 =C2=A0 =C2=A0 =C2=A0Type = =3D 5 (suggested), Length =3D 8*n (n is the number of RTs that
827 =C2= =A0 =C2=A0 =C2=A0the offending VPN routes attached) octets, value =3D the R= T of the
828 =C2=A0 =C2=A0 =C2=A0offending VPN routes.=C2=A0 If multipl= e RTs are included, there MUST be
829 =C2=A0 =C2=A0 =C2=A0an exact matc= h.

<major> And if only one RT is present in this TLV and there= are multiple RTs on
the VPN route? Please clarify.

831 7.=C2=A0 = Operation process of VPN Prefix ORF mechanism on receiver

<major&= gt; This isn't an operational process but more like a protocol procedur= e
on the router receiving these ORF entries. The title is misleading. Mo= re
importantly, what are the similar procedures on the sending side?
=
833 =C2=A0 The VPN Prefix ORF is used mainly to block the unwanted BGP= updates.
834 =C2=A0 When the receiver receives VPN Prefix ORF entry, i= t SHOULD check
835 =C2=A0 first whether the "Match" bit is &q= uot;DENY" or not.

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

<major> Why SHOULD and not MUST? Isn= 't this essential?

841 =C2=A0 "PERMIT", the entry SHO= ULD be discarded and a warning SHOULD be sent
842 =C2=A0 to the operato= r.

<major> Why SHOULD and not MUST?

844 =C2=A0 The fol= lowing procedures will only be evaluated when the "Match" bit
= 845 =C2=A0 is "DENY".

847 =C2=A0 The receiver of VPN Pre= fix ORF entries, which MAY be a RR, ASBR or

<major> s/MAY/may<= /font>

848 =C2=A0 PE, when receives VPN Prefix ORF entry from its = BGP peer, it does the
849 =C2=A0 following:

851 =C2=A0 S01. The= receiver checks the combination of <AFI/SAFI, ORF-Type,
852 =C2=A0 = =C2=A0 =C2=A0 =C2=A0Sequence, Route Distinguisher> of the received VPN P= refix
853 =C2=A0 =C2=A0 =C2=A0 =C2=A0ORF entry.
854 =C2=A0 S02. If = (the combination does not already exist in the ORF-Policy
855 =C2=A0 = =C2=A0 =C2=A0 =C2=A0table) {
856 =C2=A0 S03. =C2=A0 =C2=A0 The receiver= adds the VPN Prefix ORF entry to the
857 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0ORF-Policy table.

<major> This seems odd - what i= f the action was REMOVE?

858 =C2=A0 S04. } else {
859 =C2=A0 S0= 5. =C2=A0 =C2=A0 If (Action is ADD) {
860 =C2=A0 S06. =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Overwrite the old VPN Prefix ORF entry with the new
861 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0one.
862 =C2=A0 S07= . =C2=A0 =C2=A0 else {
863 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Remove the corresponding VPN Prefix ORF entry.

= <major> What about REMOVE-ALL handling?

866 =C2=A0 T= he filtering conditions for the stored VPN Prefix ORF entries
867 =C2= =A0 contain the RD and RT of the source PE.

<major> You mean t= he contents of the TLVs are stored? If so, please state it
that way.

869 =C2=A0 If the SPE EC is not attached to the BGP Update mess= age of the VPN
870 =C2=A0 prefixes, the receiver SHOULD use NEXT_HOP or= ORIGINATOR_ID as the

<major> Why not MUST?
<= font face=3D"monospace">
873 = =C2=A0 After installing the filter entries for the outbound VPN prefixes,<= br>874 =C2=A0 the RR or ASBR does the following before sending VPN routes:=

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

896 8.=C2=A0 Withdraw of VPN Prefix OR= F entries

<major> Is "withdraw" the same as REMOVE o= r REMOVE-ALL? I am very confused.
Seems like this entire section needs t= o go into the operational considerations
section. This has nothing to do= with protocol procedures.

931 9.=C2=A0 Applicability

= <major> This is not applicability. Feels more like examples to me. Ho= wever, 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 nee= d to be retained, please move them
into an informative appendix section.=

1004 10.=C2=A0 Operational Considerations

1006 10.1.= =C2=A0 Quota value calculation

1008 =C2=A0 Quota is a threshold to = limit the number of VPN routes under specific
1009 =C2=A0 granularities= (such as <PE>, <RD, Source AS>).

<major> It is no= t 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
applicabil= ity 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 provisi= oning), and
any other requirements and limitations.

1029 1= 1.=C2=A0 Implementation Consideration

<major-editorial> This s= ection does not contain any implementation considerations.
Please remove= it. The implementation status should be captured in the report
on the I= DR wiki as is the WG norm. The Experimental topology can be moved into
t= he Appendix section describing the experiment.

1068 13.=C2= =A0 IANA Considerations

<minor> There are 3 actions below. Sug= gest to create 3 sub-sections and in each
list precisely the IANA action= s requested or done.

<= /div>
1073 =C2=A0 We would want to refer to t= he text from [RFC5291]: This new ORF is
1074 =C2=A0 exchanged using out= bound route filtering capability defined in
1075 =C2=A0 [RFC5291] (for = the sake of completeness).

1077 =C2=A0 under "BGP Outbound Rou= te Filtering (ORF) Types"
1078 =C2=A0 Registry: "VPN Prefix O= utbound Route Filter (VPN Prefix ORF)"
1079 =C2=A0 Registration Pr= ocedure(s): First Come, First Served
1080 =C2=A0 Value: 66

<m= ajor> I am not able to follow the above two paragraphs. The allocation f= or 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.

<= /font>

1095 =C2=A0 =C2=A0+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+1096 =C2=A0 =C2=A0| Registry =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| = =C2=A0 =C2=A0 Type =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 Meaning =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
1097 =C2=A0 =C2=A0+=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D+
1098 =C2=A0 =C2=A0|Reserved =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 | 0(suggested)|Reserved =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
1099 =C2=A0 =C2=A0+---------------= ------+-------------+---------------------------+
1100 =C2=A0 =C2=A0|IP= v4 Source PE TLV =C2=A0 | 1(suggested)|IPv4 address for source PE.|
1101= =C2=A0 =C2=A0+---------------------+-------------+-----------------------= ----+
1102 =C2=A0 =C2=A0|IPv6 Source PE TLV =C2=A0 | 2(suggested)|IPv6 = address for source PE.|
1103 =C2=A0 =C2=A0+---------------------+------= -------+---------------------------+
1104 =C2=A0 =C2=A0|Source PE Ident= ifier | 3(suggested)|ORIGINATOR_ID in Source PE |
1105 =C2=A0 =C2=A0|TL= V =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |Extended Community for =C2=A0 =C2=A0 |<= br>1106 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |source PE= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
1107 = =C2=A0 =C2=A0+---------------------+-------------+-------------------------= --+
1108 =C2=A0 =C2=A0|Source AS TLV =C2=A0 =C2=A0 =C2=A0 =C2=A0| 4(sug= gested)|Source AS for source PE =C2=A0 =C2=A0|
1109 =C2=A0 =C2=A0+-----= ----------------+-------------+---------------------------+
1110 =C2=A0= =C2=A0|Route Target TLV =C2=A0 =C2=A0 | 5(suggested)|Route Target of the = =C2=A0 =C2=A0 =C2=A0 =C2=A0|
1111 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 |offending VPN routes =C2=A0 =C2=A0 =C2=A0 |
1112 =C2= =A0 =C2=A0+---------------------+-------------+---------------------------+=

<major> The above table has initial allocations which can be = done straight away.
So the "suggested" is not required. I don&= #39;t think the "meaning" column is
necessary. What is require= d is the reference column that points to this
document.

1= 114 =C2=A0 This document also requests a new Transitive Extended Community= Type.
1115 =C2=A0 The new Transitive Extended Community Type name SHAL= L be "Source PE
1116 =C2=A0 Extended Community".

1118 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Under "BGP Transitive Extended Com= munity Types:"
1119 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Registry: &= quot;Source PE Extended Community" type
1120 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A00x0d(suggested) =C2=A0 =C2=A0 =C2=A0 =C2=A0 Source PE E= xtended Community

<major> The above is not clear to me - exact= ly which registry the allocation is to
be made under and under which reg= istry-group. You cannot make suggestions here.
If required, allocations = can be done with IANA under FCFS - what is being done
here is problemati= c (squatting on code points?).
<EoRv23>

--00000000000036d44a0644294dd7--