< draft-ietf-bess-evpn-pref-df-01.txt   draft-ietf-bess-evpn-pref-df-02.txt >
skipping to change at page 1, line 16 skipping to change at page 1, line 16
S. Boutros T. Przygienda S. Boutros T. Przygienda
Individual W. Lin Individual W. Lin
J. Drake J. Drake
Juniper Networks Juniper Networks
A. Sajassi A. Sajassi
S. Mohanty S. Mohanty
Cisco Systems Cisco Systems
Expires: October 11, 2018 April 9, 2018 Expires: April 25, 2019 October 22, 2018
Preference-based EVPN DF Election Preference-based EVPN DF Election
draft-ietf-bess-evpn-pref-df-01 draft-ietf-bess-evpn-pref-df-02
Abstract Abstract
RFC7432 defines the Designated Forwarder (DF) in (PBB-)EVPN networks The Designated Forwarder (DF) in (PBB-)EVPN networks is defined as
as the PE responsible for sending broadcast, multicast and unknown the PE responsible for sending broadcast, multicast and unknown
unicast traffic (BUM) to a multi-homed device/network in the case of unicast traffic (BUM) to a multi-homed device/network in the case of
an all-active multi-homing ES, or BUM and unicast in the case of an all-active multi-homing ES, or BUM and unicast in the case of
single-active multi-homing. single-active multi-homing.
The DF is selected out of a candidate list of PEs that advertise the The DF is selected out of a candidate list of PEs that advertise the
Ethernet Segment Identifier (ESI) to the EVPN network, according to Ethernet Segment Identifier (ESI) to the EVPN network, according to
the 'service-carving' algorithm. the Default DF Election algorithm.
While 'service-carving' provides an efficient and automated way of While the Default Algorithm provides an efficient and automated way
selecting the DF across different EVIs or ISIDs in the ES, there are of selecting the DF across different EVIs or ISIDs in the ES, there
some use-cases where a more 'deterministic' and user-controlled are some use-cases where a more 'deterministic' and user-controlled
method is required. At the same time, Service Providers require an method is required. At the same time, Service Providers require an
easy way to force an on-demand DF switchover in order to carry out easy way to force an on-demand DF switchover in order to carry out
some maintenance tasks on the existing DF or control whether a new some maintenance tasks on the existing DF or control whether a new
active PE can preempt the existing DF PE. active PE can preempt the existing DF PE.
This document proposes an extension to the current RFC7432 DF This document proposes an extension to the Default DF election
election procedures so that the above requirements can be met. procedures so that the above requirements can be met.
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), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 2, line 22 skipping to change at page 2, line 22
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on October 11, 2018. This Internet-Draft will expire on April 25, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 45 skipping to change at page 2, line 45
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 3 1. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 3
2. Solution requirements . . . . . . . . . . . . . . . . . . . . . 3 2. Solution requirements . . . . . . . . . . . . . . . . . . . . . 3
3. EVPN BGP Attributes for Deterministic DF Election . . . . . . . 4 3. EVPN BGP Attributes for Deterministic DF Election . . . . . . . 4
4. Solution description . . . . . . . . . . . . . . . . . . . . . 5 4. Solution description . . . . . . . . . . . . . . . . . . . . . 5
4.1 Use of the Preference algorithm . . . . . . . . . . . . . . 5 4.1 Use of the Preference algorithm . . . . . . . . . . . . . . 6
4.2 Use of the Preference algorithm in RFC7432 4.2 Use of the Preference algorithm in [RFC7432]
Ethernet-Segments . . . . . . . . . . . . . . . . . . . . . 7 Ethernet-Segments . . . . . . . . . . . . . . . . . . . . . 7
4.3 The Non-Revertive option . . . . . . . . . . . . . . . . . . 8 4.3 The Non-Revertive option . . . . . . . . . . . . . . . . . . 8
5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5. Conventions used in this document . . . . . . . . . . . . . . . 11
11. Conventions used in this document . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 11
12. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 11
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 11
15.1 Normative References . . . . . . . . . . . . . . . . . . . 11 8.2 Informative References . . . . . . . . . . . . . . . . . . . 11
15.2 Informative References . . . . . . . . . . . . . . . . . . 11 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 12
16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 12
17. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 11 11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12
17. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12
1. Problem Statement 1. Problem Statement
RFC7432 defines the Designated Forwarder (DF) in (PBB-)EVPN networks [RFC7432] defines the Designated Forwarder (DF) in (PBB-)EVPN
as the PE responsible for sending broadcast, multicast and unknown networks as the PE responsible for sending broadcast, multicast and
unicast traffic (BUM) to a multi-homed device/network in the case of unknown unicast traffic (BUM) to a multi-homed device/network in the
an all-active multi-homing ES or BUM and unicast traffic to a multi- case of an all-active multi-homing ES or BUM and unicast traffic to a
homed device or network in case of single-active multi-homing. multi-homed device or network in case of single-active multi-homing.
The DF is selected out of a candidate list of PEs that advertise the The DF is selected out of a candidate list of PEs that advertise the
Ethernet Segment Identifier (ESI) to the EVPN network and according Ethernet Segment Identifier (ESI) to the EVPN network and according
to the 'service-carving' algorithm. to the Alg [DF].
While 'service-carving' provides an efficient and automated way of While the Default DF Election Algorithm provides an efficient and
selecting the DF across different EVIs or ISIDs in the ES, there are automated way of selecting the DF across different EVIs or ISIDs in
some use-cases where a more 'deterministic' and user-controlled the ES, there are some use-cases where a more 'deterministic' and
method is required. At the same time, Service Providers require an user-controlled method is required. At the same time, Service
easy way to force an on-demand DF switchover in order to carry out Providers require an easy way to force an on-demand DF switchover in
some maintenance tasks on the existing DF or control whether a new order to carry out some maintenance tasks on the existing DF or
active PE can preempt the existing DF PE. control whether a new active PE can preempt the existing DF PE.
This document proposes an extension to the current RFC7432 DF This document proposes an extension to the current Default DF
election procedures so that the above requirements can be met. election procedures [RFC7432] so that the above requirements can be
met.
2. Solution requirements 2. Solution requirements
This document proposes an extension of the RFC7432 'service-carving' This document proposes an extension of the [RFC7432] Default DF
DF election algorithm motivated by the following requirements: election Algorithm motivated by the following requirements:
a) The solution MUST provide an administrative preference option so a) The solution provides an administrative preference option so that
that the user can control in what order the candidate PEs may the user can control in what order the candidate PEs may become
become DF, assuming they are all operationally ready to take over. DF, assuming they are all operationally ready to take over.
b) This extension MUST work for RFC7432 Ethernet Segments (ES) and b) This extension works for [RFC7432] Ethernet Segments (ES) and
virtual ES, as defined in [vES]. virtual ES, as defined in [vES].
c) The user MUST be able to force a PE to preempt the existing DF for c) The user may force a PE to preempt the existing DF for a given
a given EVI/ISID without re-configuring all the PEs in the ES. EVI/ISID without re-configuring all the PEs in the ES.
d) The solution SHOULD allow an option to NOT preempt the current DF, d) The solution allows an option to NOT preempt the current DF, even
even if the former DF PE comes back up after a failure. This is if the former DF PE comes back up after a failure. This is also
also known as "non-revertive" behavior, as opposed to the RFC7432 known as "non-revertive" behavior, as opposed to the [RFC7432] DF
DF election procedures that are always revertive. election procedures that are always revertive.
e) The solution MUST work for single-active and all-active multi- e) The solution works for single-active and all-active multi-homing
homing Ethernet Segments. Ethernet Segments.
3. EVPN BGP Attributes for Deterministic DF Election 3. EVPN BGP Attributes for Deterministic DF Election
This solution reuses and extends the DF Election Extended Community This solution reuses and extends the DF Election Extended Community
defined in [DF] that is advertised along with the ES route: defined in [DF] that is advertised along with the ES route:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=0x06 | Sub-Type(0x06)| DF Type |DP| Reserved=0 | | Type=0x06 | Sub-Type(0x06)| DF Alg | Bitmap |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved = 0 | DF Preference (2 octets) | | Bitmap | Reserved | DF Preference (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where the following fields are re-defined as follows: Figure 1 - DF Election Extended Community
o DF Type can have the following values: Where the following fields are defined as follows:
- Type 0 - Default, mod based DF election as per RFC7432. o DF Alg can have the following values:
- Type 1 - HRW algorithm as per [DF]
- Type 2 - Preference algorithm (this document)
o DP or 'Don't Preempt' bit, determines if the PE advertising the ES - Alg 0 - Default, modulo based DF election as per [RFC7432].
route requests the remote PEs in the ES not to preempt it as DF. - Alg 1 - HRW algorithm as per [DF]
The default value is DP=0, which is compatible with the current - Alg 2 - Preference algorithm (this document)
'preempt' or 'revertive' behavior in RFC7432. The DP bit SHOULD be
ignored if the DF Type is different than 2. o Bitmap can have the following values:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|D|A| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 - Bitmap field in the DF Election Extended Community
- Bit 0 (corresponds to Bit 24 of the DF Election Extended
Community) - D bit or 'Don't Preempt' bit (DP hereafter),
determines if the PE advertising the ES route requests the remote
PEs in the ES not to preempt it as DF. The default value is DP=0,
which is compatible with the 'preempt' or 'revertive' behavior in
the Default Alg [RFC7432]. The DP bit SHOULD be ignored if the DF
Alg is different than 2.
- Bit 1 - AC-DF or AC-Influenced DF Election, explained in [DF].
The AC-DF capability bit MAY be set along with the DP capability
and Alg 2.
o DF Preference defines a 2-octet value that indicates the PE o DF Preference defines a 2-octet value that indicates the PE
preference to become the DF in the ES. The allowed values are preference to become the DF in the ES. The allowed values are
within the range 0-65535, and default value MUST be 32767. This within the range 0-65535, and default value MUST be 32767. This
value is the midpoint in the allowed Preference range of values, value is the midpoint in the allowed Preference range of values,
which gives the operator the flexibility of choosing a significant which gives the operator the flexibility of choosing a significant
number of values, above or below the default Preference. The DF number of values, above or below the default Preference. The DF
Preference field is specific to DF Type 2 and does not represent Preference field is specific to DF Alg 2 and does not represent any
any Preference value for other Types. Preference value for other Algs.
4. Solution description 4. Solution description
Figure 1 illustrates an example that will be used in the description Figure 3 illustrates an example that will be used in the description
of the solution. of the solution.
EVPN network EVPN network
+-------------------+ +-------------------+
| +-------+ ENNI Aggregation | +-------+ ENNI Aggregation
| <---ESI1,500 | PE1 | /\ +----Network---+ | <---ESI1,500 | PE1 | /\ +----Network---+
| <-----ESI2,100 | |===||=== | | <-----ESI2,100 | |===||=== |
| | |===||== \ vES1 | +----+ | | |===||== \ vES1 | +----+
+-----+ | | \/ |\----------------+CE1 | +-----+ | | \/ |\----------------+CE1 |
CE3--+ PE4 | +-------+ | \ ------------+ | CE3--+ PE4 | +-------+ | \ ------------+ |
skipping to change at page 5, line 29 skipping to change at page 5, line 47
| | | X | | | | X |
| <---ESI1,255 +-----+============ \ | | <---ESI1,255 +-----+============ \ |
| <-----ESI2,200 | PE2 |========== \ vES2 | +----+ | <-----ESI2,200 | PE2 |========== \ vES2 | +----+
| +-----+ | \ ----------+CE2 | | +-----+ | \ ----------+CE2 |
| | | --------------| | | | | --------------| |
| +-----+ ----------------------+ | | +-----+ ----------------------+ |
| <-----ESI2,300 | PE3 +--/ | | +----+ | <-----ESI2,300 | PE3 +--/ | | +----+
| +-----+ +--------------+ | +-----+ +--------------+
--------------------+ --------------------+
Figure 1 ES and Deterministic DF Election Figure 3 - ES and Deterministic DF Election
Figure 1 shows three PEs that are connecting EVCs coming from the Figure 1 shows three PEs that are connecting EVCs coming from the
Aggregation Network to their EVIs in the EVPN network. CE1 is Aggregation Network to their EVIs in the EVPN network. CE1 is
connected to vES1 - that spans PE1 and PE2 - and CE2 is connected to connected to vES1 - that spans PE1 and PE2 - and CE2 is connected to
vES2, that is defined in PE1, PE2 and PE3. vES2, that is defined in PE1, PE2 and PE3.
If the algorithm chosen for vES1 and vES2 is type 2, i.e. Preference- If the algorithm chosen for vES1 and vES2 is Alg 2, i.e. Preference-
based, the PEs may become DF irrespective of their IP address and based, the PEs may become DF irrespective of their IP address and
based on an administrative Preference value. The following sections based on an administrative Preference value. The following sections
provide some examples of the new defined procedures and how they are provide some examples of the new defined procedures and how they are
applied in the use-case in Figure 1. applied in the use-case in Figure 1.
4.1 Use of the Preference algorithm 4.1 Use of the Preference algorithm
Assuming the operator wants to control - in a flexible way - what PE Assuming the operator wants to control - in a flexible way - what PE
becomes the DF for a given vES and the order in which the PEs become becomes the DF for a given vES and the order in which the PEs become
DF in case of multiple failures, the following procedure may be used: DF in case of multiple failures, the following procedure may be used:
a) vES1 and vES2 are now configurable with three optional parameters a) vES1 and vES2 are now configurable with three optional parameters
that are signaled in the DF Election extended community. These that are signaled in the DF Election extended community. These
parameters are the Preference, Preemption option (or "Don't parameters are the Preference, Preemption option (or "Don't
Preempt Me" option) and DF algorithm type. We will represent these Preempt Me" option) and DF Alg. We will represent these parameters
parameters as [Pref,DP,type]. Let's assume vES1 is configured as as [Pref,DP,Alg]. Let's assume vES1 is configured as [500,0,Pref]
[500,0,Pref] in PE1, and [255,0,Pref] in PE2. vES2 is configured in PE1, and [255,0,Pref] in PE2. vES2 is configured as
as [100,0,Pref], [200,0,Pref] and [300,0,Pref] in PE1, PE2 and PE3 [100,0,Pref], [200,0,Pref] and [300,0,Pref] in PE1, PE2 and PE3
respectively. respectively.
b) The PEs will advertise an ES route for each vES, including the 3 b) The PEs will advertise an ES route for each vES, including the 3
parameters in the DF Election Extended Community. parameters in the DF Election Extended Community.
c) According to RFC7432, each PE will wait for the DF timer to expire c) According to [RFC7432], each PE will wait for the DF timer to
before running the DF election algorithm. After the timer expires, expire before running the DF election algorithm. After the timer
each PE runs the Preference-based DF election algorithm as expires, each PE runs the Preference-based DF election algorithm
follows: as follows:
o The PE will check the DF type in each ES route, and assuming all o The PE will check the DF Alg in each ES route, and assuming all
the ES routes are consistent in this DF type and the value is 2 the ES routes are consistent in this DF Alg and the value is 2
(Preference-based), the PE will run the new extended procedure. (Preference-based), the PE will run the new extended procedure.
Otherwise, the procedure will fall back to RFC7432 'service- Otherwise, the procedure will fall back to [RFC7432] Default
carving'. Alg.
o In this extended procedure, each PE builds a list of candidate o In this extended procedure, each PE builds a list of candidate
PEs, ordered based on the Preference. E.g. PE1 will build a list PEs, ordered based on the Preference. E.g. PE1 will build a list
of candidate PEs for vES1 ordered by the Preference, from high of candidate PEs for vES1 ordered by the Preference, from high
to low: PE1>PE2. Hence PE1 will become the DF for vES1. In the to low: PE1>PE2. Hence PE1 will become the DF for vES1. In the
same way, PE3 becomes the DF for vES2. same way, PE3 becomes the DF for vES2.
d) Note that, by default, the Highest-Preference is chosen for each d) Note that, by default, the Highest-Preference is chosen for each
ES or vES, however the ES configuration can be changed to the ES or vES, however the ES configuration can be changed to the
Lowest-Preference algorithm as long as this option is consistent Lowest-Preference algorithm as long as this option is consistent
in all the PEs in the ES. E.g. vES1 could have been explicitly in all the PEs in the ES. E.g. vES1 could have been explicitly
configured as type Preference-based with Lowest-Preference, in configured as Alg Preference-based with Lowest-Preference, in
which case, PE2 would have been the DF. which case, PE2 would have been the DF.
e) Assuming some maintenance tasks had to be executed on PE3, the e) Assuming some maintenance tasks had to be executed on PE3, the
operator could set vES2's preference to e.g. 50 so that PE2 is operator could set vES2's preference to e.g. 50 so that PE2 is
forced to take over as DF for vES2. Once the maintenance on PE3 is forced to take over as DF for vES2. Once the maintenance on PE3 is
over, the operator could decide to leave the existing preference over, the operator could decide to leave the existing preference
or configure the old preference back. or configure the old preference back.
f) In case of equal Preference in two or more PEs in the ES, the tie- f) In case of equal Preference in two or more PEs in the ES, the tie-
breakers will be the DP bit and the lowest IP PE in that order. breakers will be the DP bit and the lowest IP PE in that order.
skipping to change at page 7, line 18 skipping to change at page 7, line 39
dynamically changed based on the use of local policies. For dynamically changed based on the use of local policies. For
instance, on PE1, ES1's Preference can be lowered from 500 to 100 instance, on PE1, ES1's Preference can be lowered from 500 to 100
in case the bandwidth on the ENNI port is decreased a 50% (that in case the bandwidth on the ENNI port is decreased a 50% (that
could happen if e.g. the 2-port LAG between PE1 and the could happen if e.g. the 2-port LAG between PE1 and the
Aggregation Network loses one port). Policies MAY also trigger Aggregation Network loses one port). Policies MAY also trigger
dynamic Preference changes based on the PE's bandwidth dynamic Preference changes based on the PE's bandwidth
availability in the core, of specific ports going operationally availability in the core, of specific ports going operationally
down, etc. The definition of the actual local policies is out of down, etc. The definition of the actual local policies is out of
scope of this document. The default Preference value is 32767. scope of this document. The default Preference value is 32767.
4.2 Use of the Preference algorithm in RFC7432 Ethernet-Segments 4.2 Use of the Preference algorithm in [RFC7432] Ethernet-Segments
While the Preference-based DF type described in section 4.1 is While the Preference-based DF Alg described in section 4.1 is
typically used in virtual ES scenarios where there is normally an typically used in virtual ES scenarios where there is normally an
individual EVI per vES, the existing RFC7432 definition of ES allows individual EVI per vES, the existing [RFC7432] definition of ES
potentially up to thousands of EVIs on the same ES. If this is the allows potentially up to thousands of EVIs on the same ES. If this is
case, and the operator still wants to control who the DF is for a the case, and the operator still wants to control who the DF is for a
given EVI, the use of the Preference-based DF type can also provide given EVI, the use of the Preference-based DF Alg can also provide
the desired level of load balancing. the desired level of load balancing.
In this type of scenarios, the ES is configured with an In this type of scenarios, the ES is configured with an
administrative Preference value, but then a range of EVI/ISIDs can be administrative Preference value, but then a range of EVI/ISIDs can be
defined to use the Highest-Preference or the Lowest-Preference defined to use the Highest-Preference or the Lowest-Preference
depending on the desired behavior. With this option, the PE will depending on the desired behavior. With this option, the PE will
build a list of candidate PEs ordered by the Preference, however the build a list of candidate PEs ordered by the Preference, however the
DF for a given EVI/ISID will be determined by the local DF for a given EVI/ISID will be determined by the local
configuration. configuration.
skipping to change at page 10, line 29 skipping to change at page 10, line 52
Pref with its administrative Pref. If different, the PE will Pref with its administrative Pref. If different, the PE will
send an ES route update with its administrative Pref and DP send an ES route update with its administrative Pref and DP
values. In the example, PE3 will be the new Highest-PE, values. In the example, PE3 will be the new Highest-PE,
therefore it will send an ES route update with therefore it will send an ES route update with
[Pref,DP]=[300,1]. [Pref,DP]=[300,1].
o After running the DF Election, PE3 will become the new DF for o After running the DF Election, PE3 will become the new DF for
EVI1. No changes will occur for EVI2. EVI1. No changes will occur for EVI2.
Note that, irrespective of the DP bit, when a PE or ES comes back and Note that, irrespective of the DP bit, when a PE or ES comes back and
the PE advertises a DF Election type different than 2 (Preference the PE advertises a DF Election Alg different than 2 (Preference
algorithm), the rest of the PEs in the ES MUST fall back to the algorithm), the rest of the PEs in the ES MUST fall back to the
default RFC7432 service-carving modulo-based DF Election. Default [RFC7432] Alg.
5. Conclusions
Service Providers are seeking for options where the DF election can
be controlled by the user in a deterministic way and with a non-
revertive behavior. This document defines the use of a Preference
algorithm that can be configured and used in a flexible manner to
achieve those objectives.
11. Conventions used in this document 5. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in RFC-2119 [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in
BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all
In this document, these words will appear with that interpretation capitals, as shown here.
only when in ALL CAPS. Lower case uses of these words are not to be
interpreted as carrying RFC-2119 significance.
In this document, the characters ">>" preceding an indented line(s)
indicates a compliance requirement statement using the key words
listed above. This convention aids reviewers in quickly identifying
or finding the explicit compliance requirements of this RFC.
12. Security Considerations 6. Security Considerations
This section will be added in future versions. This section will be added in future versions.
13. IANA Considerations 7. IANA Considerations
This document solicits the allocation of DF type = 2 in the registry This document solicits the allocation of DF Alg = 2 in the registry
created by [DF] for the DF type field, and the DP bit in the [DF] created by [DF] for the DF Alg field, and the DP bit (Bit 0) in the
Bitmap registry. [DF] Bitmap registry.
15. References 8. References
15.1 Normative References 8.1 Normative References
[RFC7432]Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., [RFC7432]Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet
VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015,
<https://www.rfc-editor.org/info/rfc7432>. <https://www.rfc-editor.org/info/rfc7432>.
[DF] Rabadan J., Mohanty S. et al. "Framework for EVPN Designated [DF] Rabadan J., Mohanty S. et al. "Framework for EVPN Designated
Forwarder Election Extensibility", draft-ietf-bess-evpn-df-election- Forwarder Election Extensibility", draft-ietf-bess-evpn-df-election-
framework-00, work-in-progress, March 5, 2018. framework-05, work-in-progress, October, 2018.
15.2 Informative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March
1997, <https://www.rfc-editor.org/info/rfc2119>.
[vES] Sajassi et al. "EVPN Virtual Ethernet Segment", draft-sajassi- [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
bess-evpn-virtual-eth-segment-03, work-in-progress, August 26, 2018. 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017,
<https://www.rfc-editor.org/info/rfc8174>.
16. Acknowledgments 8.2 Informative References
[vES] Sajassi et al. "EVPN Virtual Ethernet Segment", draft-ietf-
bess-evpn-virtual-eth-segment-00, work-in-progress, June, 2018.
9. Acknowledgments
The authors would like to thank Kishore Tiruveedhula for his review The authors would like to thank Kishore Tiruveedhula for his review
and comments. and comments.
17. Contributors 10. Contributors
In addition to the authors listed, the following individuals also In addition to the authors listed, the following individuals also
contributed to this document: contributed to this document:
Kiran Nagaraj, Nokia Kiran Nagaraj, Nokia
Vinod Prabhu, Nokia Vinod Prabhu, Nokia
Selvakumar Sivaraj, Juniper Selvakumar Sivaraj, Juniper
17. Authors' Addresses 11. Authors' Addresses
Jorge Rabadan Jorge Rabadan
Nokia Nokia
777 E. Middlefield Road 777 E. Middlefield Road
Mountain View, CA 94043 USA Mountain View, CA 94043 USA
Email: jorge.rabadan@nokia.com Email: jorge.rabadan@nokia.com
Senthil Sathappan Senthil Sathappan
Alcatel-Lucent Alcatel-Lucent
Email: senthil.sathappan@nokia.com Email: senthil.sathappan@nokia.com
 End of changes. 53 change blocks. 
125 lines changed or deleted 136 lines changed or added

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