Subject: RtgDir review: draft-ietf-l2vpn-vpls-inter-domain-redundancy-05.txt

From: "Andrew G. Malis" <[email-masked]>
Date: Tue, 15 Apr 2014 06:44:59 -0400

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.

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.

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

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"

---

From: "Lizhong Jin" <[email-masked]>
Date: Wed, 16 Apr 2014 23:40:16 +0800

Hi Andy,

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

Regards

Lizhong

From: rtg-dir [mailto:[email-masked]] On Behalf Of Andrew G. Malis
Sent: 2014年4月15日 18:45
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
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.

Reviewer: Andy Malis

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.

[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 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 5, second paragraph, I personally prefer "manual provisioning" instead of "manual operation", but the current text is OK if the authors prefer it.

                           "attackes" -> "attacks"

[Lizhong] all the nits are accepted. Thanks.

Regards

Lizhong

---

From: "Andrew G. Malis" <[email-masked]>
Date: Wed, 16 Apr 2014 13:42:23 -0400

Lizhong,

You're welcome! Continued inline, with unnecessary text trimmed ...

Minor Issues:
> 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.
>

Andy: Are you going to update section 5.3 to include this text?

 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.
>

Andy: Could you simplify this to:

When deploying the inter-domain redundancy mechanism described in this
document, consistent provisioning is required for proper operation. The two
domains must both use the same use case (section 5.2 or section 5.3).
Within each section, all of the described modes and options must be
provisioned identically both within each RG and between the RGs.
Additionally, for the two-PWs redundancy options defined in section 5.2,
the two operators must also negotiate to configure same high/low PW
priority at the two PW end-points.  If the provisioning is inconsistent,
then the inter-domain redundancy mechanism may not work properly.

Cheers,
Andy

---

From: "Lizhong Jin" <[email-masked]>
Date: Thu, 17 Apr 2014 11:12:09 +0800

Hi Andy,

See inline below. Thank you.

Regards

Lizhong

From: Andrew G. Malis [mailto:[email-masked]] 
Sent: 2014年4月17日 1:42
To: Lizhong Jin
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-l2vpn-vpls-inter-domain-redundancy-05.txt

Lizhong,

Minor Issues:

[Lizhong] yes. Or we could have another section “Backward compatibility” to include the second sentence. Any suggestion?

When deploying the inter-domain redundancy mechanism described in this document, consistent provisioning is required for proper operation. The two domains must both use the same use case (section 5.2 or section 5.3). Within each section, all of the described modes and options must be provisioned identically both within each RG and between the RGs. Additionally, for the two-PWs redundancy options defined in section 5.2, the two operators must also negotiate to configure same high/low PW priority at the two PW end-points.  If the provisioning is inconsistent, then the inter-domain redundancy mechanism may not work properly. 

[Lizhong] accepted, thank you.

Cheers,

Andy

---

From: "Andrew G. Malis" <[email-masked]>
Date: Wed, 16 Apr 2014 23:57:47 -0400

Lizhong,

I don't think you need a new section, just the new text in 5.3.

Cheers,
Andy

On Wed, Apr 16, 2014 at 11:12 PM, Lizhong Jin <[email-masked]> wrote:

> *From:* Andrew G. Malis [mailto:[email-masked]]
> *Sent:* 2014年4月17日 1:42
> *To:* Lizhong Jin
> *Cc:* [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> *Subject:* Re: [RTG-DIR] RtgDir review:
> draft-ietf-l2vpn-vpls-inter-domain-redundancy-05.txt
>
>
>
> Lizhong,
>
>
>
> [Lizhong] yes. Or we could have another section “Backward compatibility”
> to include the second sentence. Any suggestion?
>
>
>
>
>

---

From: "Lizhong Jin" <[email-masked]>
Date: Thu, 17 Apr 2014 12:30:17 +0800

OK, thanks.

Regards

Lizhong

Sent: 2014年4月17日 11:58

Lizhong,

Cheers,
Andy

Hi Andy,

Regards

Lizhong

Lizhong,

Minor Issues:

 

Cheers,

Andy