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

"Shah, Himanshu" <> Thu, 22 October 2015 15:31 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 60A151B38DA; Thu, 22 Oct 2015 08:31:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.267
X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id to_pDYuYxFbr; Thu, 22 Oct 2015 08:31:14 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 61D5B1B38DB; Thu, 22 Oct 2015 08:31:14 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id t9MFSnBB017785; Thu, 22 Oct 2015 11:31:12 -0400
Received: from ( []) by with ESMTP id 1xpyf4rs2e-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 22 Oct 2015 11:31:12 -0400
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 22 Oct 2015 11:31:10 -0400
Received: from ( by ( with Microsoft SMTP Server (TLS) id 8.3.389.2; Thu, 22 Oct 2015 11:31:10 -0400
Received: from ([::1]) by ([::1]) with mapi; Thu, 22 Oct 2015 11:31:09 -0400
From: "Shah, Himanshu" <>
To: "Ralph Droms (rdroms)" <>
Date: Thu, 22 Oct 2015 11:31:08 -0400
Thread-Topic: [Gen-art] Review: draft-ietf-pals-mpls-tp-mac-wd
Thread-Index: AQHRBrtB0K0DtUmA2kyW/x0Nq3/Sjp53r6Nw
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-TM-AS-Product-Ver: SMEX-
X-TM-AS-Result: No--30.869300-8.000000-31
X-TM-AS-User-Approved-Sender: No
X-TM-AS-User-Blocked-Sender: No
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-10-22_09:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1507310000 definitions=main-1510220256
Archived-At: <>
Cc: General Area Review Team <>, "" <>, The IESG <>
Subject: Re: [Gen-art] Review: draft-ietf-pals-mpls-tp-mac-wd
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 22 Oct 2015 15:31:22 -0000

Aahh! Finally got it with content!!..

Let me go through your email..


-----Original Message-----
From: Ralph Droms (rdroms) [] 
Sent: Thursday, October 22, 2015 11:29 AM
To: Shah, Himanshu
Cc: A. Jean Mahoney; General Area Review Team;; The IESG
Subject: Re: [Gen-art] Review: draft-ietf-pals-mpls-tp-mac-wd

(originally sent 10/16; second try)

Hi, Himanshu - responses in line...

> On Oct 15, 2015, at 7:44 PM 10/15/15, Shah, Himanshu <> wrote:
> Hi Ralph -
> Thanks for your thorough review.
> Let me first address your major concern.
> As you point out, this draft builds on existing standards.
> We (authors and WG) had to carefully balance between the right amount 
> of information and wanting to describe details of methods described in other RFCs.
> This is frustrating to implementer (including myself) having to go 
> back and forth between the documents. So I share that concern.
> But we would like to refrain from indulging in beefing up the doc and 
> risk deviating from other base standards. However, for certain, if 
> there is any conflict or lack of clarity, we would prefer to rectify.

I agree that, in general, duplicating specifications from other documents increases the possibility that the respective documents unintentionally conflict with each other or are not updated in parallel.
> To that end, I would rather prefer, trimming by removing conflicting/confusing text.

I wasn't clear in my review - I think making the references to other documents concise and clear, along with trimming unnecessary text from draft-ietf-pals-mpls-tp-mac-wd, will result in the best document.

> For example, sequence number processing - I rather would ask reader to 
> get all details from relevant RFC, and point to only delta (which is 
> to apply same logic that is used for 16-bit sequence number field to 
> 32-bit field sequence number field that is used in this document).

This example is sort of an interesting one to consider, as I was thinking more of the examples in which the format and semantics of the MAC TLVs are exactly the same as in the cited defining documents.

> More comments in line.. and I look forward to your further guidance so 
> we can wrap this up in time.
> As a data point, there are two implementations of this draft deployed 
> in a Telco network in Asia.


> Thanks,
> Himanshu
> -----Original Message-----
> From: Ralph Droms (rdroms) []
> Sent: Wednesday, October 14, 2015 4:02 PM
> To: A. Jean Mahoney; General Area Review Team; 
> Subject: [Gen-art] Review: draft-ietf-pals-mpls-tp-mac-wd
> 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
> 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.
> [Himanshu>] Please see above for the justification of this approach.

Again, I wasn't clear in my review - my paging back and forth was both within draft-ietf-pals-mpls-tp-mac-wd and between draft-ietf-pals-mpls-tp-mac-wd and cited documents.  What I think would improve this specification is clarification that trims redundant specification details from draft-ietf-pals-mpls-tp-mac-wd and cites, concisely and exactly, the other documents from which the specifications are copied.

> 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.
> [Himanshu>] I would prefer taking the text out if its mention in "Introduction" section is not desirable.
> Wildcard MAC withdraw is a very well-known concept in VPLS architecture and needs no more description to L2VPNers, IMO.
> So absence of its reference in subsequent sections does not dilute the purpose of this document.

It wasn't obvious to me what is intended as a protocol specification and what is intended as a description of the protocol.  I see that RFC 4762 includes text that describes how to process an empty MAC List TLV, so perhaps removal of the text altogether would be best.

> 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.
> [Himanshu>] I agree with you. This is statement is used loosely.
> The PW OAM message header is meant to apply only to first 4 bytes.
> Perhaps -
> "The MAC withdraw PW OAM message follows the same guidelines used in 
> [RFC6478], whereby first 4-bytes of OAM message header is followed by 
> message specific field and a set of TLVs relevant for the message"
> 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?
> [Himanshu>] Yes. It is important to determine the "newness" of the 
> message first for processing eligibility and should not require hunting through entire message to find that TLV. My hope is that this is obvious to the reader who 'follows' the concepts in the draft.
> If you feel, that such an explicit mention is necessary, I do not mind.

I think it would be helpful to state explicitly that the Sequence Number TLV MUST be the first TLV in the message.

> 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?
> [Himanshu>] I do not quite follow. ACK HAS TO INCLUDE THE SEQ NO TLV, 
> how else receiver know what is ACK of what seq# message is of? I think 
> this falls into commonsense category BUT, the text explicitly says that ONLY MAC TLVs are not required.

I apologize if I appear to be finicky, again, but the sentence I quoted simply wasn't clear to me.  Common sense interpretation of specifications is, of course, expected, but in my experience a simple sentence like:

A MAC Address Withdraw OAM message with the A-bit set is sent by a receiver to acknowledge receipt and processing of a MAC Address Withdraw OAM message