review-ietf-rtgwg-segment-routing-ti-lfa-10-secdir-early-hardaker-2023-05-11-00

["Stephane Litkowski (slitkows)" <[e-mail]>]

Hi Wes,

Thanks for your review and comments.

Please find some replies inline below







>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/).



[SLI] fixed in new version (V11)





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.



[SLI] I tried to simplify the intro and move some text in later sections in new version





Other comments:



- TLDP is referenced before definition or expansion

[SLI] fixed in new version



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



[SLI] I have reworked it and move some items in different section later in the document.



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



[SLI] You are right, this is why the sentence has "it is often assumed that".

The fact is events on rerouting on nodes after an event will happen in a non-ordered fashion. And there is a chance (potentially high) that the node that sees the failure will reroute first, in this case, traffic received on the node and that was flowing over the same link will be spread (potentially until upstream nodes will reroute on a completely different 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).



[SLI] Added.



- The second paragraph of section 6 is an example of text that could

  use a longer description and additional references to an example.



[SLI] I have added 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.



[SLI] Cost depend on exact implementation (two implementations may have different completely different costs), so IMO, there is no point of talking about that.

IGP topology events will trigger new TILFA backup path computation (in addition to the regular SPF computation). So, either you have direct access to IGP (unlikely), or you have access to a node which participates to the IGP and trigger topo changes (by playing with interfaces...).

But I'm not really sure if this has anything to do with TILFA, it's just about protecting IGP, so IGP protection mechanisms. Do you see anything special that TILFA adds and that may require additional protection for the IGP ?







Thanks




Brgds,

Stephane