Subject: Re: Gen-art LC review: draft-ietf-teas-te-express-path-03

From: Jari Arkko <[email-masked]>
Date: Thu, 1 Oct 2015 16:03:06 +0300

Thanks for your review again, Robert!

Jari

---

From: Alia Atlas <[email-masked]>
Date: Thu, 1 Oct 2015 09:49:32 -0400

Hi Robert,

Thanks for your review.

On Mon, Sep 28, 2015 at 3:29 PM, Robert Sparks <[email-masked]> wrote:

> 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-teas-te-express-path-03
> Reviewer: Robert Sparks
> Review Date: 28 Sep 2015
> IETF LC End Date: 30 Sep 2015
> IESG Telechat date: 1 Oct 2015
>
> Summary: Ready for publication as Informational, with nits
>
> Nits/editorial comments:
>
> This document is all about considerations. Specifically, it discusses what
> to consider if you were to build a path computation function that uses the
> kind of information you get from the TE metric extensions in RFC7471 and
> draft-ietf-isis-te-metric-extensions. It does not appear to be requirements
> for standardization work - rather, it is information for operators to use
> when building functions that don't necessarily need standardization.
>
> However, it looks as if the document may have once contemplated actually
> specifying a path computation function, and has legacy text from that
> thought?
>

No - it was always about how one could use the information and isn't trying
to standardize a particular function.

> The abstract says "This specification uses network performance data ... to
> perform such path selections." But this document doesn't perform such path
> selections (or specify how to do them).
>

Would you prefer

"This specification describes how a path computation function may use
network performance data, such as is advertised via the OSPF and ISIS TE
metric extensions (defined outside the scope of this document) to perform
such path selections."

> Section 1.1 says "The following are the requirements that motivate this
> solution." But this draft doesn't actually specify a "solution". It
> discusses what to consider if you were to build a path computation
> function. Could this be framed as a set of goals to keep in mind while
> building your own such function?
>

Would you be ok with changing it to ".. that motivate this document?"

> The third paragraph of section 1.2 could use clarification. I suspect the
> word "even" in the 4th sentence should be removed, and the judgement in
> "There may be legitimate use" is out of place. Consider rewriting the
> paragraph using simpler sentences.
>

I've removed the word "even" and changed the last sentence about "There may
be legitimate use..." to be
"However, there may be uses of a..."

Section 2.3 appears to be considerations specifically for interpreting the
> anomalous bit in one specific extension? If so, the introduction to the
> section should call that out. If not, the section's structure needs
> improvement. The section also calls out two questions, but only discusses
> one of them explicitly.
>

 In Sec 2.3.1, the anomalous bit behavior is described for latency, loss,
and jitter.  On double-checking, I see that the Anomalous Bit was removed
for jitter in RFC7471 and draft-ietf-isis-te-metric-extensions.   I've
removed the last sentence in the second paragraph of 2.3.1 that discussed
how to handle that case.

Sec 2.3.2 discusses the second question and how to handle it in detail.

Thanks again for the review!  The changes will be in 04.

Regards,
Alia

> RjS

---

From: Robert Sparks <[email-masked]>
Date: Thu, 1 Oct 2015 09:18:20 -0500

On 10/1/15 8:49 AM, Alia Atlas wrote:
> Hi Robert,
>
> Thanks for your review.
>
> On Mon, Sep 28, 2015 at 3:29 PM, Robert Sparks <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     This document is all about considerations. Specifically, it
>     function that uses the kind of information you get from the TE
>     metric extensions in RFC7471 and
>     draft-ietf-isis-te-metric-extensions. It does not appear to be
>     requirements for standardization work - rather, it is information
>     for operators to use when building functions that don't
>     necessarily need standardization.
>
>     However, it looks as if the document may have once contemplated
>     actually specifying a path computation function, and has legacy
>     text from that thought?
>
>
> No - it was always about how one could use the information and isn't 
> trying to standardize a particular function.
>
>     The abstract says "This specification uses network performance
>     data ... to perform such path selections." But this document
>     doesn't perform such path selections (or specify how to do them).
>
>
> Would you prefer
>
> network performance data, such as is advertised via the OSPF and ISIS 
> TE metric extensions (defined outside the scope of this document) to 
> perform such path selections."
Yes, thanks!
>
>     Section 1.1 says "The following are the requirements that motivate
>     this solution." But this draft doesn't actually specify a
>     "solution". It discusses what to consider if you were to build a
>     path computation function. Could this be framed as a set of goals
>     to keep in mind while building your own such function?
>
>
They were used to drive the document contents (that's not obvious) and 
not to inform what an implementation should achieve?

Perhaps the sentence could be replaced with

"As these considerations were assembled, care was taken to discuss 
points relevant to an implementation's ability to:"

?

>
>     The third paragraph of section 1.2 could use clarification. I
>     suspect the word "even" in the 4th sentence should be removed, and
>     the judgement in "There may be legitimate use" is out of place.
>     Consider rewriting the paragraph using simpler sentences.
>
>
> I've removed the word "even" and changed the last sentence about 
> "There may be legitimate use..." to be
>     Section 2.3 appears to be considerations specifically for
>     interpreting the anomalous bit in one specific extension? If so,
>     the introduction to the section should call that out. If not, the
>     section's structure needs improvement. The section also calls out
>     two questions, but only discusses one of them explicitly.
>
>
>  In Sec 2.3.1, the anomalous bit behavior is described for latency, 
> loss, and jitter.  On double-checking, I see that the Anomalous Bit 
> was removed for jitter in RFC7471 and 
> draft-ietf-isis-te-metric-extensions.   I've removed the last sentence 
> in the second paragraph of 2.3.1 that discussed how to handle that case.
>

---

From: Alia Atlas <[email-masked]>
Date: Thu, 1 Oct 2015 10:29:10 -0400

On Thu, Oct 1, 2015 at 10:18 AM, Robert Sparks <[email-masked]> wrote:

>> This document is all about considerations. Specifically, it discusses
>> what to consider if you were to build a path computation function that uses
>> the kind of information you get from the TE metric extensions in RFC7471
>> and draft-ietf-isis-te-metric-extensions. It does not appear to be
>> requirements for standardization work - rather, it is information for
>> operators to use when building functions that don't necessarily need
>> standardization.
>>
>> The abstract says "This specification uses network performance data ...
>> to perform such path selections." But this document doesn't perform such
>> path selections (or specify how to do them).
>>
>
> Would you prefer
>
> They were used to drive the document contents (that's not obvious) and not
> to inform what an implementation should achieve?
>
> "As these considerations were assembled, care was taken to discuss points
> relevant to an implementation's ability to:"
>
> ?
>

What about "The following are the requirements considered for a path
computation function that uses network performance criteria."

Alia

> I've removed the word "even" and changed the last sentence about "There
> may be legitimate use..." to be

---

From: Robert Sparks <[email-masked]>
Date: Thu, 1 Oct 2015 09:31:17 -0500

On 10/1/15 9:29 AM, Alia Atlas wrote:
>
>
> On Thu, Oct 1, 2015 at 10:18 AM, Robert Sparks <[email-masked] 
>>     On Mon, Sep 28, 2015 at 3:29 PM, Robert Sparks
>>     <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>         discusses what to consider if you were to build a path
>>         computation function that uses the kind of information you
>>         get from the TE metric extensions in RFC7471 and
>>         draft-ietf-isis-te-metric-extensions. It does not appear to
>>         be requirements for standardization work - rather, it is
>>         information for operators to use when building functions that
>>         don't necessarily need standardization.
>>
>>         However, it looks as if the document may have once
>>         contemplated actually specifying a path computation function,
>>         and has legacy text from that thought?
>>
>>
>>     No - it was always about how one could use the information and
>>     isn't trying to standardize a particular function.
>>
>>         The abstract says "This specification uses network
>>         performance data ... to perform such path selections." But
>>         this document doesn't perform such path selections (or
>>         specify how to do them).
>>
>>
>>     Would you prefer
>>
>>     "This specification describes how a path computation function may
>>     use network performance data, such as is advertised via the OSPF
>>     and ISIS TE metric extensions (defined outside the scope of this
>>     document) to perform such path selections."
>     Yes, thanks!
>>
>>         Section 1.1 says "The following are the requirements that
>>         motivate this solution." But this draft doesn't actually
>>         specify a "solution". It discusses what to consider if you
>>         were to build a path computation function. Could this be
>>         framed as a set of goals to keep in mind while building your
>>         own such function?
>>
>>
>     They were used to drive the document contents (that's not obvious)
>     and not to inform what an implementation should achieve?
>
OK
>>         suspect the word "even" in the 4th sentence should be
>>         removed, and the judgement in "There may be legitimate use"
>>         is out of place. Consider rewriting the paragraph using
>>         simpler sentences.
>>
>>
>>         interpreting the anomalous bit in one specific extension? If
>>         so, the introduction to the section should call that out. If
>>         not, the section's structure needs improvement. The section
>>         also calls out two questions, but only discusses one of them
>>         explicitly.
>>
>>
>>      In Sec 2.3.1, the anomalous bit behavior is described for
>>     latency, loss, and jitter. On double-checking, I see that the
>>     Anomalous Bit was removed for jitter in RFC7471 and
>>     draft-ietf-isis-te-metric-extensions.   I've removed the last
>>     sentence in the second paragraph of 2.3.1 that discussed how to
>>     handle that case.
>>