RE: [RTG-DIR] RtgDir review: draft-ietf-l2vpn-vpls-inter-domain-redundancy-05.txt

["Lizhong Jin" <[e-mail]>]

Hi Andy,

Thank you for the detail review. See my reply inline below.

 

Regards

Lizhong

 

From: rtg-dir [mailto:[e-mail]] On Behalf Of Andrew G. Malis
Sent: 2014年4月15日 18:45
To: [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: [RTG-DIR] RtgDir review: draft-ietf-l2vpn-vpls-inter-domain-redundancy-05.txt

 

Hello,

 

I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html

 

Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft.

 

Document: draft-ietf-l2vpn-vpls-inter-domain-redundancy-05.txt

Reviewer: Andy Malis

Review Date: 15 April 2014

IETF LC End Date: 24 April 2014

Intended Status: Standards Track

 

Summary:

 

I have some minor concerns about this document that I think should be resolved before publication. It also has editorial nits that should be considered prior to publication.

 

Comments:

 

In general, I found the draft straightforward to read and follow. It does require a working knowledge of draft-ietf-pwe3-iccp-16.txt and RFC 6870, and it is a very good application of these two specifications.

 

I noted that the only draft in the references (draft-ietf-pwe3-iccp-16.txt) is currently in the RFC Editor's queue.

 

Major Issues:

 

No major issues found.

 

Minor Issues:

 

Section 5.3: The draft includes two variants of the 3:1 protection model, referred to as options A and B. However, it does not provide any criteria or guidelines for selection between the two either for code implementation or network operation. The draft should state whether one or both are required for implementation (I would guess both) and how to choose between them operationally (there are hints if you read between the lines, but it should be explicit). It is also implied (but again not explicitly stated) that both domains should choose the same option. That should be explicitly stated, if correct, and should be repeated in Section 6.

[Lizhong] Thank you for pointing out this. This is the missing part for a standard track draft. 

The implementation MUST support option A, and MAY support option B. Option B will be useful when the two legacy PEs in one domain does not support the function in this document. The two legacy PEs still need to support PW redundancy defined in [RFC 6870], but be configured as slave node.

The Section 6 will be updated as below:

When deploying the inter-domain redundancy mechanism described in this document, some manual operation/negotiation is required to be done correctly and securely.  For all the options described in section 5.2 and 5.3, each node within one RG should be configured with same redundancy mode, and both domains should choose the same option. For the two-PWs redundancy options defined in section 5.2, the two operators should also negotiate to configure same high/low PW priority at the two PW end-points.  If the configuration consistency is broken, the inter-domain redundancy mechanism may not work properly.

 

 

Section 6: This section provides two examples of options that need to be provisioned identically within and/or between RGs for proper operation. This should be a list of such options rather than just the two examples.

[Lizhong] right, see the changes in the previous comment.

 

Section 7, second paragraph: Should "could be secured" be "MAY be secured"?

[Lizhong] the security directorate points out that the text of paragraph two and three conflicts with [I-D.ietf-pwe3-iccp] SC. Then I will rephrase the section 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 will have 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 pseudowire may cause security threats or be exploited to create denial of service attacks.  For example, excessive pseudowire 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.

 

 

Nits:

 

Section 1, last paragraph, "behaviour" -> "behavior".

 

Section 3, fourth paragraph, "P2P" is used without definition. As this is the only use in the document, I recommend spelling it out to "point-to-point".

 

Section 4, third paragraph, "use-case" -> "use case"

 

Section 5, second paragraph, I personally prefer "manual provisioning" instead of "manual operation", but the current text is OK if the authors prefer it.

 

Section 5.1.3, "that is member" -> "that is a member"

 

Section 5.3, fourth paragraph: "option A and B" -> "options A and B"

 

Section 7, last paragraph, "activitiy" -> "activity"

                           "attackes" -> "attacks"

[Lizhong] all the nits are accepted. Thanks.

 

Regards

Lizhong