Re: [bess] Rtgdir early review of draft-ietf-bess-evpn-fast-df-recovery-07

[Matthew Bocci (Nokia)]

WG

I haven’t seen any concerns regarding this draft being marked as updating RFC 
8584. I will therefore proceed with the document shepherd’s write up and 
publication request process.

Regards

Matthew

From: Matthew Bocci (Nokia) 
Date: Friday, 13 October 2023 at 17:49
To: Luc Andre Burdet (lburdet) , Adrian Farrel 
, rtg-...@ietf.org 
Cc: bess@ietf.org , 
draft-ietf-bess-evpn-fast-df-recovery@ietf.org 

Subject: Re: 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) 
Date: Monday, 10 July 2023 at 19:46
To: Adrian Farrel , rtg-...@ietf.org 
Cc: bess@ietf.org , 
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 
Date: Saturday, May 27, 2023 at 15:42
To: rtg-...@ietf.org 
Cc: bess@ietf.org , 
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. 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

Re: [bess] Rtgdir early review of draft-ietf-bess-evpn-fast-df-recovery-07

[Alexander Vainshtein]

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  On Behalf Of Matthew Bocci (Nokia)
Sent: Friday, October 13, 2023 7:49 PM
To: Luc Andre Burdet (lburdet) ; Adrian Farrel 
; 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) mailto:lbur...@cisco.com>>
Date: Monday, 10 July 2023 at 19:46
To: Adrian Farrel mailto:adr...@olddog.co.uk>>, 
rtg-...@ietf.org<mailto:rtg-...@ietf.org> 
mailto:rtg-...@ietf.org>>
Cc: bess@ietf.org<mailto: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>
 
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 mailto:nore...@ietf.org>>
Date: Saturday, May 27, 2023 at 15:42
To: rtg-...@ietf.org<mailto:rtg-...@ietf.org> 
mailto:rtg-...@ietf.org>>
Cc: bess@ietf.org<mailto: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>
 
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.ie

Re: [bess] Rtgdir early review of draft-ietf-bess-evpn-fast-df-recovery-07

[Matthew Bocci (Nokia)]

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) 
Date: Monday, 10 July 2023 at 19:46
To: Adrian Farrel , rtg-...@ietf.org 
Cc: bess@ietf.org , 
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 
Date: Saturday, May 27, 2023 at 15:42
To: rtg-...@ietf.org 
Cc: bess@ietf.org , 
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. 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

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 A

Re: [bess] Rtgdir early review of draft-ietf-bess-evpn-fast-df-recovery-07

[Luc Andre Burdet (lburdet)]

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  |  Tel: +1 
613 254 4814


From: Adrian Farrel via Datatracker 
Date: Saturday, May 27, 2023 at 15:42
To: rtg-...@ietf.org 
Cc: bess@ietf.org , 
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. 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

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", 

Re: [bess] Rtgdir early review of draft-ietf-bess-evpn-fast-df-recovery-07

[Luc Andre Burdet (lburdet)]

Hi Matthew,

I had started going through changes but not completed; I will post this week an 
updated version
Thanks for the reminder

Regards,
Luc André

Luc André Burdet  |  lbur...@cisco.com<mailto:lbur...@cisco.com>  |  Tel: +1 
613 254 4814


From: Matthew Bocci (Nokia) 
Date: Friday, June 30, 2023 at 12:07
To: Adrian Farrel , 
draft-ietf-bess-evpn-fast-df-recovery@ietf.org 

Cc: bess@ietf.org , rtg-...@ietf.org 
Subject: Re: Rtgdir early review of draft-ietf-bess-evpn-fast-df-recovery-07
Adrian

Thanks for the RTGDir review.

Authors: Please can you look at the review and address Adrian’s comments.

Regards

Matthew

From: Adrian Farrel via Datatracker 
Date: Saturday, 27 May 2023 at 20:42
To: rtg-...@ietf.org 
Cc: bess@ietf.org , 
draft-ietf-bess-evpn-fast-df-recovery@ietf.org 

Subject: 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.



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. 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

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 ha

Re: [bess] Rtgdir early review of draft-ietf-bess-evpn-fast-df-recovery-07

[Matthew Bocci (Nokia)]

Adrian

Thanks for the RTGDir review.

Authors: Please can you look at the review and address Adrian’s comments.

Regards

Matthew

From: Adrian Farrel via Datatracker 
Date: Saturday, 27 May 2023 at 20:42
To: rtg-...@ietf.org 
Cc: bess@ietf.org , 
draft-ietf-bess-evpn-fast-df-recovery@ietf.org 

Subject: 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.



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. 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

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