Subject: [bess] Chair review of draft-ietf-bess-evpn-virtual-eth-segment-05

From: <[email-masked]>
Date: Tue, 3 Mar 2020 10:28:44 +0100

Hi Authors,

Please find  below my chair review:

Nits:

  == Missing Reference: 'ETH-OAM' is mentioned on line 606, but not defined
 
  == Missing Reference: 'MPLS-OAM' is mentioned on line 612, but not defined
 
  == Missing Reference: 'PW-OAM' is mentioned on line 612, but not defined
 
  == Missing Reference: 'EVPN-IRB' is mentioned on line 746, but not defined

Introduction:

There should be an issue with XML source as the reference to RFC7432 is not
a link.

Section 1.1:

The figure legend is not understandable as there are two many acronyms.

"Figure 1: DHD/DHN (both SA/AA) and SH on same ENNI"
 
Or It may be good to put terminology section before.

Section 1.2:

Similar comment for Figure 2

In addition, I'm wondering if there are some issues with the figure itself
regarding the attachment of EVCs.

Finally  section talks about Access MPLS Networks, but figure talks about
Aggregation Network. Of course this is applicable to both cases, but
legend/title/figure are not matching.

"  Since the PWs for the two VPWS instances can be
   aggregated into the same LSPs going to the MPLS network, a common
   virtual ES can be defined for LSP1 and LSP2.  This vES will be shared
   by two separate EVIs in the EVPN network."
 
Which MPLS network are you talking about ? Aggregation or IP/MPLS ? This is
ambiguous.

Section 3.1:
Can't we merge R1a,b, c and d as a single requirement ?

Section 3.2:
I'm a bit concerned about the scaling requirements. Scaling is always a
matter of platform resources and computing power. That's fine to have these
numbers in mind when building the protocol, however we can't be sure that
all platforms will be able to handle this numbers.

Section 3.4:
The requirements are not expressed correctly IMO. When reading R4a and b,
this definition/requirement comes indirectly from RFC7432. Shouldn't we use
something more tied to vES requirement like: a vES SHOULD support EVCs based
on a VLAN based/bundle service

Section 3.5
s/defult procedure/default procedure/

Needs also to comply to RFC8584 ?

Section 3.7
Need to create a new paragraph for R7b,c,d.
 
MHD and MHN are not expanded in terminology section.

Section 3.8:
Need a paragraph separation to introduce R8a.

Section 4.1:

Needs also to comply to RFC8584 ?

Brgds

Stephane

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Tue, 3 Mar 2020 20:45:02 +0000

Hi Stephane,

Thanks for reviewing the new rev of the document and providing us with your comments. We’ll try to take care of your comments within next few days.

Regards,
Ali

From: "[email-masked]" <[email-masked]>
Date: Tuesday, March 3, 2020 at 1:29 AM
To: "[email-masked]" <[email-masked]>, "Luc Andre Burdet (lburdet)" <[email-masked]>
Cc: 'BESS' <[email-masked]>
Subject: Chair review of draft-ietf-bess-evpn-virtual-eth-segment-05
Resent-From: <[email-masked]>
Resent-To: Cisco Employee <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Resent-Date: Tuesday, March 3, 2020 at 1:28 AM

Hi Authors,

Nits:

Introduction:
There should be an issue with XML source as the reference to RFC7432 is not a link.

Section 1.1:

“Figure 1: DHD/DHN (both SA/AA) and SH on same ENNI”

Section 1.2:

Similar comment for Figure 2
In addition, I’m wondering if there are some issues with the figure itself regarding the attachment of EVCs.
Finally  section talks about Access MPLS Networks, but figure talks about Aggregation Network. Of course this is applicable to both cases, but legend/title/figure are not matching.

“  Since the PWs for the two VPWS instances can be

   by two separate EVIs in the EVPN network.”

Which MPLS network are you talking about ? Aggregation or IP/MPLS ? This is ambiguous.

Section 3.1:

Can’t we merge R1a,b, c and d as a single requirement ?

Section 3.2:

I’m a bit concerned about the scaling requirements. Scaling is always a matter of platform resources and computing power. That’s fine to have these numbers in mind when building the protocol, however we can’t be sure that all platforms will be able to handle this numbers.

Section 3.4:

The requirements are not expressed correctly IMO. When reading R4a and b, this definition/requirement comes indirectly from RFC7432. Shouldn’t we use something more tied to vES requirement like: a vES SHOULD support EVCs based on a VLAN based/bundle service

Section 3.5

Section 3.7

Section 3.8:

Section 4.1:

Brgds

Stephane