Skip to main content

Early Review of draft-ietf-pals-mpls-tp-mac-wd-01
review-ietf-pals-mpls-tp-mac-wd-01-rtgdir-early-vigoureux-2015-09-22-00

Request Review of draft-ietf-pals-mpls-tp-mac-wd
Requested revision No specific revision (document currently at 03)
Type Early Review
Team Routing Area Directorate (rtgdir)
Deadline 2015-09-25
Requested 2015-09-21
Authors Siva Sivabalan , Sami Boutros , Himanshu C. Shah , Sam Aldrin , Mannan Venkatesan
Draft last updated 2015-09-22
Completed reviews Genart Last Call review of -02 by Ralph Droms (diff)
Secdir Last Call review of -02 by Radia Perlman (diff)
Rtgdir Early review of -01 by Martin Vigoureux (diff)
Assignment Reviewer Martin Vigoureux
State Completed
Review review-ietf-pals-mpls-tp-mac-wd-01-rtgdir-early-vigoureux-2015-09-22
Reviewed revision 01 (document currently at 03)
Result Has Nits
Completed 2015-09-22
review-ietf-pals-mpls-tp-mac-wd-01-rtgdir-early-vigoureux-2015-09-22-00
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/