draft-ietf-bess-evpn-ipvpn-interworking-11.txt   draft-ietf-bess-evpn-ipvpn-interworking-10.txt 
BESS Workgroup J. Rabadan, Ed. BESS Workgroup J. Rabadan, Ed.
Internet-Draft Nokia Internet-Draft Nokia
Intended status: Standards Track A. Sajassi, Ed. Intended status: Standards Track A. Sajassi, Ed.
Expires: 19 December 2024 Cisco Expires: 13 October 2024 Cisco
E. Rosen E. Rosen
Individual Individual
J. Drake J. Drake
Independent Independent
W. Lin W. Lin
Juniper Juniper
J. Uttaro J. Uttaro
Independent AT&T
A. Simpson A. Simpson
Nokia Nokia
17 June 2024 11 April 2024
EVPN Interworking with IPVPN EVPN Interworking with IPVPN
draft-ietf-bess-evpn-ipvpn-interworking-11 draft-ietf-bess-evpn-ipvpn-interworking-10
Abstract Abstract
Ethernet Virtual Private Network (EVPN) is used as a unified control Ethernet Virtual Private Network (EVPN) is used as a unified control
plane for tenant network intra and inter-subnet forwarding. When a plane for tenant network intra and inter-subnet forwarding. When a
tenant network spans not only EVPN domains but also domains where BGP tenant network spans not only EVPN domains but also domains where BGP
VPN-IP or IP families provide inter-subnet forwarding, there is a VPN-IP or IP families provide inter-subnet forwarding, there is a
need to specify the interworking aspects between BGP domains of type need to specify the interworking aspects between BGP domains of type
EVPN, VPN-IP and IP, so that the end to end tenant connectivity can EVPN, VPN-IP and IP, so that the end to end tenant connectivity can
be accomplished. This document specifies how EVPN interworks with be accomplished. This document specifies how EVPN interworks with
VPN-IPv4/VPN-IPv6 and IPv4/IPv6 BGP families for inter-subnet VPN-IPv4/VPN-IPv6 and IPv4/IPv6 BGP families for inter-subnet
forwarding. The document also addresses the interconnect of EVPN forwarding. The document also addresses the interconnect of EVPN
domains for Inter-Subnet Forwarding routes. In addition, this domains for Inter-Subnet Forwarding routes. In addition, this
specification defines a new BGP Path Attribute called D-PATH (Domain specification defines a new BGP Path Attribute called D-PATH (Domain
PATH) that protects gateways against control plane loops. D-PATH PATH) that protects gateways against control plane loops. D-PATH
modifies the BGP best path selection for multiprotocol BGP routes of modifies the BGP best path selection for multiprotocol BGP routes of
SAFI 128 and EVPN IP Prefix routes, and therefore this document SAFI 128 and EVPN IP Prefix routes, and therefore this document
updates the BGP best path selection specification, but only for IPVPN updates the BGP best path selection in [RFC4271], but only for IPVPN
and EVPN families. and EVPN families.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 19 December 2024. This Internet-Draft will expire on 13 October 2024.
Copyright Notice Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 32 skipping to change at page 2, line 32
extracted from this document must include Revised BSD License text as extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License. provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction and Problem Statement . . . . . . . . . . . . . 3 1. Introduction and Problem Statement . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . 4 2. Conventions used in this document . . . . . . . . . . . . . . 4
3. Terminology and Interworking PE Components . . . . . . . . . 4 3. Terminology and Interworking PE Components . . . . . . . . . 4
4. Domain Path Attribute (D-PATH) . . . . . . . . . . . . . . . 10 4. Domain Path Attribute (D-PATH) . . . . . . . . . . . . . . . 10
5. BGP Path Attribute Propagation across Domains . . . . . . . . 16 5. BGP Path Attribute Propagation across Domains . . . . . . . . 15
5.1. No-Propagation-Mode . . . . . . . . . . . . . . . . . . . 16 5.1. No-Propagation-Mode . . . . . . . . . . . . . . . . . . . 16
5.2. Uniform-Propagation-Mode . . . . . . . . . . . . . . . . 17 5.2. Uniform-Propagation-Mode . . . . . . . . . . . . . . . . 16
5.3. Aggregation of Routes and Path Attribute Propagation . . 18 5.3. Aggregation of Routes and Path Attribute Propagation . . 17
6. Route Selection Process for ISF Routes . . . . . . . . . . . 19 6. Route Selection Process for ISF Routes . . . . . . . . . . . 18
7. Composite PE Procedures . . . . . . . . . . . . . . . . . . . 21 7. Composite PE Procedures . . . . . . . . . . . . . . . . . . . 20
8. Gateway PE Procedures . . . . . . . . . . . . . . . . . . . . 24 8. Gateway PE Procedures . . . . . . . . . . . . . . . . . . . . 22
9. Interworking Use-Cases . . . . . . . . . . . . . . . . . . . 27 9. Interworking Use-Cases . . . . . . . . . . . . . . . . . . . 26
10. BGP Error Handling on Interworking PEs . . . . . . . . . . . 28 10. BGP Error Handling on Interworking PEs . . . . . . . . . . . 27
11. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 29 11. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 28
12. Security Considerations . . . . . . . . . . . . . . . . . . . 29 12. Security Considerations . . . . . . . . . . . . . . . . . . . 28
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30
15. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 31 15. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 30
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
16.1. Normative References . . . . . . . . . . . . . . . . . . 31 16.1. Normative References . . . . . . . . . . . . . . . . . . 30
16.2. Informative References . . . . . . . . . . . . . . . . . 32 16.2. Informative References . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
1. Introduction and Problem Statement 1. Introduction and Problem Statement
EVPN is used as a unified control plane for tenant network intra and EVPN is used as a unified control plane for tenant network intra and
inter-subnet forwarding. When a tenant network spans not only EVPN inter-subnet forwarding. When a tenant network spans not only EVPN
domains but also domains where BGP VPN-IP or IP families provide domains but also domains where BGP VPN-IP or IP families provide
inter-subnet forwarding, there is a need to specify the interworking inter-subnet forwarding, there is a need to specify the interworking
aspects between the different families, so that the end to end tenant aspects between the different families, so that the end to end tenant
connectivity can be accomplished. This document specifies how EVPN connectivity can be accomplished. This document specifies how EVPN
should interwork with VPN-IPv4/VPN-IPv6 and IPv4/IPv6 BGP families should interwork with VPN-IPv4/VPN-IPv6 and IPv4/IPv6 BGP families
skipping to change at page 11, line 17 skipping to change at page 11, line 17
* DOMAIN-ID is a 6-octet field that represents a domain. It is * DOMAIN-ID is a 6-octet field that represents a domain. It is
composed of a 4-octet Global Administrator sub-field and a 2-octet composed of a 4-octet Global Administrator sub-field and a 2-octet
Local Administrator sub-field. The Global Administrator sub-field Local Administrator sub-field. The Global Administrator sub-field
MAY be filled with an Autonomous System Number (ASN, Public or MAY be filled with an Autonomous System Number (ASN, Public or
Private), an IPv4 address, or any value that guarantees the Private), an IPv4 address, or any value that guarantees the
uniqueness of the DOMAIN-ID (when the tenant network is connected uniqueness of the DOMAIN-ID (when the tenant network is connected
to multiple Operators) and helps troubleshooting and debugging of to multiple Operators) and helps troubleshooting and debugging of
D-PATH in ISF routes. The Local Administrator sub-field is any D-PATH in ISF routes. The Local Administrator sub-field is any
local 2-octet value, and its allocation or configuration is a local 2-octet value, and its allocation or configuration is a
local implementation matter. The representation of the Global local implementation matter.
Administrator and Local Administrator values as opaque unsigned
integers is RECOMMENDED.
* ISF_SAFI_TYPE is a 1-octet field that indicates the Inter-Subnet * ISF_SAFI_TYPE is a 1-octet field that indicates the Inter-Subnet
Forwarding SAFI type in which a route was received, before the Forwarding SAFI type in which a route was received, before the
route is re-exported into a different domain. The ISF_SAFI_TYPE route is re-exported into a different domain. The ISF_SAFI_TYPE
field is informational and does not have any impact on the loop field is informational and does not have any impact on the loop
detection or BGP Path selection procedures. The following types detection or BGP Path selection procedures. The following types
are assigned by this document: are assigned by this document:
+=======+============================+ +=======+============================+
| Value | Type | | Value | Type |
skipping to change at page 11, line 50 skipping to change at page 11, line 48
The BGP D-PATH attribute is supported on ISF routes of type IPVPN and The BGP D-PATH attribute is supported on ISF routes of type IPVPN and
EVPN and MUST NOT be advertised along with routes different from EVPN and MUST NOT be advertised along with routes different from
IPVPN and EVPN routes. By default, the BGP D-PATH attribute is not IPVPN and EVPN routes. By default, the BGP D-PATH attribute is not
advertised and MUST be explicitly enabled by configuration on the advertised and MUST be explicitly enabled by configuration on the
Gateway PEs. In addition, D-PATH: Gateway PEs. In addition, D-PATH:
a. Identifies the sequence of domains, each identified by a <DOMAIN- a. Identifies the sequence of domains, each identified by a <DOMAIN-
ID:ISF_SAFI_TYPE> through which a given ISF route of type IPVPN ID:ISF_SAFI_TYPE> through which a given ISF route of type IPVPN
or EVPN has passed. or EVPN has passed.
* This attribute list MAY contain one or more segments. Each * This attribute list MAY contain one or more segments.
segment's Domain Segment Length MUST be equal or greater than
one.
* The first entry in the list (leftmost) is the <DOMAIN- * The first entry in the list (leftmost) is the <DOMAIN-
ID:ISF_SAFI_TYPE> from which a gateway PE is propagating an ID:ISF_SAFI_TYPE> from which a gateway PE is propagating an
ISF IPVPN or EVPN route. The last entry in the list ISF IPVPN or EVPN route. The last entry in the list
(rightmost) is the <DOMAIN-ID:ISF_SAFI_TYPE> from which a (rightmost) is the <DOMAIN-ID:ISF_SAFI_TYPE> from which a
gateway PE received an ISF IPVPN or EVPN route without a gateway PE received an ISF IPVPN or EVPN route without a
D-PATH attribute (the Domain of Origin). Intermediate entries D-PATH attribute (the Domain of Origin). Intermediate entries
in the list are domains that the ISF IPVPN or EVPN route has in the list are domains that the ISF IPVPN or EVPN route has
transited. transited.
* As an example, an ISF IPVPN or EVPN route received with a * As an example, an ISF IPVPN or EVPN route received with a
D-PATH attribute containing a domain segment of {length=2, D-PATH attribute containing a domain segment of {length=2,
<6500:2:IPVPN>,<6500:1:EVPN>} indicates that the route was <6500:2:IPVPN>,<6500:1:EVPN>} indicates that the route was
originated in EVPN domain 6500:1, and propagated into IPVPN originated in EVPN domain 6500:1, and propagated into IPVPN
domain 6500:2. domain 6500:2.
* In order to minimize the number of segments in the D-PATH
attribute, the local gateway PE prepends its own domain as the
last element of the domain segment. If the act of prepending
a new domain causes an overflow in the domain segment (i.e.,
more than 255 domains), the local gateway PE MUST prepend a
new segment and prepend its own domain to this new segment.
b. It is added/modified by a gateway PE when propagating an update b. It is added/modified by a gateway PE when propagating an update
to a different domain (which runs the same or different ISF to a different domain (which runs the same or different ISF
SAFI): SAFI):
* A gateway PE's IP-VRF, that connects two domains, belongs to * A gateway PE's IP-VRF, that connects two domains, belongs to
two DOMAIN-IDs, e.g. 6500:1 for EVPN and 6500:2 for IPVPN. two DOMAIN-IDs, e.g. 6500:1 for EVPN and 6500:2 for IPVPN.
* Whenever a prefix arrives at a gateway PE in a particular ISF * Whenever a prefix arrives at a gateway PE in a particular ISF
SAFI route, if the gateway PE needs to export that prefix to a SAFI route, if the gateway PE needs to export that prefix to a
BGP peer, the gateway PE MUST prepend a <DOMAIN- BGP peer, the gateway PE MUST prepend a <DOMAIN-
ID:ISF_SAFI_TYPE> to the list of domains in the received ID:ISF_SAFI_TYPE> to the list of domains in the received
D-PATH, as long as the gateway PE works in Uniform- D-PATH, as long as the gateway PE works in Uniform-
Propagation-Mode, as explained in Section 5.2. Propagation-Mode, as explained in Section 5.2 .
* For instance, in an IP-VRF configured with DOMAIN-IDs 6500:1 * For instance, in an IP-VRF configured with DOMAIN-IDs 6500:1
for EVPN and 6500:2 for IPVPN, if an EVPN route for prefix P for EVPN and 6500:2 for IPVPN, if an EVPN route for prefix P
is received and P installed in the IP-VRF, the IPVPN route for is received and P installed in the IP-VRF, the IPVPN route for
P that is exported to an IPVPN peer will prepend the domain P that is exported to an IPVPN peer will prepend the domain
<6500:1:EVPN> to the previously received D-PATH attribute. <6500:1:EVPN> to the previously received D-PATH attribute.
Likewise, IP-VRF prefixes that are received from IP-VPN, will Likewise, IP-VRF prefixes that are received from IP-VPN, will
be exported to EVPN peers with the domain <6500:2:IPVPN> added be exported to EVPN peers with the domain <6500:2:IPVPN> added
to the segment. to the segment.
skipping to change at page 13, line 35 skipping to change at page 13, line 22
D-PATH attribute in each copy of the ISF route is initialized D-PATH attribute in each copy of the ISF route is initialized
with an ISF_SAFI_TYPE of 0 and the DOMAIN-ID of the domain with an ISF_SAFI_TYPE of 0 and the DOMAIN-ID of the domain
with which the ISF route is associated. with which the ISF route is associated.
3. It MAY advertise that ISF route with a D-PATH attribute that 3. It MAY advertise that ISF route with a D-PATH attribute that
contains a configured domain specific to its local ISF routes contains a configured domain specific to its local ISF routes
into one or more of its configured domains, in which case the into one or more of its configured domains, in which case the
D-PATH attribute in each copy of the ISF route is initialized D-PATH attribute in each copy of the ISF route is initialized
with a ISF_SAFI_TYPE of 0 and the DOMAIN-ID for the local ISF with a ISF_SAFI_TYPE of 0 and the DOMAIN-ID for the local ISF
routes. This DOMAIN-ID MUST be globally unique and MAY be routes. This DOMAIN-ID MUST be globally unique and MAY be
shared by two or more gateway PEs. Although the three shared by two or more gateway PEs.
options help detect control plane loops, this option 3 is
RECOMMENDED, since it is the option that provides more
information about the differentiated origin of the route (it
uses a DOMAIN-ID and ISF_SAFI_TYPE that identifies the route
as a local gateway route).
d. An ISF IPVPN or EVPN route received by a gateway PE with a D-PATH d. An ISF IPVPN or EVPN route received by a gateway PE with a D-PATH
attribute that contains one or more of its locally associated attribute that contains one or more of its locally associated
DOMAIN-IDs (for the IP-VRF) is considered to be a looped ISF DOMAIN-IDs (for the IP-VRF) is considered to be a looped ISF
route for the purpose of re-exporting the route to the adjacent route for the purpose of re-exporting the route to the adjacent
domain in a Gateway PE. The ISF route in this case MUST be domain in a Gateway PE. The ISF route in this case MUST be
flagged as "looped", MUST NOT be exported, and MAY be installed flagged as "looped", MUST NOT be exported, and MAY be installed
in the IP-VRF only in case there is no better route after the in the IP-VRF only in case there is no better route after the
best path selection (Section 6). The ISF_SAFI_TYPE is irrelevant best path selection (Section 6). The ISF_SAFI_TYPE is irrelevant
for the purpose of loop detection of an ISF route. In other for the purpose of loop detection of an ISF route. In other
skipping to change at page 15, line 41 skipping to change at page 15, line 8
2. A Domain Segment is considered malformed in any of the 2. A Domain Segment is considered malformed in any of the
following cases: following cases:
* The Domain Segment length of the last Domain Segment * The Domain Segment length of the last Domain Segment
causes the D-PATH attribute length to be exceeded. causes the D-PATH attribute length to be exceeded.
* After the last successfully parsed Domain Segment there * After the last successfully parsed Domain Segment there
are less than eight octets remaining. are less than eight octets remaining.
* The D-PATH attribute MUST be at least 8 octets in length * The Domain Segment has a Domain Segment Length of zero.
or it is malformed.
* For each contained Domain Segment, the Domain Segment
length is one octet, containing the number of Domains in
this segment, each of which are 7 octets in length. If
the total length of the Domain Segment in octets (1 + 7 *
number of Domains) exceeds the remaining length of the
D-PATH attribute, the Domain Segment is malformed.
3. A PE receiving an UPDATE message with a malformed D-PATH 3. A PE receiving an UPDATE message with a malformed D-PATH
attribute SHALL apply "treat-as-withdraw" [RFC7606]. attribute SHALL apply "treat-as-withdraw" [RFC7606].
4. Domains in the D-PATH attribute with unknown ISF_SAFI_TYPE 4. Domains in the D-PATH attribute with unknown ISF_SAFI_TYPE
values are accepted and not considered an error. values are accepted and not considered an error.
5. In case a PE receives more than one D-PATH attribute with a 5. In case a PE receives more than one D-PATH attribute with a
route, the PE SHALL process the first one in the list and not route, the PE SHALL process the first one in the list and not
store and propagate the others. store and propagate the others.
skipping to change at page 19, line 12 skipping to change at page 18, line 19
When using Uniform-Propagation-Mode, Path Attributes of the same type When using Uniform-Propagation-Mode, Path Attributes of the same type
code MAY be aggregated according to the following rules: code MAY be aggregated according to the following rules:
* AS_PATH is aggregated based on the rules in [RFC4271]. The * AS_PATH is aggregated based on the rules in [RFC4271]. The
gateway PEs are not expected to receive AS_PATH attributes with gateway PEs are not expected to receive AS_PATH attributes with
path segments of type AS_SET [RFC6472]. Routes received with path segments of type AS_SET [RFC6472]. Routes received with
AS_PATH attributes including AS_SET path segments MUST NOT be AS_PATH attributes including AS_SET path segments MUST NOT be
aggregated. aggregated.
* An ISF aggregate route SHOULD NOT be advertised unless all the * An ISF aggregate route SHOULD NOT be advertised unless all the
contributing ISF routes have the same D-PATH DOMAIN-ID members. contributing ISF routes have the same D-PATH value. If there is
If there is at least one contributing ISF route that has a at least one contributing ISF route that has different D-PATH, the
different D-PATH DOMAIN-ID, the gateway PE SHOULD advertise each gateway PE SHOULD advertise each contributing ISF route with its
contributing ISF route with its own D-PATH (prepended with the own D-PATH (prepended with the gateway's domain). An
gateway's domain). An implementation MAY override this behavior, implementation MAY override this behavior, via policy, to
via policy, to advertise an ISF aggregate route without D-PATH in advertise an ISF aggregate route without D-PATH in case the
case the contributing routes did not have the same D-PATH DOMAIN- contributing routes did not have the same D-PATH value.
ID members.
* The Community, Extended Community and Large Community attributes * The Community, Extended Community and Large Community attributes
of the aggregate ISF route SHOULD contain all the Communities/ of the aggregate ISF route MUST contain all the Communities/
Extended Communities/Large Communities from all of the aggregated Extended Communities/Large Communities from all of the aggregated
ISF routes, with the exceptions of the extended communities listed ISF routes, with the exceptions of the extended communities listed
in Section 5.2 that are not propagated. in Section 5.2 that are not propagated.
* For other attributes, rules in [RFC4271] are followed. * For other attributes, rules in [RFC4271] are followed.
Assuming the aggregation can be performed (the above rules are Assuming the aggregation can be performed (the above rules are
applied), the operator should consider aggregation to deal with applied), the operator should consider aggregation to deal with
scaled tenant networks where a significant number of host routes scaled tenant networks where a significant number of host routes
exists. For example, large Data Centers. exists. For example, large Data Centers.
skipping to change at page 22, line 40 skipping to change at page 21, line 40
Composite PE2 Composite PE2
Figure 7: Composite PE example Figure 7: Composite PE example
In a composite domain with composite and regular PEs: In a composite domain with composite and regular PEs:
1. The composite PEs MUST advertise the same IP prefixes in each ISF 1. The composite PEs MUST advertise the same IP prefixes in each ISF
SAFI to the Route Reflector (RR). For example, in Figure 7, the SAFI to the Route Reflector (RR). For example, in Figure 7, the
prefix IP1/24 is advertised by PE1 and PE2 to the Route Reflector prefix IP1/24 is advertised by PE1 and PE2 to the Route Reflector
in two separate NLRIs, one for AFI/SAFI 1/128 and another one for in two separate NLRIs, one for AFI/SAFI 1/128 and another one for
EVPN. If the two routes are advertised with the same set of EVPN.
attributes, the remote Composite PE selection process will pick
up the EVPN route over the IPVPN route (as per Section 6). For
this reason, prioritizing the announcement of the EVPN route
prior to the IPVPN route is an OPTIONAL optimization, since, if
the EVPN route arrives at the composite PE first, the selected
route is not replaced by the IPVPN route later.
2. As an informative note, the Route Reflector does not forward EVPN 2. As an informative note, the Route Reflector does not forward EVPN
routes to neighbors on which the EVPN SAFI is not enabled, and routes to neighbors on which the EVPN SAFI is not enabled, and
similarly, the Route Reflector does not forward IPVPN routes to similarly, the Route Reflector does not forward IPVPN routes to
neighbors on which the IPVPN SAFI is not enabled. For example, neighbors on which the IPVPN SAFI is not enabled. For example,
the Route Reflector does not forward EVPN routes to PE3 (since the Route Reflector does not forward EVPN routes to PE3 (since
the Route Reflector does not have the EVPN SAFI enabled on its the Route Reflector does not have the EVPN SAFI enabled on its
BGP session to PE3), whereas the IPVPN routes are forwarded to BGP session to PE3), whereas the IPVPN routes are forwarded to
all the PEs. all the PEs.
skipping to change at page 30, line 6 skipping to change at page 29, line 6
build large tenant networks that may span multiple domains, use build large tenant networks that may span multiple domains, use
different ISF SAFIs to handle IP prefixes, in a deterministic way and different ISF SAFIs to handle IP prefixes, in a deterministic way and
with routing loop protection. with routing loop protection.
12. Security Considerations 12. Security Considerations
In general, the security considerations described in [RFC9136] and In general, the security considerations described in [RFC9136] and
[RFC4364] apply to this document. [RFC4364] apply to this document.
Section 4 introduces the use of the D-PATH attribute, which provides Section 4 introduces the use of the D-PATH attribute, which provides
a loop prevention mechanism that is used by gateway PEs that a security tool against control plane loops that may be introduced by
propagate ISF IPVPN/EVPN routes between domains. A correct use of the use of gateway PEs that propagate ISF IPVPN/EVPN routes between
the D-PATH will prevent control plane and data plane loops in the domains. A correct use of the D-PATH will prevent control plane and
network, however an incorrect configuration of the DOMAIN-IDs or an data plane loops in the network, however an incorrect configuration
inconsistent support of D-PATH on the Gateway PEs may lead to the of the DOMAIN-IDs or an inconsistent support of D-PATH on the Gateway
detection of false route loops, the blackholing of the traffic or may PEs may lead to the detection of false route loops, the blackholing
result in inconsistent and sub-optimal routing. An attacker may of the traffic or may result in inconsistent and sub-optimal routing.
benefit of this transitive attribute to propagate the wrong domain An attacker may benefit of this transitive attribute to propagate the
information across multiple domains. wrong domain information across multiple domains.
Section 4 restricts the use of D-PATH to IPVPN and EVPN routes in Section 4 restricts the use of D-PATH to IPVPN and EVPN routes in
"walled garden" Virtual Private Networks. An upgraded PE removes "walled garden" Virtual Private Networks. An upgraded PE removes
D-PATH from the BGP Path Attributes before advertising an IP Prefix D-PATH from the BGP Path Attributes before advertising an IP Prefix
to a CE in a SAFI 1 route. However, if D-PATH is received by a non- to a CE in a SAFI 1 route. However, if D-PATH is received by a non-
upgraded IPVPN PE that has an attached CE connected to the Internet, upgraded IPVPN PE that has an attached CE connected to the Internet,
the PE may incorrectly propagate the D-PATH attribute in a SAFI 1 the PE may incorrectly propagate the D-PATH attribute in a SAFI 1
route to the CE, and the D-PATH attribute may then escape out of the route to the CE, and the D-PATH attribute may then escape out of the
"walled garden" to the Internet. This may happen when the IPVPN PE "walled garden" to the Internet. This may happen when the IPVPN PE
re-exports a route directly, or via route leaking between IP-VRFs. re-exports a route directly, or via route leaking between IP-VRFs.
skipping to change at page 34, line 17 skipping to change at page 33, line 17
J. Drake J. Drake
Independent Independent
Email: je_drake@yahoo.com Email: je_drake@yahoo.com
W. Lin W. Lin
Juniper Juniper
Email: wlin@juniper.net Email: wlin@juniper.net
J. Uttaro J. Uttaro
Independent AT&T
Email: juttaro@ieee.org Email: ju1738@att.com
A. Simpson A. Simpson
Nokia Nokia
Email: adam.1.simpson@nokia.com Email: adam.1.simpson@nokia.com
 End of changes. 19 change blocks. 
79 lines changed or deleted 48 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/