Re: [bess] Document shepherd's review of draft-ietf-bess-evpn-vpls-seamless-integ-03

["Ali Sajassi (sajassi)" <[e-mail]>]

Hi Matthew,

Thank you for your comments. I addressed them all (please refer inline for the comment resolutions) and I published a new rev04 with these resolutions.

Regards,
Ali

From: "Bocci, Matthew (Nokia - GB)" <[e-mail]>
Date: Wednesday, April 25, 2018 at 4:53 AM
To: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Document shepherd's review of draft-ietf-bess-evpn-vpls-seamless-integ-03
Resent-From: <[e-mail]>
Resent-To: Cisco Employee <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Resent-Date: Wednesday, April 25, 2018 at 4:53 AM

Authors,

Here are my comments on the draft. In general, the draft is well written and good-to-go, but I have a few comments that are mostly aimed at improving the readability of the draft.

Please treat these as WG last call comments.

Best regards

Matthew



General Comments:
- Please expand all less-commonly used acronyms on first use.
Done.

- You use a mix of ‘a EVPN’ and ‘an EVPN’. I think it should be ‘an EVPN’ throughout, since I presume you intend the reader to say ‘EeeeVPN’.
Done.

Minor comments:
Section 1, 2nd paragraph:
“Section 2 provides the details of the requirements. Section 3 specifies procedures for the seamless integration of VPLS and EVPN networks. Section 4 specifies procedures for the seamless integration of PBB-VPLS and PBB-EVPN networks. Section 5 discusses the solution advantages.”
I am not sure we need to be talking about solution advantages in an RFC, unless we are directly comparing this solution with some other published solution. I suggest changing this to solution attributes.
Done. I got rid of that section and move the text to the introduction section and replaced “advantages” with “attributes”.

Section 3:
“All the logic for this seamless integration…” would read better as just “All the logic for seamless integration…”
Done.

Section 3.1:
“,per current standard procedures specified in..”
‘current standard’ is redundant once this is published. I suggest changing this to just “per the procedures specified in…”
Done.

Section 3.1. Second paragraph. The grammar makes this hard to parse. I suggest changing ‘would’ to ‘will’ throughout and rewording the last two sentences as follows:

“In other words, when the discovery phase is complete, the EVPN PEs will have discovered all the PEs in the VPN instance along with their associated capability (EVPN or VPLS-only), whereas the VPLS PEs will have discovered all the PEs in the VPN instance as if they were all VPLS-only PEs.”
Done.

Section 3.3: 2nd paragraph:
“The EVPN PEs do not advertise the C-MAC address learned over PW to each other because every EVPN PE learns it directly over its associated PW to that VPLS PE.”
I think this should be:
“The EVPN PEs do not advertise the C-MAC address learned over the PWs to each other because every EVPN PE learns them directly over its associated PW to that VPLS PE. “
Done.

Section 3.3: 2nd and 3rd paragraph:
“….but this is the typical behavior of VPLS PEs.”. This would be clearer if it was a new sentence e.g.:
“Note that this is behavior typical of VPLS PEs.”
Done.

Section 5: Solution Advantages
As mentioned above, I don’t think we need to push advantages of a stand-alone and soon-to-be-standardised solution unless we are directly comparing it with something else. I suggest renaming this to ‘Solution Attributes”.
Done. Moved the text of this section into the introduction section.

Section 6: Security consideration.

This section is far too light weight and I am concerned that the security area will have concerns. If there are really no additional considerations, then perhaps you could be more explicit as to what consideration from VPLS and EVPN do apply, and/or provide references.
Done.