Re: [RTG-DIR] Routing directorate "last call" review of draft-ietf-bess-evpn-virtual-eth-segment-07

["Patrice Brissette (pbrisset)" <[e-mail]>]

Hi Jon, 

Your comments have been addressed couple weeks ago. There are part of v08+.
Please let me know if they are more to address. 

Regards, 
Patrice Brissette, 
Distinguished Engineer, 
Cisco Systems 





On 2022-07-01, 13:03, "Jon Hardwick" <[e-mail] <mailto:[e-mail]>> 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.


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.


---


Section 5.2 (p17) "it is recommended to assign a B-MAC per vES and upon EVC failure" - should that be 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.)


---


Section 5.3 (p18) "the propagation if failure" -> "the propagation of failure"


---


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.


---


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.


---


References: I think the reference to [I-D.ietf-bess-pbb-evpn-isid-cmacflush] is a normative reference.