[RTG-DIR] RtgDir review: draft-ietf-isis-fs-lsp

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

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, 04 Jun 2014 00:12:56 +0000
Message-ID: <63953eac4ee842eda7f2a36439567dad@CO2PR05MB636.namprd05.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
received-spf: None (: juniper.net does not designate permitted sender hosts)
Content-Type: multipart/alternative; boundary="_000_63953eac4ee842eda7f2a36439567dadCO2PR05MB636namprd05pro_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/nzcppfVFd-13qnv2o51C5BftXQw
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: [RTG-DIR] RtgDir review: draft-ietf-isis-fs-lsp
Precedence: list

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

[RTG-DIR] RtgDir review: draft-ietf-isis-fs-lsp Ross Callon
Re: [RTG-DIR] RtgDir review: draft-ietf-isis-fs-l… Les Ginsberg (ginsberg)
Re: [RTG-DIR] RtgDir review: draft-ietf-isis-fs-l… Ross Callon
Re: [RTG-DIR] RtgDir review: draft-ietf-isis-fs-l… Ross Callon
Re: [RTG-DIR] RtgDir review: draft-ietf-isis-fs-l… Les Ginsberg (ginsberg)
Re: [RTG-DIR] RtgDir review: draft-ietf-isis-fs-l… Ross Callon