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

["Andrew G. Malis" <[e-mail]>]

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"