AD review of draft-ietf-l2vpn-vpls-ldp-mac-opt

["Adrian Farrel" <[e-mail]>]

Hi authors,

I've picked up this document after we reshuffled the working groups.
At this stage in the proceedings I normally do an AD review to try to
catch issues that would otherwise show up in IETF last call, directorate
reviews, or IESG evaluation. My intention is to fix them as early as 
possible so that everyone else gets a clean document to review and the
process runs a bit more smoothly for you.

On the other hand, I see that this document has been sitting post 
publication request for some time, and I don't want to hold it up any
more. So I am splitting my comments into two sections:
- things that absolutely need to be fixed before we can continue
- other issues, typos, questions.

I'd love for you to handle the second category now as well, but if you
prefer you can just focus on the first category and we'll pick the
others up in IETF last call.

For the moment, I'll put the document into "Revised I-D Needed" state
for the first category. When I see a revision (with or without fixes
for the second category) I'll move the document along.

As usual, all of my comments are open for discussion.

Thanks for the work,
Adrian

=======

== Must Fix ==

Section 7 needs some work.

- Please split it into 7.1 and 7.2
- Please identify exactly which registries you want code-points from
- For the LDP TLV you need to say which range you want the assignment
  from (since there seems to be a set of sub-ranges that are preferred
  for different uses).
- Are you asking for a new subregistry for the sub-TLVs (such as the
  "MAC Flush Parameters Sub-TLVs" registry)? If not, where are the 
  allocations coming from? If so, what is the allocation policy for
  new allocations, and what does the registry table look like?
- Do you need a registry for the flags in the MAC Flush Parameters TLV?

== Other Issues ===

Terminology

The RFC Editor will require that the first section of the document is 
the Introduction.

Notwithstanding the pointers to other documents that define terminology,
you need to expand some acronyms on first use. The Abstract must be 
treated as a completely standalone piece of text so expansions are 
needed there and on first use in the body of the text. I see:
PE
PW
PBB
MTU-s
PE-rs
LDP
FEC
MSTP

Actually, once you move the Terminology section down, I think you'll 
find that you have many of the expansions in place.

---
 

I wonder what value Figure 1 has given that Figure 2 illustrates the
same point with the added value of showing the mesh as a real mesh.

---

Section 4

   This document describes the problems in detail with respective to
   various MAC flush actions described in section 2.

s/document/section/

---

Section 5

   This section describes the solution for the requirements described in
   section 3.

s/3/4/?

---

Section 5.1.1

   The MAC Flush TLV SHOULD be placed after the existing TLVs in MAC
   Flush message in [RFC4762].

Are LDP TLVs order-sensitive, or is this a special requirement?

---

If I read section 6 correctly, I see that you are comfortable with the
"undesired" over-flushing that would result from a flush where the new
TLV is not understood and the operator has "made a mistake" or chosen to
not check that the TLV is supported.

Do I have this right?

---

Section 8 seems a bit light.

A reference to RFC 5920 and RFC 6952 would not hurt. Maybe 5036, itself, 
should be mentioned.

It seems to me that something you can usefully say is that the 
extensions defined here optimise the flushing and so the risk of
security attacks is reduced. However, in the event that the 
configuration of support for the new TLV can be spoofed, sub-optimal
behavior will be seen.

Wrt the data plane, presumably, causing MAC flush when not needed is a
bad thing?