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

[Greg Mirsky <[e-mail]>]

Hi Kiran,
thank you for your quick response. Please find my follow-up notes inlined
below under the GIM2>> tag.

Regards,
Greg

On Wed, Nov 30, 2022 at 9:53 AM Kiran Makhijani <[e-mail]>
wrote:

> Thanks Greg.
> Personally, I find version fields scary, therefore, wanted to see its
> value (e.g. I’d imagine that Node ID field size may need to grow in future
> or you need to add some kind of security signature as a new field,  etc.)
>  and of course, we cannot possibly list all cases exhaustively.
>
GIM2>> I consider using the Version field as a part of good engineering
practice in the protocol design.

> I guess you could add what you suggested below -  “Version field is needed
> if the update to d-ACH can not be introduced in a backward-compatible way”,
> similar to [RFC 4385].
>
GIM2>> I agree and will add it with the next update (part of -09).

> Btw, why is it default to 1? 4385 sets it to 0. From your explanation it
> does not seem they are related.
>
GIM2>>> Thank you for the question. That provides a logical reference to
RFC 4385. The defined value of the Version field in d-ACH is to further
differentiate between ACH defined in RFC 4385 and d-ACH defined in the
draft.

>
> With this document is good to go. BTW, I still see -08 in the datatracker (
> https://datatracker.ietf.org/doc/draft-ietf-detnet-mpls-oam/).
>
GIM2>> Thank you for catching this! I've uploaded -09 version.

>
> Cheers,
> Kiran
>
> On November 29, 2022 at 5:32:53 PM, Greg Mirsky ([e-mail])
> wrote:
>
> 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 <[e-mail]>
> 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 ([e-mail])
>> 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 <[e-mail]>
>> 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:[e-mail]]
>>> *发送时间:* 2022年11月9日 22:24
>>> *收件人:* Tianran Zhou <[e-mail]>
>>> *抄送:* Janos Farkas <[e-mail]>; [e-mail]
>>> *主题:* 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 <[e-mail]>
>>> 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=
>>> [e-mail]> 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:[e-mail]] *On Behalf Of *Janos
>>> Farkas
>>> *Sent:* Tuesday, October 11, 2022 10:23 PM
>>> *To:* [e-mail]
>>> *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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/detnet
>>>
>>> _______________________________________________
>> detnet mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/detnet
>>
>>