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://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

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-pals-mpls-tp-mac-wd-01
Reviewer: Martin Vigoureux
Review Date: 2015-09-23
IETF LC End Date: 2015-10-02
Intended Status: Standards Track

Summary:
This document is basically ready for publication, but has nits that 
should be considered prior to publication.

Comments:
The document is concise and (nearly) clear in the description it makes 
of the technology it defines.

Issues:
Section 3
       |0 0 0 1|Version|   Reserved    |0xZZ MAC Withdraw OAM Message  |
Shouldn't this be (TBD) instead of 0xZZ ?

It might only be me having difficulties but I feel that this paragraph 
could be rewritten to be clearer:
    Only half of the sequence number space is used.  Modular arithmetic
    is used to detect wrapping of sequence number.  When sequence number
    wraps, all MAC addresses are flushed and the sequence number is
    reset.  The sequence number handling is described in [RFC4385] with
    the exception that sequence number in this case is 32-bits and hence
    sequence number in half the number space (~2billion) is considered in
    the valid receive range.
Why use half? Half of what (of 32bits or of 16 bits)? ...
Since you refer to two sequence number fields we loose track of which is 
which in the sentences.

Section 4
The drafts says:
                                                        Whenever a node
    sends a new set of MAC TLVs, it increments the transmitted sequence
    number counter, and include the new sequence number in the message.
    The transmit sequence number is initialized to 1 at the onset.
As I read it, in the case of the first set of MAC TLVs to withdraw, the 
counter will move to 2 and the seq# in the message also = 2. Is that 
correct?

Now, on the receiving side, register is at 1, and the draft says:
        Whenever a MAC withdrawal message is received, and if the
    sequence number on the message is greater than the value in the
    register, the MAC address(es) contained in the MAC TLV(s) is/are
    removed, and the register is updated with the received sequence
    number plus 1.  The receiver sends an ACK whose sequence number is
    the same as that in the received message.
we are in that case, so register moves at 3 and sends an ACK with seq#=2

Now the sender needs to send a new list of MAC TLVs to withdraw.
It increments its counter to 3 and sends the message with seq#=3

But at the receiver side we are now in the situation:
    If the sequence number in the received message is smaller than or
    equal to the value in the register, the MAC TLV(s) is/are not
    processed.

So, I am sure I have missed something, but what?
Maybe the sender also increments its counter when it receives an ACK,
but I have not seen this written.
Or is it that the receiver should set its counter to the received seq# 
and not received seq# + 1

Section 6.2
I am doubtful about the need to create a sub registry for the TLVs 
behind a MAC withdrawal OAM message, but I can leave with it.
What is really puzzling me is why do you want to call this sub-registry 
the "Sequence Number" registry (in order to control "Sequence Number 
TLV" type value assignments).
Do you really foresee the need for 16 382 different Sequence Number TLVs?
By the way, I think you should explicitly give a name to that 
sub-registry. I think the title of the sub-section is not enough for that.

Also, the draft says:
    The Type space is divided into assignment ranges;
Well, in reality there is only one assignment range [0 16,383], the rest 
is reserved. Also you do not mention the rest of the range.
So I'd write:
    The Type space is divided into different ranges:
    The value 0 and the values of the range 16 384 to 65 535 are
    reserved and not available for assignments.
    The range 1 to 16 384 is available for assignments, with the
    "Standards Action" policy (RFC5226]).
    This document defines value 0x0001.
    The initial registry should look like:
    Type        Description
    --------    -----------------------------
    0           Reserved (not available for allocation)
    1           Sequence Number
    2-16383     Unassigned
    16384-65535 Reserved (not available for allocation)


Section 7
I am surprised to see RFC2119 as an Informative Reference

Nits:
Not being a native English speaker I have hesitated before making this 
comment, but it seems to me that in many places you use withdraw while 
withdrawal should have been used instead.

Section 1
s/withdrawl/withdrawal/
s/re-uses concepts of -/re-uses concepts of/
s/as is the/as it is the/ ?
s/but does/but do/

Section 4.1
s/node,it/node, it/
s/implementer/implementers/ ?
s/retrasmission/retransmission/

Section 6
s/IANA to a assign new/IANA to assign a new/