[bess] Shepherd's review of draft-ietf-bess-evpn-virtual-eth-segment-04

["Luc Andre Burdet (lburdet)" <[e-mail]>]

Authors,

I have completed my review of -04 version of the draft.

Overall impression:
The document is almost ready to be published from a technical standpoint.
There a few changes/discussions I'd like to see regarding:
(1) being more explicit on step-by-step procedures as/where I point out (s.5.3);
(2) one deviation from RFC7432 requires explanation, or much more detail;
(3) expansion of the convergence s5.5 to include EVPN by modifying the proposal to match s5.3 procedure.

The following email captures functional questions, omissions or clarifications.
There were many nits: typos, inconsistent hyphenation/pluralisation, grammar, etc. These have been corrected inline in the txt diff, attached.


Comments:

C1: Formatting
C1.1: Pluralisation of abbreviations
Virtual Eth Segments is alternately pluralised vES and vES's. In most cases, I feel 'vES' would suffice for a clear reading. In any case, it needs to be consistent throughout.
C1.2: Pagination
There are several widow/orphan section titles. 1.2, 3.2, 6, 9, 13(dangling email).
C1.3: Document title (each page): full draft title fits: “EVPN Virtual Ethernet Segment”
C1.4: Consistency
Ethernet A-D per ES vs Ether-AD per ES and similar shortcuts. I tried to normalise as many of these types of inconsistencies as I could in attached diff.

C2: Hierarchical ESI
ES-of-ES (Hierarchical ESI) discussions must have come up when discussing Virtual ES, s.5.3 is borderline Hierarchical ESI... Please add a statement that i.e. “only vES-Grouping for scale purposes is considered but Hierarchical ESI itself is outside the scope of this document”.

C3: Intro vs. Abstract
Second paragraph of Introduction is much clearer & concise in summarising goal than Abstract.
Consider swapping them: (see diff)
- Moving second paragraphs of Abstract to Introduction
- Second paragraph of current Abstract is word for word in s.1.1, remove redundancy & leave that detailed description for s.1.1.

C4: Unclear figures. Too compressed.
Figure1: it is not immediately clear whether EVC4 &EVC3 are meant to represent multihomed EVCs?
Also : Customer B is not represented. Stop the left EVPN arrow above “PE1”, it extends one too far. Same Carrier Eth box: misaligned. See diff.
Figure 2 is packing too much information on left-hand side. Consider collapsing RHS to give more clarity to the left/EVCs drawings.
Alignment is currently very off, see proposed diff.

C5: All-Active
The document explicitly excludes addressing All-Active multihoming yet makes constant references to it, includes A/A in the requirements section, etc. It should be clearer that A/A is not the focus of this document-- or simply extend the document to include A/A.

C6: Scale (guess-)timates ?
s.1.1, last para
I am missing the intent of the 1000/100/10 breakdown, why differentiate scale of SH, S/A and of the excluded A/A ?
-> cf same question applies to requirements R2a-R2c.
The statement here is simpler/clearer by stating “several thousands of single-homed, single-active multi-homed, or all-active multi-homed vES” or even “several thousands of single- or multi-homed vES”.

C7:
p.7, l.4: “aggregated into the same LSPs going to the EVPN network, a common”
-> MPLS network.

C8:
s.1.2 last para no longer reflects content: section 5 is failure handling recovery AND scale, fast convergence. Section 6 is BGP encoding -> see proposed diff.

C9:
Mention 802.1ag explicitly in terminology for CFM + add to normative refs ?

C10:
Reword R1c. Unclear, especially when read in conjunction with R1e.
R1e: “A Multi-Homed vES (Single-Active or All-Active) can be spread across any two or more ENNIs, across two or more PEs.“

C11:
s.3.8 is a requirement for a radical change from RFC7432? It reads as suggesting performing DF election of a vESI based on the withdrawal of a single RT-1 ES/EAD ?
With that in mind, it is additionally (I presume) based on the “parent” ENNI-Type3 ESI introduced in s.5.3 ?
s.5.3. details how the ENNI-Type3-ESI affects backup/aliasing on remote but NOT DF. This needs to be clarified explicitly.

C12:
add RFC 4447/8077 as Informative: PW-Status + MAY statement

C13:
s.5 p.14: [ETH-OAM], [MPLS-OAM] and [PW-OAM] are undefined: add to references

C14: ENNI Type3-ESI
C14.1: Advertise or withdraw?
“2) Upon a port failure (e.g., ENNI failure), the PE advertise a special mass-withdraw message with the MAC address of the failed port”
Is the ENNI-Type3-ESI ES/EAD advertised in normal circumstances and WITHDRAWN upon ENNI failure, like RFC7432 ES/EAD; or
As the draft currently says, the ES/EAD is ADVERTISED during failure of ENNI as a form of negating/invalidating the vES/EAD per-EVC routes ?
If the latter, this is the “opposite” of RFC7432 and more detail is required to explain how the invalidation procedure works.
I suspect the text should read:
“2) The PE also advertises a special Ethernet A-D per ES mass-withdraw message,
with the MAC address of the ENNI port (i.e., the color of the port) encoded
in the ESI field.
For this encoding, Type 3 ESI (RFC7432 section 5) is used with the MAC field
set to the MAC address of the port and the 3-octet local discriminator
field set to 0xFFFFFF.
This mass-withdraw route is advertised with a list of Route
Targets corresponding to the vES service instances. If the
number of Route Targets is more than can fit into a single
attribute, then a set of Ethernet A-D per ES routes are advertised.
3) Upon a port failure (e.g., ENNI failure), the PE withdraws this
special ESI Type 3 Ethernet A-D per ES message.

4) The remote PEs upon receiving this message withdrawal, based on
ESI Type 3 and 0xFFFFFF Local Discrimnator values, detect the special vES
mass-withdraw message. The remote PEs then access the list of the vES
for the specified color created in (1) and initiate locally mass-withdraw
procedures for each of the vES's in the list.”

C14.2:Aliasing/Backup procedure
s.5.3: “realise it's a special message” needs a more technical breakdown based on field identification: a PE detects routes/fields/etc, and takes action. See proposed diff.

C14.3: ENNI DF Election
Additionally per C11 above, s.5.3 details how the ENNI-Type3-ESI affects backup/aliasing but NOT DF. There needs to be a section/subsection on DF-usage of this ENNI-Type3-ESI !
Since this ENNI-Type3-ESI is being defined here, why not advertise it also as a single RT-4 ESI route for peering/DF purposes of the ENNI “parent” of EVC?

C14.4: ESI/Route-Type4 scale
s.5.5 is narrow to PBB-EVPN but I feel could easily be generalised to include EVPN.
s.5.3 describes a Type3-ESI used in ES/EAD for “mass-withdraw” but the same concept should be generalised to apply also to Route-Type4.
s.5.5 describes using a BMAC: what if the System BMAC is being used? The scheme will not work and means operator MUST use the ENNI-BMAC as in s.5.4(1) and MUST NOT rely on BMAC like s5.4(2)?
==> changing this section to be more like s.5.3 i.e. ESI Type3 advertise/wdw as RT-4, and vES Route-Type4 add Routers MAC colour => the same scale optimisation is achieved as vES/EAD <> ES/EAD !
==> additionally, that would work also for EVPN, not just PBB-EVPN !






Luc André Burdet
[e-mail]<mailto:[e-mail]>
Tel: [phone]






Cisco Systems Canada Co. / Les Systemes Cisco Canada CIE
Cisco.com<http://www.cisco.com/web/CA/>