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/ |