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

[Greg Mirsky <[e-mail]>]

Lou,
many thanks for your comments, suggestions, and guidance. The new version
has been uploaded.

Regards,
Greg

On Thu, Oct 6, 2022 at 12:56 PM Lou Berger <[e-mail]> wrote:

> Greg,
>
> This version looks ready!
>
> Thank you
>
> Lou
> On 10/4/2022 11:59 AM, Greg Mirsky wrote:
>
> Hi Lou,
> I've switched the reference as you suggested (also removed the unnecessary
> I've introduced). I've updated the text to reference the DetNet Control
> Plane with "controller" as an example.
> Many thanks for your patience and help.
>
> Attached are the diff and the working version of the draft.
>
> Regards,
> Greg
>
> On Mon, Oct 3, 2022 at 1:17 PM Lou Berger <[e-mail]> wrote:
>
>> Greg,
>>
>> I suggest you instead reference RFC8655, the Deterministic Networking
>> Architecture. It uses consistent capitalization for the "DetNet Controller
>> Plane" term.
>>
>> I think you still have a few more instances of " centralized/central"
>> controller to clarify.
>>
>> Thanks!
>>
>> Lou
>> On 10/3/2022 4:08 PM, Greg Mirsky wrote:
>>
>> 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
>>>>>
>>>>