Subject: [Last-Call] Opsdir last call review of draft-ietf-bess-evpn-bum-procedure-updates-09

From: Scott Bradner via Datatracker <[email-masked]>
Date: Mon, 06 Sep 2021 09:45:23 -0700

Reviewer: Scott Bradner
Review result: Has Issues

This is an OPS-DIR review of “Updates on EVPN BUM Procedures”
<draft-ietf-bess-evpn-bum-procedure-updates>

These comments should be treated as any other last-call comments

This ID describes procedures to be used to support unknown unicast, and
multicast (BUM) traffic in Ethernet VPNs, and as such, will impact the
operators of networks where the procedures are used.

I found this document to be quite complex and expect that operators will have a
hard time getting all the details right when trying to implement it.  I do not
know if it can be made more straightforward but I would not want to be assigned
to get this running properly on a big network.

That said, the procedures seem useful enough to publish the document as
requested but I hope the WG does a pass to see if it can be simplified first
and deal with the following:

Section 5.3.1 – uses SHOULD – but I do not see why a  SHOULD is used instead of
a MUST

        In my opinion, a SHOULD introduces operational or implementation
        confusion unless
the SHOULD is accompanied with an explanation of what might happen if the
SHOULD is not followed so that the implementer or operator knows if it’s
important and why – if I were writing RFC 2119 today, knowing what has happened
since I did write it, I would not include SHOULD & SHOULD NOT – far better to
say “MUST unless the following is the case” or “MUST NOT unless the following
is the case” –

        if the authors fell that there is a reason to not use MUST & MUST NOT
        then it would
help if they included the reason in the text

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Wed, 8 Sep 2021 16:49:28 +0000

Hi Scott,

Thanks for your review and comments/suggestions.

Yes I will change the SHOULD to MUST as you pointed out.

As for the complexity, unfortunately due to the nature of the tunnel segmentation (if different tunnel technology/instantiation is needed in different regions) the procedures are indeed needed and they're actually very much similar to what's specified in RFC 6514 (for MVPN), RFC7117 (for VPLS) and RFC7524 (inter-area segmentation for both MVPN and EVPN).

The need to address backward compatibility is another reason for some added complexity. For example, section 5.3 could be removed if we would not need to consider legacy PEs that do not support the procedures in this document.

Thanks.
Jeffrey

-----Original Message-----
From: Scott Bradner via Datatracker <[email-masked]>
Sent: Monday, September 6, 2021 12:45 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Opsdir last call review of draft-ietf-bess-evpn-bum-procedure-updates-09

[External Email. Be cautious of content]

Reviewer: Scott Bradner

Juniper Business Use Only

---

From: Scott Bradner <[email-masked]>
Date: Wed, 8 Sep 2021 15:43:38 -0400

thanks

I do understand its complex but I would hope that the language can be reworked to make it more likley
that an operator will get it right when trying to set up

I would not remove ether backward compatibility information but, as above, see if the language can be simplified

maybe more of a 
if you want to X then do these steps
	1
	2
	3

Scott

> On Sep 8, 2021, at 12:49 PM, Jeffrey (Zhaohui) Zhang <[email-masked]> wrote:
> 
> Hi Scott,
>

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Tue, 14 Sep 2021 20:27:54 +0000

Hi Scott,

In the example of "5.3.  Backward Compatibility", seems that it is already in the following format?

----

" if you want to X then do these steps
        1
        2
        3
"
---

Specifically, section 5.3 has the following text:

   The above procedures assume that all PEs are upgraded to support the
   segmentation procedures:
   ...
   If a deployment has legacy PEs that does not support the above ...

   To address this backward compatibility problem, the following
   procedure can be used (see Section 6.2 for per-PE/AS/region I-PMSI
   A-D routes) ...

Thanks.
Jeffrey

-----Original Message-----
From: Scott Bradner <[email-masked]>
Sent: Wednesday, September 8, 2021 3:44 PM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Opsdir last call review of draft-ietf-bess-evpn-bum-procedure-updates-09

thanks

maybe more of a

Scott