Re: [sfc] WGLC for https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/

[Shwetha Bhandari <[e-mail]>]

Hi Greg,

Sorry for the very late reply. Please find responses to your comments
inline @Shwetha:



On Wed, Sep 8, 2021 at 3:30 AM Greg Mirsky <[e-mail]> wrote:

> Dear Authors and All,
> I've read the current version of the draft and have some comments I'd like
> to share with you. I much appreciate your thoughts on where this work
> should go considering developments in other IETF WGs. Please find my notes
> and questions below:
>
>    - It is stated in the Abstract that:
>
>    In-situ Operations, Administration, and Maintenance (IOAM) records
>    operational and telemetry information in the packet while the packet
>    traverses a path between two points in the network.
>
> But that is the case only for the pre-allocated and incremental trace
> option types. The Direct Export option
> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-direct-export/__;!!MZ3Fw45to5uY!db6q3n8-5YqHkLtf3wyeBoUpO72v7UzeDtfPNhyePahNAYMo9eFdQxxBWM4C7Z0OJKE0jphubQ$>
> does not write telemetry data into the data packet itself but export
> telemetry information in a specially constructed packet.
> And as we are talking about different IOAM trace options, the question of
> the scope of this document seems appropriate. There is a WGLC on two IOAM
> documents
> <https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/ippm/A0OcGQ5LlNjnjfRVp_iUTMYMrcs/__;!!MZ3Fw45to5uY!db6q3n8-5YqHkLtf3wyeBoUpO72v7UzeDtfPNhyePahNAYMo9eFdQxxBWM4C7Z0OJKHOndSFRg$>
> active through September 15th at the IPPM WG. I believe that it would be
> beneficial if we had a single document that describes the applicability of
> IOAM in all its functionality defined by documents in IPPM WG. Of course,
> that cannot be a moving target as that would not be helpful. But since the
> IPPM WG discusses the progress of two IOAM documents, it could be a great
> time to address the applicability of the Direct Export trace type
> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-direct-export/__;!!MZ3Fw45to5uY!db6q3n8-5YqHkLtf3wyeBoUpO72v7UzeDtfPNhyePahNAYMo9eFdQxxBWM4C7Z0OJKE0jphubQ$>
> and Loopback and Active flags defined in draft-ietf-ippm-ioam-flags
> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-flags/__;!!MZ3Fw45to5uY!db6q3n8-5YqHkLtf3wyeBoUpO72v7UzeDtfPNhyePahNAYMo9eFdQxxBWM4C7Z0OJKHO7lReVw$>.
> It would be concerning to have more than one SFC document describing the
> applicability of the generic IOAM mechanisms
>
>
Shwetha> This is a fair point. We will revise the  draft with text in the
abstract and Section 3 IOAM-Type to be updated to include the usage of
trace and DEX options.  The encapsulation of IOAM options within NSH itself
in its current form already supports all the IOAM Option Type defined both
from draft-ietf-ippm-ioam-data and draft-ietf-ippm-ioam-direct-export along
with the flags supported within the options. Hence the IOAM-data-field
definitions in the draft will remain unchanged.

>
>
>
>    - The location of the IOAM header in the SFC NSH-encapsulated packet
>    is defined in Section 3:
>
>    IOAM-Data-Fields are carried in NSH
>    using a next protocol header which follows the NSH MD context
>    headers.
>
> I've checked RFC 8300 but couldn't find it defines the Next Protocol
> header. Also, it appears that NSH Context headers are optional. Hence my
> question. Is the presence of an NSH Context header required when using
> IOAM? Could you clarify which mechanism is used to identify the payload of
> an SFC NSH-encapsulated packet as IOAM?
>
> Shwetha> We will reword it, it is not Next Protocol header but using IOAM
as a Next Protocol as described in Section 4.1 and requested in IANA
section. Following is the proposed text to align with the RFC 8300
reference to context headers following base header and service path header:
"The NSH is defined in [RFC8300].  IOAM-Data-Fields are carried in
NSH using a next protocol to identify IOAM data fields that follows NSH
context headers."

>
>    - If I understand the format of the IOAM header defined in Section 3
>    correctly, the header's length is limited by 1020 octets, while the
>    effective length containing IOAM options and data - 1016 octets. Is that
>    correct? What is the recommended technique of collecting IOAM data that
>    exceeds that limit?
>
> Shwetha > IOAM options inherently support specifying the size limits at
the node that added the IOAM options. While operationalizing the solution
the data types included and number of nodes expected to be adding the data
should be selected. This is covered in deployment
considerations draft-brockners-opsawg-ioam-deployment.

>
>    - In Section 4.1, I've found the text reflecting the history of the
>    discussion about how to carry the IOAM header using NSH encapsulation. As
>    the text has no normative value, I suggest moving it into an Appendix.
>
> Shwetha > Agreed, revised draft will have this section moved to Appendix.

>
>    - I find the rules of handling the O-bit in NSH listed in Section 4.2
>    inconsistent and confusing. The IOAM header is not part of NSH
>    encapsulation but is a part of the payload. But in one case, when user data
>    follows it, the O-bit must not be set as. If there's no user data after the
>    IOAM header, then the O-bit must be set. But from the perspective of NSH
>    encapsulation, it includes specially constructed data added for the sole
>    purpose of collecting OAM/telemetry information. Then, why, in one case,
>    the O-bit is cleared and in the other set if, in both cases, the
>    NSH-encapsulated packet is used to perform the OAM function?
>
> Shwetha > The reason for not setting the O-bit for packets that contains
actual user data is because RFC 8300 has " SF/SFF/SFC Proxy/Classifier
implementations that do not support

      SFC OAM procedures SHOULD discard packets with O bit set". It
will be undesirable to discard packets with O-bit set that carry user
data as IOAM can be inserted insitu.

For synthetic traffic created for OAM along with IOAM-data-fields in
NSH following the NSH OAM function with 0-bit set is desirable.


Thanks,
Shwetha

> I much appreciate your consideration of my comments and questions and
> looking forward to your feedback.
>
> Regards,
> Greg
>
> On Wed, Aug 18, 2021 at 5:32 AM James Guichard <
> [e-mail]> wrote:
>
>> Dear WG:
>>
>>
>>
>> This email starts a 2 week Working Group Last Call for
>> draft-ietf-sfc-ioam-nsh [1].
>>
>>
>>
>> Please read this document if you haven’t read the most recent version and
>> send your comments to the SFC WG list no later than September 1st 2021.
>>
>>
>>
>> If you are raising a point which you expect will be specifically debated
>> on the mailing list, consider using a specific email/thread for this point.
>>
>>
>>
>> Lastly, if you are an author or contributor please response to indicate
>> whether you know of any undisclosed IPR related to this document.
>>
>>
>>
>> Thanks!
>>
>>
>>
>> Jim & Joel
>>
>>
>>
>> [1] https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/
>> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/__;!!MZ3Fw45to5uY!db6q3n8-5YqHkLtf3wyeBoUpO72v7UzeDtfPNhyePahNAYMo9eFdQxxBWM4C7Z0OJKHdTiRE6A$>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> sfc mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/sfc
>> <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/sfc__;!!MZ3Fw45to5uY!db6q3n8-5YqHkLtf3wyeBoUpO72v7UzeDtfPNhyePahNAYMo9eFdQxxBWM4C7Z0OJKEKMsIVaA$>
>>
>