Subject: Re: [Teas] OPS-DIR review of draft-ietf-teas-rsvp-te-srlg-collect

From: "Matt Hartley (mhartley)" <[email-masked]>
Date: Thu, 17 Mar 2016 16:10:37 +0000

Niclas,

Many thanks for the review, and my apologies for taking so long to get back to you. We've published v-04 of this which hopefully addresses your comments. More inline:

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

I've added some words about this, with reference to the policy stuff later on

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

Yes. Fixed.

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

The document is focused on the signaling mechanisms. Section 1 is intended to give an overview of how the disjointness stuff works (and has been improved since v-02), as it's a significant use-case for the mechanisms in the document, but a full specification of that is out of scope.

> 
> Section 6.1. Personally I would want this to be a ‘MUST’ for the exposure
> control. Mapping service is fine as ‘SHOULD’.

Done.

Cheers

Matt

> /nco