[bess] Re: Experiment criteria for draft-ietf-bess-evpn-bfd

["Matthew Bocci (Nokia)" <[e-mail]>]

Thanks Prasad,

Once you have updated the draft, I will request publication.

Regards,

Matthew

From: Vengada Prasad Govindan (venggovi) <[e-mail]>
Date: Monday, 2 November 2026 at 15:56
To: Matthew Bocci (Nokia) <[e-mail]>; Dikshit, Saumya <[e-mail]>; Matthew Bocci (Nokia) <matthew.bocci=[e-mail]>; [e-mail] <[e-mail]>
Cc: '[e-mail]' <[e-mail]>
Subject: RE: Experiment criteria for draft-ietf-bess-evpn-bfd


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.


Hello Saumya,
I will add the suggested to Appendix -A
Thanks
Prasad

From: Matthew Bocci (Nokia) <[e-mail]>
Sent: Monday, November 2, 2026 09:24 PM
To: Dikshit, Saumya <[e-mail]>; Matthew Bocci (Nokia) <matthew.bocci=[e-mail]>; Vengada Prasad Govindan (venggovi) <[e-mail]>; [e-mail]
Cc: '[e-mail]' <[e-mail]>
Subject: Re: Experiment criteria for draft-ietf-bess-evpn-bfd

Authors,

Please can you respond so we can close on this.

Thanks

Matthew

From: Dikshit, Saumya <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, 9 September 2026 at 16:33
To: Matthew Bocci (Nokia) <matthew.bocci=[e-mail]<mailto:matthew.bocci=[e-mail]>>; Vengada Prasad Govindan (venggovi) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Cc: '[e-mail]' <[e-mail]<mailto:[e-mail]>>
Subject: Re: Experiment criteria for draft-ietf-bess-evpn-bfd

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 Prasad, Matthew

I understand and agree with why this document went to Experimental rather than Standards Track, and I am not trying to bring back in through Appendix A the implementation tags the WG deliberately decided not to require up front. A WG participant saying "I have an implementation" is enough to satisfy the policy, and I am not asking for more than that.

What I am alluding to is narrower than that policy question.:
Section 3 states that this document covers unicast traffic, BUM traffic using ingress replication, BUM traffic using P2MP tunnels, and both MPLS and VXLAN encapsulations. Appendix A as it stands only asks that report to say BFD bootstrap, state transitions and teardown were seen between two PEs, it does not ask which of those forwarding and encapsulation cases were actually involved.
Hence, the same single implementation that satisfies the policy today could, later, be read as the evidence behind a Std track decision, without anyone being able to tell from the report whether Sections 5 through 7 were ever exercised at all. That is not a call for more implementations, it is a request that whatever gets reported says what it covered.

Hi Prasad,
I agree with your concern about not overspecifying this, and I do not want Appendix A to become a formal test matrix either. My suggestion is only that the report names which cases it covered.

A quick snippet if agreeable:
"An implementation report for this document should identify which of the forwarding and encapsulation cases in Section 3, unicast, BUM with ingress replication, BUM with P2MP tunnels, MPLS and VXLAN, were exercised, alongside the BFD bootstrap, maintenance and teardown behaviour observed."

This stays guidance, not a gate

Best Regards,
Saumya

From: Matthew Bocci (Nokia) <matthew.bocci=[e-mail]<mailto:matthew.bocci=[e-mail]>>
Date: Wednesday, 9 September 2026 at 7:35 PM
To: Vengada Prasad Govindan (venggovi) <[e-mail]<mailto:[e-mail]>>; Dikshit, Saumya <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Cc: '[e-mail]' <[e-mail]<mailto:[e-mail]>>
Subject: Re: Experiment criteria for draft-ietf-bess-evpn-bfd
The current implementation policy for the BESS working group says the following:

"We consider that there is consensus to put in place the following (which
is the amended proposal):

At the same time we will issue a Working Group Last Call, we will ask
for knowledge of existing implementations, and the more details provided
at that time, the better.
In the situation where an implementation exists we will proceed with
submission to IESG.
In the opposite situation, we will systematically ask the WG for
reasoned opinions regarding whether we should nevertheless proceed
with submission to IESG.
We will gauge consensus on that aspect. In case consensus is in favour
of proceeding with submission to IESG we will do so. In the opposite
case, we will put the document in a "Waiting for implementation" state
until information on an existing implementation is brought to our
knowledge or of the WG.”

As it stands, there is no strict requirement to demonstrate multiple interoperable implementations to progress a proposal. It is just “an implementation”.

In the case of this draft, there was no publicly declared implementation to meet this requirement, and so the consensus was to go forward as an experimental document to allow the necessary code point allocation and preserve a clear specification to encourage implementation of what the WG agreed was needed, with the view to potentially moving to standards track in the future. Speaking as document shepherd, I think there is no need to further specify the experiment, since a WG participant simply has to say “I have an implementation” to meet the above requirement.

Matthew

From: Vengada Prasad Govindan (venggovi) <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, 8 September 2026 at 17:33
To: Dikshit, Saumya <saumya.dikshit=[e-mail]<mailto:saumya.dikshit=[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Cc: '[e-mail]' <[e-mail]<mailto:[e-mail]>>
Subject: RE: Experiment criteria for draft-ietf-bess-evpn-bfd

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.


Hello Saumya,
Thank you for your note, I do agree that criteria of Appendix A can be made more specific. At the same time, I hope you would agree that this is no formal specification of the test criteria, it is more a guideline. The reason I want to request you to keep the text as-is is that we do not want to overspecify the criteria that gates Exp->Std transition (even partially) if required. Let me know your thoughts about the text and we can take a call please.
Thanks
Prasad

From: Dikshit, Saumya <saumya.dikshit=[e-mail]<mailto:saumya.dikshit=[e-mail]>>
Sent: Monday, September 7, 2026 10:48 PM
To: Vengada Prasad Govindan (venggovi) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: '[e-mail]' <[e-mail]<mailto:[e-mail]>>
Subject: Re: Experiment criteria for draft-ietf-bess-evpn-bfd


Hello BESS WG and authors,

I have one comment on Appendix A of draft-ietf-bess-evpn-bfd-17 and just saw 2 or 3 superior versions published and applicable to those as well.

Section 3 says that the document covers unicast traffic, BUM traffic using ingress replication, BUM traffic using P2MP tunnels, and both MPLS and VXLAN encapsulations.
Appendix A presently asks only for BFD bootstrap, state transitions, and teardown between two independently implemented PEs.
That confirms basic BFD interoperability, but it does not show which of the forwarding and encapsulation cases specified by the document were interoperable.

I suggest following or similar text for Appendix A:

"For each forwarding and encapsulation case implemented, an implementation report must record successful bootstrap, maintenance including Up to Down to Up transitions, and teardown of EVPN BFD sessions between independently implemented PEs. The report must identify the traffic class, tunnel type, encapsulation, BFD session mode, injected fault, and the BFD state observed at each endpoint. The report must cover unicast and BUM traffic, ingress replication and P2MP forwarding where implemented, and MPLS and VXLAN where implemented."

This helps to keep implementation aligned, while giving a later standards track decision evidence that the mechanisms in Sections 5 through 7 were tested rather than only the common BFD session lifecycle.

From: Vengada Prasad Govindan (venggovi) <venggovi=[e-mail]<mailto:venggovi=[e-mail]>>
Date: Monday, 17 August 2026 at 1:24 PM
To: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Cc: '[e-mail]' <[e-mail]<mailto:[e-mail]>>
Subject: [bess] Re: Experiment criteria for draft-ietf-bess-evpn-bfd
Hello WG,
 draft-ietf-bess-evpn-bfd-15 has been submitted with the proposed text for success criteria in the Appendix. The scope section calls out this reference as well.
Chairs,
I hope this should help progress the document forward in exp track. Please let me know if any more edits are required.

Thanks
Prasad

________________________________
From: Vengada Prasad Govindan (venggovi) <venggovi=[e-mail]<mailto:venggovi=[e-mail]>>
Sent: Tuesday, July 28, 2026 10:40 PM
To: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: [bess] Experiment criteria for draft-ietf-bess-evpn-bfd


Hello WG,

During the IETF-126, there was a suggestion that the draft-ietf-bess-evpn-bfd be moved to exp track (from std) to progress it further towards RFC. It was also required to define the criteria based on which the document could progress to STD track at a later date. To satisfy the comment, the following text is proposed. Comments are welcome:

[cid:image001.png@01DD6B10.C9988E50]

Thanks
Prasad