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

Hi Kiran,
thank you for your questions. Please find my notes inlined below under the
GIM>> tag. Please let me know if you have any further questions or
suggestions.

Regards,
Greg

On Tue, Nov 29, 2022 at 3:11 PM Kiran Makhijani <kiran.ietf@gmail.com>
wrote:

> Hi authors,
>
> My apologies for late comment. I went through the 08 version of the draft.
> The main concerns of not describing fields are taken care of in 09 in
> response to Tiaran’s comments.
>
> Similar to other fields if you can describe under what circumstances
> version change could be needed, that should clarify when to change this
> field. I am not to familiar with ACH format but if it exists already,
> please provide the reference.
>
GIM>> Providing an exhaustive list of all scenarios that would require a
new value for the Version field seems like a challenge. If I try to
generalize it, a new value for the Version field is needed if the update to
d-ACH can not be introduced in a backward-compatible way. Of course, we can
reference RFC 4385. Where in the text would you suggest it will be helpful?

>
> One thing I am not sure about is PREOF function in OAM vs d-CW. Is it an
> either  d-CW or d-ACH over S-label to carry sequence number or both of them
> can exist?
>
GIM>> Indeed, d-CW and d-ACH carry separate sequence number spaces. A node
that acts on the DetNet Service sub-layer uses the first nibble to
differentiate between d-CW and d-ACH sequence number encodings.

>
> Cheers,
> --Kiran
>
> On November 29, 2022 at 8:49:29 AM, Greg Mirsky (gregimirsky@gmail.com)
> wrote:
>
> Hi Janos,
> it appears that all the comments we've received during the WG LC have been
> addressed.  The authors greatly appreciate constructive comments and
> thoughtful suggestions from Ethan and Tianran. Do you see the conclusion of
> the WG LC on draft-ietf-detnet-mpls-oam? We're ready for the next steps in
> progressing this work.
>
> Regards,
> Greg (on behalf of the authors)
>
> On Fri, Nov 11, 2022 at 1:53 AM Tianran Zhou <zhoutianran@huawei.com>
> wrote:
>
>> Hi Grey,
>>
>> Thanks very much for taking my suggestion.
>>
>> I am comfortable with all the changes.
>>
>>
>>
>> 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?
>>
>>
>>
>> ZTR> I am not sure. Maybe “contains -> reuses” could be better? I think
>> in somewhere you would better describe something like, the proposed fields
>> are attached to existing ACHs as shown in figure *.
>>
>>
>>
>> Best,
>>
>> Tianran
>>
>>
>>
>> *发件人:* Greg Mirsky [mailto:gregimirsky@gmail.com]
>> *发送时间:* 2022年11月9日 22:24
>> *收件人:* Tianran Zhou <zhoutianran@huawei.com>
>> *抄送:* Janos Farkas <Janos.Farkas@ericsson.com>; detnet@ietf.org
>> *主题:* 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
>>
>> _______________________________________________
> detnet mailing list
> detnet@ietf.org
> https://www.ietf.org/mailman/listinfo/detnet
>
>