Document: draft-ietf-bess-evpn-dpath
Title: Domain Path (D-PATH) for Ethernet VPN (EVPN) Interconnect Networks
Reviewer: ROBERT RASZUK
Review result: Not Ready
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 <DOMAIN-ID:ISF_SAFI_TYPE>. 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 <Domain-
404 ID:TYPE>.
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.
_______________________________________________
BESS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
