Ketan Talaulikar has entered the following ballot position for draft-ietf-bess-evpn-ipvpn-interworking-15: Discuss
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-ipvpn-interworking/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks to the authors and the WG for their this important document that has multiple implementations and widespread deployment. However, there are some points that I would like to discuss. <discuss-1> The document is about intra/inter-subnet forwarding within tenant networks but also bring in BGP IP (Global) Routing (SAFI 1) into the discussion which has no notion of multi-tenancy. I fail to see in the document where SAFI 1 is being used as an ISF SAFI or ISF Route. I do see some prospects about leaking routes between default VRF (global table) and non-default VRF (of tenants). However, that practice is an very old artifact of IPVPN and is unchanged by this document. I'll admit that artifact has not been fully specified in an IETF RFC, but not sure why this document should take that upon itself. And, if it was the intent to do so, we'll probably need more. So, the question is can SAFI 1 be removed as an ISF SAFI/Route in this document? <discuss-2> The title of the document but also the abstract/introduction is misleading in the sense that this document does not only specify EVPN interworking with IPVPN. It actually is about interconnecting of different domains that could be any combination of EVPN and IPVPN (e.g., two EVPN domains). Please correct if I am wrong. So then perhaps the title could be: "Interconnecting EVPN and IPVPN Domains" ... and this get clarified in the abstract and introduction? <discuss-3> The document references MPLS and NVO tunnels. However, I don't believe those terms cover SRv6 overlays (at least not per RFC9136). This document does seem to cover some SRv6 aspects though. Perhaps an easy way to address is to include 'SRv6 Overlay' alongside MPLS & NVO and maybe one or two bits of text needs adjustment. Another option is to introduce a term like "overlay" in the terminology section and clarify that overlay could use any of the encapsulations - MPLS, NVO, SRv6, foo ... Then most of the rest of the text is anyway abstracted from the encapsulation. <discuss-4> The document uses the term "propagates" and "propagation" in the context of advertisement of routes across domains (whether the ISF SAFIs are changing or not) by a Gateway PE. I believe the correct technical term for what is happening is "re-origination" (or export). The difference is important from BGP perspective since (re)origination is actually a fresh forming of the BGP UPDATE with the necessary attributes associated with the route. I am not getting into implementation aspects and instead sticking to the semantics. Propagation refers to the usual propagation of BGP routes across BGP speakers (hop by hop or over RRs) and not really what a Gateway PE does. When doing (re)origination, the attributes are "created" afresh - they may or may not pick up contents (called in this spec as no-propagation and propagation modes) from the original route advertisement that was imported. This depends almost always on the type of each specific attribute and its functionality. Then again, this import/export and (re)advertisement is clearly specified in section 8 and also in the 2nd last para of section 1 when dealing with multiple encapsulations. So, why not bring the same consistency throughout the document? Note: Please see discuss-11 to better understand the reason why I bring up this important semantic. <discuss-5> Section 4 says: 492 Similar to AS_PATH, D-PATH is composed of a sequence of Domain 493 segments. Each Domain segment is comprised of <domain segment 494 length, domain segment value>, where the domain segment value is a 495 sequence of one or more Domains, as illustrated in Figure 6. Each The document does not describe the semantics of a Domain Segment. A reading of the procedures gives the impression that Domain Segments are a mean to "attach more domains" when the Domain Segment Length cannot be incremented anymore (i.e., beyond 255 domains). I highly doubt the real-world/practical relevance of such a hypothetical situation. But then the bullet (f) makes me wonder if there is some other purpose as well. Can you please clarify? <discuss-6> Section 4 says: "The Local Administrator sub-field is any local 2-octet value, and its allocation or configuration is a local implementation matter." I am having trouble understanding how this can be a "local implementation matter". If I have two gateway PEs from two different vendors, I need them both to have/use the exact same Domain-ID. So, this seems very important operational aspect for this to be specified - perhaps that it is configured by operator and may be some recommended default value if the Global Administrator sub-field is sufficient for unique identification of a domain? I believe some guidance/recommendations on the operational considerations for the setting of Local Administration along with the Global Administration would be helpful in this document. There is already some text on the Global Administration sub-field and in other places in the document. Consolidating it in one place to provide guidance based on existing implementations and deployments would be super-helpful. <discuss-7> Section 4 says: 539 local implementation matter. Expressing the Global Administrator 540 and Local Administrator values as opaque unsigned integers is 541 RECOMMENDED. What is meant by "expressing" here? Is it how these fields are reported via YANG and/or in CLI outputs? Again, for operational consistency across implementations, is it possible to identify a few well-known/implemented ways of reporting these fields? <discuss-8> Section 4 says: 551 +=======+============================+ 552 | Value | ISF_SAFI_TYPE | 553 +=======+============================+ 554 | 0 | Gateway PE local ISF route | 555 +-------+----------------------------+ 556 | 70 | EVPN | 557 +-------+----------------------------+ 558 | 128 | SAFI 128 | 559 +-------+----------------------------+ 561 Table 1 Is an IANA registry not required for the ISF_SAFI_TYPE? The text says "assigned by this document" but this is not being actually done. Another option is to say that these values come from the IANA SAFI registry with the exception that the value 0 is used as above and that this document recommends the use of only IPVPN and EVPN to avoid introducing a new registry. <discuss-9> Section 4 says: 728 f. The number of domains encoded in the D-PATH attribute reflects 729 the number of Gateway PEs that the corresponding ISF route update 730 has traversed. If a transit Gateway PE performs route leaking 731 between two local tenant IP-VRFs, it MAY prepend a domain segment 732 to the D-PATH attribute with an ISF_SAFI_TYPE value of 0 when 733 exporting the leaked route into an ISF SAFI. In such cases, the 734 total number of domain entries in the D-PATH attribute represents 735 the number of tenant IP-VRFs through which the ISF route update 736 has propagated. I am having some trouble understanding the above procedure. Does the Gateway PE strip off the previous D-PATH attribute contents and start with a fresh one with the Local_ISF_Type of its tenant/domain (considering propagation mode)? Or does it still retain the previous contents and prepend a new domain segment within that same D-PATH attribute. Why is there a "MAY" here? If prepending to existing content, is there a problem with prepending into the existing Domain Segment? And how come domain entries only represent the number of tenant IP-VRFs if gateways were to add domain IDs as they re-originated the route further? <discuss-10> Section 4 says: 780 6. The D-PATH Path Attribute MAY be included only in UPDATE 781 messages that carry routes of SAFI 128 (IPVPN) or EVPN. It 782 MUST NOT be included with any other AFI/SAFI combinations. 783 If a D-PATH attribute is received in an UPDATE message 784 associated with an unsupported AFI/SAFI, the "treat-as- 785 withdraw" procedure MUST be applied, in accordance with 786 [RFC7606]. Why not perform "attribute discard" instead? Since, the D-PATH attribute has no use in any other SAFI routes, then its presence there is due to an error or bug. Is the most robust response to such situation not "attribute discard" so that other speakers don't encouter it as the route propagates further? The "treat-as-withdraw" takes out the route/path and will affect the functionality or reachability for that BGP prefix. <discuss-11> Section 4 says: 845 1. Upon receiving an ISF route, the gateway PE imports the route 846 into the associated IP-VRF and stores the original BGP Path 847 Attributes. When advertising the route into a different domain, 848 the gateway PE SHOULD propagate only the following set of 849 attributes. All other Path Attributes SHOULD NOT be propagated: Have all the current/existing attributes been considered? How about ones that would be defined in the future? What if there is a proper use-case for advertising another attribute? Let's take Edge Metadata Path Attribute that is carried from one NVE to another to indicate information about the edge resources? I can understand normative text mandating or prohibiting propagation of certain specific attributes, but I am concerned with the "all other" blanket statement. The root issue that I see here is what is happening at a Gateway PE is "re-origination" and not "propagation". When "re-origination" is performed, attributes are determined afresh and whether or not information is copied across would depend heavily on the functionality/specification of that attribute (but also community of any type) itself. Please see the comments section for some issue related to similar blanket statements about communities. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Please also find below comments provided inline in the idnits text of v15 of the document. Look for the tag <EoRv15> at the end of the email to ensure you have the full review. Some of these comments are minor/editorial/nits but I hope the authors will consider to improve the clarity, correctness and readability of this document. 25 tenant networks. When a tenant network spans multiple domains — 26 including EVPN domains as well as domains that use BGP VPN-IP or IP 27 address families for inter-subnet forwarding — it becomes necessary 28 to define the interworking mechanisms among these BGP domains (EVPN, 29 VPN-IP, and IP) to ensure seamless end-to-end tenant connectivity. 31 In addition, this document defines a new BGP Path Attribute, referred <minor> Perhaps you meant to say that "This document defines the interworking ..." And then the above sentence with "In addition, this document defines ..." would make sense? Please consider rephrasing the last sentence of the first paragraph (it would also make it easier to read and remove those '-'). 123 between domains without proper safeguards. For example, if gateway 124 PE1 imports a VPN-IP route for a given prefix and redistributes it as 125 an EVPN IP Prefix route into the EVPN domain, and a second gateway PE 126 (PE2) receives this EVPN route and re-advertises it back into the <nit> Perhaps ... second gateway PE2 ? 131 The D-PATH attribute alters the BGP best path selection logic for 132 Multiprotocol BGP routes of SAFI 128 (VPN-IPv4/IPv6) and for EVPN IP 133 Prefix routes. Accordingly, this document updates the BGP best path 134 selection procedures specified in [RFC4271], but only in the context 135 of IPVPN and EVPN families. <major> There are far too many occurrences of 'SAFI 128' in the document and almost all of them also indicate that the reference is to 'IPVPN'. On the other side there is only one reference to 'SAFI 70' in the terminology section where ISF SAFI is explained and the rest of the document simply says 'EVPN'. I found this contrast strange and also a bit jarring. Why not treat IPVPN and EVPN the same and indicate their SAFIs just once in the terminology section? 145 When interworking with other BGP address families for inter-subnet 146 forwarding, the IP prefixes conveyed in these EVPN route types must 147 be propagated into corresponding address families (e.g., VPN-IP), and <minor> s/must be propagated into/are propagated into ? (but please also see the discuss-4 point) 200 | +------------------+ | SAFIs | 201 | | 1 +---+ | 202 -------------------------------------------------+ 128 |BGP| | 203 | EVPN +---+ | 204 | | 205 +-------------------------------------------------------------+ 207 Figure 1: EVPN-IPVPN Interworking PE <minor> There is an inconsistency in the figure when referring to the SAFIs. Either refer to all of them as numbers or names but not a mix of both. I would prefer names to numbers. 209 * ISF SAFI: the Inter-Subnet Forwarding (ISF) Subsequent Address 210 Family Identifier (SAFI) defines an MP-BGP Sub-Address Family used 211 to advertise IP prefix reachability for inter-subnet forwarding 212 within a tenant network. The SAFIs used for ISF include 1 213 (applicable only to IPv4 and IPv6 AFIs), 128 (applicable only to 214 IPv4 and IPv6 AFIs), and 70 (EVPN, applicable only to AFI 25). 215 This document uses the following terms interchangeably: ISF SAFI 1 216 or BGP IP, ISF SAFI 128 or IPVPN, ISF SAFI 70 or EVPN. <minor> Is it possible to use the terms IP Route, VPN Route, and EVPN Route (and for the SAFI names IP Unicast, IPVPN, and EVPN)? Once those terms are clarified in this section, the rest of the document will become much more readable by de-cluttering the SAFI references and SAFI numbers (also the innumerable instances of examples). This also takes care of different terms being used interchangeably. 218 * ISF route: a route for a given prefix, whose ISF SAFI may change 219 as it transits different domains. BGP IP routes as in [RFC4760] 220 [RFC8950], IPVPN routes as in [RFC4364], [RFC4659], EVPN IP Prefix 221 routes as in [RFC9136] or EVPN MAC/IP Advertisement routes when 222 they are programmed within an IP-VRF [RFC9135], are considered ISF 223 routes in this document. <major> Note that what BGP is used for "IP routes", IPVPN and EVPN - all of them. Please consider s/BGP IP Routes/IP Unicast Routes ? ... that is what SAFI 1 is for. 233 (RTs), which are required attributes for its operation. These RD 234 and RT values are typically distinct from those used by any 235 associated IP-VRF, when such an IP-VRF is linked to the MAC-VRF 236 through a Bridge Table via an Integrated Routing and Bridging 237 (IRB) interface. <major> This is the first reference to IRB (baring the figure). Please consider adding reference to RFC9135. 253 * Ethernet Tag: used to represent a Broadcast Domain. <major> Please consider adding RFC7432 as reference for the term Ethernet Tag (at least here but perhaps also in the description of BT above). In general, please review other similar terms (e.g., EVI) in this section and provide the appropriate RFC references against them. 267 * IRB: Integrated Routing and Bridging interface. It refers to the 268 logical interface that connects a BT to an IP-VRF and allows to 269 forward packets with destination in a different subnet. <major> Does IRB stand for 'Integrated Routing and Bridging' (as in the feature or technology) or 'Integrated Routing and Bridging Interface'? I find the usage inconsistent in RFC9135, but most of the text in that document seems to refer to the technology and the 'interface' suffix is added when the reference is to the interface. Can you please review and bring consistency in this document? 271 * MPLS/NVO tunnel: A tunnel that may be based on either MPLS or a 272 Network Virtualization Overlay (NVO) technology. Such tunnels are 273 utilized by both MAC-VRFs and IP-VRFs. Regardless of the 274 underlying tunneling technology, the tunnel may carry either 275 Ethernet or IP payloads. MAC-VRFs are restricted to using tunnels 276 that carry Ethernet payloads - Ethernet NVO Tunnels [RFC9136] - 277 which are typically established via EVPN signaling. In contrast, 278 IP-VRFs may utilize tunnels carrying Ethernet payloads - Ethernet 279 NVO Tunnels [RFC9136], signaled via EVPN - or IP payloads - IP NVO 280 Tunnels [RFC9136], signaled via EVPN or IPVPN mechanisms. IPVPN- 281 only PE devices support IP-VRFs but do not support sending or 282 receiving traffic over tunnels carrying Ethernet payloads. <major> I see RFC9014 as an informative reference but not really used anywhere. I would like to check if it was meant to be used as a reference perhaps in the above paragraph? If not, please remove that unused reference. 285 tunnel to transport Ethernet frames associated with MAC-VRF1. The 286 PE device identifies the corresponding MAC-VRF and BT based on the 287 EVPN label, either an MPLS label or a Virtual Network Identifier 288 (VNI), depending on the encapsulation type. Additionally, <major> Also SRv6 SID when using SRv6 encapsulation? Although perhaps this document does not need to get into the details of the encapsulation? 301 * NVE: Network Virtualization Edge router. <major> NVE term needs RFC9136 reference? 376 * Regular PE: A PE that is attached to a domain, either regular or 377 composite, and which uses one of the control plane protocols (BGP 378 IP, IPVPN or EVPN) operating in the domain. <major> S/control plane protocols/control plane ISF SAFI ... the control plane is BGP all through. 380 * Interworking PE: A PE device that is capable of advertising a 381 given IP prefix using one or more of the following route types: an 382 EVPN Inter-Subnet Forwarding (ISF) route, either an EVPN MAC/IP 383 Advertisement route or an EVPN IP Prefix route-an IPVPN ISF route, <nit> s/route-an IPVPN/route, an IPVPN <minor> There is unnecessary repetition of terms here and through the document text that affects readability. Once the term ISF Route is defined above, why not use that and simplify the text and improve readability? 399 Example: Figure 1 shows an interworking PE of type gateway, where 400 ISF SAFIs 1, 128 and 70 are enabled. IP-VRF1 and MAC-VRF1 are 401 instantiated on the PE, and together provide inter-subnet 402 forwarding for the tenant. <minor> The example above introduces the gateway type but that type is defined further below. Perhaps it can just say 'interworking PE' without getting into the type just yet? 404 * Composite PE: An Interworking PE device that is connected to a 405 composite domain and is capable of advertising a given prefix to 406 multiple types of peers using appropriate route types. 407 Specifically, a Composite PE advertises the prefix to an IPVPN 408 peer using an IPVPN ISF route, to an EVPN peer using an EVPN ISF 409 route, and to a route reflector using both IPVPN and EVPN ISF <major> This assumes that the same RR is used for IPVPN and EVPN (as in Figure 4 below). Can you please state this since RR is also a peer (unless you meant to use PE instead of peer). 439 - Propagates ISF routes using the same ISF SAFI, such as BGP IP, 440 IPVPN, or EVPN, between the connected domains. 442 - Translates and propagates an ISF route received with one ISF 443 SAFI to a domain that uses a different ISF SAFI. For example, 444 a received EVPN ISF route may be propagated as an IPVPN ISF 445 route, and vice versa. <minor> The above two bullets unnecessary repeat things already clarified previously in the terminology section (i.e., ISF route and ISF SAFI). Such repetition here and throughout this document just makes it verbose but also affects readability. I'll stop pointing this out again, but please consider cutting out all of this endless repetition - all the "for examples" can just be removed? 467 * Composite/Gateway PE: An Interworking PE device that 468 simultaneously performs the functions of both a Composite PE and a 469 Gateway PE. This type of PE is connected to two domains: one 470 regular domain and one composite domain. It operates as follows: 472 - Propagates an ISF route received from the regular domain into 473 the composite domain. Within the composite domain, it performs 474 the behavior of a Composite PE. 476 - Propagates an ISF route received from the composite domain into 477 the regular domain. In the regular domain, the route is 478 advertised using the ISF SAFI applicable to that domain. 480 This functionality is particularly useful in scenarios where a 481 tenant network spans multiple domains using different ISF SAFIs 482 (e.g., BGP IP, IPVPN, and EVPN), and where any-to-any tenant 483 connectivity is required. In such deployments, maintaining 484 consistent end-to-end control plane behavior across domains is 485 desirable when feasible. <minor> Please consider if it is possible to include an example here - it would really be helpful (a mix of figures 4 and 5 perhaps?). 551 +=======+============================+ 552 | Value | ISF_SAFI_TYPE | 553 +=======+============================+ 554 | 0 | Gateway PE local ISF route | 555 +-------+----------------------------+ 556 | 70 | EVPN | 557 +-------+----------------------------+ 558 | 128 | SAFI 128 | <major> Why not call it IPVPN instead of SAFI 128 ? After all, that is what is used in the procedures section further below. 567 Gateway PEs. In addition, D-PATH: <minor> This "In addition, D-PATH:" does not parse for many of the bullets below. Since these are D-PATH related procedures, how about - "The rest of this section specifies the D-PATH related procedures." (or something like that) and then fix the opening sentences for a few of the bullets? 592 * In order to minimize the number of segments in the D-PATH 593 attribute, the local gateway PE prepends its own domain as the <major> Why not "... gateway PE MUST prepend its own domain as ..." ? 599 b. Is added/modified by a gateway PE when propagating an update to a 600 different domain (which runs the same or different ISF SAFI): <major> Unlike the previous bullet (a), the sub-bullets under (b) use examples instead of normative text to describe what are normative procedures. Suggest to follow the way in which both normative text and examples are used independently as done in the case of (a). 631 c. For a local ISF route, i.e., a configured route or a route 632 learned from a local attachment circuit, a gateway PE following <major> It is not clear whether "local" here means only prefixes that are configured on one the local interfaces or ACs. Or can it also include say locally configured static routes that are redistribute. 633 this specification has three choices: <major> Only these 3 choices or are there more? The MAYs in the 3 choice allow for other unspecified options. 672 * The route MAY be installed in the IP-VRF only if it is <major> perhaps s/route MAY be installed/route is installed ? 755 * The total length of the D-PATH attribute is less than 756 eight octets. <minor> Doesn't the above bullet fit better under (1) than (2)? 788 h. The use of the D-PATH attribute is restricted to "walled garden" 789 Virtual Private Network (VPN) deployments. An operator MUST NOT 790 enable the generation of D-PATH attributes in conjunction with 791 IPVPN and/or EVPN routes if any CE devices connected to a PE 792 device, belonging to any domain within the VPN, is also connected 793 to the public Internet. <major> I do not follow this. How is the provider operator going to determine what all a particular customer CE is doing. It is very much likely that a CE is also peering with another independent ISP for Internet. What is required here is that implementations by default strip the D-PATH attribute when advertising from a VRF instance on a PE towards the CE - this should normally happen anyway since the PE-CE session is IP Unicast SAFI? After all, this seems to be what is indicated in the Security Considerations. Isn't this an inconsistencies? 838 advertising an ISF route between domains. This mode is typically 839 employed in deployments where IP prefixes are seamlessly distributed 840 using both EVPN and IPVPN SAFIs. <major> Is it "using both EVPN and IPVPN" or "only when using EVPN and/or IPVPN" ? i.e., not used when using IP Unicast. 878 4. As stated in Item 1, the gateway PE SHOULD preserve the 879 COMMUNITY, EXTENDED_COMMUNITY, LARGE_COMMUNITY, and 880 WIDE_COMMUNITY attributes from the original ISF route. However, 881 the following Extended Community types SHOULD NOT be propagated:: <major> Similar to the attributes (please see discuss-11), I am wondering how this document can put a blanket statement about preservation of all these types of communities (current and future). Should it not depend on the functionality of the community? I can understand the exceptions for not propagating some of the communities that are typically used with IPVPN/EVPN - although even those really don't need to be specified as they are obvious based on their functionality. e.g., it is obvious that the RTs to be used as determined via the IP-VRF configuration when re-originated from the VRF. 886 b. Route Target Extended Communities. Route Targets MUST NOT be 887 propagated and MUST be re-initialized when re-advertising the 888 ISF route into a different domain. The re-initialized Route 889 Target value MAY or MAY NOT match the value used in the 890 original route. <major> Incorrect use of BCP14 keyword. I would suggest the following since "MAY" implicitly allows the possibility of "MAY NOT": The re-initialized Route Target value MAY match the value used in the original route. 892 c. All EVPN-specific Extended Communities. <major> Are we sure that no current or future EVPN-specific ECs are to be propagated even when the ISF SAFIs of both domains is EVPN (say with different encapsulation so they need the gateway function)? 897 5. For a given ISF route, only the BGP Path Attributes associated 898 with the best path MAY be propagated when re-advertising the 899 route into a different domain. If multiple paths are received 900 for the same prefix within the same ISF SAFI, the standard BGP 901 best path selection procedure MUST be applied to determine the 902 active path and its associated attributes. Even when Equal-Cost 903 Multi-Path (ECMP) is enabled for the IP-VRF, only the Path 904 Attributes of the selected best path SHALL be propagated. <major> SHALL = MUST. Is that a MUST or a SHOULD? What would be the issue if an implementation picks the attributes from any one of the ECMP paths? <major> I am probably missing something, but what about (5) is new or specific to interworking between EVPN/IPVPN or interconnecting multi-domains? Is this not standard BGP (albeit I cannot remember where this is specified). 940 * The Community, Extended Community, Large Community and Wide 941 Community attributes of an aggregated ISF route SHOULD include the 942 union of the corresponding attributes from all constituent ISF 943 routes that were aggregated, with the exception of those Extended 944 Community types explicitly excluded from propagation as specified 945 in Section 5.2. <major> This is another blanket statement for all types of communities being handled in a particular way during aggregation without regards to the semantics of those specific ECs. Consider Link Bandwidth EC. Is this handling appropriate? 947 * For other attributes, rules in [RFC4271] are followed. <major> Why only RFC4271? What about attributes from RFC4456 or other RFCs (currently available or those coming in future) that would introduce new attributes? 1100 Composite PEs MUST advertise the same IP prefixes using each ISF 1101 SAFI to the Route Reflector (RR). For example, as shown in 1102 Figure 7, the prefix IP1/24 is advertised by PE1 and PE2 to the 1103 Route Reflector in two separate NLRI entries: one for AFI/SAFI 1104 1/128 (IPVPN) and another for EVPN. If both routes are <major> This seems to preclude a design where different RRs are used for different ISF SAFIs. It probably does not matter to the composite PE but would be good to clarify that such an alternate design is possible. 1157 6. Applicability of EVPN Forwarding Enhancements 1158 In composite domains such as the one depicted in Figure 7, the 1159 advanced forwarding features provided by EVPN are available only 1160 to composite and EVPN-capable PEs that select an EVPN IP Prefix 1161 route as the best path. These enhancements are not available to 1162 IPVPN-only PEs. For example, if PE1 advertises IP1/24 using both 1163 EVPN and IPVPN routes, and the EVPN route is selected as the best 1164 path, only composite PEs such as PE2 and PE4 can leverage EVPN- 1165 specific recursive resolution and forwarding mechanisms. IPVPN 1166 PEs, such as PE3, cannot utilize these capabilities. 1167 Consequently, the benefits of EVPN-based indirection and route 1168 resolution in large-scale deployments may not be available 1169 uniformly across all PEs in the network. <minor> Can you please provide reference so the reader can understand these EVPN Forwarding Enhancements? 1256 specification. For example, an EVPN IP Prefix route that 1257 contains both a non-zero EESI and a Gateway IP address is <nit> s/EESI/ESI 1296 b. The gateway PE MAY use the Route Distinguisher (RD) of the IP-VRF 1297 when re-advertising prefix P via ISF SAFI y. <minor> Why MAY? What are the other options? How about "The gateway PE uses the Route Distinguisher ..." 1299 c. Label allocation for route advertisement is an implementation- 1300 specific matter. The gateway PE MAY use per-VRF, per-prefix, or <major> Is it an implementation-specific or a local matter? How about for other encapsulation types - VNI and SRv6 SIDs? Perhaps this can be abstracted as: "The encapsulation specific context (e.g., label) allocation is a local matter." 1309 e. Although Figure 8 illustrates a scenario with only two domains 1310 per gateway PE, gateway PEs MAY interconnect more than two 1311 domains. <minor> Perhaps ... gateway PEs may/can interconnect more ... ? 1316 g. If Uniform Propagation Mode is used for BGP Path Attribute 1317 propagation, the gateway PE MUST follow the procedures defined in 1318 Section 5.2 in addition to the D-PATH specific behavior described 1319 in item (a). <minor> I am not sure what (g) provides more than (a). Perhaps consider combining? 1371 Figure 9: Gateway and composite combined functions - example 1373 In the example illustrated, PE1 and PE2 MUST follow the procedures <major> Please don't mix normative text and examples. The normative text should stand on its own and then the examples clarify. 1384 10. BGP Error Handling on Interworking PEs 1386 An Interworking PE, whether operating in a Gateway PE or Composite PE 1387 role, MUST adhere to the following error-handling procedures when 1388 processing Inter-Subnet Forwarding (ISF) routes: <major> Why just interworking PE? Aren't some of these procedures also applicable for other BGP Speaker roles such as RR or normal ingress/egress PEs or even ASBRs? i.e., for the new D-PATH attribute. 1401 type. Applicable references include:: 1403 BGP IP routes: [RFC4760], [RFC8950]. 1405 IPVPN routes: [RFC4364], [RFC4659]. 1407 EVPN MAC/IP Advertisement routes (Route Type 2): [RFC7432], 1408 [RFC8365]. 1410 EVPN IP Prefix routes (Route Type 5): [RFC9136]. 1412 ISF routes installed in IP-VRFs with SRv6 forwarding: 1413 [RFC9252]. <major> I think trying to list specific ISF Routes and provides pointers is going to be tricky. EVPN error handling is coming only in the RFC7432bis. Perhaps consider skipping the specific references above since this document needs to cover only what is newly introduced or new procedures. 1448 11. Conclusion <minor> Conclusion section seems odd. This text, however, would fit nicely in the introduction section and be helpful for the reader. 1564 15. Contributors <nit> please remove empty contributors section <EoRv15> _______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
