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 | [email protected] | Tel: +1 613 254 4814
From: Matthew Bocci (Nokia) <[email protected]>
Date: Thursday, November 3, 2022 at 06:33
To: Ali Sajassi (sajassi) <[email protected]>,
[email protected]
<[email protected]>, [email protected] <[email protected]>
Cc: [email protected] <[email protected]>
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) <[email protected]>
Date: Thursday, 14 July 2022 at 10:39
To: Ali Sajassi (sajassi) <[email protected]>,
[email protected]
<[email protected]>, [email protected] <[email protected]>
Cc: [email protected] <[email protected]>
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) <[email protected]>
Date: Wednesday, 13 July 2022 at 20:01
To: Bocci, Matthew (Nokia - GB) <[email protected]>,
[email protected]
<[email protected]>, [email protected] <[email protected]>
Cc: [email protected] <[email protected]>
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) <[email protected]>
Date: Monday, January 31, 2022 at 5:58 AM
To: [email protected]
<[email protected]>, [email protected] <[email protected]>
Cc: [email protected] <[email protected]>
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
_______________________________________________
BESS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bess
