Skip to main content

Last Call Review of draft-ietf-teas-rsvp-te-srlg-collect-02
review-ietf-teas-rsvp-te-srlg-collect-02-opsdir-lc-comstedt-2016-01-04-00

Request Review of draft-ietf-teas-rsvp-te-srlg-collect
Requested revision 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 Gonzalez de Dios , Matt Hartley , Zafar Ali , Cyril Margaria
Draft last updated 2016-01-04
Completed reviews Genart Last Call review of -02 by Elwyn B. Davies (diff)
Genart Last Call review of -06 by Elwyn B. Davies (diff)
Secdir Last Call review of -02 by Paul E. 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 revision 02 (document currently at 08)
Result Has Issues
Completed 2016-01-04
review-ietf-teas-rsvp-te-srlg-collect-02-opsdir-lc-comstedt-2016-01-04-00
Sorry for the duplicate to the authors, mistyped the OPS-DIR address.

/nco

> On Dec 17, 2015, at 8:24 AM, Niclas Comstedt <nco at comstedt.net> 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