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

["Fedyk, Don" <[e-mail]>]

Thanks Adrian

I will take a first pass of addressing your comments and get a collective agreement,

I will get to this in a couple days

Thanks,
Don 

-----Original Message-----
From: L2vpn [mailto:[e-mail]] On Behalf Of Adrian Farrel
Sent: Tuesday, March 11, 2014 4:05 PM
To: [e-mail]
Cc: [e-mail]
Subject: AD review of draft-ietf-l2vpn-vpls-ldp-mac-opt

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?