Skip to main content

Last Call Review of draft-ietf-bess-evpn-virtual-eth-segment-07

Request Review of draft-ietf-bess-evpn-virtual-eth-segment-07
Requested revision 07 (document currently at 15)
Type Last Call Review
Team Routing Area Directorate (rtgdir)
Deadline 2022-07-01
Requested 2022-06-19
Requested by Andrew Alston
Authors Ali Sajassi , Patrice Brissette , Rick Schell , John Drake , Jorge Rabadan
I-D last updated 2022-08-03
Completed reviews Intdir Telechat review of -13 by Brian Haberman (diff)
Genart Last Call review of -08 by Meral Shirazipour (diff)
Rtgdir Last Call review of -07 by Jonathan Hardwick (diff)
Requesting a last call review before moving this into last call.
Assignment Reviewer Jonathan Hardwick
State Completed
Request Last Call review on draft-ietf-bess-evpn-virtual-eth-segment by Routing Area Directorate Assigned
Posted at
Reviewed revision 07 (document currently at 15)
Result Has issues
Completed 2022-07-01
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

I have some minor concerns (mostly editorial) about this document that I think
should be resolved before publication.


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 -


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.