Matthew, and all, I feel pretty sure that this draft, if approved, should be considered as updating RFC 8584.
I also thing that there is no backward compatibility issues. My 2c, Sasha From: rtg-dir <rtg-dir-boun...@ietf.org> On Behalf Of Matthew Bocci (Nokia) Sent: Friday, October 13, 2023 7:49 PM To: Luc Andre Burdet (lburdet) <lbur...@cisco.com>; Adrian Farrel <adr...@olddog.co.uk>; rtg-...@ietf.org Cc: bess@ietf.org; draft-ietf-bess-evpn-fast-df-recovery....@ietf.org Subject: [EXTERNAL] Re: [RTG-DIR] Rtgdir early review of draft-ietf-bess-evpn-fast-df-recovery-07 Authors, Working Group, I would like to gauge the consensus of the group on the question below about the draft updating 8584. The meaning of "updates" is perhaps a little ambiguous, and the interpretation I had used when suggesting that we should mark the draft as updating 8584 was that it makes some changes to the procedures in 8584. Specifically, these changes are described in the introduction section of the draft, as follows: "This document updates the state machine described in Section 2.1 of [RFC8584], by optionally introducing delays between some events, as further detailed in Section 2.2. The solution is based on a simple one-way signaling mechanism." Are there any concerns about interoperability between a 8584-only compliant implementation, and one that also implements draft-ietf-bess-evpn-fast-df-recovery? Thanks Matthew From: Luc Andre Burdet (lburdet) <lbur...@cisco.com<mailto:lbur...@cisco.com>> Date: Monday, 10 July 2023 at 19:46 To: Adrian Farrel <adr...@olddog.co.uk<mailto:adr...@olddog.co.uk>>, rtg-...@ietf.org<mailto:rtg-...@ietf.org> <rtg-...@ietf.org<mailto:rtg-...@ietf.org>> Cc: bess@ietf.org<mailto:bess@ietf.org> <bess@ietf.org<mailto:bess@ietf.org>>, draft-ietf-bess-evpn-fast-df-recovery....@ietf.org<mailto:draft-ietf-bess-evpn-fast-df-recovery....@ietf.org> <draft-ietf-bess-evpn-fast-df-recovery....@ietf.org<mailto:draft-ietf-bess-evpn-fast-df-recovery....@ietf.org>> Subject: Re: Rtgdir early review of draft-ietf-bess-evpn-fast-df-recovery-07 CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. Hi Adrian, Thank you for your valuable comments, and apologies for the late reply/update. I have incorporated all changes into -v08 which I hope address your feedback: some comments are replied to below: I note that the topic of "updates" was raised by matthew in his review, and that 2.2 is clear about the changes. I note, however, that the decision to make this an Update happened after WG last call, and I wonder whether the owrking group is fully on board with the implication that any future implementation claiming conformance to 8584 will be required to implement this specification. There is a difference between an Update and an additional procedure. [LAB] It is worth noting that the delay introduced (change to 8584) is by default 0 i.e. no change to RFC8584 when the extcomm is not present. An implementation which does not support this adding a delay of 0 and one supporting it but with a delay of 0 would display similar behaviours ? I can defer to Matthew and the WG on this. Why bit 3? I know the answer is "because that's the bit our implementation uses" and I'm fine with that and I'm not asking for any change, but it makes me suspicious about what happened to bits 0 and 2. Why aren't they used? Is someone squatting on them? [LAB] yes bits 0 and 2 are in-use already for Preference-Based DF indication; Bit 2 is iirc from an old version of this document which was also requesting a H=handshake bit, no longer is. We felt it best to just leave this one at 3 instead of shifting down. (Bit 5 is also in-use for Port-Mode in another document) I see some challenges here. The first is when a PE joins the segment while DF election is ongoing among the other PEs. The second is what happens if the SCT BGP extended community is present when the T-bit is not set. The third is what happens if the T-bit is set but no SCT BGP extended community is provided. All of these are easy to describe. Does the backwards compatibility not describe these already i.e. "SHALL revert back to 7432" ? Regards, Luc André Luc André Burdet | lbur...@cisco.com<mailto:lbur...@cisco.com> | Tel: +1 613 254 4814 From: Adrian Farrel via Datatracker <nore...@ietf.org<mailto:nore...@ietf.org>> Date: Saturday, May 27, 2023 at 15:42 To: rtg-...@ietf.org<mailto:rtg-...@ietf.org> <rtg-...@ietf.org<mailto:rtg-...@ietf.org>> Cc: bess@ietf.org<mailto:bess@ietf.org> <bess@ietf.org<mailto:bess@ietf.org>>, draft-ietf-bess-evpn-fast-df-recovery....@ietf.org<mailto:draft-ietf-bess-evpn-fast-df-recovery....@ietf.org> <draft-ietf-bess-evpn-fast-df-recovery....@ietf.org<mailto:draft-ietf-bess-evpn-fast-df-recovery....@ietf.org>> Subject: Rtgdir early review of draft-ietf-bess-evpn-fast-df-recovery-07 Reviewer: Adrian Farrel Review result: Has Issues Hello I have been selected to do a Routing Directorate early review of this draft.. https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-fast-df-recovery<https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-fast-df-recovery>. I reviewed revision -07. The Routing Directorate will, on request from the working group chair, perform an early review of a draft before it is submitted for publication to the IESG. The early review can be performed at any time during the draft's lifetime as a working group document. The purpose of the early review depends on the stage that the document has reached. I reviewed revision -07 of this draft after the completion of WG last call and shepherd review, but before the WG makes a publication request. The purpose of a review at this stage is to improve the quality before AD review and so reduce the AD workload as wellas improve the output of the working group and the final quality of any published RFCs. For more information about the Routing Directorate, please see https://wiki.ietf.org/en/group/rtg/RtgDir<https://wiki.ietf.org/en/group/rtg/RtgDir> Document: draft-ietf-bess-evpn-fast-df-recovery-07.txt Reviewer: Adrian Farrel Review Date: 2023-05-27 Intended Status: Standards Track Summary: I have some minor concerns about this document that I think should be resolved before it is submitted to the AD. This document is short and readable. While most of what I found is nits, they somewhat detract from the clarity of the document. The minor points could do with small additions to the text to help the reader and smooth the document's passage through the IESG. === Abstract should note that this document updates RFC 8584 and say (briefly) how. (Note that idnits warned you about this.) I would put similar text in the Introduction, but that text can have a pointer to Section 2.2). I note that the topic of "updates" was raised by matthew in his review, and that 2.2 is clear about the changes. I note, however, that the decision to make this an Update happened after WG last call, and I wonder whether the owrking group is fully on board with the implication that any future implementation claiming conformance to 8584 will be required to implement this specification. There is a difference between an Update and an additional procedure. --- Abstract Move "(DF)" to the first use of "Designated Forwarder" Please expand "EVI" and "PE" s/via a simple signaling/via simple signaling/ --- Move the requirements language into a new Section 1.1 Please use the correct version of the boilerplate text... 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 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. --- 1. Please expand "DF", "EVI", and "PE" on first use. s/applying Highest/applying the Highest/ s/independent of number/independent of the number/ s/via a simple signaling/via simple signaling/ s/on simple one-way signaling/on a simple one-way signaling/ --- 1.2 s/in redundancy group/in a redundancy group/ --- 1.2 The RFC Editor will ask you to consider another term in place of "blackholing". You might choose to retain the term, or you might think that it is OK to say "packets being dropped if the timer is too long" There are quite a few similar uses throughout the document. --- 1.2 upon re-entry of the packet I think you mean, "upon the packet re-entering the Ethernet Segment" --- 1.3. This section is a bit messy because it talks about the "proposed solution" in text that will eventually become an RFC, and because it makes cryptic references to mechanisms that have not yet been described. I am not convinced that you actually need this text (why are you trying to sell the benefits having already told us there is a problem to be solved?) but if you want to keep the text, I would suggest that you position it as "design principles" and scale it right back. Something like... 1.3. Design Priniciples for a Solution The solution presented in this document follows several design pronciples as follows. * Complicated handshake signamling mechanisms and state machines are avoided in favor of a simple uni-directional signaling approach. * The solution is backwards-compatible (see Section 4). * Existing DF Election algorithms are supported. * The solution is independent of any BGP delays in propagation of Ethernet Segment routes (Route Type 4). * The solution is agnostic of the actual time synchronization mechanism used. --- 2. s/participating to a common/participating in a common/ s/at a same pre-announced time/at the same pre-announced time/ s/e.g. NTP/e.g., NTP/ s/along with Ethernet/along with the Ethernet/ s/from local PE/from the local PE/ s/is called "Service/is called the "Service/ s/by newly added/by the newly added/ -- 2. What is "carving state"? I see that "service carving" is a term of art in RFCs 7432 and 8584, but there is no mention there of "carving state". --- 2. OLD to communicate to other partners the Service Carving Time NEW to communicate the Service Carving Time to other partners END --- 2. When a new PE is inserted or an existing PE device Unqualified verb: a new PE is inserted where? Probably "inserted in an Ethernet segment". Incomplete clause: an existing PE device is what? Possibly "booted up" in line with the text after Figure 1. --- 2. Upon reception of that new BGP Extended Community, partner PEs can determine exactly the anticipated carving time. s/reception/receipt/ Why "exactly"? Is there some doubt that other mechanisms might not be exact? How "anticipated"? Is this still guesswork? Maybe just... ...can determine the carving time. --- 2.1 s/needs to be defined/is defined/ s/along with Ethernet/along with the Ethernet/ s/as a 8-octet/as an 8-octet/ s/the NTP protocol/NTP/ --- 2.1 * Timestamp Fractional Seconds: 16 bits of the NTP fractional seconds are encoded in this field. The use of a 16-bit fractional seconds yields adequate precision of 15 microseconds (2^-16 s). Which 16 bits? I think "the high order 16 bits" --- 2.1 Do you intend this solution to have a "bad time" when the NTP era transitions in 2036? Or do you expect the implementation to handle NTP wrapping? If so, you should probably point this out (because otherwise I can see some fun in the field). --- 2.1 1 2 3 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)| RSV | DF Alg | |A| |T| ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Bitmap | Reserved = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * Bit 3: Time Synchronization (corresponds to Bit 27 of the DF Election Extended Community). When set to 1, it indicates the desire to use Time Synchronization capability with the rest of the PEs in the Ethernet Segment. Why bit 3? I know the answer is "because that's the bit our implementation uses" and I'm fine with that and I'm not asking for any change, but it makes me suspicious about what happened to bits 0 and 2. Why aren't they used? Is someone squatting on them? --- 2.2 9.1 Where SCT timestamp is present on the RECV_ES event of Action 11, wait the remaining time before continuing to 9.2. You could usefully clarify "the remaining time". I think you are saying that the implementation should "wait until the time indicated by the timestamp in the (with the possible reduction by the skew value) is in the past". This would also cover you against the transmission of timestamps that are already in the past or which go into the past when the skew is deducted. --- 2.2 Why do you show: 10. DF_DONE on exiting the state: If a new DF election is triggered and the current DF is lost, then assume an NDF for the local PE for the VLAN or VLAN Bundle. 11. DF_DONE on VLAN_CHANGE, RCVD_ES, or LOST_ES: Transition to DF_CALC. As far as I can see, these are unchanged from 8584/2.1 and showing them in this section is confusing. --- What's a "peering timer"? I think you have assigned a name to the timer described in step 2 of section 8.5 of RFC 7432. No reason not to give it a name, but perhaps you should make it nice and clear what you are talking about? So... In the examples in section 3 (thanks for these), it looks like the value of the SCT and the value of the peering timer are coincidentally "now+3" and 3 respectively. In fact they are both based on the value of the timer configured for all PEs on the Ethernet Segment. This could be clearer. --- 4. PEs running a baseline DF election mechanism will simply discard the new SCT BGP extended community as unrecognized. Would be useful to give a reference for that behavior. --- 4. A PE can indicate its willingness to support clock-synched carving by signaling the new 'T' DF Election Capability as well as including the new Service Carving Time BGP extended community along with the Ethernet Segment Route (Type-4). In the case where one or more PEs attached to the Ethernet Segment do not signal T=1, all PEs in the Ethernet Segment SHALL revert back to the [RFC7432] timer approach. This is especially important in the context of the VLAN shuffling with more than 2 PEs. I see some challenges here. The first is when a PE joins the segment while DF election is ongoing among the other PEs. The second is what happens if the SCT BGP extended community is present when the T-bit is not set. The third is what happens if the T-bit is set but no SCT BGP extended community is provided. All of these are easy to describe. --- 5. Is there a "downgrade attck" achieved by causing a T-bit to be clear? --- 5. This document uses MPLS and IP-based tunnel technologies to support data plane transport. Security considerations described in [RFC7432] and in [RFC8365] are equally applicable. I don't think this document is concerned with the data plane transport. On the other hand, you should describe the impact of any attacks on the new protocol elements (for example, what happens if the SCT is set to a value that is many hours ahead?). Of course, your escape clause remains that the message must be protected in the same way that other messages (in 7432 and 8584) are protected, but you should still describe the risks. --- 6. Looks like the SCT extended community has already been assigned. So, you need... OLD This document solicits the allocation of the following sub-type in the "EVPN Extended Community Sub-Types" registry setup by [RFC7153]: 0x0F Service Carving Timestamp This document NEW IANA maintains the "EVPN Extended Community Sub-Types" registry set up by [RFC7153]. IANA is requested to confirm the First Come First Served assignment as follows: Sub-Type Value | Name | Reference | DATE ---------------+---------------------------+---------------+------ 0x0F | Service Carving Timestamp | This document | TBD IANA should replace the field TBD with the date of publicaton of this document as an RFC. END --- 6. Just a little political correctness... OLD This document solicits the allocation of the following values in the "DF Election Capabilities" registry setup by [RFC8584]: Bit Name Reference ---- ---------------- ------------- 3 Time Synchronization This document NEW IANA maintains the "DF Election Capabilities" registry set up by [RFC8584]. IANA is requested to make the following assignment from this registry: Bit Name Reference Date ---- ---------------- ------------- ---- 3 Time Synchronization This document TBD IANA should replace the field TBD with the date of publicaton of this document as an RFC. END Disclaimer This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments.
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
