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
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
