Hi Jon, Thank for the review. Update addressing your comments was made in v08. To help the review of the updates, please see below, how each comment has been addressed:
General updates: Replaced globally [I-D.ietf-bess-evpn-inter-subnet-forwarding] by [RFC9135] Replaced globally “colour” by “color” Please look for </Patrice> below. Regards, Patrice Brissette, Distinguished Engineer, Cisco Systems On 2022-07-01, 13:03, "Jon Hardwick" <jonhardw...@microsoft.com <mailto:jonhardw...@microsoft.com>> wrote: Document: draft-ietf-bess-evpn-virtual-eth-segment-07 Reviewer: Jon Hardwick Review Date: 1 July 2022 IETF LC End Date: N/A (last call has not been issued for this draft yet) Intended Status: Standards Track Summary: I have some minor concerns (mostly editorial) about this document that I think should be resolved before publication. Comments: --- Section 4.2 reads like a procedure but is light on normative language. In particular, I think this could be formalized better: The ESI label extended community ([RFC7432] Section 7.5) is not relevant to Grouping Ethernet A-D per ES. The label value is NOT used for encalsulating BUM packets for any split-horizon function and the 'Single-Active' but is left as 0. </Patrice> Replaced “the 'Single-Active' but is left as 0. To save label space, all Grouping Ethernet A-D per ES of a PE SHOULD use same label value.” By “The ESI label extended community MAY not be added to Grouping Ethernet A-D per ES and SHOULD be ignored on receiving PE.” Are we saying that the label value in this extended community MUST be set to zero? Or that the extended community SHOULD NOT be included in the update? What is meant by ".and the 'Single-Active'"? NB Typo "encalsulating" in the above. </Patrice> Typo is fixed. --- Section 5.2 (p17) "it is recommended to assign a B-MAC per vES and upon EVC failure" - should that be RECOMMENDED? </Patrice> Replaced recommended by RECOMMENDED --- Section 5.3 - I think this whole section is normative, and so each statement should use normative language and the active voice. For example: BEFORE: "When a PE advertises an Ethernet A-D per ES route for a given vES, it is coloured as described in Section 4.2.1 using the physical port MAC by default." AFTER: "The PE SHOULD colour each Ethernet A-D per ES route that it advertises for a given vES, as described in Section 4.2.1. The PE SHOULD use the physical port MAC by default." (I think that SHOULD is the appropriate strength of requirement here.) </Patrice> Fixed several sentence in bullet 1 to 4 with proper normative language --- Section 5.3 (p18) "the propagation if failure" -> "the propagation of failure" </Patrice> Fixed typo --- Section 5.4 - Same comments apply about using normative language and the active voice (albeit this section already does that in some places). Section 5.5 - Ditto. </Patrice> Fixed several sentence in bullet 1 to 4 with proper normative language </Patrice> Same as been done for section 5.5. --- Section 8 - IANA Considerations I cannot find reference to this new extended community anywhere in the document. I note that it was present in earlier versions of the draft. Has the need for it been removed? If so, you should change this section to request to IANA that they remove the early allocation. </Patrice> Section 8 has been updated to “This document requests no actions from IANA.” Since the I-D.ietf-bess-pbb-evpn-isid-cmacflush document already defined the I-SID extcom. --- References: I think the reference to [I-D.ietf-bess-pbb-evpn-isid-cmacflush] is a normative reference. </Patrice> Reference has been moved to normative reference. _______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
