[big apologies: I wrote this a while ago but never hit send]

Reviewer: Wes Hardaker
Review result: Not Ready

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

Document: draft-ietf-rtgwg-segment-routing-ti-lfa
Reviewer: Wes Hardaker
Review Date: 2023-04-13 (early review)

These are generally fairly high level comments as a reviewer, as I
know this is an early review so I did not flag any grammatical or
other needed changes (aside from the one in the abstract: s/connected
network/connected networks/).


General comment: I found the document rather hard to read in general.
I think the reasons for this were two fold:

1. I am not extensively familiar with segment routing (even though I
have a decent about of more generalized routing background).  Thus,
much of the document is targeted toward someone that has read all of
the background material which I had not.  If I get asked to do the
final secdir review (which is likely), I'll fist read all the base
RFCs to get a better handle on what the draft is trying to accomplish.

2. To some extent, I found the document written somewhat backwards.
The beginning starts with rather dense text that provides no examples
or more detailed clarifications, while the ending of the document is
easier to read as spends more time spelling out the details.  In
particular, I think the example usage in section 10 with the diagram
and the example would be far better served if placed earlier in the
document so it could be used to set an example for discussions and
referred to by the remainder of the document.


Other comments:

- TLDP is referenced before definition or expansion

- The introduction is very very long.  This in itself is not a bad
  thing, but I'd recommend breaking it up into subsections to help the
  reader get a better handle on the break down of sub-topics.

- In section 1, the paragraph that starts with "From a network
  capacity planning... if link L fails on [node X], the bandwidth
  consumed on L will be spread over some of the remaining links of X".
  I do not think this is necessarily always true.  When a link fails,
  some routing may entirely route around X if other paths are shorter
  because the link that failed was critical in a shortest-path
  calculation.

- The section introductions at the bottom of section 1 skip
  introducing section 4, which considering is the "base principle" is
  worth including (even though short).

- The second paragraph of section 6 is an example of text that could
  use a longer description and additional references to an example.

- Although section 11 is interesting and brings real facts, these
  types of real-world datasets would be better listed in an appendix
  rather than part of the main document.  IMHO.

- With section 11 and more generally I don't see a cost measurement.
  What sort of resources does this algorithm take to execute?  How
  often would it need to be done?  From a security point of view, can
  I trigger a router (frequently) to do recalculations so I can cause
  it to waste resources?  Again, without being an expert in segment
  routing I'm not positive about this.  But I'd think an upstream
  would be able to trigger calculation events.  If any of this is
  possible, it would be worth mentioning in the security
  considerations section.


-- 
Wes Hardaker
USC/ISI