> On May 1, 2017, at 4:03 AM, Brian Carpenter <brian.e.carpen...@gmail.com> > wrote: > > Reviewer: Brian Carpenter > Review result: Ready with Issues > > Gen-ART Last Call review of draft-ietf-spring-resiliency-use-cases-08 > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. > > Document: draft-ietf-spring-resiliency-use-cases-08.txt > Reviewer: Brian Carpenter > Review Date: 2017-05-01 > IETF LC End Date: 2017-05-04 > IESG Telechat date: > > Summary: Ready with issues > -------- > > Comment: > -------- > > I wonder about the value to the community of publishing use cases and > requirements late in the standards process. They clearly have value > while designing solutions, but do they really have archival value, > since > RFC7855 was published a year ago? (An alternative approach to use > case > documents is to structure them as example applications to validate > the > protocol design, but that would be a major rewrite.)
when spring was formed, it has been required from the AD (in charge at that time) to provide a problem-statement and use-case documents, hence this and the other use cases documents. The resiliency use cases draft describes one of the major requirements for SR. LFAs, and their intrinsic characteristic of being topology-dependent, have been worked out for many years without reaching the complete (any topology) coverage. SR closed the loop and we have now the ability to not only have a complete topology-independent LFA coverage, but also an efficient microloop-avoidance mechanisms. Therefore, it is important to have an ietf document describing the use-case that illustrates/drives the architectural choices of SR (and the related extensions of igp/bgp protocols). Now, one can argue that we are late in the process but so far no architectural document or even protocol extension have been standardized yet (even if for some of them we’re pretty well advanced). This is easily explained by the amount of SR drafts and the number of people involved in the. We had a lot of interactions (most of them have been extremely useful and constructive) and this, of course, consumes some time. Also, I’ve been told (but I may be wrong) that some ietf documents are still not sorted out after more than 18 years... so we have some room here ;-) > Major issue: > ------------ > > I agree with the AD review dated 2017-04-20; if we publish a use case > document of this kind, it should be historically consistent. which it seems they are knowing that no architectural document is published yet. > Minor issue: > ------------ > > The text of section 3 doesn't explain what requirements for SPRING it > generates. Really it just describes what any IGP will do anyway. not really. Igp’s compute Dijkstra-based shortest paths. Igp’s do not compute repair paths (whatever flavor: dual, parallel, disjoint, etc). > How does that impact SPRING? If there is no impact, please say so! spring is about source routing and resiliency makes use of source routing. Resiliency makes use of source routing through SR. > The other sections are quite clear on this aspect. Thanks for your review. s. _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
