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

[James Guichard <[e-mail]>]

Hi Shwetha & Greg,

Thank you for the update.

I still believe however that more work is necessary to reconcile how SFC OAM is supposed to work. RFC 8300 says:

   O bit:  Setting this bit indicates an OAM packet (see [RFC6291<https://datatracker.ietf.org/doc/html/rfc6291>]
      The actual format and processing of SFC OAM packets is outside the
      scope of this specification (for example, see [SFC-OAM-FRAMEWORK<https://datatracker.ietf.org/doc/html/rfc8300#ref-SFC-OAM-FRAMEWORK>]
      for one approach).

      The O bit MUST be set for OAM packets and MUST NOT be set for
      non-OAM packets.

If we look at RFC6291 it simply describes what OAM is supposed to mean and this is independent from SFC. The SFC-OAM-Framework (now RFC 8924) in section 6.3 says:

   The Next Protocol field in the NSH header may be used to indicate what OAM function is intended
   or what toolset is used.  Any other overlay encapsulations used at the service layer must have a
   similar way to indicate the intended OAM function.

So my reading of this is that if you take 8300 together with the framework then 1. The O-bit MUST be set for OAM packets, and 2. The Next Protocol field may or may not be used to indicate which OAM function is to be applied. >From this I can determine that iOAM has taken the approach of using the next protocol field to indicate how to process the OAM packet and does NOT use the NSH context headers in any way shape or form. This seems consistent with the current definitions of the O-bit from RFC 8300 and processing guidelines from RFC 8924.

However, your document says:

4.1<https://datatracker.ietf.org/doc/html/draft-ietf-sfc-ioam-nsh-07#section-4.1>.  IOAM and the use of the NSH O-bit

   [RFC8300] defines an "O bit" for OAM packets.  Per [RFC8300<https://datatracker.ietf.org/doc/html/rfc8300>] the O
   bit must be set for OAM packets and must not be set for non-OAM
   packets.  Packets with IOAM data included MUST follow this
   definition, i.e. the O bit MUST NOT be set for regular customer
   traffic which also carries IOAM data and the O bit MUST be set for
   OAM packets which carry only IOAM data without any regular data
   payload.

This text basically says that if the packet is customer traffic and happens to carry iOAM data then it is NOT an OAM packet.  What am I missing, customer traffic or not, both carry iOAM data so how are they different within an SFC domain?

In addition to the above I will note that there is still a conflict with Greg's draft namely this text from section 4:

   *  O bit set and the "Next Protocol" value does not match the value
      Active SFC OAM (TBA1), defined in Section 10.1<https://datatracker.ietf.org/doc/html/draft-ietf-sfc-multi-layer-oam#section-10.1>:

         - An SFC NSH Context Header(s) contain an OAM processing
         instructions or data.

         - The "Next Protocol" field determines the type of the payload.

The above text suggests to me that if the O-bit is set and the next protocol is not active SFC OAM then it is *required* that OAM data will be in the NSH context headers (which is not the case for iOAM) and the next protocol will indicate what follows the NSH header. While iOAM does follow the NSH header as indicated by the next protocol there is still an expectation that OAM is also carried in the NSH context headers. This seems to be in conflict with RFC 8300 AND RFC 8924.

This of course is just my reading of the text and I would like to hear yours and other folks thoughts.

Jim

From: Shwetha Bhandari <[e-mail]>
Sent: Monday, January 31, 2022 11:25 PM
To: Greg Mirsky <[e-mail]>
Cc: James Guichard <[e-mail]>; [e-mail]; [e-mail]; [e-mail]
Subject: Re: [sfc] WGLC for https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/

Hi Greg,

Sorry for the late action on this. https://datatracker.ietf.org/doc/html/draft-ietf-sfc-ioam-nsh-07<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-sfc-ioam-nsh-07&data=04%7C01%7Cjames.n.guichard%40futurewei.com%7Caf9cde32be65486e459d08d9e53ac90c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637792862928234181%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=pl23JSzuzl5p2F8vooPyxVcUnWRdcWx%2F26MRFfJAIh4%3D&reserved=0> has been now posted with the edits per this discussion.

Hi Jim,

After Greg's review please let us know if the changes are good to progress the draft to the next step.

Thanks,
Shwetha

On Wed, Oct 27, 2021 at 7:31 PM Greg Mirsky <[e-mail]<mailto:[e-mail]>> wrote:
Hi Shwetha,
thank you for the detailed response to my comments. Please feel free to share any updates you're considering for the next version. I'll be glad to work together on these.
I have several follow-up notes in-lined below under the GIM>> tag.

Regards,
Greg

On Tue, Oct 26, 2021 at 6:51 PM Shwetha Bhandari <[e-mail]<mailto:[e-mail]>> wrote:
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]<mailto:[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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-ippm-ioam-direct-export%2F__%3B!!MZ3Fw45to5uY!db6q3n8-5YqHkLtf3wyeBoUpO72v7UzeDtfPNhyePahNAYMo9eFdQxxBWM4C7Z0OJKE0jphubQ%24&data=04%7C01%7Cjames.n.guichard%40futurewei.com%7Caf9cde32be65486e459d08d9e53ac90c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637792862928234181%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=i7sTr0MtC5qfzx3twOKSpbW8LkQJzsAJBxF%2FZPLUwKc%3D&reserved=0> 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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fippm%2FA0OcGQ5LlNjnjfRVp_iUTMYMrcs%2F__%3B!!MZ3Fw45to5uY!db6q3n8-5YqHkLtf3wyeBoUpO72v7UzeDtfPNhyePahNAYMo9eFdQxxBWM4C7Z0OJKHOndSFRg%24&data=04%7C01%7Cjames.n.guichard%40futurewei.com%7Caf9cde32be65486e459d08d9e53ac90c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637792862928234181%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=cHtvsgDl%2FuzSv70oS9LN5l2o5nEIwiKHDZ1sfiFJCrE%3D&reserved=0> 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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-ippm-ioam-direct-export%2F__%3B!!MZ3Fw45to5uY!db6q3n8-5YqHkLtf3wyeBoUpO72v7UzeDtfPNhyePahNAYMo9eFdQxxBWM4C7Z0OJKE0jphubQ%24&data=04%7C01%7Cjames.n.guichard%40futurewei.com%7Caf9cde32be65486e459d08d9e53ac90c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637792862928234181%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=i7sTr0MtC5qfzx3twOKSpbW8LkQJzsAJBxF%2FZPLUwKc%3D&reserved=0> and Loopback and Active flags defined in draft-ietf-ippm-ioam-flags<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-ippm-ioam-flags%2F__%3B!!MZ3Fw45to5uY!db6q3n8-5YqHkLtf3wyeBoUpO72v7UzeDtfPNhyePahNAYMo9eFdQxxBWM4C7Z0OJKHO7lReVw%24&data=04%7C01%7Cjames.n.guichard%40futurewei.com%7Caf9cde32be65486e459d08d9e53ac90c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637792862928234181%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=1kqtcu3xjl1C7ytQ%2BoaKdiQN96rQt94e1S2ElC0nD3M%3D&reserved=0>. 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.
GIM>> I agree that the definitions of the IOAM data-fields are invariant in various data plane encapsulations. You likely follow the discussion of the IAOM Direct Export and IOAM flags on the IPPM WG list. I think that for SFC NSH, IOAM Direct Export could be as simple as "use the local policy". The applicability of the Loopback and Active flags seems to require detailed explanation by SFP actors.



  *   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."
GIM>> I think that RFC 8300 views data following Context Headers as NSH payload, not being "in NSH".

  *   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.
GIM>> Thank you.

  *   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.
 GIM>> This is an interesting situation. I agree that there could be an SFC element not supporting "SFC OAM procedures" (not clear what these are). By the same token, would such SFC element support IOAM, be capable of processing IOAM without adverse impact to user data? I am not certain and it seems that it might be better to recommend that NSH packets with IOAM be dropped by an SFP element if it does not support "SFC OAM". What are your thoughts?


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]<mailto:[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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-sfc-ioam-nsh%2F__%3B!!MZ3Fw45to5uY!db6q3n8-5YqHkLtf3wyeBoUpO72v7UzeDtfPNhyePahNAYMo9eFdQxxBWM4C7Z0OJKHdTiRE6A%24&data=04%7C01%7Cjames.n.guichard%40futurewei.com%7Caf9cde32be65486e459d08d9e53ac90c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637792862928234181%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=9uDdhw0ViwBtWvn52V8UZ2G77lRnSye2Ols5z3U8QwQ%3D&reserved=0>



_______________________________________________
sfc mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/sfc<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsfc__%3B!!MZ3Fw45to5uY!db6q3n8-5YqHkLtf3wyeBoUpO72v7UzeDtfPNhyePahNAYMo9eFdQxxBWM4C7Z0OJKEKMsIVaA%24&data=04%7C01%7Cjames.n.guichard%40futurewei.com%7Caf9cde32be65486e459d08d9e53ac90c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637792862928234181%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Lrdp7ipXNWqDvp3mWkIQWF%2FJoClfmd4G3TlaH2kB550%3D&reserved=0>