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

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

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" <[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.

</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.