Reviewer: Stewart Bryant
Review result: Has Issues
I am entering these last call comments as part of the Routing Area review
process.
I regret that it isthis text is not yet ready to proceed to the next stage of
the IETF Review Process.
I think that editorial work is needed to clarify the document for the reader.
One particular comment is that the authors tend to describe behaviour in terms
of bit values and not in terms of bit semantics or bit name when describing the
operation of the protocol. In general, people tend to think and code in terms
of names rather than 1s and 0s.
Detailed comments below
=======
BESS Workgroup J. Rabadan, Ed.
Internet-Draft S. Sathappan
Intended status: Standards Track Nokia
Expires: 7 January 2023 T. Przygienda
W. Lin
J. Drake
Juniper Networks
A. Sajassi
S. Mohanty
Cisco Systems
6 July 2022
SB> There are too many front page authors.
[jorge] version 10 has moved two authors to the contributors section.
========
1.1. Problem Statement
<snip>
While the Default DF Alg [RFC7432] or HRW [RFC8584] provide an
efficient and automated way of selecting the DF across different
Ethernet Tags in the ES, there are some use-cases where a more
'deterministic' and user-controlled 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 some maintenance tasks on the
existing DF or control whether a new active PE can preempt the
existing DF PE.
This document proposes a new DF Alg and capability to address the
above needs.
SB> As far as I can see you propose two algorithms and I cannot see in the
above how you map each algorithm to a particular set of sub-use-cases.
[jorge] I replaced the last sentence with:
“This document proposes two new DF Algs (Highest-Preference and Lowest-Preference) which provide the deterministic Designated Forwarder method required, as
well as the "Don't Preempt" capability to address the need to control whether a PE can take over an existing Designated Forwarder PE.”
=======
1.2. Solution requirements
<snip>
d. The solution allows an option to NOT preempt the current DF, even
if the former DF PE comes back up after a failure. This is also
known as "non-revertive" behavior, as opposed to the [RFC7432] DF
election procedures that are always revertive.
SB> It is useful to say why.
SB> Again in this section the two algorithms need to map to use cases.
[jorge] the section has been changed accordingly.
==========
2. Requirements Language and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
SB> Nits does not like the above boilerplate. I would be helpful to other
reviewers to address so they do not have to investigate the warning.
[jorge] it is fixed now, thanks.
=======
* DF Alg or simply Alg - refers to Designated Forwarder Election
Algorithm.
SB> “simply Alg” is confusing since it is not clear if simply is part of the
name. How about
* DF Alg - refers to Designated Forwarder Election
Algorithm. This is sometimes shortened to “Alg” in this document.
Alternatively consider always using the term DF Alg, or if you want to save
space use something like DFA in the text.
[jorge] I took your text, thx
==========
3. EVPN BGP Attributes Extensions
This solution reuses and extends the DF Election Extended Community
defined in [RFC8584] that is advertised along with the ES route:
SB> I think you need some text of the form: by replacing the last two reserved
octets of the DF EEC when the DF Alg is set to Alg TBD.
[jorge] added
SB> RFC8584 does not specify the value of the the reserved fields, and how they
are to be processed. All the notation RSV/Reserved is unclear if this concerns
just bits 16..18 or bits 16..18 and bits 40..63. Perhaps you need to use this
text to update RFC 8584.
[jorge] I added this:
“When DF Alg is set to Highest-Preference or Lowest-Preference algorithm, the value of the RSV and Reserved fields (from bit 16 to bit 18, and from bit 40
to 47) are set to zero when advertising the Ethernet Segment route and they are ignored when receiving the Ethernet Segment route.”
[jorge] In a nutshell, RFC8584 implicitly ignores the RSV/Reserved bits for the algorithms that defines, and says other Algs may repurpose them.. I don’t think
we should update RFC8584, but happy to discuss with the WG.
==========
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
SB> Where is the semantics of Bit 0 defined for Alg 2?
[jorge] hmm.. not sure if I understand. I added this:
“The procedures of the "Don't Preempt" capability for DF Alg 2 and TBD are described in section 4.4"
* Bit 0 (corresponds to Bit 24 of the DF Election Extended Community
and it is defined by this document): 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 DF Alg [RFC7432]. The DP
capability is supported by Alg 2 and Alg TBD, and MAY be used with
DF Alg 0 or 1. The procedures of the DP capability for DF Alg 0
or 1 are out of the scope of this document.
SB>I am confused by the following text.
SB> I think that you need to explain more clearly what behaviour is defined in
RFC8584 and continues here, what behaviour has changed and what new behaviour
is introduced. Also, where is Alg2 defined.
[jorge] noted. I changed the entire section, let me know if addresses your concerns.
* Bit 1: AC-DF or AC-Influenced DF Election, as explained in
[RFC8584]. When set to 1, it indicates the desire to use AC-
Influenced DF Election with the rest of the PEs in the ES. The
AC-DF capability bit MAY be set along with the DP capability and
DF Alg 2 or Alg TBD.
- DF Preference (defined in this document): defines a 2-octet
value that indicates the PE preference to become the DF in the
ES. The allowed values are within the range 0-65535, and the
default value MUST be 32767. This value is the midpoint in the
allowed Preference range of values, which gives the operator
the flexibility of choosing a significant number of values,
above or below the default Preference. The DF Preference field
is specific to DF Alg 2 and DF Alg TBD, and does not represent
any Preference value for other Algs. If the DF Alg is
different than Alg 2 or Alg TBD, these two octets can be
encoded differently.
SB> The last sentence is confusing and I think redundant. Those octets are
defined for the case Alg2 and Alg TBD, but clearly the are not defined for
anything that precedes this design and any future design is free to give them
new semantics. SB> As far as I can see the text has not said whether 0 is more
preferred than 65535 or the other way about.
[jorge] the new text addressing your comments follow:
-
Designated Forwarder (DF) Preference (described in this document): defines a 2-octet value that indicates the PE preference to become the Designated Forwarder in the Ethernet Segment, as described in Section
4.1 and Section 4.2. The allowed values are within the range 0-65535, and the default value MUST be 32767. This value is the midpoint in the allowed Preference range of values, which gives the operator the flexibility of choosing a significant number of values,
above or below the default Preference. A numerically higher or lower value of this field is more preferred for Designated Forwarder election depending on the DF Alg being used, as explained in Section 4.1 and Section 4.2. The Designated Forwarder Preference
field is specific to DF Algs Highest-Preference and Lowest-Preference, and this document does not define any meaning for other algorithms. If the DF Alg is different from Highest-Preference or Lowest-Preference, these two octets can be encoded differently.
============
a. vES1 and vES2 are now configurable with three optional parameters
that are signaled in the DF Election extended community. These
parameters are the Preference, Preemption option (or "Don't
Preempt Me" option) and DF Alg. We will represent these
parameters as (Pref,DP,Alg). Let's assume vES1 is configured as
(500,0,Highest-Pref) in PE1, and (255,0,Highest-Pref) in PE2.
SB> Where does the 0 come from in your notation?
[jorge] it is the DP capability bit. I added this to clarify:
“Let's assume vES1 (Pref,DP,Alg) is configured as (500,0,Highest-Preference) in PE1,…”
========
c. According to [RFC8584], each PE will run the DF election
algorithm upon expiration of the DF Wait timer. In this case,
each PE runs the Highest-Preference DF Alg for each ES as
follows:
* The PE will check the DF Alg value in each ES route, and
assuming all the ES routes are consistent in this DF Alg and
the value is 2 (Highest-Preference), the PE will run the
procedure in this section. Otherwise, the procedure will fall
back to [RFC7432] Default Alg.
SB> I think that it is confusing to use packet identifier values (2) rather
than the name of the identifier value.
[jorge] changed.
===========
d. Assuming some maintenance tasks had to be executed on, E.g., PE3,
the operator could set vES2's Preference to E.g., 50 so that PE2
is forced to take over as DF for vES2 (irrespective of the DP
capability). Once the maintenance task on PE3 is over, the
operator could decide to leave the existing preference or
configure the old preference back.
SB> On which PE does the advertisement change?
[jorge] on PE3. I modified the text to clarify.
e. In case of equal Preference in two or more PEs in the ES, the DP
bit and the lowest IP of the candidate PEs are used as tie-
breakers.
SB> That is the lowest IP address I assume. That is easy on IPv4. Are there any
issues with doing this in IPv6?
[jorge] the only issue is in the case there are PEs with originating router’s ip addresses of different families. In this case I added this:
“…The PE's IP address is the address used in the candidate list and it is derived from the Originating Router's IP address of the Ethernet
Segment route. In case PEs use Originating Router's IP address of different families, an IPv4 address is always considered numerically lower than an IPv6 address…”
After selecting the PEs with the highest Preference
value, an implementation MUST first select the PE advertising the
DP bit set, and then select the PE with the lowest IP address (if
the DP bit selection does not yield a unique candidate).
SB> Of perhaps more intuitively if more that one PE is advertising itself as
the preferred forwarder.
[jorge] added
The
PE's IP address is the address used in the candidate list and it
is derived from the Originating Router's IP address of the ES
route. Some examples of the use of the DP bit and IP address
tie-breakers follow:
* If vES1 parameters were (500,0,Highest-Pref) in PE1 and
(500,1,Highest-Pref) in PE2, PE2 would be elected due to the
DP bit.
* If vES1 parameters were (500,0,Highest-Pref) in PE1 and
(500,0,Highest-Pref) in PE2, PE1 would be elected, assuming
SB> s/assuming/if/
SB> Although it might be better to describe both cases.
PE1's IP address is lower than PE2's.
[jorge] I took both suggestions.
f. The Preference is an administrative option that MUST be
configured on a per-ES basis from the management plane, but MAY
also be dynamically changed based on the use of local policies.
SB> It is confusing to jump from the global statement above direct to a number
example without explaining first what is happening.
[jorge] I modify the text to address this comment. Please let me know if it reads better.
For 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 could happen if e.g. the 2-port LAG between PE1 and the
Aggregation Network loses one port). Policies MAY also trigger
dynamic Preference changes based on the PE's bandwidth
availability in the core, specific ports going operationally
down, etc. The definition of the actual local policies is out of
scope of this document. The default Preference value is 32767.
===========
4.2. Use of the Lowest-Preference Algorithm
In addition to the Highest-Preference Alg described in Section 4.1
this document defines the Lowest-Preference Alg.
SB> I think that it would be clearer to describe the section algorithm as the
generic selection algorithm rather than binding it to HP and then have this
almost “dummy” section.
[jorge] ok, done.
In this case, and
using the example of vES1 in Figure 3, if the Lowest-Preference Alg
is configured in all the PEs in the ES, PE2 will be the DF due to its
lower Preference.
SB> I can see why you might have an HP choice, but you should explain use case
for the lowest preference. Indeed since this text introduces both it would be
useful to see text explaining why one is chosen over the other.
[jorge] both can be used, it’s the operator’s choice. I added some text to reflect that.
===========
* In addition, assuming VLAN-based service interfaces and that the
PEs are attached to all Ethernet Tags in the range 1-4000, both
PE1 and PE2 will be configured with (Ethernet Tag-range,low),
E.g., (2001-4000, low).
SB> I think that this needs to be described in general terms first and then the
case study included.
[jorge] done. Please let us know if it reads better.
==========
4.4. The Non-Revertive Capability
As discussed in Section 1.2 (d), a capability to NOT preempt the
existing DF (for all the Ethernet Tags in the ES) is required and
therefore added to the DF Election extended community. This option
will allow a non-revertive behavior in the DF election.
Note that, when a given PE in an ES is taken down for maintenance
operations, before bringing it back, the Preference may be changed in
order to provide a non-revertive behavior.
SB> Doesn’t this result in long term instability/inconsistency in the network
configuration if you change the value each time you do maintenance?
[jorge] from what I’ve seen, some people would change the preference on the PE under maintenance mode to give up the DF state, and then if that PE reboots,
it won’t affect the CE in the Ethernet Segment. Some operators want to change back the preference so that the PE becomes DF again and if so, they usually do it in maintenance windows to avoid impact.
========
1. A "Don't Preempt Me" capability is defined on a per-PE/per-ES
basis, as described in Section 3. If "Don't Preempt Me" is
disabled (default behavior), the advertised DP bit will be 0.
SB> I feel that it is better to talk about bit states in terms of semantics
rather than binary values like 0 and 1.
[jorge] changed
If
"Don't Preempt Me" is enabled, the ES route will be advertised
with DP=1 ("Don't Preempt Me"). All the PEs in an ES SHOULD be
consistent in their configuration of the DP capability, however
this document does not enforce the consistency across all the
PEs. In case of inconsistency in the support of the DP
capability in the PEs of the same ES, non-revertive behavior is
not guaranteed. However, PEs supporting this capability will
still attempt this procedure.
===========
5. Security Considerations
This document describes a DF Election Algorithm that provides
absolute control (by configuration) over what PE is the DF for a
given Ethernet Tag. While this control is desired in many situations,
a malicious user that gets access to the configuration of a PE in the
ES may change the behavior of the network. In other DF Algs such as
HRW, the DF Election is more automated and cannot be determined by
configuration.
The non-revertive capability described in this document may be seen
as a security improvement over the regular EVPN revertive DF
Election: an intentional link (or node) "flapping" on a PE will only
cause service disruption once, when the PE goes to NDF state.
SB> What is NDF?
[jorge] non-Designated Forwarder. I expanded it.
The document also describes how a local policy can override the
Highest-Preference Alg for a range of Ethernet Tags in the ES. If
the local policy is not consistent across all PEs in the ES and there
is an Ethernet Tag that ends up with an inconsistent use of Highest-
Preference or Lowest-Preference in different PEs, black-holing or
packet duplication may occur for that Ethernet Tag.
SB> There may be some security considerations that need to be taken into
account when you manipulate parameters in the middle of mainatance as is
proposed in the text.
[jorge] Added: “With Highest-Preference or Lowest-Preference as DF Alg, an attacker may change the configuration of the Preference value on a PE and Ethernet
Segment, and impact the traffic going through that PE and Ethernet Segment.”
======
6. IANA Considerations
SB> It helps everyone if you specify the namespace (Border Gateway Protocol
(BGP) Extended Communities) and then the registry and then set out your request
just like it would appear in the registry itself:
Bit Name Ref
2 Highest Preference This RFC
Etc
[jorge] done
This document solicits the allocation of the following values:
* DF Alg = 2 in the [RFC8584] "DF Alg" registry, with name "Highest-
Preference Algorithm".
* DF Alg = TBD in the same "DF Alg" registry, with name "Lowest-
Preference Algorithm".
* Bit 0 in the [RFC8584] DF Election Capabilities registry, with
name "D (Don't Preempt) Capability" for Non-revertive ES.
========
