Hi Stephane, Thanks for reviewing the new rev of the document and providing us with your comments. We’ll try to take care of your comments within next few days.
Regards, Ali From: "slitkows.i...@gmail.com" <slitkows.i...@gmail.com> Date: Tuesday, March 3, 2020 at 1:29 AM To: "draft-ietf-bess-evpn-virtual-eth-segm...@ietf.org" <draft-ietf-bess-evpn-virtual-eth-segm...@ietf.org>, "Luc Andre Burdet (lburdet)" <lbur...@cisco.com> Cc: 'BESS' <bess@ietf.org> Subject: Chair review of draft-ietf-bess-evpn-virtual-eth-segment-05 Resent-From: <alias-boun...@ietf.org> Resent-To: Cisco Employee <saja...@cisco.com>, <pbris...@cisco.com>, <richard.sch...@verizon.com>, <jdr...@juniper.net>, <jorge.raba...@nokia.com> Resent-Date: Tuesday, March 3, 2020 at 1:28 AM Hi Authors, Please find below my chair review: Nits: == Missing Reference: 'ETH-OAM' is mentioned on line 606, but not defined == Missing Reference: 'MPLS-OAM' is mentioned on line 612, but not defined == Missing Reference: 'PW-OAM' is mentioned on line 612, but not defined == Missing Reference: 'EVPN-IRB' is mentioned on line 746, but not defined Introduction: There should be an issue with XML source as the reference to RFC7432 is not a link. Section 1.1: The figure legend is not understandable as there are two many acronyms. “Figure 1: DHD/DHN (both SA/AA) and SH on same ENNI” Or It may be good to put terminology section before. Section 1.2: Similar comment for Figure 2 In addition, I’m wondering if there are some issues with the figure itself regarding the attachment of EVCs. Finally section talks about Access MPLS Networks, but figure talks about Aggregation Network. Of course this is applicable to both cases, but legend/title/figure are not matching. “ Since the PWs for the two VPWS instances can be aggregated into the same LSPs going to the MPLS network, a common virtual ES can be defined for LSP1 and LSP2. This vES will be shared by two separate EVIs in the EVPN network.” Which MPLS network are you talking about ? Aggregation or IP/MPLS ? This is ambiguous. Section 3.1: Can’t we merge R1a,b, c and d as a single requirement ? Section 3.2: I’m a bit concerned about the scaling requirements. Scaling is always a matter of platform resources and computing power. That’s fine to have these numbers in mind when building the protocol, however we can’t be sure that all platforms will be able to handle this numbers. Section 3.4: The requirements are not expressed correctly IMO. When reading R4a and b, this definition/requirement comes indirectly from RFC7432. Shouldn’t we use something more tied to vES requirement like: a vES SHOULD support EVCs based on a VLAN based/bundle service Section 3.5 s/defult procedure/default procedure/ Needs also to comply to RFC8584 ? Section 3.7 Need to create a new paragraph for R7b,c,d. MHD and MHN are not expanded in terminology section. Section 3.8: Need a paragraph separation to introduce R8a. Section 4.1: Needs also to comply to RFC8584 ? Brgds Stephane
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
