Framework for Ethernet VPN Designated Forwarder Election Extensibility
draft-ietf-bess-evpn-df-election-framework-09
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2019-04-22
|
09 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2019-04-15
|
09 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2019-04-11
|
09 | (System) | RFC Editor state changed to RFC-EDITOR from AUTH |
2019-04-08
|
09 | (System) | RFC Editor state changed to AUTH from EDIT |
2019-02-05
|
09 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2019-02-04
|
09 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2019-02-04
|
09 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2019-02-01
|
09 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2019-01-25
|
09 | (System) | RFC Editor state changed to EDIT |
2019-01-25
|
09 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2019-01-25
|
09 | (System) | Announcement was received by RFC Editor |
2019-01-25
|
09 | (System) | IANA Action state changed to In Progress |
2019-01-25
|
09 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2019-01-25
|
09 | Amy Vezza | IESG has approved the document |
2019-01-25
|
09 | Amy Vezza | Closed "Approve" ballot |
2019-01-25
|
09 | Martin Vigoureux | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2019-01-25
|
09 | Martin Vigoureux | Ballot approval text was generated |
2019-01-24
|
09 | Benjamin Kaduk | [Ballot comment] Thank you for resolving my DISCUSS (and COMMENT) points! |
2019-01-24
|
09 | Benjamin Kaduk | [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from Discuss |
2019-01-24
|
09 | Jorge Rabadan | New version available: draft-ietf-bess-evpn-df-election-framework-09.txt |
2019-01-24
|
09 | (System) | New version approved |
2019-01-24
|
09 | (System) | Request for posting confirmation emailed to previous authors: Kiran Nagaraj , Senthil Sathappan , John Drake , Jorge Rabadan , " satyamoh@cisco.com" , Ali … Request for posting confirmation emailed to previous authors: Kiran Nagaraj , Senthil Sathappan , John Drake , Jorge Rabadan , " satyamoh@cisco.com" , Ali Sajassi |
2019-01-24
|
09 | Jorge Rabadan | Uploaded new revision |
2019-01-21
|
08 | Martin Vigoureux | Ballot approval text was generated |
2019-01-18
|
08 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2019-01-18
|
08 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2019-01-18
|
08 | Jorge Rabadan | New version available: draft-ietf-bess-evpn-df-election-framework-08.txt |
2019-01-18
|
08 | (System) | New version approved |
2019-01-18
|
08 | (System) | Request for posting confirmation emailed to previous authors: Kiran Nagaraj , Senthil Sathappan , John Drake , Jorge Rabadan , " satyamoh@cisco.com" , Ali … Request for posting confirmation emailed to previous authors: Kiran Nagaraj , Senthil Sathappan , John Drake , Jorge Rabadan , " satyamoh@cisco.com" , Ali Sajassi |
2019-01-18
|
08 | Jorge Rabadan | Uploaded new revision |
2019-01-10
|
07 | Benjamin Kaduk | [Ballot discuss] It's not really clear to me that the question of Updating 7432 has been settled by the responses to the directorate reviews; I've … [Ballot discuss] It's not really clear to me that the question of Updating 7432 has been settled by the responses to the directorate reviews; I've noted a few places in the text that are problematic in this regard, in the COMMENT section. [concerns about combinatoric explosion were overblown; removed] Section 3.3 Section 7.6 of [RFC7432] describes how the value of the ES-Import Route Target for ESI types 1, 2, and 3 can be auto-derived by using the high-order six bytes of the nine byte ESI value. The same auto- derivation procedure can be extended to ESI types 0, 4, and 5 as long as it is ensured that the auto-derived values for ES-Import RT among different ES types don't overlap. How do I ensure that the auto-derived values don't overlap? Section 4.2 The ESI value MAY be set to all 0's in the Weight function below if the operator so chooses. I'm not 100% sure I'm interpreting this correctly, but this sounds like a piece of device-specific configuration (i.e., configured by the operator) that must be the same across all devices for correct operation, but is not covered by the advertisement of the DF Election Exctended Community. This would decrease the robustness of the system to basically the "experimental" level of DF election algorithm 31, which also relies on universal agreement of manual configuration. Is this actually something we want to include? Section 5 The AC-DF capability MAY be used with any "DF Alg" algorithm. It MUST As written, this suggests that it is true for any current or future algorithm, which is in conflict with the text in Section 3.2 that notes that "for any new DF Alg defined in future, its applicability/compatibility to the existing capabilities must be assessed on a case by case basis." It seems more prudent to make the assessment after the relevant technologies are both extant, so I would suggest this be non-normative text, perhaps "the AC-DF capability is expected to be of general applicability with any future 'DF Alg' algorithm". |
2019-01-10
|
07 | Benjamin Kaduk | Ballot discuss text updated for Benjamin Kaduk |
2019-01-10
|
07 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2019-01-10
|
07 | Ignas Bagdonas | [Ballot comment] Thank you for the document - it addresses the real deployment problems encountered in the field. |
2019-01-10
|
07 | Ignas Bagdonas | [Ballot Position Update] New position, No Objection, has been recorded for Ignas Bagdonas |
2019-01-10
|
07 | Mirja Kühlewind | [Ballot comment] First one minor editorial comment: Sec 3.2 "Otherwise if even a single advertisement for the type-4 route is not received … [Ballot comment] First one minor editorial comment: Sec 3.2 "Otherwise if even a single advertisement for the type-4 route is not received with the locally configured DF Alg and capability, the Default DF Election algorithm (modulus) algorithm MUST be used as in [RFC7432]." I believe you meant a single advertisement is received without the configured DF Alg and capability (or a different one I guess), and not that the advertisement is not received at all (because that might be hard to check), right? Maybe you can rephrase this sentence a bit to make the intention more clear! However, think about this further, I wondering if there is something here that such be discussed in the security considerations, e.g. how easy would it be for an attacker to disturb the algo selection and cause a fallback to the default scheme...? |
2019-01-10
|
07 | Mirja Kühlewind | [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind |
2019-01-09
|
07 | Adam Roach | [Ballot comment] I have one minor comment that the authors may wish to consider. §1.2.1: > It is well-known that for good > hash distribution … [Ballot comment] I have one minor comment that the authors may wish to consider. §1.2.1: > It is well-known that for good > hash distribution using the modulus operation, the modulus N should > be a prime-number not too close to a power of 2 [CLRS2009]. I suppose this refers to the explanation in [CLRS2009] §11.3.1. The description there is pretty hand-wavy and not completely accurate except under certain (admittedly common) conditions -- in which this case is not included. You may wish to consider instead citing "The Art of Computer Programming (Vol. 3)" by Knuth, as it captures a lot more of the nuance behind why this rule of thumb is frequently true, and covers the general case. There is probably a set of considerations to take into account for Ethernet Tags with an even distribution, but only because you have a relatively small set of potential inputs -- not for any of the reasons cited in [CLRS2009]. Quoting Knuth: In general, we want to avoid values of M that divide r^k+a or r^k−a, where k and a are small numbers and r is the radix of the alphabetic character set (usually r=64, 256 or 100), since a remainder modulo such a value of M tends to be largely a simple superposition of key digits. Such considerations suggest that we choose M to be a prime number such that r^k!=a(modulo)M or r^k!=−a(modulo)M for small k & a. I see that Benjamin has made a related comment. I share his objection to the way point #2 is phrased, and think it needs to be reworded to properly capture the subtleties implied by the preceding passage. |
2019-01-09
|
07 | Adam Roach | [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach |
2019-01-09
|
07 | Suresh Krishnan | [Ballot comment] Given the drawbacks this document mentions regarding the default DF election algorithm defined in RFC7432, I also think it would be better … [Ballot comment] Given the drawbacks this document mentions regarding the default DF election algorithm defined in RFC7432, I also think it would be better for this document to update RFC7432 so that implementers are aware that there are better alternatives out there. * Section 3.2: Who actually advertises Type 0 in the DF Alg field given that the legacy RFC7432 implementations do not use this extended community at all? |
2019-01-09
|
07 | Suresh Krishnan | [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan |
2019-01-09
|
07 | Ben Campbell | [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell |
2019-01-09
|
07 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2019-01-09
|
07 | Deborah Brungard | [Ballot comment] I can be swayed either way on the update discussion. I usually prefer to be conservative with using "update" so the reader of … [Ballot comment] I can be swayed either way on the update discussion. I usually prefer to be conservative with using "update" so the reader of the original RFC does not have to parse many updates to understand what is applicable when implementing the original RFC. While others view it as applying to the new RFC and its relationship with the original. What's important (to me) is to clearly describe the update in the abstract for the reader to decide to read or not. |
2019-01-09
|
07 | Deborah Brungard | Ballot comment text updated for Deborah Brungard |
2019-01-09
|
07 | Deborah Brungard | [Ballot comment] I can be swayed either way on the update discussion. I usually prefer to be conservative with using "update" so the reader of … [Ballot comment] I can be swayed either way on the update discussion. I usually prefer to be conservative with using "update" so the reader of the original RFC does not have to parse many updates to understand what is applicable when implementing the original RFC. While others view it as applying to the new RFC and its relationship with the original. What's important (to me) is to clearly describe the update in the abstract for the reader to decide to read or not. |
2019-01-09
|
07 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2019-01-09
|
07 | Warren Kumari | [Ballot comment] Thanks to Benjamin for the thorough review - he covered many of the items I was going to ask. Unfortunately this leaves me … [Ballot comment] Thanks to Benjamin for the thorough review - he covered many of the items I was going to ask. Unfortunately this leaves me with only nits to contribute: "The default algorithm for DF election defined by [RFC7432] at the granularity of (ESI,EVI) ..." - EVI is not expanded on first use (and it would be easier for the reader than having to go read 7432 just to expand an acronym). "Note that while [RFC7432] elects a DF per , this document elects a DF per ." -- same. Just as an edit: I noticed that the Shepherd writeup mentioned that one of the contributors hasn't ACKed the IPR question - not sure if that is still the case. |
2019-01-09
|
07 | Warren Kumari | Ballot comment text updated for Warren Kumari |
2019-01-09
|
07 | Warren Kumari | [Ballot comment] Thanks to Benjamin for the thorough review - he covered many of the items I was going to ask. Unfortunately this leaves me … [Ballot comment] Thanks to Benjamin for the thorough review - he covered many of the items I was going to ask. Unfortunately this leaves me with only nits to contribute: "The default algorithm for DF election defined by [RFC7432] at the granularity of (ESI,EVI) ..." - EVI is not expanded on first use (and it would be easier for the reader than having to go read 7432 just to expand an acronym). "Note that while [RFC7432] elects a DF per , this document elects a DF per ." -- same. |
2019-01-09
|
07 | Warren Kumari | [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari |
2019-01-09
|
07 | Alexey Melnikov | [Ballot comment] 1.2.2. Traffic Black-Holing on Individual AC Failures As discussed in section 2.1 the Default DF Election algorithm defined by [RFC7432 … [Ballot comment] 1.2.2. Traffic Black-Holing on Individual AC Failures As discussed in section 2.1 the Default DF Election algorithm defined by [RFC7432] takes into account only two variables in the modulus function for a given ES: the existence of the PE's IP address on the candidate list and the locally provisioned Ethernet Tags. This document doesn't have section 2.1. 1.3. The Need for Extending the Default DF Election in EVPN Section 2.2 describes some of the issues that exist in the Default DF Election procedures. In order to address those issues, this document This document doesn't have section 2.2 either. |
2019-01-09
|
07 | Alexey Melnikov | [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov |
2019-01-09
|
07 | Alissa Cooper | [Ballot comment] I know there has already been a bunch of discussion about whether this document should formally update RFC 7432. I wanted to … [Ballot comment] I know there has already been a bunch of discussion about whether this document should formally update RFC 7432. I wanted to ask specifically about Section 3.1. I may be completely misunderstanding this since I did not give RFC 7432 a thorough read, but it appears as though Section 3.1 specifically articulates details applicable to RFC 7432 (independent of what this draft specifies in 3.2 and later sections) that were not included in that RFC. That seems like it warrants the "Updates" relationship, because then people reading RFC 7432 in the future will know to look at this document for updates, and can at least find the FSM and its description there. There is not consensus about what "Updates" means (as evidenced by recent discussion instigated by the IESG [1]) and I don't think this is worth dying on a hill over, just wanted to raise that specifically in case people hadn't considered it. The introduction of this document is unusually long (more than a third of the substantive content of the document). You might consider having 1.1 start a new section rather than having 1.1, 1.2, and 1.3 be subsections of the introduction. [1] https://mailarchive.ietf.org/arch/msg/ietf/-1u_1-peHKAmUDuLyGAJYu0fPCE |
2019-01-09
|
07 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2019-01-08
|
07 | Alvaro Retana | [Ballot comment] (0) Some of my comments are related to Benjamin's DISCUSS. (1) The FSM in §3.1 applies to rfc7432, the introductory text (in … [Ballot comment] (0) Some of my comments are related to Benjamin's DISCUSS. (1) The FSM in §3.1 applies to rfc7432, the introductory text (in that section) says as much, and even the text in §1 calls it "a formal definition and clarification". I understand that the new procedures are not intended to update rfc7432 (which is fine), but the fact that this document says that an "implementation MUST comply with a behavior equivalent to the one outlined in this FSM" seems like an Update to rfc7432 to me. Note that the Update can, and should, be qualified in the Abstract/Introduction, so you can explicitly indicate what is being Updated and what isn't. (2) The MAYs in this paragraph (§1.3) are not needed because they are used to state a fact: o HRW and AC-DF mechanisms are independent of each other. Therefore, a PE MAY support either HRW or AC-DF independently or MAY support both of them together. A PE MAY also support AC-DF capability along with the Default DF election algorithm per [RFC7432]. (3) "Only one DF Election Extended Community can be sent..." What should a receiver do if more than one community is received? (4) §3.2 -- I'm confused about this text: - DF Algs 0 and 1 can be both used with bit AC-DF set to 0 or 1. - In general, a specific DF Alg MAY determine the use of the reserved bits in the Extended Community, which may be used in a different way for a different DF Alg. (a) This text is assigning a function to the "reserved bits", so they are really not reserved. The description should be updated (from "Reserved bits for future use") to reflect that their interpretation depends on the DF Alg. (b) Form that text, what I get is that a new algorithm can define the meaning of the bits. Is that correct? If so, (1) s/a specific DF Alg MAY determine the use/a specific DF Alg MUST/SHOULD determine the use ...and... (2) for DF Algs 0 and 1, what happens if any of the other bits are set? (5) §3.2: "if even a single advertisement for the type-4 route is not received with the locally configured DF Alg and capability, the Default DF Election algorithm (modulus) algorithm MUST be used" Given that the PEs advertise only their preferred algorithm/capability, it is possible that it also supports other algorithm/capability combinations, which may have been advertised. I assume that it is up to the implementation if they want to update their advertisement. Do you want to say anything about this? Are there potential downsides to an implementation changing their preferred combination? (6) The HRW1999 reference must be Normative. (7) [nit] There are a couple of references to other sections on this document that don't exist: §1.2.2 points to section 2.1, §1.3 to 2.2... |
2019-01-08
|
07 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2019-01-08
|
07 | Benjamin Kaduk | [Ballot discuss] It's not really clear to me that the question of Updating 7432 has been settled by the responses to the directorate reviews; I've … [Ballot discuss] It's not really clear to me that the question of Updating 7432 has been settled by the responses to the directorate reviews; I've noted a few places in the text that are problematic in this regard, in the COMMENT section. I'm a little worried that we're setting future extensions up for a combinatoric explosion of required analysis, by requiring new capabilities and DF algorithms to determine their applicability/compatibility with all previously defined mechanisms of the other type. But maybe there's some easy math to show that it won't be too bad. Let's have a discussion about this topic, even if we don't end up needing to make any changes to the document as a result. (I do note that this explosion would not really happen if we combined the two into a single enumerated codepoint space that combines DF algorithm with the enablement state of all then-defined feature flags.) Wection 3.3 Section 7.6 of [RFC7432] describes how the value of the ES-Import Route Target for ESI types 1, 2, and 3 can be auto-derived by using the high-order six bytes of the nine byte ESI value. The same auto- derivation procedure can be extended to ESI types 0, 4, and 5 as long as it is ensured that the auto-derived values for ES-Import RT among different ES types don't overlap. How do I ensure that the auto-derived values don't overlap? Section 4.2 The ESI value MAY be set to all 0's in the Weight function below if the operator so chooses. I'm not 100% sure I'm interpreting this correctly, but this sounds like a piece of device-specific configuration (i.e., configured by the operator) that must be the same across all devices for correct operation, but is not covered by the advertisement of the DF Election Exctended Community. This would decrease the robustness of the system to basically the "experimental" level of DF election algorithm 31, which also relies on universal agreement of manual configuration. Is this actually something we want to include? Section 5 The AC-DF capability MAY be used with any "DF Alg" algorithm. It MUST As written, this suggests that it is true for any current or future algorithm, which is in conflict with the text in Section 3.2 that notes that "for any new DF Alg defined in future, its applicability/compatibility to the existing capabilities must be assessed on a case by case basis." It seems more prudent to make the assessment after the relevant technologies are both extant, so I would suggest this be non-normative text, perhaps "the AC-DF capability is expected to be of general applicability with any future 'DF Alg' algorithm". |
2019-01-08
|
07 | Benjamin Kaduk | [Ballot comment] Section 1.2.1 I a little bit wonder if the risk of poor distribution of DFs with the default algorithm is being oversold -- … [Ballot comment] Section 1.2.1 I a little bit wonder if the risk of poor distribution of DFs with the default algorithm is being oversold -- any "hash identifiers into buckets" scheme will be susceptible to pessimal input, but if the inputs are not attacker-controlled and the pessimal inputs are unlikely to occur randomly, we may not need to care. 2- Even in the case when the Ethernet Tag distribution is uniform the instance of a PE being up or down results in re-computation ((v mod N-1) or (v mod N+1) as is the case); the resulting modulus value need not be uniformly distributed because it can be subject to the primality of N-1 or N+1 as may be the case. This is making some assumptions about the (potential) distribution of the tag values that could be made more clear, as otherwise the primality is not particularly relevant (particularly for an actual uniform distribution that covers all possible values). Similarly below, by the CLRS reference (CLRS probably has the ability to assume that we're running on binary computers and may even be doing things like operating on pointers, which tend to have fixed structure in the low-order bits due to alignment considerations, etc. For these (human-allocated?) integer identifiers it's less clear what assumptions should come into play.) Section 1.3 Section 2.2 describes some of the issues that exist in the Default DF There is no section 2.2; presumably this is supposed to be 1.2. o HRW and AC-DF mechanisms are independent of each other. Therefore, a PE MAY support either HRW or AC-DF independently or MAY support both of them together. A PE MAY also support AC-DF capability along with the Default DF election algorithm per [RFC7432]. This seems a little confusing since just a couple paragraphs ago you are distinguishing between "election algorithms" and "capabilities", but here the two new things (one of each type) are lumped together as "mechanisms". If election algorithms and capabilities are inherently independent things, then maybe there is not a need to reiterate the independence of HRW and AC-DF here. Section 3 This section describes the BGP extensions required to support the new DF Election procedures. In addition, since the EVPN specification [RFC7432] does leave several questions open as to the precise final state machine behavior of the DF election, section 3.1 describes precisely the intended behavior. This text sounds like we should be Update:ing 7432. Section 3.2 - Otherwise if even a single advertisement for the type-4 route is not received with the locally configured DF Alg and capability, nit: shouldn't this be "received without"? Section 3.2.1 [RFC7432] implementations (i.e., those that predate this specification) will not advertise the DF Election Extended Community. This wording also suggests that we should be Update:ing 7432. Section 4 I note that the state of the art in non-cryptographic fast hashing has improved a lot since 1998 and we have things like the Jenkins hash that are supposed to be superior to CRC-32 and such. [HRW1999] provides pseudo-random functions based on the Unix utilities rand and srand and easily constructed XOR functions that perform considerably well. This imparts very good properties in the load balancing context. Also each server independently and unambiguously arrives at the primary server selection. [...] It's not really clear to me that this text adds much value -- we go on later to say that we explicitly use a Wrand() function from HRW1999. Section 4.2 1. DF(v) = Si: Weight(v, Es, Si) >= Weight(v, Es, Sj), for all j. In case of a tie, choose the PE whose IP address is numerically the least. Note 0 <= i,j < Number of PEs in the redundancy group. I strongly suggest expanding out the notation with more words, e.g. "DF(v) is defined to be the address Si such that [...]". We probably shouldn't assume much abstract math background from RFC readership. (Similarly for BDF(v). The BDF(v) expression doesn't even say what the i, j, and k are evaluated over.) HRW solves the disadvantages pointed out in Section 2.2.1 and ensures: Again, this is now Section 1.2.1 o More importantly it avoids the needless disruption case of Section 2.2.1 (3), that is inherent in the existing Default DF Election. and here. (Also, this bullet point is just describing the same situation as the previous one, if I understand correctly.) Section 5 modify the DF Election procedures by removing from consideration any candidate PE in the ES that cannot forward traffic on the AC that belongs to the BD. [...] What guarantees that the ACS information is available on all PEs involved in the election? In particular, when used with the Default DF Alg, the AC-DF capability modifies the Step 3 in the DF Election procedure described in [RFC7432] Section 8.5, as follows: Only a single paragraph follows, but the referenced document has three paragraphs in the indicated step. Are the last two paragraphs no longer intended to apply? In particular, if we apply this paragraph as a direct replacement for the RFC 7432 step 3, then there is no longer a normative description of the modulus-based algorithm, which seems incorrect. Also, there's a lot of style/editorial changes, that make the difference in behavior harder to read from the diff. (Side note: I don't think this particular text implies that this document needs an Updates: relation to RFC 7432, since it is a behavior change conditional on the use of a negotiated feature.) a) When PE1 and PE2 discover ES12, they advertise an ES route for ES12 with the associated ES-import extended community and the DF Election Extended Community indicating AC-DF=1; they start a timer at the same time. [...] (nit?) This text implies some synchronization between PE1 and PE2 for starting the timer, whereas I think the intent is just to note that they each start a timer as they advertise the route, independently of each other. In addition to the events defined in the FSM in Section 3.1, the following events SHALL modify the candidate PE list and trigger the DF re-election in a PE for a given or . In the FSM of Figure 3, the events below MUST trigger a transition from DF_DONE to DF_CALC: Then why are they not listed as part of the referenced FSM (or at least mentioned with a forward-reference)? Section 7 Are there any considerations to discuss about increased resource consumption (e.g., for storing and transmiting Ethernet A-Ds per- vs. per-) and the risk of DoS due to reaching resource caps? Note that the network will not benefit of the new procedures if the configuration of one of the PEs in the ES is changed to the Default [RFC7432] DF Election. Isn't this the case if there is not unanimity among all PEs in the ES about what election algorithm is preferred, which is a broader possible case than one being changed to use the default algorithms? Section 8 o Allocate Sub-Type value 0x06 in the "EVPN Extended Community Sub- Types" registry defined in [RFC7153] as follows: Sometimes we see language about "confirm the existing early allocation", but I assume that the RFC Editor and IANA have a standard way of sorting this stuff out. |
2019-01-08
|
07 | Benjamin Kaduk | [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk |
2019-01-07
|
07 | Francesca Palombini | Request for Telechat review by GENART Completed: Ready. Reviewer: Francesca Palombini. |
2019-01-03
|
07 | (System) | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2018-12-27
|
07 | Jean Mahoney | Request for Telechat review by GENART is assigned to Francesca Palombini |
2018-12-27
|
07 | Jean Mahoney | Request for Telechat review by GENART is assigned to Francesca Palombini |
2018-12-21
|
07 | Amy Vezza | Placed on agenda for telechat - 2019-01-10 |
2018-12-21
|
07 | Martin Vigoureux | IESG state changed to IESG Evaluation from Waiting for Writeup |
2018-12-21
|
07 | Martin Vigoureux | Ballot has been issued |
2018-12-21
|
07 | Martin Vigoureux | [Ballot Position Update] New position, Yes, has been recorded for Martin Vigoureux |
2018-12-21
|
07 | Martin Vigoureux | Created "Approve" ballot |
2018-12-21
|
07 | Martin Vigoureux | Ballot writeup was changed |
2018-12-20
|
07 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2018-12-20
|
07 | Jorge Rabadan | New version available: draft-ietf-bess-evpn-df-election-framework-07.txt |
2018-12-20
|
07 | (System) | New version approved |
2018-12-20
|
07 | (System) | Request for posting confirmation emailed to previous authors: Kiran Nagaraj , Senthil Sathappan , John Drake , Jorge Rabadan , " satyamoh@cisco.com" , Ali … Request for posting confirmation emailed to previous authors: Kiran Nagaraj , Senthil Sathappan , John Drake , Jorge Rabadan , " satyamoh@cisco.com" , Ali Sajassi |
2018-12-20
|
07 | Jorge Rabadan | Uploaded new revision |
2018-12-18
|
06 | (System) | IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed |
2018-12-18
|
06 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-bess-evpn-df-election-framework-06. If any part of this review is inaccurate, please let … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-bess-evpn-df-election-framework-06. If any part of this review is inaccurate, please let us know. The IANA Functions Operator understands that, upon approval of this document, there are three actions which we must complete. First, in the EVPN Extended Community Sub-Types registry on the Border Gateway Protocol (BGP) Extended Communities registry page located at: https://www.iana.org/assignments/bgp-extended-communities/ a single, new sub-type is to be registered as follows: Sub-Type Value: 0x06 Name: DF Election Extended Community Reference: [ RFC-to-be ] Date: [ TBD-at-Registration ] IANA notes that this registration is already complete through early registration. The existing registration will be made permanent and its reference changed to [ RFC-to-be ]. Second, a new registry is to be created called the DF Alg registry. The new registry will be located on the Border Gateway Protocol (BGP) Extended Communities registry page located at: https://www.iana.org/assignments/bgp-extended-communities/ New registrations will be managed via RFC Required as defined in RFC 8126. There are initial registrations in the new registry as follows: Alg Name Reference ---- -------------- ------------- 0 Default DF Election [ RFC-to-be ] 1 HRW algorithm [ RFC-to-be ] 2-30 Unassigned 31 Reserved for Experimental use [ RFC-to-be ] Third, a new registry is to be created called the DF Elections Capabilities registry. The new registry will be located on the Border Gateway Protocol (BGP) Extended Communities registry page located at: https://www.iana.org/assignments/bgp-extended-communities/ New registrations will be managed via RFC Required as defined in RFC 8126. There are initial registrations in the new registry as follows: Bit Name Reference ---- -------------- ------------- 0 Unassigned 1 AC-DF capability [ RFC-to-be ] 2-15 Unassigned The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed. Thank you, Sabrina Tanamal Senior IANA Services Specialist |
2018-12-18
|
06 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2018-12-14
|
06 | Francesca Palombini | Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Francesca Palombini. Sent review to list. |
2018-12-11
|
06 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Mehmet Ersue |
2018-12-11
|
06 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Mehmet Ersue |
2018-12-08
|
06 | Russ Housley | Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Russ Housley. Sent review to list. |
2018-12-07
|
06 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Russ Housley |
2018-12-07
|
06 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Russ Housley |
2018-12-07
|
06 | Adrian Farrel | Request for Last Call review by RTGDIR Completed: Has Nits. Reviewer: Adrian Farrel. Sent review to list. |
2018-12-06
|
06 | Jean Mahoney | Request for Last Call review by GENART is assigned to Francesca Palombini |
2018-12-06
|
06 | Jean Mahoney | Request for Last Call review by GENART is assigned to Francesca Palombini |
2018-12-06
|
06 | Min Ye | Request for Last Call review by RTGDIR is assigned to Adrian Farrel |
2018-12-06
|
06 | Min Ye | Request for Last Call review by RTGDIR is assigned to Adrian Farrel |
2018-12-05
|
06 | Min Ye | Request for Last Call review by RTGDIR is assigned to Papadimitriou Dimitri |
2018-12-05
|
06 | Min Ye | Request for Last Call review by RTGDIR is assigned to Papadimitriou Dimitri |
2018-12-05
|
06 | Martin Vigoureux | Requested Last Call review by RTGDIR |
2018-12-04
|
06 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2018-12-04
|
06 | Cindy Morgan | The following Last Call announcement was sent out (ends 2018-12-18): From: The IESG To: IETF-Announce CC: stephane.litkowski@orange.com, martin.vigoureux@nokia.com, draft-ietf-bess-evpn-df-election-framework@ietf.org, bess-chairs@ietf.org, bess@ietf.org … The following Last Call announcement was sent out (ends 2018-12-18): From: The IESG To: IETF-Announce CC: stephane.litkowski@orange.com, martin.vigoureux@nokia.com, draft-ietf-bess-evpn-df-election-framework@ietf.org, bess-chairs@ietf.org, bess@ietf.org, Stephane Litkowski Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Framework for EVPN Designated Forwarder Election Extensibility) to Proposed Standard The IESG has received a request from the BGP Enabled ServiceS WG (bess) to consider the following document: - 'Framework for EVPN Designated Forwarder Election Extensibility' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2018-12-18. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The Designated Forwarder (DF) in EVPN networks is the Provider Edge (PE) router responsible for sending broadcast, unknown unicast and multicast (BUM) traffic to a multi-homed Customer Equipment (CE) device, on a given VLAN on a particular Ethernet Segment (ES). The DF is selected out of a list of candidate PEs that advertise the same Ethernet Segment Identifier (ESI) to the EVPN network. By default, EVPN uses a DF Election algorithm referred to as "Service Carving" and it is based on a modulus function (V mod N) that takes the number of PEs in the ES (N) and the VLAN value (V) as input. This default DF Election algorithm has some inefficiencies that this document addresses by defining a new DF Election algorithm and a capability to influence the DF Election result for a VLAN, depending on the state of the associated Attachment Circuit (AC). In addition, this document creates a registry with IANA, for future DF Election Algorithms and Capabilities. It also presents a formal definition and clarification of the DF Election Finite State Machine. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-df-election-framework/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-df-election-framework/ballot/ No IPR declarations have been submitted directly on this I-D. |
2018-12-04
|
06 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2018-12-04
|
06 | Martin Vigoureux | Last call was requested |
2018-12-04
|
06 | Martin Vigoureux | Ballot approval text was generated |
2018-12-04
|
06 | Martin Vigoureux | Ballot writeup was generated |
2018-12-04
|
06 | Martin Vigoureux | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
2018-12-04
|
06 | Martin Vigoureux | Last call announcement was generated |
2018-12-04
|
06 | Jorge Rabadan | New version available: draft-ietf-bess-evpn-df-election-framework-06.txt |
2018-12-04
|
06 | (System) | New version approved |
2018-12-04
|
06 | (System) | Request for posting confirmation emailed to previous authors: Kiran Nagaraj , Senthil Sathappan , John Drake , Jorge Rabadan , " satyamoh@cisco.com" , Ali … Request for posting confirmation emailed to previous authors: Kiran Nagaraj , Senthil Sathappan , John Drake , Jorge Rabadan , " satyamoh@cisco.com" , Ali Sajassi |
2018-12-04
|
06 | Jorge Rabadan | Uploaded new revision |
2018-10-20
|
05 | Jorge Rabadan | New version available: draft-ietf-bess-evpn-df-election-framework-05.txt |
2018-10-20
|
05 | (System) | New version approved |
2018-10-20
|
05 | (System) | Request for posting confirmation emailed to previous authors: Kiran Nagaraj , Senthil Sathappan , John Drake , Jorge Rabadan , " satyamoh@cisco.com" , Ali … Request for posting confirmation emailed to previous authors: Kiran Nagaraj , Senthil Sathappan , John Drake , Jorge Rabadan , " satyamoh@cisco.com" , Ali Sajassi |
2018-10-20
|
05 | Jorge Rabadan | Uploaded new revision |
2018-10-19
|
04 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2018-10-19
|
04 | Jorge Rabadan | New version available: draft-ietf-bess-evpn-df-election-framework-04.txt |
2018-10-19
|
04 | (System) | New version approved |
2018-10-19
|
04 | (System) | Request for posting confirmation emailed to previous authors: Kiran Nagaraj , Senthil Sathappan , John Drake , Jorge Rabadan , " satyamoh@cisco.com" , Ali … Request for posting confirmation emailed to previous authors: Kiran Nagaraj , Senthil Sathappan , John Drake , Jorge Rabadan , " satyamoh@cisco.com" , Ali Sajassi |
2018-10-19
|
04 | Jorge Rabadan | Uploaded new revision |
2018-08-19
|
03 | Martin Vigoureux | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation |
2018-06-19
|
03 | Martin Vigoureux | IESG state changed to AD Evaluation from Publication Requested |
2018-05-24
|
03 | Stephane Litkowski | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Internet standard is requested. This makes sense as the document defines protocol extensions as well as behaviors that need interoperability. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Broadcast, Unknown an Multicast traffic forwarding requires the election of a designated forwarder (DF) is EVPN. RFC7432 defines an election procedure that does not cover all the use cases and may also cause some issues. This document defines a flexible framework that allows to negotiate the DF election algorithm to be used as well as some capabilities. This document also defines a new optional DF election algorithm as well as one capability which allows to recompute DF election based on an attachment circuit failure. Working Group Summary The document is coming from a merge of two documents. The merge was requested by the chairs during the WGLC of the two documents. There was no controversy about the content of the document. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? There is one implementation of HRW as well as one implementation of AC-DF. As the framework is new, these implementations may not be 100% compliant. Personnel Who is the Document Shepherd? Who is the Responsible Area Director? Stephane Litkowski is the document shepherd. Martin Vigoureux is the responsible AD. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The shepherd provided comments to the authors that have been addressed. The document is considered as ready. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. No (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. Yes for the author. One contributor (Keyur Patel) has not answered the IPR poll. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No IPR disclosed. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is a strong consensus from vendors and operators on this draft. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No (11) Identify any ID nits the Document Shepherd has found in this document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. No (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No (13) Have all references within this document been identified as either normative or informative? Yes There is one normative reference to HRW algorithm which is a research paper. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). The IANA section is well written (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. No (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. No |
2018-05-24
|
03 | Stephane Litkowski | Responsible AD changed to Martin Vigoureux |
2018-05-24
|
03 | Stephane Litkowski | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2018-05-24
|
03 | Stephane Litkowski | IESG state changed to Publication Requested |
2018-05-24
|
03 | Stephane Litkowski | IESG process started in state Publication Requested |
2018-05-24
|
03 | Stephane Litkowski | Intended Status changed to Proposed Standard from Internet Standard |
2018-05-24
|
03 | Stephane Litkowski | Changed consensus to Yes from Unknown |
2018-05-24
|
03 | Stephane Litkowski | Intended Status changed to Internet Standard from None |
2018-05-24
|
03 | Jorge Rabadan | New version available: draft-ietf-bess-evpn-df-election-framework-03.txt |
2018-05-24
|
03 | (System) | New version approved |
2018-05-24
|
03 | (System) | Request for posting confirmation emailed to previous authors: Kiran Nagaraj , Senthil Sathappan , John Drake , Jorge Rabadan , " satyamoh@cisco.com" , Ali … Request for posting confirmation emailed to previous authors: Kiran Nagaraj , Senthil Sathappan , John Drake , Jorge Rabadan , " satyamoh@cisco.com" , Ali Sajassi |
2018-05-24
|
03 | Jorge Rabadan | Uploaded new revision |
2018-05-24
|
02 | Stephane Litkowski | Changed document writeup |
2018-05-24
|
02 | Stephane Litkowski | Changed document writeup |
2018-05-24
|
02 | Stephane Litkowski | Changed document writeup |
2018-05-23
|
02 | Jorge Rabadan | New version available: draft-ietf-bess-evpn-df-election-framework-02.txt |
2018-05-23
|
02 | (System) | New version approved |
2018-05-23
|
02 | (System) | Request for posting confirmation emailed to previous authors: Kiran Nagaraj , Senthil Sathappan , bess-chairs@ietf.org, Jorge Rabadan , " satyamoh@cisco.com" , Ali Sajassi … Request for posting confirmation emailed to previous authors: Kiran Nagaraj , Senthil Sathappan , bess-chairs@ietf.org, Jorge Rabadan , " satyamoh@cisco.com" , Ali Sajassi , John Drake |
2018-05-23
|
02 | Jorge Rabadan | Uploaded new revision |
2018-04-12
|
01 | Jorge Rabadan | New version available: draft-ietf-bess-evpn-df-election-framework-01.txt |
2018-04-12
|
01 | (System) | New version approved |
2018-04-12
|
01 | (System) | Request for posting confirmation emailed to previous authors: Kiran Nagaraj , Senthil Sathappan , Jorge Rabadan , " satyamoh@cisco.com" , Ali Sajassi , John … Request for posting confirmation emailed to previous authors: Kiran Nagaraj , Senthil Sathappan , Jorge Rabadan , " satyamoh@cisco.com" , Ali Sajassi , John Drake |
2018-04-12
|
01 | Jorge Rabadan | Uploaded new revision |
2018-04-09
|
00 | Stephane Litkowski | IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call |
2018-03-26
|
00 | Stephane Litkowski | Notification list changed to Stephane Litkowski <stephane.litkowski@orange.com> |
2018-03-26
|
00 | Stephane Litkowski | Document shepherd changed to Stephane Litkowski |
2018-03-26
|
00 | Stephane Litkowski | This document now replaces draft-ietf-bess-evpn-df-election, draft-ietf-bess-evpn-ac-df instead of None |
2018-03-26
|
00 | Stephane Litkowski | IETF WG state changed to In WG Last Call from WG Document |
2018-03-17
|
00 | Stephane Litkowski | Added to session: IETF-101: bess Tue-1550 |
2018-03-05
|
00 | Jorge Rabadan | New version available: draft-ietf-bess-evpn-df-election-framework-00.txt |
2018-03-05
|
00 | (System) | New version approved |
2018-03-05
|
00 | Jorge Rabadan | Request for posting confirmation emailed to submitter and authors: Kiran Nagaraj , Senthil Sathappan , Jorge Rabadan , " satyamoh@cisco.com" , Ali Sajassi , … Request for posting confirmation emailed to submitter and authors: Kiran Nagaraj , Senthil Sathappan , Jorge Rabadan , " satyamoh@cisco.com" , Ali Sajassi , John Drake |
2018-03-05
|
00 | Jorge Rabadan | Uploaded new revision |