16 Domain Path (D-PATH) for Ethernet VPN (EVPN) Interconnect Networks 17 draft-ietf-bess-evpn-dpath-04 18 19 Abstract 20 21 The BGP Domain PATH (D-PATH) attribute is defined for Inter-Subnet 22 Forwarding (ISF) BGP Sub-Address Families that advertise IP prefixes. + or mac addresses. It applies to type 2 and type 5. 23 When used along with EVPN IP Prefix routes or IP-VPN routes, it 24 identifies the domain(s) through which the routes have passed and 25 that information can be used by the receiver BGP speakers to detect 26 routing loops or influence the BGP best path selection. This 27 document extends the use of D-PATH so that it can also be used along 28 with other EVPN route types. But draft-ietf-bess-evpn-ipvpn-interworking already provides examples for using D-PATH with route type 2. 98 1. Introduction 99 100 The BGP Domain PATH (D-PATH) attribute 101 [I-D.ietf-bess-evpn-ipvpn-interworking] is defined for Inter-Subnet 102 Forwarding (ISF) BGP Sub-Address Families that advertise IP prefixes. 103 When used along with EVPN IP Prefix routes or IP-VPN routes, it 104 identifies the domain(s) through which the routes have passed and 105 that information can be used by the receiver BGP speakers to detect 106 routing loops or influence the BGP best path selection. This 107 document extends the use of D-PATH so that it can also be used along 108 with other EVPN route types. Please be precise and list which "other EVPN route types" is this draft trying to extend for ISF. 124 1.1. D-PATH to Prevent Loops for EVPN Routes 125 126 Figure 1 illustrates an EVPN Interconnect case where EVPN MAC/IP 127 Advertisement routes can be looped indefinitely. The three Gateways 128 (GW1, GW2 and GW3) and PE1 in the diagram are attached to the same 129 EVPN Broadcast Domain (BD1). However, BD1 is extended throughout 130 three different domains that are interconnected by the Gateways, 131 which follow [RFC9014] procedures. Suppose a host with MAC address 132 M1 is learned on GW1 and GW1 advertises an EVPN MAC/IP Advertisement 133 route for M1 into Domain-1 and Domain-2. When the route gets 134 imported by GW2 and GW3 and later exported into Domain-3, GW2 and GW3 135 may re-originate each other's route for M1 back into Domain-1 and 136 Domain-2, respectively, creating a loop. Re-origination without preserving AS-PATH is a bug. BGP protocol prohibits re-origination with stripping AS-PATH attribute. So no loop will form if re-origination is done correctly. 183 originated AD per EVI routes is necessary. D-PATH delivers the end- 184 to-end path visibility required to avoid such loops. I disagree why in this case properly handled AS-PATH would not be sufficient without any need to invent to BGP Path Attribute. 186 1.2. Add Path Visibility and Influence Best Path Selection for EVPN 187 Routes 188 189 Figure 2 illustrates another [RFC9014] EVPN Interconnect case where, 190 in addition to using D-PATH to prevent EVPN MAC/IP Advertisement 191 route loops when re-originating routes between domains, the D-PATH 192 attribute can also influence the best path selection for the routes. 193 For example, if all the Gateways in the diagram are attached to the 194 same BD1, an EVPN MAC/IP Advertisement route for MAC address M1 195 advertised by GW1 is advertised into Domain-1. Two routes for M1 196 will arrive at GW3 with different route distinguishers and BGP Next 197 Hops. If D-PATH is used by all the Gateways, the two routes arriving 198 at GW3 will have a different sequence of domain-ids in the D-PATH 199 attribute. GW3 can use the length of the D-PATH as a way of 200 influencing the selection (i.e., the shortest D-PATH route is 201 selected). D-PATH improves the path visibility of the route since it 202 provides information about all the Domains through which the route 203 has passed. Exactly the same happens with AS-PATH length and best path selection without any need to introduce new BGP attribute nor modify existing best path selection steps/criteria. 351 4. Use of Domain Path Attribute (D-PATH) with EVPN routes 352 353 This document extends the use of the D-PATH attribute, as specified 354 in [I-D.ietf-bess-evpn-ipvpn-interworking], to allow it to be 355 advertised and processed in conjunction with the following EVPN route 356 types: 357 358 * EVPN MAC/IP Advertisement routes that are not used for Inter- 359 Subnet Forwarding (ISF). What type are those routes ? You mean Type 1,3 & 6-11 ? Why wouldn't the draft say it explicitely ? Are those types needed across domains ? And again why AS-PATH is not sufficient ? Possibly augmented with Site-of-Origin encoded as Route Origin RFC4364/RFC4360 ? 364 * EVPN A-D per EVI routes that are used for EVPN VPWS [RFC8214]. Please explicitely provide route types to avoid confusion 366 * EVPN Inclusive Multicast Ethernet Tag routes 367 [I-D.ietf-bess-rfc7432bis]. Please explicitely provide route types to avoid confusion 372 The following EVPN routes SHOULD NOT include D-PATH: 373 374 * A-D per EVI routes not used for EVPN VPWS. Examples include A-D 375 per EVI routes used as specified in [I-D.ietf-bess-rfc7432bis], or 376 [I-D.ietf-bess-evpn-ip-aliasing], which are not associated with 377 EVPN VPWS. Please explicitely provide route types to avoid confusion 379 * ES routes, as specified in [I-D.ietf-bess-rfc7432bis]. Please explicitely provide route types to avoid confusion 384 The use of D-PATH with EVPN IP Prefix routes is specified in 385 [I-D.ietf-bess-evpn-ipvpn-interworking]. When D-PATH is used with 386 EVPN route types other than IP Prefix routes, the attribute is 387 characterized as follows: 388 396 397 1. D-PATH is composed of a sequence of Domain segments following the 398 format specified in [I-D.ietf-bess-evpn-ipvpn-interworking] where 399 each Domain is represented as . In this 400 specification, DOMAIN-ID is an EVPN Domain identifier configured 401 in an EVPN Domain Gateway and ISF_SAFI_TYPE is set to either 70 402 (EVPN) or 0 (local route). To simplify the explanation, this 403 document represents the domains for EVPN routes as . Configuration of DOMAIN-ID is error prone and creates an unnecessary overlay over BGP ASN. Please consider using 4 octet BGP ASN in place of DOMAIN-ID if at all use of D-PATH is necessary in the light of AS-PATH. 481 4.1. D-PATH and Best Path Selection for MAC/IP Advertisement routes 482 483 When two (or more) MAC/IP Advertisement routes with the same route 484 key (regardless of whether the RDs are identical or different) are 485 received, the best path selection algorithm is used to select and 486 install only one route. I realize you have copied that text from section 7.13 of draft-ietf-bess-rfc7432bis but I fundamentally disagree with any best path selection executed across routes with different RDs. 487 Advertisement routes is specified in [I-D.ietf-bess-rfc7432bis], in 488 section 7.13.1, and this document modifies the algorithm by including 489 the D-PATH comparison across EVPN MAC/IP Advertisement routes after 490 tie-breaking rule 5 in [I-D.ietf-bess-rfc7432bis] section 7.13.1, 491 which removes from consideration routes that are not tied for higher 492 degree of preference. 493 494 If none of the tie-breaking rules up to (and including) rule 5 495 produces a single route, the router compares the D-PATH attribute in 496 the remaining candidate routes: 497 498 1. The routes with the shortest D-PATH are preferred, hence routes 499 not tied for the shortest D-PATH are removed. Routes without 500 D-PATH are considered zero-length D-PATH. Please be explicit if zero-length is considered as shortest D-PATH. draft-ietf-bess-evpn-ipvpn-interworking is also not clear in this regard. 509 2. Then routes with the numerically lowest left-most Domain-ID are 510 preferred (only the Domain-ID is compared, and not the 511 ISF_SAFI_TYPE). Hence, routes not tied for the numerically 512 lowest left-most Domain-ID are removed from consideration. When 513 comparing two Domain-IDs, the two six byte values are compared 514 starting with the Global Admin field. The lowest value in the 515 first differing byte between the two six byte values, is 516 considered to belong to the "numerically lowest Domain-ID". I do not follow. Glabal Admin is 4 octets not 6 octets. So if you are starting with Global Admin you are ignoring Local Admin 2 octet field. Octets v 0 6 7 +------------------//-----+----------------+ | DOMAIN-ID | ISF_SAFI_TYPE | +------------------//-----+----------------+ \________________________/ | Octets v 0 1 2 3 4 5 6 +-----------------------+-----------+ | Global | Local | | Admin | Admin | +-----------------------+-----------+ Figure 7: D-PATH Domain Segment Is this intentional ? The paragraph does not mention the return to compare Local admin field of DOMAIN-ID ! Please also be consistent through entire draft on how "DOMAIN-ID" or "Domain-ID" is written. 518 If the steps above do not produce a single route, then the rest of 519 the rules in [I-D.ietf-bess-rfc7432bis] follow. There are no more rules ! Last rule number 6 of draft-ietf-bess-rfc7432bis section 7.13.1 says: 6. If the steps above do not produce a single route, the rest of the rules in [RFC4271] apply. Please modify the above lines 518-519 accordingly to refer directly to RFC4271. 521 4.2. D-PATH and Best Path Selection for Ethernet A-D per EVI routes 522 523 When two (or more) EVPN A-D per EVI routes with the same route key 524 (regardless of whether the RDs are identical or different) Again the ignorance of RD is very worrying ! 525 received for a Virtual Private Wire Service (VPWS), the best path 526 selection algorithm is applied to select a single route. BGP Best Path selection is selecting best path not a single route. It always applies to single route with more then one path. 545 4.4. Loop Detection 546 547 An EVPN route received by a PE with a D-PATH attribute that contains 548 one or more of its locally associated Domain-IDs for the MAC-VRF or 549 VPWS instance is considered to be a looped route. A looped route 550 MUST NOT be re-originated to a different domain and SHOULD be flagged 551 as "looped". How can D-PATH contain more then one occurence of specific any DOMAIN-ID ? And how it can be received by PE ? Wouldn't it mean that GW allowed it in in the first place. 589 The procedures described in this section, based on D-PATH, can be 590 used along with the Ethernet Segment Identifier of the received 591 routes as a way to detect looped routes on EVPN domain gateways 592 attached to an Interconnect Ethernet Segment as in [RFC9014]. Please explian how AS-PATH native BGP loop detection would not detect a loop in the first place ? 621 Figure 4 and Figure 5 illustrate an integrated interconnect solution 622 for an EVPN BD, as described in section 4.4 and section 4.6 of 623 [RFC9014]. GW1 and GW2 are EVPN Domain Gateways connecting two EVPN 624 Domains identified by D-PATH domain {1:1:EVPN} and {1:2:EVPN}, 625 respectively. Received Ethernet A-D routes, ES routes, and Inclusive 626 Multicast routes from the routers in one EVPN Domain are consumed and 627 processed by GW1 and GW2, but not re-originated to the other EVPN 628 Domain. However, MAC/IP Advertisement routes received by GW1 and GW2 629 in one EVPN Domain are processed and, if installed, re-originated 630 into the other EVPN Domain. 631 632 +----EVPN Domain-1---+ +----EVPN Domain-2--+ 633 | 1:1:EVPN | GW1 | 1:2:EVPN | 634 | +---------+ | 635 | | +-----+ | | 636 | | | BD1 | X <-+ | 637 PE1 | +-----+ | | PE2 638 +---------+ +---------+ | +---------+ 639 | +-----+ | | | | | +-----+ | 640 M1-----| BD1 | | | | | | | BD1 |-----M2 641 | +-----+ | -------> | | | | +-----+ | 642 +---------+ (RT2)M1/IP1 | | | +---------+ 643 | +---------+ | | 644 | | +-----+ | |(RT2)M1/IP1 | 645 | | | BD1 | | --+ <1:1:EVPN> | 646 | | +-----+ | | 647 | +---------+ | 648 | | GW2 | | 649 +---------------------+ +-------------------+ 650 651 Figure 4: EVPN Interconnect 652 653 Consider the example of Figure 4, where PE1 advertises a MAC/IP 654 Advertisement route for M1/IP1. The route is processed and installed 655 by GW1 and GW2 in BD1, and both re-originate the routes into the EVPN 656 Domain-2. By using D-PATH in GW1 and GW2, when the route is received 657 on PE2, PE2 has the visibility of the EVPN Domains through which the 658 route has gone, and can also use the D-PATH for best path selection. 659 In addition, GW1 and GW2 can compare the D-PATH of the incoming 660 routes with their local list of EVPN Domain-IDs, and detect looped 661 routes if any of the local EVPN Domain-IDs matches a domain in the 662 received D-PATH. This procedure prevents the re-origination of the 663 route back into EVPN Domain-1. For example, when GW1 receives the 664 MAC/IP Advertisement route for M1/IP1 with D-PATH <1:1:EVPN>, GW1 665 identifies the route as looped and it does not re-originate it back 666 to Domain-1. The M1/IP1 route with Next Hop PE1 is installed. If 667 M1/IP1 with Next Hop PE1 is withdrawn, GW1 MAY install the route M1/ 668 IP1 with Next Hop GW2, as specified in Section 4.4. BGP uses AS-PATH for the pricesely very same control plane loop avoidance. Building a new overlay for BGP loop detection using D-PATH on top of base BGP AS-PATH is simply not helpful. 744 In a nutshell, the use of D-PATH in MAC/IP Advertisement routes helps 745 prevent loops and influences the best path selection so that PEs 746 choose the shortest paths to the destination PEs. Presented loops are not real loops. BGP offers today native loop free route propagation both inter and intra domain. As reviwer I have not seen any case in this document nor in draft-ietf-bess-evpn-ipvpn-interworking which would justify invention of new D-PATH attribute. 748 6. Operational Considerations 749 750 This document modifies the best-path selection algorithm for EVPN 751 routes that include D-PATH. Well - proposed mofifications are already vastly covered by draft-ietf-bess-evpn-ipvpn-interworking ... perhaps it would be useful what changes if any is needed to draft-ietf-bess-evpn-ipvpn-interworking here. 757 upgrade status. Therefore, enabling D-PATH is RECOMMENDED only when 758 all PEs participating in the EVPN service (Broadcast Domain or VPWS) 759 have been upgraded. That's quite unrealistic in practice. Flag dates are no-go. If you can not provide smooth gradual deployment perhaps a revisiting the entire design of draft-ietf-bess-evpn-ipvpn-interworking would be needed. 761 In deployments where EVPN Domain Gateways are redundantly 762 interconnecting the same two domains, enabling D-PATH is RECOMMENDED 763 only when all such Gateways for a given EVPN service have been 764 upgraded. If some Gateways remain non-upgraded, D-PATH may not 765 prevent forwarding loops or packet duplication. In such cases, 766 alternative loop-prevention mechanisms (without D-PATH) are assumed 767 to be in use. Those mechanisms are outside the scope of this 768 document. Again there is zero comment in the draft why AS-PATH would SOO be not sufficient. 770 7. Security Considerations 771 772 Most of the security considerations included in 773 [I-D.ietf-bess-evpn-ipvpn-interworking] related to D-PATH apply to 774 this document. 775 776 In particular, a correct use of the D-PATH will prevent control plane 777 and data plane loops in the network, however an incorrect 778 configuration of the DOMAIN-IDs or an inconsistent support of D-PATH 779 on the Gateway PEs may lead to the detection of false route loops, 780 dropping packets or may result in inconsistent and sub-optimal 789 forwarding. As an additional security mechanism, a PE following this 790 specification that receives an EVPN route from a non-upgraded PE 791 should discard the route via policy if the route contains the D-PATH 792 attribute. My comments made earlier also do apply to section 7.