Skip to main content

Last Call Review of draft-ietf-l2vpn-vpls-ldp-mac-opt-11

Request Review of draft-ietf-l2vpn-vpls-ldp-mac-opt
Requested revision No specific revision (document currently at 13)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2014-04-08
Requested 2014-03-27
Authors Pranjal Dutta , Florin Balus , Olen Stokes , Don Fedyk , Geraldine Calvginac
Draft last updated 2014-04-07
Completed reviews Opsdir Last Call review of -11 by Susan Hares (diff)
Genart Last Call review of -11 by Robert Sparks (diff)
Genart Telechat review of -12 by Robert Sparks (diff)
Opsdir Telechat review of -12 by Susan Hares (diff)
Assignment Reviewer Robert Sparks
State Completed
Review review-ietf-l2vpn-vpls-ldp-mac-opt-11-genart-lc-sparks-2014-04-07
Reviewed revision 11 (document currently at 13)
Result Ready with Issues
Completed 2014-04-07
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at


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

Document: draft-ietf-l2vpn-vpls-ldp-mac-opt-11
Reviewer: Robert Sparks
Review Date: 7Apr2014
IETF LC End Date: 8Apr2014
IESG Telechat date: not yet scheduled

Summary: This draft is almost ready for publication as a Proposed
Standard, but has minor issues (primarily editorial) that should be

I found this document very difficult to read. It asks the reader to hop
between sections in unusual ways (for instance, it sends the reader to
the problem statement section for details on normative behavior). I
strongly encourage an editorial pass focusing on document structure.

There are many instances of SHOULD in the document where the text should
just be using prose instead. It's not always clear when an
implementation would choose to ignore the SHOULD, and what the
consequences of that choice would be.

The document is inconsistent about the level of support needed in the
network before trying to use this extension.
Section 5.1.2 says the assumption is everything understands it before
it's turned on. Section 6 points back to figure 2 and says
to use the extension over the pw where you administratively know the
peer supports the extension, and fall back to 4762 for
everything else. Which of those did you intend?

Specific comments in document order:

Section 3.2 paragraph 1: This paragraph would benefit from being broken
into several. It's hard to find its point. The SHOULD in this paragraph
is probably not a 2119 SHOULD (this section isn't defining the
protocol). It would be useful in this overview to explicitly say _why_
"This cannot be achieved with ... 4762]" at this point in the document.

Section 3.2 paragraph 2: This SHOULD _is_ defining protocol - shouldn't
it be in section 5?

Section 4.1.1 paragraph 3: It took me some time to find Z on the figure.
It might help to introduce it similar to how you introduce X.

Section 4.1.2: paragraph 1: I think you meant to reference 4.1.1

Section 5: The first sentence talks about requirements in section 4.
Section 4 describes a problem using some examples but doesn't explicitly
call out requirements. Doing so would help the document.

Last sentence in 5.1.1 (and several other places in the document):
Please add an article before "MAC Flush message".  (I apologize for such
a small nit, but each of these instances made making sure I was reading
what the sentence intended significantly more difficult).

Section 5.1.2 first paragraph: This section is defining behavior - why
are you sending the reader back into the problem statement for detail on
the behavior?

5.1.2 paragraph 2: You meant section 6, not 5.

5.1.2 paragraph 3: I can't follow this paragraph's structure. I think
you're trying to say "An MTU-s or PE2-rs SHOULD send MAC withdraw
messages as defined in [RFC4762] in cases where the network is being
upgraded and devices are not capable of understanding the optimized MAC
flush." (But if so, the next sentence is redundant.) Why is this SHOULD?

5.1.3 paragraph 1: Why is this a SHOULD and not a MUST? (Similar
question for the SHOULD in paragraph 2). It's not clear if you're trying
to avoid "Some things won't implement this spec" or "Don't do this if
you haven't administratively ensured every element understands this
extension first" or something else?

5.1.3 paragraph 3: You say "unless specified otherwise". Do you ever
specify otherwise? Why is this disclaimer here?

5.1.3 last paragraph: You meant section 6 not 5.