[Gen-art] Review: draft-ietf-pals-mpls-tp-mac-wd

"Ralph Droms (rdroms)" <rdroms@cisco.com> Wed, 14 October 2015 19:56 UTC

Return-Path: <rdroms@cisco.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 6AD4A1A0372; Wed, 14 Oct 2015 12:56:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id UhU6Xe_wdvjS; Wed, 14 Oct 2015 12:56:20 -0700 (PDT)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 998441A033A; Wed, 14 Oct 2015 12:56:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8059; q=dns/txt; s=iport; t=1444852568; x=1446062168; h=from:to:cc:subject:date:message-id:mime-version; bh=gyMGY57jjH33dm5dff5HDZXrOOfftbeCqiDYwoc4Nm8=; b=MUtoCuwBw+3mXUL6fqQ4cnz+dI1aJhiHqgboXfQ1zLgilGYhoIN5g0V+ fAqi62MX2rDaJZBSZGzv7S+D3ZScEGG5sIX221UVjBSUBNQFaw+KCFo0E awm+LCbprx3LEBQzLC5Hv7PoXc+/K/BhVCYefZ3k1A9NVJEY5G5meBkC8 Y=;
X-Files: signature.asc : 841
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.17,682,1437436800"; d="asc'?scan'208";a="197990435"
Received: from rcdn-core-2.cisco.com ([]) by alln-iport-7.cisco.com with ESMTP; 14 Oct 2015 19:56:07 +0000
Received: from XCH-ALN-019.cisco.com (xch-aln-019.cisco.com []) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t9EJu7uD024504 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 14 Oct 2015 19:56:07 GMT
Received: from xch-aln-016.cisco.com ( by XCH-ALN-019.cisco.com ( with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 14 Oct 2015 14:55:53 -0500
Received: from xch-aln-016.cisco.com ([]) by XCH-ALN-016.cisco.com ([]) with mapi id 15.00.1104.000; Wed, 14 Oct 2015 14:55:53 -0500
From: "Ralph Droms (rdroms)" <rdroms@cisco.com>
To: "A. Jean Mahoney" <mahoney@nostrum.com>, General Area Review Team <gen-art@ietf.org>, "draft-ietf-pals-mpls-tp-mac-wd.all@ietf.org" <draft-ietf-pals-mpls-tp-mac-wd.all@ietf.org>
Thread-Topic: Review: draft-ietf-pals-mpls-tp-mac-wd
Thread-Index: AQHRBrpVBnuXgsTn1E2uvKJJc8iPAA==
Date: Wed, 14 Oct 2015 19:55:53 +0000
Message-ID: <C72542CD-FDFE-4696-B61B-8C054F696718@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/signed; boundary="Apple-Mail=_33C07AFD-F50B-498C-A2C5-4D5EB4F43C59"; protocol="application/pgp-signature"; micalg="pgp-sha256"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/gen-art/e4pxtgKCXEw1mVNhpPxa21w-eRs>
Cc: "Ralph Droms (rdroms)" <rdroms@cisco.com>
Subject: [Gen-art] Review: draft-ietf-pals-mpls-tp-mac-wd
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Oct 2015 19:56:27 -0000

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


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


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.