Skip to main content

Last Call Review of draft-ietf-pals-mpls-tp-mac-wd-02
review-ietf-pals-mpls-tp-mac-wd-02-genart-lc-droms-2015-11-20-00

Request Review of draft-ietf-pals-mpls-tp-mac-wd
Requested revision No specific revision (document currently at 03)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2015-10-20
Requested 2015-10-08
Authors Siva Sivabalan , Sami Boutros , Himanshu C. Shah , Sam Aldrin , Mannan Venkatesan
I-D last updated 2015-11-20
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 Ralph Droms
State Completed
Request Last Call review on draft-ietf-pals-mpls-tp-mac-wd by General Area Review Team (Gen-ART) Assigned
Reviewed revision 02 (document currently at 03)
Result Ready
Completed 2015-11-20
review-ietf-pals-mpls-tp-mac-wd-02-genart-lc-droms-2015-11-20-00
I am the assigned Gen-ART reviewer for this draft. The General Area Review Team
(Gen-ART) reviews all IETF documents being processed by the IESG for the IETF
Chair.  Please treat these comments just like any other last call comments.

For more information, please see the FAQ at

<

http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-pals-mpls-tp-mac-wd-02, "MAC Address Withdrawal over
Static Pseudowire" Reviewer: Ralph Droms Review Date: 2015-10-14 IETF LC End
Date: 2015-10-19 IESG Telechat date: (if known) N/A

Summary:

This draft is on the right track but has open issues, described in the review.

Major issues:

While this document is describing a straightforward adaptation of previously
defined standards to statically provisioned PWs, in my opinion an implementor
would not necessarily be able to construct a fully interoperable implementation
from this document.  There are several sections of the document that are not
clear in their description of how to use mechanisms from referenced documents
in this standard.

If it appears that some of my comments are overly finicky, I'll agree that the
correct implementation could probably be deduced from the text in most cases. 
That is, I didn't find many outright errors or inconsistencies.  Many of my
comments took a lot of paging back and forth, reading of referenced documents
and head-scratching, which, in my experience, can lead to implementations that
don't interoperate.

Section 1:

   When the number of MAC addresses to be
   removed is large, the empty MAC List TLV may be used.  The empty MAC
   List TLV signifies wildcard MAC Address withdrawl.

This text seems to be the only reference to the processing of an empty MAC List
TLV.  Specification of how the protocol works doesn't belong in the
Introduction, and "wildcard MAC Address withdrawal" could certainly use some
more explanation.

Section 3:

   The PW OAM message header is exactly the same as what is
   defined in [RFC6478].

Is this statement really true?  The MAC Address Withdraw header seems to
replace the "Refresh Timer" field with a "Reserved" field, and adds a new "R"
flag.  The statement might be misleading to an implementor.

   a MAC address withdraw OAM message MUST contain a
   "Sequence Number TLV" otherwise the entire message is dropped.

Is the "Sequence Number TLV" required to be the first TLV in the message?  Are
the TLVs required to appear in any particular order?

   A single bit (called A-bit) is set to indicate if a MAC withdraw
   message is for ACK.  Also, ACK does not include MAC TLV(s).

Does this mean that the message is an ACK if the A-bit is set?  Can an ACK
contain a "Sequence Number" TLV?

   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 16-bit sequence number handling is described in
   [RFC4385]. This document uses 32-bits sequence numbers and hence
   sequence number in half the number space (i.e. 31-bits or ~2billion)
   is considered in the valid receive range.

This paragraph is not at all clear to me. Reading section 4 of RFC 4385 helped
but left me unsure about how my understanding of how to extend the sequence
number mechanism to 32 bits corresponds to the expectations of this document.

Section 4.1:

   Each PW is associated with a counter to keep track of the sequence
   number of the transmitted MAC withdrawal messages.  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.

I'm pretty sure this is supposed to mean that the sequence number in the first
message is 1.  The text could be interpreted to mean that the counter is
initialized to 1 and then incremented to 2 when sending the first message.

   The retransmission MUST be
   ceased anytime when ACK is received or after three retries.  This
   avoids unended retransmissions in the absence of acknowledgements.
   Since retransmission time interval and the maximum number of retries
   is local configuration of the sender node, it is up to the
   implementers to pick a discipline.

Is the maximum number of retransmissions 3 or is it locally configured?  Is the
default 3?

   The 'R' reset bit is set in the first MAC withdraw
   to notify the remote peer to reset the send and receive sequence
   numbers.  The 'R' bit must be cleared in subsequent MAC withdraw
   messages after the acknowledgement is received

"First" as in "first message after reset or restart or ???  Would it be better
to say "The R-bit is set in a message when one peer needs to force the remote
peer to reset its send and receive sequence numbers"?  Does the device sending
the message with the R-bit use a sequence number of 1 in that message, and
expect the next message from the peer to have a sequence number of 1?  It would
be helpful to state explicitly that a receiver does not compare the contents
Sequence Number TLV against the expected sequence number if the R-bit is set in
a message.

   The exact processing on how to handle the
   sequence number overflow is described in [RFC4385]

If this sentence refers to section 4 in RFC 4385, then it describes similar
processing for a 16 bit sequence number, not "the exact processing".  I know
I'm being finicky again, but it's crucial that implementors get this sequence
number processing right.

Minor issues: (none)

Nits/editorial issues:

Is there a reason this document does not use RFC 2119 terminology?

In the Introduction, I think it would be clearer to explain the general problem
first, and then refer back to RFC 4762 and RFC 6478 as the standards on which
this document draws.

Section 2:

s/Provide/Provider/ in the definition of PE?

Section 3:

In general, I think it's better to specify protocol behavior once and only onc.
 As an example, this text:

   the sender re-transmits the message for
   a configured number of times in the absence of an ACK response for
   the sequence numbered message.

is somewhat redundant with the text describing retransmission in the following
section.  In fact, much of the entire first paragraph of section 3 describes
protocol behavior rather than message format, and might better be combined with
the corresponding text in section 4.

Attachment:

signature.asc

Description:

 Message signed with OpenPGP using GPGMail