Skip to main content

Early Review of draft-ietf-rtgwg-segment-routing-ti-lfa-10

Request Review of draft-ietf-rtgwg-segment-routing-ti-lfa-09
Requested revision 09 (document currently at 14)
Type Early Review
Team Security Area Directorate (secdir)
Deadline 2023-04-14
Requested 2023-03-20
Requested by Yingzhen Qu
Authors Ahmed Bashandy , Stephane Litkowski , Clarence Filsfils , Pierre Francois , Bruno Decraene , Daniel Voyer
I-D last updated 2023-05-11
Completed reviews Opsdir Early review of -12 by Gyan Mishra (diff)
Secdir Last Call review of -13 by Wes Hardaker (diff)
Rtgdir Last Call review of -13 by Ben Niven-Jenkins (diff)
Genart Last Call review of -13 by Roni Even (diff)
Opsdir Early review of -11 by Gyan Mishra (diff)
Secdir Early review of -10 by Wes Hardaker (diff)
Rtgdir Early review of -09 by Andy Smith (diff)
Intdir Early review of -11 by Antoine Fressancourt (diff)
The RTGWG chairs would like to request some early directorate reviews to prepare the draft for WGLC, which will start after IETF 116.
Assignment Reviewer Wes Hardaker
State Completed
Request Early review on draft-ietf-rtgwg-segment-routing-ti-lfa by Security Area Directorate Assigned
Posted at
Reviewed revision 10 (document currently at 14)
Result Not ready
Completed 2023-05-05
[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

- 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