Re: [Teas] RtgDir review: draft-ietf-teas-p2mp-loose-path-reopt-07.txt

"Rakesh Gandhi (rgandhi)" <rgandhi@cisco.com> Wed, 07 December 2016 16:10 UTC

Return-Path: <rgandhi@cisco.com>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14B611294F5; Wed, 7 Dec 2016 08:10:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.418
X-Spam-Level:
X-Spam-Status: No, score=-17.418 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ov2SqsUSDFNo; Wed, 7 Dec 2016 08:10:26 -0800 (PST)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BCE012947F; Wed, 7 Dec 2016 08:10:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4406; q=dns/txt; s=iport; t=1481127025; x=1482336625; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=xnHI7p+LTrJBGtWfmSVSodKTNtV3mI5hntWR1ZZWUsk=; b=PHwJkJZP40zvh6V7iTHZOek/tjlSMxCxM7RP3yieojwrSn9YcRoX1Y+Q EmQbhEJMfWvuT3tZ3vA+IO+co2PRjWffaSWJmXrEbezn3uyO04vtqra+S R2EYVefrbgVTxioJURq/UB4jrt4r+ohO21zwy0xmzdQF0xSW03V15ML3+ Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0D/AQDAM0hY/5pdJa1eGgEBAQECAQEBAQgBAQEBgzkBAQEBAR9agQYHAY1AlxGUfoIHKYV5AhqBXD8UAQIBAQEBAQEBYiiEaQYjEUUQAgEIFAYCJgICAjAVEAIEAQ0FG4hUDqhdgimLNQEBAQEBAQEBAQEBAQEBAQEBAQEBARyBC4UzgX0IglaESBeCbS2CMAWaZgGGS4pMgXNQhC2JT4dhhiKEDQEfN4EZMQEBgykcgV1yAYg4AYEMAQEB
X-IronPort-AV: E=Sophos;i="5.33,310,1477958400"; d="scan'208";a="184202082"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Dec 2016 16:10:24 +0000
Received: from XCH-RCD-016.cisco.com (xch-rcd-016.cisco.com [173.37.102.26]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id uB7GAOUP011269 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 7 Dec 2016 16:10:24 GMT
Received: from xch-aln-018.cisco.com (173.36.7.28) by XCH-RCD-016.cisco.com (173.37.102.26) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 7 Dec 2016 10:10:23 -0600
Received: from xch-aln-018.cisco.com ([173.36.7.28]) by XCH-ALN-018.cisco.com ([173.36.7.28]) with mapi id 15.00.1210.000; Wed, 7 Dec 2016 10:10:23 -0600
From: "Rakesh Gandhi (rgandhi)" <rgandhi@cisco.com>
To: "Joel M. Halpern" <jmh@joelhalpern.com>, "rtg-ads@tools.ietf.org" <rtg-ads@tools.ietf.org>
Thread-Topic: RtgDir review: draft-ietf-teas-p2mp-loose-path-reopt-07.txt
Thread-Index: AQHSRc3r9+xr+rgbikyiI9lVcuFrpKD8zf8A
Date: Wed, 07 Dec 2016 16:10:23 +0000
Message-ID: <F6373E6A-C2EA-4520-AE98-EC7B02576DF7@cisco.com>
References: <a703aa8f-3d9a-faa8-143b-470d09dd8c4b@joelhalpern.com>
In-Reply-To: <a703aa8f-3d9a-faa8-143b-470d09dd8c4b@joelhalpern.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.15.1.160411
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [161.44.213.13]
Content-Type: text/plain; charset="utf-8"
Content-ID: <239DB247A6960841A7E484260C10A906@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/Agz8mB2WIyl4MinW5rnyLJ29EOA>
Cc: "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "draft-ietf-teas-p2mp-loose-path-reopt.all@ietf.org" <draft-ietf-teas-p2mp-loose-path-reopt.all@ietf.org>, "teas@ietf.org" <teas@ietf.org>
Subject: Re: [Teas] RtgDir review: draft-ietf-teas-p2mp-loose-path-reopt-07.txt
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Dec 2016 16:10:28 -0000

Thank you Joel for the thorough review of the document.

We will go through the comments and update the document as suggested.

Thanks,

Rakesh (for authors and contributors)




On 2016-11-23, 4:10 PM, "Joel M. Halpern" <jmh@joelhalpern.com> wrote:

>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-teas-p2mp-loose-path-reopt-07.txt
>Reviewer: Joel M. Halpern
>Review Date: 23-November-2016
>IETF LC End Date: N/A
>Intended Status: Standards Track
>
>Summary: I have some moderate concerns about this document that I think 
>should be resolved before publication is approved.
>
>Comments:
>
>Major:
>     The use of SHOULD and MAY in section 4.1 seems to lead to a device 
>which ostensibly supports this document, but does the wrong things.
>     First, with regard to the SHOULDs, in the absence of any indication 
>as to why it would not do this, it appears that the SHOULD is really 
>"MUST if the device supports this document" which is what MUST in a 
>document actually means.
>     Section 4.2 first bullet says that a mid-point LSR "SHOULD" check 
>for a preferable P2MP-TE LSP Tree.  But if it doesn't, it is not 
>supporting this document.  As written, it could decide to ignore the 
>message, even though it claims to support this RFC.
>     Looking at the handling when a preferable P2MP-TE LSP tree is 
>found, according to the document, the LSR MAY send the PathErr response. 
>  My assumption is that if it does not send the PathErr, it MUST 
>propagate the request.  If it does not do either one, the protocol does 
>not function.  It seems likely that if this is really intended to be 
>optional (MAY), the document would be improved my giving implementors 
>some hint as to when it is desirable or undesirable to send the message.
>     Then in the third bullet, it is only a SHOULD to pass on the 
>request.  Thus, a device which supports this mechanism, but chooses not 
>to pass on the request, is compliant to this document while preventing 
>other devices from properly supporting the mechanism.
>
>Minor:
>     The abstract is much too long.  Much of the content of the abstract 
>belongs in the introduction.  Even teh second paragraph has too much 
>detail for an abstract.
>
>Editorial:
>     In the last paragraph of the introduction, it says that this 
>document "proposes" solutions.  Given we are now in the position of 
>evaluating publication as a Proposed Standard, I would say that this 
>document "defines" solutions.
>