Subject: [Gen-art] Gen-ART review of draft-ietf-l2vpn-vpls-inter-domain-redundancy-05

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 17 Apr 2014 10:34:20 -0500

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-l2vpn-vpls-inter-domain-redundancy-05
Reviewer: Vijay K. Gurbani
Review Date: Apr-17-2014
IETF LC End Date: Apr-24-2014
IESG Telechat date: Not known.

This document is ready as a Proposed Standard but has some nits and a
minor issue that should be looked at.

Major: 0
Minor: 1
Nits:  7

Minor:

- Section 7, paragraph 2: Okay to use MD5?  Or something stronger...?

Nits:

- Section 1, paragraph 1:
   s/is to provide/provides/

- Section 1, paragraph 2:
   s/options introduced./options are introduced./

- Section 3: What is an "ASBR"?  If it is a well-known term in the
  domain, I suspect you don't need to expand it ...

- Section 3: s/agreements(SLAs)./agreements (SLAs).

- Section 7, first paragraph: s/will have/has/

- Section 7, second paragraph:
  s/ICCP is now/If ICCP is/

- Section 7: You use "pseudowire" here whereas in most of the
  remaining document you used "PW".  You may want to be consistent.

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / [email-masked]
Web: http://ect.bell-labs.com/who/vkg/  | Calendar: http://goo.gl/x3Ogq

---

From: Lizhong Jin <[email-masked]>
Date: Fri, 18 Apr 2014 00:13:05 +0800

Hi Vijay,
Thank you for the review. See my reply inline below.

Regards
Lizhong

> - Section 7, paragraph 2: Okay to use MD5?  Or something stronger...?
[Lizhong] the MD5 will follow the security consideration in
[I-D.ietf-pwe3-iccp] where "SHOULD" is used. And the security section has
been proposed by SEC-Dir to change as below:
   Besides the security properties of [I-D.ietf-pwe3-iccp] for ICCP
   control plane, [RFC4762] and [RFC6870] for PW control plane, this
   document has additional security consideration for ICCP control
   plane.

   In this document, ICCP protocol is deployed between two PEs or ASBRs.
   The two PEs or ASBRs should only be connected by a well managed and
   highly monitored network.  This should be ensured by the operator.

   The state flapping on the inter-domain and intra-domain PW may cause
   security threats or be exploited to create denial of service attacks.
   For example, excessive PW state flapping (e.g., by malicious peer
   PE's implementation) may lead to excessive ICCP exchanges.
   Implementations SHOULD provide mechanisms to perform control-plane
   policing and mitigate such types of attacks.

>   s/is to provide/provides/
[Lizhong] accepted

>   s/options introduced./options are introduced./
[Lizhong] accepted

>  domain, I suspect you don't need to expand it ...
[Lizhong] should be expanded. Thanks.

> - Section 3: s/agreements(SLAs)./agreements (SLAs).
[Lizhong] accepted

> - Section 7, first paragraph: s/will have/has/
[Lizhong] accepted

>  s/ICCP is now/If ICCP is/
[Lizhong] accepted

>  remaining document you used "PW".  You may want to be consistent.
[Lizhong] accepted

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 17 Apr 2014 11:20:15 -0500

On 04/17/2014 11:13 AM, Lizhong Jin wrote:
> [I-D.ietf-pwe3-iccp] where "SHOULD" is used. And the security section
> has been proposed by SEC-Dir to change as below: [...]

Lizhong: No worries; I just wanted to make sure that enough eyeballs had
paid attention to MD5, and it appears that is the case.

Thanks for accepting the rest of the nits.

Cheers,

- vijay