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.
_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
