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 <zzh...@juniper.net>
> wrote:
>
> 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 <nore...@ietf.org>
> Sent: Monday, September 6, 2021 12:45 PM
> To: ops-...@ietf.org
> Cc: bess@ietf.org; draft-ietf-bess-evpn-bum-procedure-updates....@ietf.org;
> last-c...@ietf.org
> Subject: Opsdir last call review of
> draft-ietf-bess-evpn-bum-procedure-updates-09
>
> [External Email. Be cautious of content]
>
>
> 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
>
>
>
>
> Juniper Business Use Only
_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
