Last Call Review of draft-ietf-teas-rsvp-te-srlg-collect-02

Request Review of draft-ietf-teas-rsvp-te-srlg-collect
Requested rev. no specific revision (document currently at 08)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2015-09-24
Requested 2015-09-11
Authors Fatai Zhang, Oscar de Dios, Matt Hartley, Zafar Ali, Cyril Margaria
Draft last updated 2016-01-04
Completed reviews Genart Last Call review of -02 by Elwyn Davies (diff)
Genart Last Call review of -06 by Elwyn Davies (diff)
Secdir Last Call review of -02 by Paul Hoffman (diff)
Opsdir Last Call review of -02 by Niclas Comstedt (diff)
Opsdir Last Call review of -04 by Niclas Comstedt (diff)
Assignment Reviewer Niclas Comstedt 
State Completed
Review review-ietf-teas-rsvp-te-srlg-collect-02-opsdir-lc-comstedt-2016-01-04
Reviewed rev. 02 (document currently at 08)
Review result Has Issues
Review completed: 2016-01-04


Sorry for the duplicate to the authors, mistyped the OPS-DIR address.


> On Dec 17, 2015, at 8:24 AM, Niclas Comstedt <nco at> wrote:
> Hi
> I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG.  These  comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review.  Document editors and WG chairs should treat these comments just like any other last call comments.
> ======
> Status: Ready with issues
> I think the mechanism for collecting and recording SRLG info is fine. The way I read the whole draft I do have some minor concerns and feel there is a gap around an important area. It could be that some of these concerns are addressed elsewhere or intended not be in scope but including them here.
> Section 1.1, last paragraph. I don’t fully agree with this statement. You may not be able to derive the complete topology but given (to expand on your use case in here) enough CEs spread out you can conclude quite a bit, specifically more then what a provider would be ok with.
> Section 3.3. In the case where this is supported and collected isn’t the capability to update the SRLG information a ‘MUST’? Supporting the capability but without a mechanism to update it doesn’t seem useful
> Section 5.1, last paragraph. Its not entirely clear to me this paragraph (and the examples in the reference together with the rest of the doc) completely solves the original use case here. Or do see how to map and signal to ensure disjointness between the two paths of CE1<>CE2 as outside the scope of this doc? Which could be fine, i.e. this is focused on just providing a mechanism to record SRLG in the RRO.
> Section 6.1. Personally I would want this to be a ‘MUST’ for the exposure control. Mapping service is fine as ‘SHOULD’.
> /nco