[Isis-wg] RtgDir review: draft-ietf-isis-fs-lsp

Ross Callon <rcallon@juniper.net> Wed, 04 June 2014 00:13 UTC

Return-Path: <rcallon@juniper.net>
X-Original-To: isis-wg@ietfa.amsl.com
Delivered-To: isis-wg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77A971A00D6; Tue, 3 Jun 2014 17:13:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 OqMiXQiy8zue; Tue, 3 Jun 2014 17:13:06 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0184.outbound.protection.outlook.com [207.46.163.184]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F8A31A00C9; Tue, 3 Jun 2014 17:13:05 -0700 (PDT)
Received: from CO2PR05MB636.namprd05.prod.outlook.com (10.141.199.24) by CO2PR05MB636.namprd05.prod.outlook.com (10.141.199.24) with Microsoft SMTP Server (TLS) id 15.0.954.9; Wed, 4 Jun 2014 00:12:57 +0000
Received: from CO2PR05MB636.namprd05.prod.outlook.com ([10.141.199.24]) by CO2PR05MB636.namprd05.prod.outlook.com ([10.141.199.24]) with mapi id 15.00.0954.000; Wed, 4 Jun 2014 00:12:57 +0000
From: Ross Callon <rcallon@juniper.net>
To: "rtg-ads@tools.ietf.org" <rtg-ads@tools.ietf.org>
Thread-Topic: RtgDir review: draft-ietf-isis-fs-lsp
Thread-Index: AQHPf4m85EAbI0Lr3EKuCz3dI7ZY5w==
Date: Wed, 4 Jun 2014 00:12:56 +0000
Message-ID: <63953eac4ee842eda7f2a36439567dad@CO2PR05MB636.namprd05.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [66.129.241.10]
x-microsoft-antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID:
x-forefront-prvs: 0232B30BBC
x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(428001)(199002)(189002)(51444003)(164054003)(76482001)(15975445006)(83322001)(19580395003)(77982001)(33646001)(76576001)(74316001)(21056001)(15202345003)(77096999)(54356999)(99396002)(80022001)(92566001)(2656002)(86362001)(575784001)(66066001)(87936001)(79102001)(99286001)(50986999)(85852003)(64706001)(20776003)(4396001)(83072002)(101416001)(46102001)(74502001)(81542001)(74662001)(31966008)(81342001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:CO2PR05MB636; H:CO2PR05MB636.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (: juniper.net does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=rcallon@juniper.net;
Content-Type: multipart/alternative; boundary="_000_63953eac4ee842eda7f2a36439567dadCO2PR05MB636namprd05pro_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
Archived-At: http://mailarchive.ietf.org/arch/msg/isis-wg/tH6F6rDAEIA0nlocvR8n3e6UtEA
Cc: "draft-ietf-isis-fs-lsp.all@tools.ietf.org" <draft-ietf-isis-fs-lsp.all@tools.ietf.org>, "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "isis-wg@ietf.org" <isis-wg@ietf.org>
Subject: [Isis-wg] RtgDir review: draft-ietf-isis-fs-lsp
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/isis-wg/>
List-Post: <mailto:isis-wg@ietf.org>
List-Help: <mailto:isis-wg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Jun 2014 00:13:09 -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://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-isis-fs-lsp
Reviewer: Ross Callon
Review Date: June 3, 2014
IETF LC End Date: June 3, 2014
Intended Status: Standards Track

Summary: This document is basically ready for publication, but has nits that should be considered prior to publication.

Comments:

The draft is well written, clear, and very readable. I have only a few minor thoughts or questions that the authors might consider along with any other comments received.

Major Issues:  None

Minor Issues:

These are mostly actually questions or very minor clarity issues that the authors could optionally think about.


Section 1 (“Introduction”), second paragraph, second to last sentence. This reads:

   When the information content is large this is inefficient
   and still does not provide a guarantee of reliability.

Actually, I think that it does provide a guarantee of reliability, since the data is resent periodically and therefore if the network is operating should *eventually* get there. What it does not guarantee is timely reliability. Therefore I would suggest that the word “reliability” should be replaced with either “timeliness” or “timely reliability”.


Section 1, third paragraph: I did eventually figure out (when reading sections 9 and 12) that the solution to the “limited LSP set carrying capacity”, extended TLVs, also apply to the existing scopes. I even see this briefly mentioned in the abstract. It might add clarity slightly if the last sentence of the third paragraph is changed from “This capability is also defined in this document” to something such as “This capability is also defined in this document and may be applied to both existing and new scopes”.


Section 3.1 (“Flooding Scoped LSP Format”), description of the Scope:

Received
     FS-LSPs with a scope of 0 MUST be ignored.

Is it commonly understood that “ignored” includes “do NOT forward”? If there is any chance that anyone might get confused we could change this to:

 Received
     FS-LSPs with a scope of 0 MUST NOT be forwarded and MUST be ignored.


Still section 3.1, I wondered whether 16 bits is long term going to be enough for the remaining lifetime. If I did the math right, this implies a maximum of just over 18 hours. Given reliable flooding is there anything that we might want to refresh less often than every 18 hours?


Section 12: I wondered whether “expert review” was the right allocation method for scope identifiers, or if we want to require IETF consensus (normally implying an RFC which goes through IETF last call). I don’t think that we want a lot of them. Do we anticipate either standards from other groups or proprietary protocols (ie, anything that wouldn’t have an IETF consensus RFC) to receive scope IDs?


Nits: None

Thanks, Ross