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

[Ross Callon <[e-mail]>]

Regarding the first point (“reliability” versus “timeliness”), looking at this again I believe that you are correct.

Regarding the second point (the extended TLVs also applies to existing LSPs) I like your new additional wording better than mine (for the reason that you state).

On the third (what does “ignored” mean) I also like your new wording.

On the fourth (is 18 hours long enough) I also had the same misgivings that you had – this is a large change to introduce at this point. It seems to be a tradeoff between “be certain we don’t get stuck by this in the future” versus “don’t make unnecessary changes”. As such I am fine with whatever WG consensus is.

On the last point (expert review versus IETF consensus) this is a point where we have to pick one – again I can go with WG consensus.

Thanks, Ross

From: Les Ginsberg (ginsberg) [mailto:[e-mail]]
Sent: Tuesday, June 03, 2014 10:29 PM
To: Ross Callon; [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: RE: RtgDir review: draft-ietf-isis-fs-lsp

Ross –

Thank you for your thoughtful review.
Inline.

From: rtg-dir [mailto:[e-mail]] On Behalf Of Ross Callon
Sent: Tuesday, June 03, 2014 5:13 PM
To: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: [RTG-DIR] RtgDir review: draft-ietf-isis-fs-lsp

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”.

LES: I am going to disagree with you here. ☺
Reliability to me means not just that you know that somehow you will (eventually) receive all of the current information but also that you have a way of determining whether the information you currently have is up to date or not.  Imagine that it takes 2 hellos to contain all of the AF information. My neighbor will repeatedly send IIH-1 and IIH-2. So even if I drop IIH-2, I should eventually receive it – which I think is your point. But when I do receive IIH-2, it is also possible that IIH-1 has recently changed and I managed to drop the most recent IIH-1. So how do I know at a given moment in time that I really do have the latest information? Answer – I don’t.

So the term “timely reliability” to me is a bit of a misnomer. The current scheme works because drops are (usually) rare and repetition makes up for the occasional drop – but this is qualitatively different than saying it is reliable.

I prefer to leave the text unchanged.

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”.

LES: I added the phrase “alternative solution to the limited LSP set carrying capacity of Level 1 and Level 2 LSPs as part of the extensions defined in this document.”

I wasn’t comfortable with the term “existing scopes” as it seemed to confuse existing L1/L2 LSPs with the new PDUs (FS-LSPs) .

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.

LES: Point taken. The new text reads:
  “Received   FS-LSPs with a scope of 0 MUST be ignored and MUST NOT
     be flooded.”

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?

 LES: Interesting comment. A similar question was raised during WG review – but for a very different reason. Someone “did the math” and concluded that if we actually generated 65000 FS-LSPs that even at maximum lifetime we would have to refresh one FS-LSP/second constantly. Of course, the reality is that we aren’t going to approach anywhere near 65000 FS-LSPs. The 16 bit extended LSP number is deemed so much larger than any anticipated need as to never approach the maximum number in real deployments. (We are not trying to become BGP. ☺)

Changing the lifetime field would violate our goal of keeping the format of FS-LSPs as close as possible to existing LSPs so as to maximize reuse of existing code.  And such a change would affect the format of LSP entries in FS-SNPs as well. Refreshing a given FS_LSP once every 18 hours still seems like a “very long time” to me. So unless we feel strongly that there is a need for a longer lifetime I would like to leave things as they are.

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?

LES: I thought about this. I think Expert Review is almost always selected for IS-IS because ISO still has some ownership (though admittedly none of the IS-IS experts live there any more). So while the chances of something other than an RFC requesting a scope identifier seems neglible, using Expert Review covers us in case this ever happens. I have nothing invested here – if there is consensus that IETF Review is more appropriate I am fine with it – but the current choice was a conscious decision.

   Les


Nits: None

Thanks, Ross