Re: [bess] WGLC, IPR and Implementation Poll for draft-ietf-bess-evpn-fast-df-recovery-03

[Luc André Burdet <[e-mail]>]

Hi Matthew,

Thanks for the review/comment. I took a closer look at RFC8584, specifically the section about the DF FSM.

The behaviour at PE1 which has a recovering interface ES1 remains unchanged. Effectively PE1 is signalling the equivalent of the DF_TIMER event which leads from DF_WAIT to DF_CALC.

The behaviour at PE2 receiving the ES route with SCT extcomm would correspond to :

  *   DF_DONE :  RCVD_ES -> DF_CALC   (action #11)
  *   DF_CALC:  CALCULATED -> DF_DONE (action #9)

I find the actions described for #9-11 somewhat vague (maybe even wrong for #10?)
   9.   DF_CALC on CALCULATED: Mark the election result for the VLAN or
        bundle, and transition to DF_DONE.

   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.


“marking the election result” in action #9 to me stands out in contrast to “assume an NDF for the local PE“ elsewhere, which conveys effectively programming hardware...


Action#10 could be read to do that but it’s on exiting the state... which we have done already to go to DF_CALF on the RCVD_ES.  The text in RFC8584 seems to wrongly think any new/updated DF result is available already when exiting the state—not on re-entering it from DF_CALC.
Action#10 should be reviewed to be sure it’s not on  **entering** DF_DONE with a (new) DF result from DF_CALC.

I don’t mind marking this draft updating 8584 and adding the following:


+   This document introduces an additional delay to the events and

+   transitions defined for the default DF election algorithm in

+   [RFC8584].

   9.   DF_CALC on CALCULATED: Mark the election result for the VLAN or
        Bundle.
+  9.1  Where SCT timestamp is present on the RECV_ES event of Action 11,
+       wait the remaining time before continuing to 9.2.
+  9.2  Assume a DF/NDF for the local PE for the VLAN or VLAN Bundle,
        and transition to DF_DONE.

   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.


This would be better though:


+   This document introduces an additional delay to the events and

+   transitions defined for the default DF election algorithm in

+   [RFC8584].

   9.   DF_CALC on CALCULATED: Mark the election result for the VLAN or
        Bundle.
+  9.1  Where SCT timestamp is present on the RECV_ES event of Action 11,
+       wait the remaining time before continuing to 9.2
+  9.2  Transition to DF_DONE.

+  10.  DF_DONE on **entering** 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.


Regards,
Luc André

Luc André Burdet |  Cisco  |  [e-mail]  |  Tel: [phone]


From: Matthew Bocci (Nokia) <[e-mail]>
Date: Thursday, November 3, 2022 at 06:33
To: Ali Sajassi (sajassi) <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: Re: WGLC, IPR and Implementation Poll for draft-ietf-bess-evpn-fast-df-recovery-03
Authors and WG

A further question about this document. Do you consider that it updates the procedures in RFC8584?

The abstract says the following: “This document improves these procedures by providing a fast Designated Forwarder (DF) election upon recovery of the failed link or node associated with the multihomed Ethernet Segment. “

If so, please add “Updates 8584” to the header.

Thanks

Matthew


From: Bocci, Matthew (Nokia - GB) <[e-mail]>
Date: Thursday, 14 July 2022 at 10:39
To: Ali Sajassi (sajassi) <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: Re: WGLC, IPR and Implementation Poll for draft-ietf-bess-evpn-fast-df-recovery-03
Ali, WG,

Thank you.

I think there is consensus to publish the draft as a standards track RFC.

Please watch for my shepherd’s review.

Regards

Matthew

From: Ali Sajassi (sajassi) <[e-mail]>
Date: Wednesday, 13 July 2022 at 20:01
To: Bocci, Matthew (Nokia - GB) <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: Re: WGLC, IPR and Implementation Poll for draft-ietf-bess-evpn-fast-df-recovery-03
I support publication of this document and I am not aware of any IPR that hasn’t been disclosed.

Cheers,
Ali

From: Bocci, Matthew (Nokia - GB) <[e-mail]>
Date: Monday, January 31, 2022 at 5:58 AM
To: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: WGLC, IPR and Implementation Poll for draft-ietf-bess-evpn-fast-df-recovery-03
Hi WG,

This email starts a two-week Working Group Last Call on draft-ietf-bess-evpn-fast-df-recovery-03 [1].

This poll runs until Monday 14th February 2022.

We are also polling for knowledge of any undisclosed IPR that applies to this Document, to ensure that IPR has been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).
If you are listed as an Author or a Contributor of this document, please respond to this email and indicate whether or not you are aware of any relevant undisclosed IPR. The Document won't progress without answers from all the Authors and Contributors.
There is currently no IPR disclosed.

If you are not listed as an Author or a Contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules.

We are also polling for any existing implementation as per [2]. Please indicate if you are aware of any implementations.

Thank you,
Matthew & Stephane

[1] draft-ietf-bess-evpn-fast-df-recovery-03 - Fast Recovery for EVPN DF Election<https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-fast-df-recovery/>
[2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw