Re: [Detnet] comments on draft-ietf-detnet-oam-framework-06

[Greg Mirsky <[e-mail]>]

Hi Lou,
apologies for missing the normative verbs and necessary updates to "DetNet
controller plane" terminology. I've added the reference to
draft-ietf-detnet-controller-plane-framework
<https://datatracker.ietf.org/doc/html/draft-ietf-detnet-controller-plane-framework-02>
as
Informational. A minor question about the capitalization of "DetNet
controller plane". It seems like the draft uses
capitalization interchangeably. I've used only lower case in the OAM draft.
Please let me know if that is acceptable.

Attached, please find the diff and the new working version of the draft.

Regards,
Greg

On Fri, Sep 30, 2022 at 5:17 AM Lou Berger <[e-mail]> wrote:

> Hi Greg,
>
> see below. I think the version you sent doesn't address everything
> discussed below.
>
> Also - this is important -  please update the draft with a current email
> address for Georgios as his current address bounces. If you don't have one,
> he must be moved to contributor.
> On 9/28/2022 12:47 PM, Greg Mirsky wrote:
>
> Hi Lou,
> thank you for your quick response and helpful suggestions to improve the
> document. I've applied them all. As usual, I've attached the diff to
> highlight all the updates and the working version of the draft.
> RE: the number of authors on the first page. I agree with the response
> you've proposed. I hope that IESG will thoughtfully consider this case.
>
> Regards,
> Greg
>
> On Wed, Sep 28, 2022 at 4:52 AM Lou Berger <[e-mail]> wrote:
>
>> Hi Greg,
>>
>>     Thanks for the response/update -- please see below.
>> On 9/27/2022 5:52 PM, Greg Mirsky wrote:
>>
>> Hi Lou,
>> thank you for the review, comments, and helpful suggestions. Please find
>> my notes and responses inlined below under the GIM>> tag. Attached is the
>> working version of the draft and the diff highlighting all updates.
>>
>> Regards,
>> Greg
>>
>> On Fri, Sep 23, 2022 at 11:13 AM Lou Berger <[e-mail]> wrote:
>>
>>> Hi,
>>>
>>> In preparing my shepherd write up, I noticed a few minor/editorial
>>> points that should be addressed before submission for publication to the
>>> IESG.
>>>
>>> - Number of authors:
>>> The IESG requires justification for more than 5 authors listed on the
>>> font page.  This document has 6.  Is anyone willing to move to
>>> contributor? If not, can you provide a justification for more than 5
>>> authors
>>>
>> GIM>> I believe that all authors, in the course of developing this
>> document, provided essential contributions.
>>
>>
>> The question that needs to be answered in the Shepherd write up is as
>> follows:
>>
>>
>> 13. ... If the total number of authors and editors on the front page
>>     is greater than five, please provide a justification.
>>
>> Do you want me to just say?
>>
>>     The authors believe all listed have provided essential contributions
>> in the course of developing this document.
>>
>> Keep in mind the IESG pushes back hard on more than 5 authors. If the
>> authors have a stronger justification, can you (authors) provide it.
>>
> I will try, but I expect that we will receive strong push back on this.
>
>
>
>>> - Inclusion of conformance boilerplate (Section 1.3) and conformance
>>> language.
>>>
>>> Generally informational documents do not include the conformance
>>> boilerplate or related language.  For example, there is none in the
>>> DetNet framework, RFC8939.  On the other hand RFC 4377, OAM Requirements
>>> for MPLS Networks, does.
>>>
>>> Is there really a need for such in this document? If you do, the scope
>>> of the requirement needs to be clear. (E.g, the requirements are on
>>> future solutions "DetNet OAM solutions MUST..." or "solutions providing
>>> DetNet OAM MUST..."). Or perhaps just a statement to this effect at the
>>> end of section 1.3 or start of section 6.
>>>
>>  GIM>>  I propose appending Section 1.3 with the following:
>>    The requirements language in Section 6
>>    applies to future implementations of DetNet OAM.
>>
>> How about
>>
>> The requirements language is used in Section 6 and applies to future
>> implementations of DetNet OAM.
>>
> I still see requirements terms in sections other than 6 in the version you
> sent out, e.g.,
>
>   3.  Operation
>
>    OAM features will enable DetNet with robust operation both for
>    forwarding and routing purposes.
>
>    It is worth noting that the test and data packets MUST follow the
>    same path, i.e., the connectivity verification has to be conducted
>    in-band without impacting the data traffic.  Test packets MUST share
>    fate with the monitored data traffic without introducing congestion
>    in normal network conditions.
>
>
>>> Section 3-5 I really don't see the need for conformance language in this
>>> section.
>>>
>> GIM>> Upon reviewing the last paragraph, propose to remove it altogether:
>> OLD TEXT:
>>    DetNet OAM mechanisms SHOULD allow a fault detection in real time.
>>    They MAY, when possible, predict faults based on current network
>>    conditions.  They MAY also identify and report the cause of the
>>    actual/predicted network failure.
>>
>>
>>>
>>> - Section 3.4, s/NOT RECOMMENDED/expected
>>>
>> GIM>> We've discussed this and propose the following update:
>>  OLD TEXT:
>>    DetNet is not expected to use multiple paths or links, i.e., Equal-
>>    Cost Multipath (ECMP) [RFC8939].  As the result, OAM in ECMP
>>    environment is outside the scope of this document.
>> NEW TEXT
>>    DetNet is not expected to use Equal-Cost Multipath (ECMP) [RFC8939].
>>    As the result, DetNet OAM in ECMP environment is outside the scope of
>> this
>>    document.
>>
>>
>>> - Section 5.2
>>> Can you rephrase/clarify the following sentence.  I frankly have no idea
>>> what is meant by it:
>>>
>>>      We need to provide mechanisms to patch the network
>>>     configuration.
>>>
>> GIM>> Thank you for pointing out this sentence to us. It is not really
>> related to OAM but seems more in place in a discussion of the management
>> plane. Hence, propose removing the sentence.
>>
>>>
>>> That's it!
>>>
>> The above all looks good -- thanks!
>>
>> GIM>> In the course of addressing your comments, we've come up with
>> several more editorial updates. Please let us know if these are helpful:
>> In Section 4:
>> OLD TEXT
>>    *  per path to detect misbehaving path when multiple paths are
>>       applied.
>> NEW TEXT
>>    *  per path to detect misbehaving path(s) when multiple paths are
>>       used for service protection.
>>
>> In Section 5, prepend the following new text to the first paragraph:
>> NEW TEXT:
>>    Service protection (provided by the DetNet service sub-layer) is
>> designed
>>    to cope with simple network failures, and it mitigates the immediate
>> reaction
>>    of the DetNet controller to network events.
>>
>> What about the case where a controller is not used? Do you perhaps mean
>> "DetNet Controller Plane"?
>>
> Note this is a general comment: The document mentions controller in many
> places.  To be consistent with the DetNet Architecture the document should
> allow for any 'Controller Plane' solution.  This should be easily fixed,
> starting in section 2.
>
> Thank you,
>
> Lou
>
> Lou
>>
>>
>>
>>> Thank you,
>>> Lou
>>>
>>