Re: [RTG-DIR] Rtgdir last call review of draft-ietf-spring-oam-usecase-06

["Joel M. Halpern" <[e-mail]>]

Almost.
I believe the earlier email had agreed to replace pre-SR with non-SR. 
There are two uses of pre-SR stil in the document.

Otherwise, yes, these address my comments.

Yours,
Joel

On 7/1/17 4:52 PM, Carlos Pignataro (cpignata) wrote:
> Thanks for your review, Joel!
> 
> Revision -07, just submitted, should address all your concerns and 
> suggestions. Please let us know otherwise.
> 
> Thanks,
> 
> — Carlos.
> 
>> On Jun 22, 2017, at 9:29 AM, Joel Halpern <[e-mail] 
>> <mailto:[e-mail]>> wrote:
>>
>> Reviewer: Joel Halpern
>> Review result: Has Nits
>>
>> This is a rtg-dir requested review.
>>
>> Summary: Ready for publication as an Informational RFC with some minor 
>> items
>> that should be considered.
>>
>> Major: N/A
>>
>> Minor:
>>    The introduction treats having a single centralized monitoring 
>> system as an
>>    unalloyed positive.  To set context properly, it would seem more
>>    appropriate to note that many operators find such central systems 
>> useful,
>>    and the approach described here enables that when desired.
>>
>>    The reference in the introduction to IGP topology discovery is very
>>    confusing. "Adding MPLS topology awareness to an IGP speaking 
>> device hence
>>    enables a simple and scalable data plane based monitoring 
>> mechanism."  As
>>    noted later in the document, link-state IGPs provide topology 
>> awareness.
>>    So what is this part of the introduction trying to say? 
>>  (Side-note, not
>>    all IGPs are link state, although the applicability of Babel or RIP 
>> to MPLS
>>    Segment Routing is clearly outside the scope of this document.)
>>
>>    In section 5.1 in discussing path trace the reference is to RFC 
>> 4379 which
>>    is a clear source for path trace.  However, the text refers to "tree
>>    trace".  While that may have become a common phrase for the usage, 
>> it is
>>    not used in RFC 4379.  The term should either be explain, include a
>>    suitable reference, or not be used.
>>
>>   In section 5.3 on fault isolation, the text notes that the only 
>> difference
>>   between the test which succeeds and that which fails is the 
>> difference the
>>   the adjacency SID.  The text then goes on to say "Assuming the 
>> second probe
>>   has been routed correctly, the fault must have been occurring in R2 
>> which
>>   didn't forward the packet to the interface identified by its 
>> Adjacency SID
>>   663."  That does not follow.  If the link as failed in an undetected 
>> fashion
>>   (either in one direction or both), R2 would be functioning fine and the
>>   symptom would be the same.  Remotely detecting the difference between R2
>>   failing to forward and the link not working seems a much harder task.
>>
>>    The claim that the PMS can / should (intent is ambiguous) notify 
>> the router
>>    when it detects a path failure raises a number of issues.   It is 
>> not at
>>    all clear what the router would do with the notification.  (e.g. If it
>>    removed the link from service, then future monitoring would not be 
>> able to
>>    detect that the link was working.)  Either this needs to become a
>>    significantly larger section, or (more likely) the text needs to be 
>> removed.
>>
>> Editorial:
>>    Chapter 7 is titled dealing with non-SR environments.  Which makes 
>> sense.
>>    The text then switches to using "pre-SR" instead of "non-SR".  I would
>>    recommend that all uses of "pre-SR" be changed to "non-SR".
>>
> 
> —
> Carlos Pignataro, [e-mail] <mailto:[e-mail]>
> 
> /“Sometimes I use big words that I do not fully understand, to make 
> myself sound more photosynthesis."/
>