[mpls] AD review: draft-ietf-mpls-tp-temporal-hitless-psm

"BRUNGARD, DEBORAH A" <db3546@att.com> Fri, 26 February 2016 22:44 UTC

Return-Path: <db3546@att.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id C1FCE1B31F5; Fri, 26 Feb 2016 14:44:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.366
X-Spam-Status: No, score=-0.366 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id vfjEgfn3kWLr; Fri, 26 Feb 2016 14:44:09 -0800 (PST)
Received: from mx0b-00191d01.pphosted.com (mx0b-00191d01.pphosted.com []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2FC71B3205; Fri, 26 Feb 2016 14:44:08 -0800 (PST)
Received: from pps.filterd (m0049463.ppops.net []) by m0049463.ppops.net-00191d01. ( with SMTP id u1QMhwx6037512; Fri, 26 Feb 2016 17:44:04 -0500
Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com []) by m0049463.ppops.net-00191d01. with ESMTP id 21aa35ka1f-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 26 Feb 2016 17:44:03 -0500
Received: from enaf.aldc.att.com (localhost []) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u1QMi3vs022163; Fri, 26 Feb 2016 17:44:03 -0500
Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com []) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u1QMhtpS021944 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 26 Feb 2016 17:43:59 -0500
Received: from MISOUT7MSGHUBAF.ITServices.sbc.com (MISOUT7MSGHUBAF.itservices.sbc.com []) by mlpi409.sfdc.sbc.com (RSA Interceptor); Fri, 26 Feb 2016 22:43:39 GMT
Received: from MISOUT7MSGUSRDE.ITServices.sbc.com ([]) by MISOUT7MSGHUBAF.ITServices.sbc.com ([]) with mapi id 14.03.0248.002; Fri, 26 Feb 2016 17:43:39 -0500
From: "BRUNGARD, DEBORAH A" <db3546@att.com>
To: "draft-ietf-mpls-tp-temporal-hitless-psm@ietf.org" <draft-ietf-mpls-tp-temporal-hitless-psm@ietf.org>
Thread-Topic: AD review: draft-ietf-mpls-tp-temporal-hitless-psm
Thread-Index: AdFw5l8emBCiMb0bRwGGTnZ2sVVRwA==
Date: Fri, 26 Feb 2016 22:43:39 +0000
Message-ID: <F64C10EAA68C8044B33656FA214632C852829C75@MISOUT7MSGUSRDE.ITServices.sbc.com>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_F64C10EAA68C8044B33656FA214632C852829C75MISOUT7MSGUSRDE_"
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-02-26_15:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy 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-1601100000 definitions=main-1602260423
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/wU0GJcSTSxJ9HUVybJu-GjlujXM>
Cc: "mpls@ietf.org" <mpls@ietf.org>, "mpls-chairs@ietf.org" <mpls-chairs@ietf.org>
Subject: [mpls] AD review: draft-ietf-mpls-tp-temporal-hitless-psm
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Feb 2016 22:44:13 -0000


I've done my AD review of this document. I'm not sure these are concerns or I need clarification on the intention of this document:

1.      At first reading of this draft, no alarms were triggered as I was thinking the aim was a profile of standard MPLS-TP OAM. But after some re-reading, there is no explicit requirement for compatibility with the standard MPLS-TP OAM solution? The abstract states "this document provides considerations for the specification of new requirements to consider a new improved mechanism". So it seems this draft is opening the door for an alternative method to be developed?
2.      I noted you did not use the name "MPLS-TP" in the title (only the draft title). RFC5921 is very clear in defining MPLS-TP and MPLS-TP OAM and says any additional functions falling outside the scope of MPLS-TP will be treated as an evolution of MPLS. It would be a very slippery slope to say these are MPLS-TP requirements. To avoid confusion, the text also needs to be explicit that these requirements are not associated with MPLS-TP but are applicable for both MPLS and MPLS-TP networks.
3.      Requirements should be scoped to requirements, then an assessment can be made if the current standard MPLS-TP OAM (or MPLS OAM) can meet the need or not (e.g. replacing some of the wheels of the cart vs. needing to buy a new cart). Suggest s/mechanism/solution in the document (including the summary) and toning down the negative assertions on MPLS-TP OAM will improve the reading. In my comments below, I noted several negative assertions which are not appropriate. Either reword to be objective or delete.
4.      Considering MPLS-TP is joint work with ITU-T, I checked for any liaisons specific to this draft (other than as part of a list of on-going work) and didn't find any? It would be good to give ITU-T a heads-up. Though it would be best to tone down the negative assertions on MPLS-TP OAM first.



1.      This document is a combination of requirements and problem statement. The status needs to be "Informational", not "Proposed Standard".
2.      There are 6 authors listed on the front page.  According to RFC7322, the total number is generally limited to 5.  Please work among yourselves to cut the number of authors.  Alternatively, can just list an Editor (preferred approach). Or you can produce a justification detailing the contributions of each author to consider an exception and the Document Shepherd will need to include it in the write-up for review by the IESG.
3.      The Abstract is too long -it needs to be shortened. There is no need to repeat the history and justification of MPLS-TP. While wordy, it is missing any mention of "temporal", "temporary", or on-demand. Why not simply use the term "on-demand" (instead of three terms) which is used in other MPLS-TP documents? RFC6371 5.7.1 defines on-demand as initiated manually and for a limited time. Seems to fit.
4.      Introduction/2nd paragraph: "Similar to legacy technologies, MPLS-TP also does not scale when an arbitrary number of OAM functions is enabled." I don't think it is appropriate in an IETF document to make negative assertions on ITU-T technologies, especially this assertion is actually dependent on implementations and deployment. The same can be said for MPLS-TP. All of the ITU-T Recommendations (as early as Y.1711) had this as a basic principal. And it is stated (both ITU-T and IETF), it is for an operator to manage, but the solution should not limit. Remove.
5.      I don't think P-1 or P-2 help to justify the need and only weaken the rationale. P-1 on "lowers the bandwidth efficiency" and P-2 on "management complexity" because of the shim header stacking was not discussed in any of the MPLS-TP documents as a problem. And ITU-T Y.1711's requirement was that OAM packets were to be differentiated by label stacking and sublayering so these "problems" are not aligned with ITU-T's architecture for OAM or IETF'S (e.g. RFC6371). Considering MPLS also needs extra server layers for transport, I don't think the bandwidth penalty of extra labels is significant. If you insist to keep this "problem", you will need objective proof.
6.      P-2 problem on an "identifier management issue" paragraph is very questionable as to what it implies and this is not aligned with MPLS-TP requirements. Supporting identifiers is REQUIRED by MPLS-TP OAM (and the other technologies). Whether or not an operator chooses to use them is optional. Operators can choose to utilize many managed entities or not. They choose to use whichever functions are needed. They are not "forced" as stated here. Not to support identifiers will have security implications. The negative comments on OTN and Ethernet need to be removed. I have never heard an ITU operator raise these concerns, and while ITU operators have argued over the format of identifiers, none have argued not to have them. Later, M-7 has an identifier requirement. So not clear - are you going to use identifiers or not?
7.      P-3 and P-4 while considered problems in this document, were not considered requirements (or problems) in the original MPLS-TP OAM requirements. This should be clearly described that what you want is in addition to the original requirements. The summary statement needs to be reframed that the intention is for operation of an MPLS network (not as stated for an MPLS-TP transport network) if you are not basing your solution on MPLS-TP's standard (hierarchical LSP) solution.
8.      Section 5: Packet Loss and Packet Delay in the original MPLS-TP OAM requirements were only defined for MEPs (SPME is implemented as a MEP too). These should clearly be identified as new requirements if you intend for a "MIP" to originate and terminate. It's very confusing to use standard terminology of MEP/MIP but change the definition/requirements (e.g. section 6.6). You can't redefine a MIP functionality.
9.      Section 6.6: M-7 doesn't seem to align with the text. As this is the first use of MEP/MIP need to spell out and provide a reference. The description is difficult to parse - EPSM points do not correspond with MIPs or MEPs?
10.     Missing any requirements on compatibility/re-use with the standard solution.
11.     Security Considerations - incorrect reference. If the intention is not to support identifiers, the security considerations are not the same as previous.
12.     As only a subset of the OAM requirements can be done, this doesn't seem to be "enhanced" compared to MPLS-TP OAM. May want to reconsider the title to state what it is "Requirements for Hitless On-demand LSP Segment Monitoring".
13.     I had some editorial nits though will wait for a re-spin of the document. I've also asked for a Routing Directorate review - hopefully will be done early next week.