Re: [bess] Roman Danyliw's No Objection on draft-ietf-bess-evpn-bum-procedure-updates-11: (with COMMENT)

["Jeffrey (Zhaohui) Zhang" <[e-mail]>]

Hi Roman,

Thanks for your review and comments. Please see zzh> below.

-----Original Message-----
From: Roman Danyliw via Datatracker <[e-mail]>
Sent: Tuesday, October 19, 2021 7:07 PM
To: The IESG <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Subject: Roman Danyliw's No Objection on draft-ietf-bess-evpn-bum-procedure-updates-11: (with COMMENT)

[External Email. Be cautious of content]


Roman Danyliw has entered the following ballot position for
draft-ietf-bess-evpn-bum-procedure-updates-11: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://urldefense.com/v3/__https://www.ietf.org/blog/handling-iesg-ballot-positions/__;!!NEt6yMaO-gk!W9aXZSC6YB_tGS-I05oE_xAchhv7ZbAc7eyvp9QLkay63a9oKtRPkl9f-wuQRPzJ$
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-bum-procedure-updates/__;!!NEt6yMaO-gk!W9aXZSC6YB_tGS-I05oE_xAchhv7ZbAc7eyvp9QLkay63a9oKtRPkl9f-5KAvuRS$



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

** I support Lars Eggert’s DISCUSS position.  I have come to the same
conclusion as the GENART reviewer (Paul Kyzivat).  It isn’t clear what this
document is updating.

-- The document header and abstract explicitly say that RC7432 is updated.
However, I can’t find a clear explanation of how the next in this documents
updates RFC7432

-- Section 5.1. is titled as “Changes to Section 7.2.2 of [RFC7117]” and
changes behavior in RFC7117, but RFC7117 is not being updated (according to the
header and abstract).

Zzh> This document updates RFC7432 in that it provides extensions to support: a) selective tunnels b) tunnel segmentation. Perhaps it's arguable that counts as "updates". I am fine with removing the "update" tag if that does not count as "updates".
Zzh> This document does NOT update RFC7117/7524, which are for VPLS. This document is for EVPN (though both are different solutions for ethernet VPNs), but it refers to the selective or segmented tunnel procedures for VPLS defined in 7117/7524. While minor changes/modifications are needed to apply to EVPN (and they are pointed out in this document as you noted), the procedures for VPLS are not modified (therefore this document does not update 7117/7524).

Zzh> It was an intentional choice not to copy text from 7117/7524. I understand that is causing some concern here but I hope we'd eventually agree that it is better than copying text.

** Section 9.
   They do not introduce new security concerns besides what have been
   discussed in [RFC6514], [RFC7117], [RFC7432] and [RFC7524].

Which parts of these security considerations specifically apply here.  For
example, RFC7524 and RFC7432 makes references to MPLS mechanisms (which seem
out of scope here).  Additionally, it appears some of the guidance across these
documents is directed at securing generic EVPN technology – this is helpful,
but please be clear about this case.  What specific guidance is relevant to the
procedures for handling BUM traffic?

Zzh> No guidance. It simply says that there are no new issues/concerns introduced by this document, so whatever discussed in those referenced RFCs applies here as well.
Zzh> Thanks!
Zzh> Jeffrey



Juniper Business Use Only