Re: [Detnet] WG Last Call: draft-ietf-detnet-mpls-oam-08

Hi Tianran,
I've uploaded the -09 version of the draft that includes clarifications of
fields in the d-ACH as proposed in the text below. I greatly appreciate
your feedback and comments about the updates and my responses to your
questions.

Kind regards,
Greg

On Fri, Oct 21, 2022 at 12:15 AM Greg Mirsky <gregimirsky@gmail.com> wrote:

> Hi Tianran,
> thank you for your questions and comments. Please find responses in-lined
> below tagged with GIM>>. Attached are the diff and a copy of the working
> version of the draft.
>
> Regards,
> Greg
>
> On Wed, Oct 12, 2022 at 8:38 PM Tianran Zhou <zhoutianran=
> 40huawei.com@dmarc.ietf.org> wrote:
>
>> Hi Authors,
>>
>>
>>
>> I read this draft and find it’s useful.
>>
>> I have several suggestions as follows.
>>
>> 1. I am not clear why existing PW OAM cannot be used directly for DetNet.
>> I think there will be text to describe why 4 bytes are added, and also why
>> each field, like node id.
>>
> GIM>> As described in RFC 8655, DetNet headers may be needed to support
> DetNet service and forwarding sub-layers. Additional fields are added in
> support of OAM at the DetNet service sub-layer. Furthermore, we can note
> that a DetNet PW is more like an MS-PW, where DetNet service sub-layer
> functions are at the “segment” endpoints. However, DetNet service sub-layer
> functions operate per packet level (not per segment level). These
> per-packet level characteristics of PREOF require additional fields for
> proper OAM packet processing. Would the following update make it clearer:
> OLD TEXT:
>    DetNet OAM, like PW OAM, uses PW Associated Channel Header defined in
>    [RFC4385].  Encapsulation of a DetNet MPLS [RFC8964] active OAM
>    packet is shown in Figure 3.
> NEW TEXT:
>    DetNet OAM, like PW OAM, uses PW Associated Channel Header defined in
>    [RFC4385].  At the same time, a DetNet PW can be viewed as a Multi-
>    Segment PW, where DetNet service sub-layer functions are at the
>    segment endpoints.  However, DetNet service sub-layer functions
>    operate per packet level (not per segment level).  These per-packet
>    level characteristics of PREOF require additional fields for proper
>    OAM packet processing.  Encapsulation of a DetNet MPLS [RFC8964]
>    active OAM packet is shown in Figure 3.
>
> The Node ID field is described in the draft as follows:
>
>       Node ID - is an unsigned 20 bits-long field.  The value of the
>       Node ID field identifies the DetNet node that originated the
>       packet.  Methods of distributing Node ID are outside the scope of
>       this specification.
>
> 2. There is no description for Level,  Flags, and Session fields on the
>> meaning. I do not know how to use and how to extend.
>>
> GIM>> Thank you for pointing out too minimalistic descriptions.  The
> following text is updated in the working version:
> OLD TEXT:
>       Level - is a 3-bit field.
> NEW TEXT:
>       Level - is a 3-bit field.  Level field is used to cope with the
>       "all active path forwarding" characteristics of the PREOF concept.
>       A hierarchical relationship between OAM domains can be created
>       using the Level field value.
> And another update:
> OLD TEXT:
>       Session ID is a four-bits field.
> NEW TEXT:
>       Session ID - is a 4-bit field.  Session field is used to distinguish
>       OAM sessions originated from the same node (a given Maintenance
>       End Point may have multiple simultaneously active OAM sessions).
>
> 3. “Channel Type - contains the value of DetNet Associated Channel Type.”
>> This is confusing to me at first sight. It seem you are going to define a
>> new channel type. I struggled a while before I understand finally. So it
>> would be nice to revise the text.
>>
> GIM>> I greatly appreciate your suggestions to clarify the definition of
> the Channel Type field. Could you kindly propose the clarification making
> it clearer?
>
>> 4. You mentioned hybrid OAM a little bit in section 4. IMHO, it has
>> nothing to do with this draft, including the solution, the format. So, I
>> would suggest to clean up the hybrid OAM texts in this doc.
>>
> GIM>> We've discussed and agreed with your suggestion. Removed the section
> in the working version.
>
>>
>>
>> Best,
>>
>> Tianran
>>
>>
>>
>> *From:* detnet [mailto:detnet-bounces@ietf.org] *On Behalf Of *Janos
>> Farkas
>> *Sent:* Tuesday, October 11, 2022 10:23 PM
>> *To:* detnet@ietf.org
>> *Subject:* [Detnet] WG Last Call: draft-ietf-detnet-mpls-oam-08
>>
>>
>>
>> All,
>>
>>
>>
>> This starts working group last call on
>>
>> https://datatracker.ietf.org/doc/draft-ietf-detnet-mpls-oam/
>>
>>
>>
>> The working group last call ends on October 25th.
>>
>> Please send your comments to the working group mailing list.
>>
>>
>>
>> No IPR has been disclosed against this document.
>>
>>
>>
>> Positive comments, e.g., "I've reviewed this document and believe it is
>> ready for publication", are welcome!
>>
>> This is useful and important, even from authors.
>>
>>
>>
>> Thank you,
>>
>> János (DetNet Co-Chair & doc Shepherd)
>> _______________________________________________
>> detnet mailing list
>> detnet@ietf.org
>> https://www.ietf.org/mailman/listinfo/detnet
>>
>