Hi Roman, Thanks for your review and comments. Please see zzh> below.
-----Original Message----- From: Roman Danyliw via Datatracker <[email protected]> Sent: Tuesday, October 19, 2021 7:07 PM To: The IESG <[email protected]> Cc: [email protected]; [email protected]; [email protected]; [email protected] <[email protected]>; [email protected] <[email protected]> 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 _______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
