[RTG-DIR] RtgDir review: draft-ietf-pppext-trill-protocol-06.txt
mike shand <mshand@cisco.com> Tue, 31 May 2011 13:10 UTC
Return-Path: <mshand@cisco.com>
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D14FE084D for <rtg-dir@ietfa.amsl.com>; Tue, 31 May 2011 06:10:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 84cxMamGy3UW for <rtg-dir@ietfa.amsl.com>; Tue, 31 May 2011 06:10:32 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 12C25E0858 for <rtg-dir@ietf.org>; Tue, 31 May 2011 06:10:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mshand@cisco.com; l=4636; q=dns/txt; s=iport; t=1306847431; x=1308057031; h=message-id:date:from:mime-version:to:cc:subject: content-transfer-encoding; bh=LzU+cPhzeruYlcP0/3kWu8WbQ67Q/QXdDghdjwj97bA=; b=MEe7w+WkLeIFB7tLqkw3JvOeKN/C6AYQpmk58qrpwu5iEhTq8LWrG/OJ mzLS0I5M/dIUeIL3x68rybSpW5syu6uO5IDVPmOYyMjOxmUZa9UfZQgjR wJMklpYwl2CZ66gOtfNUbsAlg6pjQ+xcmlstxVWACtAc/nyQUHVuMwCUw 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAK7n5E2Q/khM/2dsb2JhbABTph13qDWdUIYeBJBPhD6KXQ
X-IronPort-AV: E=Sophos;i="4.65,297,1304294400"; d="scan'208";a="91566045"
Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 31 May 2011 13:10:28 +0000
Received: from [64.103.65.19] (dhcp-gpk02-vlan300-64-103-65-19.cisco.com [64.103.65.19]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p4VDARDC010709; Tue, 31 May 2011 13:10:28 GMT
Message-ID: <4DE4E8C3.6030205@cisco.com>
Date: Tue, 31 May 2011 14:10:27 +0100
From: mike shand <mshand@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10
MIME-Version: 1.0
To: rtg-ads@tools.ietf.org
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: rtg-dir@ietf.org, draft-ietf-pppext-trill-protocol.all@tools.ietf.org
Subject: [RTG-DIR] RtgDir review: draft-ietf-pppext-trill-protocol-06.txt
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtg-dir>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 31 May 2011 13:10:36 -0000
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://www.ietf.org/iesg/directorate/routing.html 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-pppext-trill-protocol-06.txt Reviewer: Mike Shand Review Date: 31 May 2011 IETF LC End Date: 8 June 2011 Intended Status: Proposed Standard Summary: I have some minor concerns about this document that I think should be resolved before publication. Comments: The reference to RFC 1142 is misleading and dangerous. RFC 1142 is a poor copy of a pre-standard version of IS-IS ( ISO DP 10589, as opposed to ISO/IEC 10589 version 2). There are significant technical differences between RFC 1142 and the ISO standard. Note that, for this reason, it is proposed that RFC 1142 be re-classified as historic. (see http://tools.ietf.org/html/draft-shand-rfc1142-to-historic-01). It should never be used as a reference for IS-IS. The correct reference for ISO/IEC 10589 is :- International Organization for Standardization, "Intermediate system to Intermediate system intra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode Network Service (ISO 8473)", ISO/IEC 10589:2002, Second Edition, Nov 2002. Consequently some references to sections in this draft need to be modified, as noted below. Major Issues: No major issues found. Minor Issues: 1) Section 2 para 3 last sentence. says "If a TNP or TLSP packet is received when TNCP is not in Opened state and LCP is Opened, an implementation SHOULD respond using LCP Protocol-Reject." I assume that such a packet MUST be discarded, but that in addition the implementation SHOULD respond with a LCP Protocol-Reject. Is this correct, and if so, does it need clarification? I note that RFC 1661 explicitly states "Any supported network-layer protocol packets received when the corresponding NCP is not in the Opened state MUST be silently discarded." So RFC 1661 requires a silent discard, whereas this draft encourages an explicit reject. 2) Section 2.2 para 1 says "When TNCP is in Opened state, TNP packets MAY be sent by setting the PPP Protocol field to hex TBD-00XX (TNP) and placing the TRILL-encapsulated data in the PPP Information field." I think this is the wrong use of "MAY". MAY implies that TNP packets may be sent as described here, or by some other undisclosed encoding. Surely what is meant is that if TNP packets are sent, they MUST be encoded as described here. Similarly in Section 2.3. concerning TLSP packets. 3) Section 3, bullet 1. The text:- per "Point-to-Point IS to IS Hello PDU" (section 9.3 of [6] in PDF, 9.7 in text), do not use Neighbor IDs." should simply refer to section 9.7 in ISO/IEC 10589 second edition. 4) In addition, it may be helpful here to draw attention to the requirement in [1] 4.2.4.1 that the IS-IS three way hand shake MUST be used on such links. In particular, the reference (in the present draft) in the last sentence of section 2.3 to "only an arbitrary circuit ID", rather than an "extended circuit ID" as described in RFC 5303, and the clause "do not use Neighbor IDs" at the end of section 3 bullet 1, may give the erroneous impression that RFC 5303, (and the "Neighbor System ID", and "Neighbor Extended Circuit ID" defined therein) is not mandated for PPP links. That said, I appreciate that this draft should not unnecessarily re-state every requirement of the base TRILL spec 5) Section 3, bullet 3 The discussion of the issue that there may be no MAC address as a possible source for a unique system ID is out of place in this draft. It is not a direct consequence of using either PPP or TRILL. It is a situation which may arise in any usage of IS-IS where there is no MAC address available to source the system ID. It seems arbitrary to reference [8] in this context, particularly since [8] has not been submitted as an IS-IS WG document. Thanks, Mike
- [RTG-DIR] RtgDir review: draft-ietf-pppext-trill-… mike shand
- Re: [RTG-DIR] RtgDir review: draft-ietf-pppext-tr… James Carlson
- Re: [RTG-DIR] RtgDir review: draft-ietf-pppext-tr… mike shand
- Re: [RTG-DIR] RtgDir review: draft-ietf-pppext-tr… Stewart Bryant
- Re: [RTG-DIR] RtgDir review: draft-ietf-pppext-tr… James Carlson
- Re: [RTG-DIR] RtgDir review: draft-ietf-pppext-tr… James Carlson
- Re: [RTG-DIR] RtgDir review: draft-ietf-pppext-tr… Jari Arkko
- Re: [RTG-DIR] RtgDir review: draft-ietf-pppext-tr… Jari Arkko