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

From: Shwetha Bhandari <[email-masked]>
Date: Sun, 3 Apr 2022 13:35:59 +0530

Hi Jim, Greg,

We have addressed the additional comments received in this discussion. Can
you please take a look :
https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-ioam-nsh-08.txt

Thanks,
Shwetha

On Thu, Feb 10, 2022 at 11:27 PM James Guichard <
[email-masked]> wrote:

> Hi Shwetha,
>
>
>
> My only point was that in the case of IOAM the O-bit seems to be obsolete
> as you use the next protocol field rather than the context headers. It
> seems to me that the definition of the O-bit should be that if set then the
> context headers are used to obtain the OAM instructions. Currently that is
> not what 8300 says. As I said in my previous emails I would really like to
> hear the WGs opinion on what to do with the O-bit and we certainly need to
> reconcile the various documents to be following the same standard.
>
>
>
> Jim
>
>
>
> *From:* Shwetha Bhandari <[email-masked]>
> *Sent:* Wednesday, February 9, 2022 9:57 AM
> *To:* Greg Mirsky <[email-masked]>
> *Cc:* James Guichard <[email-masked]>;
> [email-masked]; [email-masked]; [email-masked]
> *Subject:* Re: [sfc] WGLC for
> 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!f5SSgs9VAH1xxjFWgJMfr5ZlZH93z6GJlXoOgCmY8AVbjdeh2YlaUz632nE-HqDItW_8pjQ1iQ$>
>
>
>
> Hi Jim,
>
>
>
> On the O bit handling, are you suggesting that the O-bit for IOAM, that is
> carried as a next protocol following NSH header, is not applicable? Would
> removing the section on O-bit considerations resolve your concern?
>
>
>
> Hi Greg,
>
>
>
> >I have one more question. As the draft now mentions the option of using
> IOAM Direct Export to collect the IOAM data, it might be helpful reflecting
> that in the figure on p.2. I think that the caption "IOAM Option and Data
> Space" might be reworded to "IOAM Option and Optional Data Space".
>
> What are your thoughts?
>
> Yes, that will make it accurate. I will update the diagram and publish a
> new version.
>
>
>
> >I cannot find the text in the draft suggesting that an SFF that does not
> support IOAM may forward the packet with the NSH Next Protocol field equal
> to IOAM protocol identifier. Could you help me find it?
>
> Can you suggest text to help with this ? This would be a generic problem
> for NSH implementation when a next protocol is set to a value it does not
> understand. What should is recommended action in this situation?
>
>
>
>
>
> > For example, if the Loopback IOAM flag is set, the node is required to
> send a copy of the packet back to the IOAM encapsulating node. It is not
> clear to me how an SFF learns the identity of the IOAM encapsulating node
> and how it encapsulates the loopbacked packet. Can you help me find how it
> is supposed to work in the NSH?
>
>
> https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-flags#section-4.2
> <https://urldefense.com/v3/__https://nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Fdatatracker.ietf.org*2Fdoc*2Fhtml*2Fdraft-ietf-ippm-ioam-flags*23section-4.2&data=04*7C01*7Cjames.n.guichard*40futurewei.com*7Ca5db82494c32402334fc08d9ebdc83cf*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637800154631120774*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000&sdata=zcOpC0Gzzi8xzhttBqWaeaU3pMd0KDo*2FZYdGsEPG0uE*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUl!!MZ3Fw45to5uY!f5SSgs9VAH1xxjFWgJMfr5ZlZH93z6GJlXoOgCmY8AVbjdeh2YlaUz632nE-HqDItW_cH_6kAg$>
> :
>
>   A Loopback flag that is set indicates to the transit nodes processing
>
>    this option that they are to create a copy of the received packet and
>
>    send the copy back to the source of the packet.
>
> Given this is explained in the flag handling, do you see a need to define
> it again in NSH? IMHO the explanation of flag handling is quite generic for
> any packet based transport.
>
> Please share your thoughts and text suggestions to improve the draft for
> flag handling if it requires clarification.
>
>
>
>
>
> Thanks,
>
> Shwetha
>
>
>
> On Thu, Feb 3, 2022 at 6:48 AM Greg Mirsky <[email-masked]> wrote:
>
> Hi Shwetha,
>
> I have one more question. As the draft now mentions the option of using
> IOAM Direct Export to collect the IOAM data, it might be helpful reflecting
> that in the figure on p.2. I think that the caption "IOAM Option and Data
> Space" might be reworded to "IOAM Option and Optional Data Space".
>
> What are your thoughts?
>
>
>
> Regards,
>
> Greg
>
>
>
> On Wed, Feb 2, 2022 at 7:29 AM Shwetha Bhandari <
> [email-masked]> wrote:
>
> Hi Jim, Greg,
>
>
>
> Thanks for the follow up.
>
> 1) On O-bit: I am a bit confused about the O-bit feedback. Are you
> suggesting that it should not be a consideration for IOAM as it is handled
> as a next protocol and not as NSH context headers?
>
> What should a SFC element handle a packet containing IOAM as next header
> and does not implement IOAM and hence does not understand IOAM? I think
> O-bit helps in such situations to help such elements decide to drop or
> forward without processing the IOAM header.
>
> Let me know if that is not the case and if simply not considering O-bit in
> the context of IOAM is what you would recommend.
>
> 2) Active or Loopback flags
> <https://urldefense.com/v3/__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!eu05ObEvXtnVX2OXFzl0g16vk36xSqTyjMReG_i6BavtG_ru2AnjQSjXHiZ_Ve3sBjJRuHMBUg*24&data=04*7C01*7Cjames.n.guichard*40futurewei.com*7Ca5db82494c32402334fc08d9ebdc83cf*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637800154631277005*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000&sdata=DvpZHlkn0PNCP5*2BzFQzGayutZGPUMxJXtPll6nR8Ay8*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!MZ3Fw45to5uY!f5SSgs9VAH1xxjFWgJMfr5ZlZH93z6GJlXoOgCmY8AVbjdeh2YlaUz632nE-HqDItW_4eduZWg$> -
> there is nothing specific for NSH on how the flags are to be handled.  The
> IOAM specific fields are to be handled as recommended by the respective
> IOAM drafts. Do you see any specific NSH considerations to be documented
> for IOAM fields?
>
>
>
> Thanks,
>
> Shwetha
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Tue, Feb 1, 2022 at 4:29 PM James Guichard <
> [email-masked]> wrote:
>
> 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://urldefense.com/v3/__https://nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fdatatracker.ietf.org*2Fdoc*2Fhtml*2Frfc6291__*3B!!MZ3Fw45to5uY!bzL7Vb_jHltGMCbCwne2rywfzpGjZW4o3fVr4clCr4Ir10KydDyJy5gHA8obfbMABJs06rKUNw*24&data=04*7C01*7Cjames.n.guichard*40futurewei.com*7Ca5db82494c32402334fc08d9ebdc83cf*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637800154631277005*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000&sdata=4wRcNgj93har9TlylAfX*2BtbW24VCqfneSZd0rD9CRzs*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!MZ3Fw45to5uY!f5SSgs9VAH1xxjFWgJMfr5ZlZH93z6GJlXoOgCmY8AVbjdeh2YlaUz632nE-HqDItW8b5uw-Yg$>
> ]).
>
>       The actual format and processing of SFC OAM packets is outside the
>
>       scope of this specification (for example, see [SFC-OAM-FRAMEWORK
> <https://urldefense.com/v3/__https://nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fdatatracker.ietf.org*2Fdoc*2Fhtml*2Frfc8300*ref-SFC-OAM-FRAMEWORK__*3BIw!!MZ3Fw45to5uY!bzL7Vb_jHltGMCbCwne2rywfzpGjZW4o3fVr4clCr4Ir10KydDyJy5gHA8obfbMABJsisioAug*24&data=04*7C01*7Cjames.n.guichard*40futurewei.com*7Ca5db82494c32402334fc08d9ebdc83cf*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637800154631277005*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000&sdata=A6fkAO8CwRJeW5tLLEpU0GhZrqsBOm7nUiE1QiMxwVQ*3D&reserved=0__;JSUlJSUlJSUlJSUqJSUlJSUlJSUlJSUlJSUl!!MZ3Fw45to5uY!f5SSgs9VAH1xxjFWgJMfr5ZlZH93z6GJlXoOgCmY8AVbjdeh2YlaUz632nE-HqDItW_b7k_TUA$>
> ]
>
>       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://urldefense.com/v3/__https://nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fdatatracker.ietf.org*2Fdoc*2Fhtml*2Fdraft-ietf-sfc-ioam-nsh-07*section-4.1__*3BIw!!MZ3Fw45to5uY!bzL7Vb_jHltGMCbCwne2rywfzpGjZW4o3fVr4clCr4Ir10KydDyJy5gHA8obfbMABJtXMLMQUw*24&data=04*7C01*7Cjames.n.guichard*40futurewei.com*7Ca5db82494c32402334fc08d9ebdc83cf*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637800154631277005*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000&sdata=w3hANsqqvVWz5oeH*2BLfPwS*2Fxwh2hNERJwCw5zwdrAMA*3D&reserved=0__;JSUlJSUlJSUlJSUqJSUlJSUlJSUlJSUlJSUlJSU!!MZ3Fw45to5uY!f5SSgs9VAH1xxjFWgJMfr5ZlZH93z6GJlXoOgCmY8AVbjdeh2YlaUz632nE-HqDItW9Fp7_C8w$>.
> IOAM and the use of the NSH O-bit*
>
>
>
>    [RFC8300] defines an "O bit" for OAM packets.  Per [RFC8300
> <https://urldefense.com/v3/__https://nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fdatatracker.ietf.org*2Fdoc*2Fhtml*2Frfc8300__*3B!!MZ3Fw45to5uY!bzL7Vb_jHltGMCbCwne2rywfzpGjZW4o3fVr4clCr4Ir10KydDyJy5gHA8obfbMABJuMIrqXAQ*24&data=04*7C01*7Cjames.n.guichard*40futurewei.com*7Ca5db82494c32402334fc08d9ebdc83cf*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637800154631277005*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000&sdata=a*2BVevL6noSzqRzdWg6dscjiqevlLbxcgEdTEmfJAY7U*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!MZ3Fw45to5uY!f5SSgs9VAH1xxjFWgJMfr5ZlZH93z6GJlXoOgCmY8AVbjdeh2YlaUz632nE-HqDItW92fQLzlQ$>]
> 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://urldefense.com/v3/__https://nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fdatatracker.ietf.org*2Fdoc*2Fhtml*2Fdraft-ietf-sfc-multi-layer-oam*section-10.1__*3BIw!!MZ3Fw45to5uY!bzL7Vb_jHltGMCbCwne2rywfzpGjZW4o3fVr4clCr4Ir10KydDyJy5gHA8obfbMABJv1ohYIeg*24&data=04*7C01*7Cjames.n.guichard*40futurewei.com*7Ca5db82494c32402334fc08d9ebdc83cf*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637800154631277005*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000&sdata=HTLx6e4sQCvsjXZKxG1GA8XPvdswsQKEMIEABitkprw*3D&reserved=0__;JSUlJSUlJSUlJSUqJSUlJSUlJSUlJSUlJSUl!!MZ3Fw45to5uY!f5SSgs9VAH1xxjFWgJMfr5ZlZH93z6GJlXoOgCmY8AVbjdeh2YlaUz632nE-HqDItW-EwTZ2zw$>
> :
>
>
>
>          - 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 <[email-masked]>
> *Sent:* Monday, January 31, 2022 11:25 PM
> *To:* Greg Mirsky <[email-masked]>
> *Cc:* James Guichard <[email-masked]>;
> [email-masked]; [email-masked]; [email-masked]
> *Subject:* Re: [sfc] WGLC for
> https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/
> <https://urldefense.com/v3/__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!bzL7Vb_jHltGMCbCwne2rywfzpGjZW4o3fVr4clCr4Ir10KydDyJy5gHA8obfbMABJu3416GCQ*24&data=04*7C01*7Cjames.n.guichard*40futurewei.com*7Ca5db82494c32402334fc08d9ebdc83cf*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637800154631277005*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000&sdata=NKz8*2Fm*2Fh7WXjK0OP8NF4j5cQ*2FYgSrSMULRmDt*2FkX*2B10*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJQ!!MZ3Fw45to5uY!f5SSgs9VAH1xxjFWgJMfr5ZlZH93z6GJlXoOgCmY8AVbjdeh2YlaUz632nE-HqDItW8EWrHtpA$>
>
>
>
> Hi Greg,
>
>
>
> Sorry for the late action on this.
> https://datatracker.ietf.org/doc/html/draft-ietf-sfc-ioam-nsh-07
> <https://urldefense.com/v3/__https://nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fnam11.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Fdatatracker.ietf.org*2Fdoc*2Fhtml*2Fdraft-ietf-sfc-ioam-nsh-07*26data*3D04*7C01*7Cjames.n.guichard*40futurewei.com*7Caf9cde32be65486e459d08d9e53ac90c*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C1*7C637792862928234181*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*26sdata*3Dpl23JSzuzl5p2F8vooPyxVcUnWRdcWx*2F26MRFfJAIh4*3D*26reserved*3D0__*3BJSUlJSUlJSUlJSUlJSUlJSUlJSU!!MZ3Fw45to5uY!bzL7Vb_jHltGMCbCwne2rywfzpGjZW4o3fVr4clCr4Ir10KydDyJy5gHA8obfbMABJvEbkwM5w*24&data=04*7C01*7Cjames.n.guichard*40futurewei.com*7Ca5db82494c32402334fc08d9ebdc83cf*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637800154631277005*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000&sdata=dpoyXLu*2F9fGVSgLtewdI7wNfSPdrkhs7FtBdD3Aq7*2B0*3D&reserved=0__;JSUlJSUlJSUlJSUqKioqKiolJSoqKioqKioqKioqKiUlKiolJSUlJSUlJSUlJSUlJSUlJSUl!!MZ3Fw45to5uY!f5SSgs9VAH1xxjFWgJMfr5ZlZH93z6GJlXoOgCmY8AVbjdeh2YlaUz632nE-HqDItW9PuM1neA$>
> 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 <[email-masked]> 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 <
> [email-masked]> 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 <[email-masked]> 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://nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fnam11.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*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*26data*3D04*7C01*7Cjames.n.guichard*40futurewei.com*7Caf9cde32be65486e459d08d9e53ac90c*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C1*7C637792862928234181*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*26sdata*3Di7sTr0MtC5qfzx3twOKSpbW8LkQJzsAJBxF*2FZPLUwKc*3D*26reserved*3D0__*3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!MZ3Fw45to5uY!bzL7Vb_jHltGMCbCwne2rywfzpGjZW4o3fVr4clCr4Ir10KydDyJy5gHA8obfbMABJt0mRguJg*24&data=04*7C01*7Cjames.n.guichard*40futurewei.com*7Ca5db82494c32402334fc08d9ebdc83cf*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637800154631277005*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000&sdata=yVGpJY1y6dud5c44HOsptPjqEuXdNUa1DMzjAelvU5c*3D&reserved=0__;JSUlJSUlJSUlJSUqKioqKioqKioqKioqJSUqKioqKioqKioqKiolJSoqJSUlJSUlJSUlJSUlJSUlJSU!!MZ3Fw45to5uY!f5SSgs9VAH1xxjFWgJMfr5ZlZH93z6GJlXoOgCmY8AVbjdeh2YlaUz632nE-HqDItW-BwxdRIg$>
> 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://nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fnam11.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fmailarchive.ietf.org*2Farch*2Fmsg*2Fippm*2FA0OcGQ5LlNjnjfRVp_iUTMYMrcs*2F__*3B!!MZ3Fw45to5uY!db6q3n8-5YqHkLtf3wyeBoUpO72v7UzeDtfPNhyePahNAYMo9eFdQxxBWM4C7Z0OJKHOndSFRg*24*26data*3D04*7C01*7Cjames.n.guichard*40futurewei.com*7Caf9cde32be65486e459d08d9e53ac90c*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C1*7C637792862928234181*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*26sdata*3DcHtvsgDl*2FuzSv70oS9LN5l2o5nEIwiKHDZ1sfiFJCrE*3D*26reserved*3D0__*3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSU!!MZ3Fw45to5uY!bzL7Vb_jHltGMCbCwne2rywfzpGjZW4o3fVr4clCr4Ir10KydDyJy5gHA8obfbMABJu2SsX7cg*24&data=04*7C01*7Cjames.n.guichard*40futurewei.com*7Ca5db82494c32402334fc08d9ebdc83cf*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637800154631277005*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000&sdata=Y*2BwywuTSj4SpugrjmDTquAY0MZWKoT43CMjsyha*2FnOc*3D&reserved=0__;JSUlJSUlJSUlJSUqKioqKioqKioqKioqKiolJSoqKioqKioqKioqKiUlKiolJSUlJSUlJSUlJSUlJSUlJSUl!!MZ3Fw45to5uY!f5SSgs9VAH1xxjFWgJMfr5ZlZH93z6GJlXoOgCmY8AVbjdeh2YlaUz632nE-HqDItW-FRADPxg$>
> 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://nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fnam11.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*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*26data*3D04*7C01*7Cjames.n.guichard*40futurewei.com*7Caf9cde32be65486e459d08d9e53ac90c*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C1*7C637792862928234181*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*26sdata*3Di7sTr0MtC5qfzx3twOKSpbW8LkQJzsAJBxF*2FZPLUwKc*3D*26reserved*3D0__*3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!MZ3Fw45to5uY!bzL7Vb_jHltGMCbCwne2rywfzpGjZW4o3fVr4clCr4Ir10KydDyJy5gHA8obfbMABJt0mRguJg*24&data=04*7C01*7Cjames.n.guichard*40futurewei.com*7Ca5db82494c32402334fc08d9ebdc83cf*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637800154631277005*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000&sdata=yVGpJY1y6dud5c44HOsptPjqEuXdNUa1DMzjAelvU5c*3D&reserved=0__;JSUlJSUlJSUlJSUqKioqKioqKioqKioqJSUqKioqKioqKioqKiolJSoqJSUlJSUlJSUlJSUlJSUlJSU!!MZ3Fw45to5uY!f5SSgs9VAH1xxjFWgJMfr5ZlZH93z6GJlXoOgCmY8AVbjdeh2YlaUz632nE-HqDItW-BwxdRIg$>
> and Loopback and Active flags defined in draft-ietf-ippm-ioam-flags
> <https://urldefense.com/v3/__https://nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fnam11.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fdatatracker.ietf.org*2Fdoc*2Fdraft-ietf-ippm-ioam-flags*2F__*3B!!MZ3Fw45to5uY!db6q3n8-5YqHkLtf3wyeBoUpO72v7UzeDtfPNhyePahNAYMo9eFdQxxBWM4C7Z0OJKHO7lReVw*24*26data*3D04*7C01*7Cjames.n.guichard*40futurewei.com*7Caf9cde32be65486e459d08d9e53ac90c*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C1*7C637792862928234181*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*26sdata*3D1kqtcu3xjl1C7ytQ*2BoaKdiQN96rQt94e1S2ElC0nD3M*3D*26reserved*3D0__*3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!MZ3Fw45to5uY!bzL7Vb_jHltGMCbCwne2rywfzpGjZW4o3fVr4clCr4Ir10KydDyJy5gHA8obfbMABJt8NqRRKg*24&data=04*7C01*7Cjames.n.guichard*40futurewei.com*7Ca5db82494c32402334fc08d9ebdc83cf*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637800154631277005*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000&sdata=zzcnXlewWKrtEDv4BmsNNk4pvDlMKNKvPzBZ2dZJm5k*3D&reserved=0__;JSUlJSUlJSUlJSUqKioqKioqKioqKioqJSUqKioqKioqKioqKiolJSoqJSUlJSUlJSUlJSUlJSUlJSU!!MZ3Fw45to5uY!f5SSgs9VAH1xxjFWgJMfr5ZlZH93z6GJlXoOgCmY8AVbjdeh2YlaUz632nE-HqDItW-gOuTqwg$>.
> 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 <
> [email-masked]> 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://nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fnam11.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fdatatracker.ietf.org*2Fdoc*2Fdraft-ietf-sfc-ioam-nsh*2F__*3B!!MZ3Fw45to5uY!db6q3n8-5YqHkLtf3wyeBoUpO72v7UzeDtfPNhyePahNAYMo9eFdQxxBWM4C7Z0OJKHdTiRE6A*24*26data*3D04*7C01*7Cjames.n.guichard*40futurewei.com*7Caf9cde32be65486e459d08d9e53ac90c*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C1*7C637792862928234181*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*26sdata*3D9uDdhw0ViwBtWvn52V8UZ2G77lRnSye2Ols5z3U8QwQ*3D*26reserved*3D0__*3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSU!!MZ3Fw45to5uY!bzL7Vb_jHltGMCbCwne2rywfzpGjZW4o3fVr4clCr4Ir10KydDyJy5gHA8obfbMABJv33kGkLw*24&data=04*7C01*7Cjames.n.guichard*40futurewei.com*7Ca5db82494c32402334fc08d9ebdc83cf*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637800154631277005*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000&sdata=S6sx7MrrVkzKepVgj45q*2F2KPZzBMyOFnol*2BMfgRQ730*3D&reserved=0__;JSUlJSUlJSUlJSUqKioqKioqKioqKioqJSUqKioqKioqKioqKiolJSolJSUlJSUlJSUlJSUlJSUlJSUl!!MZ3Fw45to5uY!f5SSgs9VAH1xxjFWgJMfr5ZlZH93z6GJlXoOgCmY8AVbjdeh2YlaUz632nE-HqDItW-FOmuSHA$>
>
>
>
>
>
>
>
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc
> <https://urldefense.com/v3/__https://nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fnam11.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Fsfc__*3B!!MZ3Fw45to5uY!db6q3n8-5YqHkLtf3wyeBoUpO72v7UzeDtfPNhyePahNAYMo9eFdQxxBWM4C7Z0OJKEKMsIVaA*24*26data*3D04*7C01*7Cjames.n.guichard*40futurewei.com*7Caf9cde32be65486e459d08d9e53ac90c*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C1*7C637792862928234181*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*26sdata*3DLrdp7ipXNWqDvp3mWkIQWF*2FJoClfmd4G3TlaH2kB550*3D*26reserved*3D0__*3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!MZ3Fw45to5uY!bzL7Vb_jHltGMCbCwne2rywfzpGjZW4o3fVr4clCr4Ir10KydDyJy5gHA8obfbMABJv0WsQtHA*24&data=04*7C01*7Cjames.n.guichard*40futurewei.com*7Ca5db82494c32402334fc08d9ebdc83cf*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637800154631277005*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000&sdata=Xj4fU0JctSsPl6a36R*2Bp9N4RkQ*2Bs8m4V7s9Qm2HHIVw*3D&reserved=0__;JSUlJSUlJSUlJSUqKioqKioqKioqKioqJSUqKioqKioqKioqKiolJSoqJSUlJSUlJSUlJSUlJSUlJSUlJQ!!MZ3Fw45to5uY!f5SSgs9VAH1xxjFWgJMfr5ZlZH93z6GJlXoOgCmY8AVbjdeh2YlaUz632nE-HqDItW8h731QiA$>
>
>

---

From: Greg Mirsky <[email-masked]>
Date: Sun, 3 Apr 2022 13:11:04 -0700

Hi Shwetha,
thank you for your kind consideration of my comments and for
thoroughly addressing those in the new version. I've noticed that you've
decided to remove the discussion of the O bit in the NSH from the draft
altogether. I think that it might be helpful to a reader if the document
includes a short clarification and the reference to
draft-ietf-sfc-oam-packet
<https://www.ietf.org/id/draft-ietf-sfc-oam-packet-00.html> like the
following:

For the IOAM functionality is SFC NSH described in this document the O bit
in NSH MUST be set clear according to [I-D.ietf-sfc-oam-packet].

Regards,
Greg

On Sun, Apr 3, 2022 at 1:06 AM Shwetha Bhandari <
[email-masked]> wrote:

>> On the O bit handling, are you suggesting that the O-bit for IOAM, that
>> is carried as a next protocol following NSH header, is not applicable?
>> Would removing the section on O-bit considerations resolve your concern?
>>
>>
>>
>> Hi Greg,
>>
>>
>>
>> Let me know if that is not the case and if simply not considering O-bit
>> in the context of IOAM is what you would recommend.
>>
>> 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:
>>
>>
>>
>> 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
>> 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
>> After Greg's review please let us know if the changes are good to
>> progress the draft to the next step.
>>
>>
>>
>> Thanks,
>>
>> Shwetha
>>
>>
>>
>> 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
>> the scope of this document seems appropriate. There is a WGLC on two
>> IOAM documents

---

From: Shwetha Bhandari <[email-masked]>
Date: Mon, 4 Apr 2022 06:10:30 +0530

Hi Greg,

Thanks for the feedback. From the discussion and Jim's feedback
 "My only point was that in the case of IOAM the O-bit seems to be obsolete
as you use the next protocol field rather than the context headers. It
seems to me that the definition of the O-bit should be that if set then the
context headers are used to obtain the OAM instructions."
Which makes sense. The O-bit does not influence IOAM handling as it is
carried as a next protocol.
Hence the consideration section on O-bit is removed in the new revision.
What do you think?

Thanks
Shwetha

On Mon, Apr 4, 2022, 1:41 AM Greg Mirsky <[email-masked]> wrote:

> <https://urldefense.com/v3/__https://www.ietf.org/id/draft-ietf-sfc-oam-packet-00.html__;!!MZ3Fw45to5uY!JYVtUwScRxFf7rDoRMpiv7YwbRTcaHXzsGIxr9eVEi_p_xSQUWAjDvFy_UhGEQbl8530VaLM0Tj7k5Wzu6YfUSVditWyZ_8$> like
> the following:
>
>> We have addressed the additional comments received in this discussion.
>> Can you please take a look :
>> <https://urldefense.com/v3/__https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-ioam-nsh-08.txt__;!!MZ3Fw45to5uY!JYVtUwScRxFf7rDoRMpiv7YwbRTcaHXzsGIxr9eVEi_p_xSQUWAjDvFy_UhGEQbl8530VaLM0Tj7k5Wzu6YfUSVd4KRpUCA$>
>>
>> Thanks,
>> Shwetha
>>
>>> My only point was that in the case of IOAM the O-bit seems to be
>>> obsolete as you use the next protocol field rather than the context
>>> headers. It seems to me that the definition of the O-bit should be that if
>>> set then the context headers are used to obtain the OAM instructions.
>>> Currently that is not what 8300 says. As I said in my previous emails I
>>> would really like to hear the WGs opinion on what to do with the O-bit and
>>> we certainly need to reconcile the various documents to be following the
>>> same standard.
>>>
>>>
>>>
>>> Jim
>>>
>>>
>>>
>>> >I cannot find the text in the draft suggesting that an SFF that does
>>> not support IOAM may forward the packet with the NSH Next Protocol field
>>> equal to IOAM protocol identifier. Could you help me find it?
>>>
>>> Given this is explained in the flag handling, do you see a need to
>>> define it again in NSH? IMHO the explanation of flag handling is quite
>>> generic for any packet based transport.
>>>
>>>    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
>>>
>>> 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
>>> 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
>>> 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
>>>    - 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
>>> 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.
>>>
>>>
>>>

---

From: <[email-masked]>
Date: Mon, 4 Apr 2022 05:39:38 +0000

Hi Shwetha, all,

I agree with Greg that a statement is needed to be added to draft-ietf-sfc-oam-packet.

For example, the current text says the following:

      Next Protocol:  8-bit unsigned integer that determines the type of
         header following IOAM.  The semantics of this field are
         identical to the Next Protocol field in [RFC8300<https://datatracker.ietf.org/doc/html/rfc8300>].

which means that “None” is authorized. The O-bit must be set for such packets, while it should be unset for other values indicating user payload as per draft-ietf-sfc-oam-packet. Absent a pointer to the OAM packet, an implementer will have to guess the behavior to follow.

BTW, the text quoted above when combined with:

   IANA is requested to allocate protocol numbers for the following "NSH
   Next Protocol" related to IOAM:

…means that IOAM data can be encapsulated in IOAM data. I don’t think you want such a behavior. No?

One last comment: please update the security considerations with NSH-specific considerations. An approach is to simply refer to Section 5 of draft-ietf-sfc-oam-packet.

Cheers,
Med

De : sfc <[email-masked]> De la part de Shwetha Bhandari
Envoyé : lundi 4 avril 2022 02:41
À : Greg Mirsky <[email-masked]>
Cc : [email-masked]; Frank Brockners (fbrockne) <[email-masked]>; [email-masked]; James Guichard <[email-masked]>; Tal Mizrahi <[email-masked]>; [email-masked]
Objet : Re: [sfc] WGLC for https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/

Hi Greg,

Thanks for the feedback. From the discussion and Jim's feedback
 "My only point was that in the case of IOAM the O-bit seems to be obsolete as you use the next protocol field rather than the context headers. It seems to me that the definition of the O-bit should be that if set then the context headers are used to obtain the OAM instructions."
Which makes sense. The O-bit does not influence IOAM handling as it is carried as a next protocol.
Hence the consideration section on O-bit is removed in the new revision. What do you think?

Thanks
Shwetha

On Mon, Apr 4, 2022, 1:41 AM Greg Mirsky <[email-masked]<mailto:[email-masked]>> wrote:
Hi Shwetha,
thank you for your kind consideration of my comments and for thoroughly addressing those in the new version. I've noticed that you've decided to remove the discussion of the O bit in the NSH from the draft altogether. I think that it might be helpful to a reader if the document includes a short clarification and the reference to draft-ietf-sfc-oam-packet<https://urldefense.com/v3/__https:/www.ietf.org/id/draft-ietf-sfc-oam-packet-00.html__;!!MZ3Fw45to5uY!JYVtUwScRxFf7rDoRMpiv7YwbRTcaHXzsGIxr9eVEi_p_xSQUWAjDvFy_UhGEQbl8530VaLM0Tj7k5Wzu6YfUSVditWyZ_8$> like the following:
For the IOAM functionality is SFC NSH described in this document the O bit
in NSH MUST be set clear according to [I-D.ietf-sfc-oam-packet].

Regards,
Greg

On Sun, Apr 3, 2022 at 1:06 AM Shwetha Bhandari <[email-masked]<mailto:[email-masked]>> wrote:
Hi Jim, Greg,

We have addressed the additional comments received in this discussion. Can you please take a look :
https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-ioam-nsh-08.txt<https://urldefense.com/v3/__https:/www.ietf.org/rfcdiff?url2=draft-ietf-sfc-ioam-nsh-08.txt__;!!MZ3Fw45to5uY!JYVtUwScRxFf7rDoRMpiv7YwbRTcaHXzsGIxr9eVEi_p_xSQUWAjDvFy_UhGEQbl8530VaLM0Tj7k5Wzu6YfUSVd4KRpUCA$>

Thanks,
Shwetha

On Thu, Feb 10, 2022 at 11:27 PM James Guichard <[email-masked]<mailto:[email-masked]>> wrote:
Hi Shwetha,

My only point was that in the case of IOAM the O-bit seems to be obsolete as you use the next protocol field rather than the context headers. It seems to me that the definition of the O-bit should be that if set then the context headers are used to obtain the OAM instructions. Currently that is not what 8300 says. As I said in my previous emails I would really like to hear the WGs opinion on what to do with the O-bit and we certainly need to reconcile the various documents to be following the same standard.

Jim

From: Shwetha Bhandari <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, February 9, 2022 9:57 AM
To: Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Cc: James Guichard <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] WGLC for 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!f5SSgs9VAH1xxjFWgJMfr5ZlZH93z6GJlXoOgCmY8AVbjdeh2YlaUz632nE-HqDItW_8pjQ1iQ$>

Hi Jim,

On the O bit handling, are you suggesting that the O-bit for IOAM, that is carried as a next protocol following NSH header, is not applicable? Would removing the section on O-bit considerations resolve your concern?

Hi Greg,

>I have one more question. As the draft now mentions the option of using IOAM Direct Export to collect the IOAM data, it might be helpful reflecting that in the figure on p.2. I think that the caption "IOAM Option and Data Space" might be reworded to "IOAM Option and Optional Data Space".
What are your thoughts?
Yes, that will make it accurate. I will update the diagram and publish a new version.

>I cannot find the text in the draft suggesting that an SFF that does not support IOAM may forward the packet with the NSH Next Protocol field equal to IOAM protocol identifier. Could you help me find it?
Can you suggest text to help with this ? This would be a generic problem for NSH implementation when a next protocol is set to a value it does not understand. What should is recommended action in this situation?

> For example, if the Loopback IOAM flag is set, the node is required to send a copy of the packet back to the IOAM encapsulating node. It is not clear to me how an SFF learns the identity of the IOAM encapsulating node and how it encapsulates the loopbacked packet. Can you help me find how it is supposed to work in the NSH?
https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-flags#section-4.2<https://urldefense.com/v3/__https:/nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Fdatatracker.ietf.org*2Fdoc*2Fhtml*2Fdraft-ietf-ippm-ioam-flags*23section-4.2&data=04*7C01*7Cjames.n.guichard*40futurewei.com*7Ca5db82494c32402334fc08d9ebdc83cf*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637800154631120774*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000&sdata=zcOpC0Gzzi8xzhttBqWaeaU3pMd0KDo*2FZYdGsEPG0uE*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUl!!MZ3Fw45to5uY!f5SSgs9VAH1xxjFWgJMfr5ZlZH93z6GJlXoOgCmY8AVbjdeh2YlaUz632nE-HqDItW_cH_6kAg$>:

   send the copy back to the source of the packet.
Given this is explained in the flag handling, do you see a need to define it again in NSH? IMHO the explanation of flag handling is quite generic for any packet based transport.
Please share your thoughts and text suggestions to improve the draft for flag handling if it requires clarification.

Thanks,
Shwetha

On Thu, Feb 3, 2022 at 6:48 AM Greg Mirsky <[email-masked]<mailto:[email-masked]>> wrote:
Hi Shwetha,
I have one more question. As the draft now mentions the option of using IOAM Direct Export to collect the IOAM data, it might be helpful reflecting that in the figure on p.2. I think that the caption "IOAM Option and Data Space" might be reworded to "IOAM Option and Optional Data Space".
What are your thoughts?

Regards,
Greg

On Wed, Feb 2, 2022 at 7:29 AM Shwetha Bhandari <[email-masked]<mailto:[email-masked]>> wrote:
Hi Jim, Greg,

Thanks for the follow up.
1) On O-bit: I am a bit confused about the O-bit feedback. Are you suggesting that it should not be a consideration for IOAM as it is handled as a next protocol and not as NSH context headers?
What should a SFC element handle a packet containing IOAM as next header and does not implement IOAM and hence does not understand IOAM? I think O-bit helps in such situations to help such elements decide to drop or forward without processing the IOAM header.
Let me know if that is not the case and if simply not considering O-bit in the context of IOAM is what you would recommend.
2) Active or Loopback flags<https://urldefense.com/v3/__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!eu05ObEvXtnVX2OXFzl0g16vk36xSqTyjMReG_i6BavtG_ru2AnjQSjXHiZ_Ve3sBjJRuHMBUg*24&data=04*7C01*7Cjames.n.guichard*40futurewei.com*7Ca5db82494c32402334fc08d9ebdc83cf*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637800154631277005*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000&sdata=DvpZHlkn0PNCP5*2BzFQzGayutZGPUMxJXtPll6nR8Ay8*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!MZ3Fw45to5uY!f5SSgs9VAH1xxjFWgJMfr5ZlZH93z6GJlXoOgCmY8AVbjdeh2YlaUz632nE-HqDItW_4eduZWg$> - there is nothing specific for NSH on how the flags are to be handled.  The IOAM specific fields are to be handled as recommended by the respective IOAM drafts. Do you see any specific NSH considerations to be documented for IOAM fields?

Thanks,
Shwetha

On Tue, Feb 1, 2022 at 4:29 PM James Guichard <[email-masked]<mailto:[email-masked]>> wrote:
Hi Shwetha & Greg,

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://urldefense.com/v3/__https:/nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fdatatracker.ietf.org*2Fdoc*2Fhtml*2Frfc6291__*3B!!MZ3Fw45to5uY!bzL7Vb_jHltGMCbCwne2rywfzpGjZW4o3fVr4clCr4Ir10KydDyJy5gHA8obfbMABJs06rKUNw*24&data=04*7C01*7Cjames.n.guichard*40futurewei.com*7Ca5db82494c32402334fc08d9ebdc83cf*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637800154631277005*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000&sdata=4wRcNgj93har9TlylAfX*2BtbW24VCqfneSZd0rD9CRzs*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!MZ3Fw45to5uY!f5SSgs9VAH1xxjFWgJMfr5ZlZH93z6GJlXoOgCmY8AVbjdeh2YlaUz632nE-HqDItW8b5uw-Yg$>]).
      The actual format and processing of SFC OAM packets is outside the
      scope of this specification (for example, see [SFC-OAM-FRAMEWORK<https://urldefense.com/v3/__https:/nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fdatatracker.ietf.org*2Fdoc*2Fhtml*2Frfc8300*ref-SFC-OAM-FRAMEWORK__*3BIw!!MZ3Fw45to5uY!bzL7Vb_jHltGMCbCwne2rywfzpGjZW4o3fVr4clCr4Ir10KydDyJy5gHA8obfbMABJsisioAug*24&data=04*7C01*7Cjames.n.guichard*40futurewei.com*7Ca5db82494c32402334fc08d9ebdc83cf*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637800154631277005*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000&sdata=A6fkAO8CwRJeW5tLLEpU0GhZrqsBOm7nUiE1QiMxwVQ*3D&reserved=0__;JSUlJSUlJSUlJSUqJSUlJSUlJSUlJSUlJSUl!!MZ3Fw45to5uY!f5SSgs9VAH1xxjFWgJMfr5ZlZH93z6GJlXoOgCmY8AVbjdeh2YlaUz632nE-HqDItW_b7k_TUA$>]
      for one approach).

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.

4.1<https://urldefense.com/v3/__https:/nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fdatatracker.ietf.org*2Fdoc*2Fhtml*2Fdraft-ietf-sfc-ioam-nsh-07*section-4.1__*3BIw!!MZ3Fw45to5uY!bzL7Vb_jHltGMCbCwne2rywfzpGjZW4o3fVr4clCr4Ir10KydDyJy5gHA8obfbMABJtXMLMQUw*24&data=04*7C01*7Cjames.n.guichard*40futurewei.com*7Ca5db82494c32402334fc08d9ebdc83cf*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637800154631277005*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000&sdata=w3hANsqqvVWz5oeH*2BLfPwS*2Fxwh2hNERJwCw5zwdrAMA*3D&reserved=0__;JSUlJSUlJSUlJSUqJSUlJSUlJSUlJSUlJSUlJSU!!MZ3Fw45to5uY!f5SSgs9VAH1xxjFWgJMfr5ZlZH93z6GJlXoOgCmY8AVbjdeh2YlaUz632nE-HqDItW9Fp7_C8w$>.  IOAM and the use of the NSH O-bit

   [RFC8300] defines an "O bit" for OAM packets.  Per [RFC8300<https://urldefense.com/v3/__https:/nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fdatatracker.ietf.org*2Fdoc*2Fhtml*2Frfc8300__*3B!!MZ3Fw45to5uY!bzL7Vb_jHltGMCbCwne2rywfzpGjZW4o3fVr4clCr4Ir10KydDyJy5gHA8obfbMABJuMIrqXAQ*24&data=04*7C01*7Cjames.n.guichard*40futurewei.com*7Ca5db82494c32402334fc08d9ebdc83cf*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637800154631277005*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000&sdata=a*2BVevL6noSzqRzdWg6dscjiqevlLbxcgEdTEmfJAY7U*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!MZ3Fw45to5uY!f5SSgs9VAH1xxjFWgJMfr5ZlZH93z6GJlXoOgCmY8AVbjdeh2YlaUz632nE-HqDItW92fQLzlQ$>] the O

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://urldefense.com/v3/__https:/nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fdatatracker.ietf.org*2Fdoc*2Fhtml*2Fdraft-ietf-sfc-multi-layer-oam*section-10.1__*3BIw!!MZ3Fw45to5uY!bzL7Vb_jHltGMCbCwne2rywfzpGjZW4o3fVr4clCr4Ir10KydDyJy5gHA8obfbMABJv1ohYIeg*24&data=04*7C01*7Cjames.n.guichard*40futurewei.com*7Ca5db82494c32402334fc08d9ebdc83cf*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637800154631277005*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000&sdata=HTLx6e4sQCvsjXZKxG1GA8XPvdswsQKEMIEABitkprw*3D&reserved=0__;JSUlJSUlJSUlJSUqJSUlJSUlJSUlJSUlJSUl!!MZ3Fw45to5uY!f5SSgs9VAH1xxjFWgJMfr5ZlZH93z6GJlXoOgCmY8AVbjdeh2YlaUz632nE-HqDItW-EwTZ2zw$>:

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 <[email-masked]<mailto:[email-masked]>>
Sent: Monday, January 31, 2022 11:25 PM
To: Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Cc: James Guichard <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] WGLC for https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/<https://urldefense.com/v3/__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!bzL7Vb_jHltGMCbCwne2rywfzpGjZW4o3fVr4clCr4Ir10KydDyJy5gHA8obfbMABJu3416GCQ*24&data=04*7C01*7Cjames.n.guichard*40futurewei.com*7Ca5db82494c32402334fc08d9ebdc83cf*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637800154631277005*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000&sdata=NKz8*2Fm*2Fh7WXjK0OP8NF4j5cQ*2FYgSrSMULRmDt*2FkX*2B10*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJQ!!MZ3Fw45to5uY!f5SSgs9VAH1xxjFWgJMfr5ZlZH93z6GJlXoOgCmY8AVbjdeh2YlaUz632nE-HqDItW8EWrHtpA$>

Hi Greg,

Sorry for the late action on this. https://datatracker.ietf.org/doc/html/draft-ietf-sfc-ioam-nsh-07<https://urldefense.com/v3/__https:/nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fnam11.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Fdatatracker.ietf.org*2Fdoc*2Fhtml*2Fdraft-ietf-sfc-ioam-nsh-07*26data*3D04*7C01*7Cjames.n.guichard*40futurewei.com*7Caf9cde32be65486e459d08d9e53ac90c*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C1*7C637792862928234181*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*26sdata*3Dpl23JSzuzl5p2F8vooPyxVcUnWRdcWx*2F26MRFfJAIh4*3D*26reserved*3D0__*3BJSUlJSUlJSUlJSUlJSUlJSUlJSU!!MZ3Fw45to5uY!bzL7Vb_jHltGMCbCwne2rywfzpGjZW4o3fVr4clCr4Ir10KydDyJy5gHA8obfbMABJvEbkwM5w*24&data=04*7C01*7Cjames.n.guichard*40futurewei.com*7Ca5db82494c32402334fc08d9ebdc83cf*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637800154631277005*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000&sdata=dpoyXLu*2F9fGVSgLtewdI7wNfSPdrkhs7FtBdD3Aq7*2B0*3D&reserved=0__;JSUlJSUlJSUlJSUqKioqKiolJSoqKioqKioqKioqKiUlKiolJSUlJSUlJSUlJSUlJSUlJSUl!!MZ3Fw45to5uY!f5SSgs9VAH1xxjFWgJMfr5ZlZH93z6GJlXoOgCmY8AVbjdeh2YlaUz632nE-HqDItW9PuM1neA$> 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 <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> 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:/nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fnam11.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*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*26data*3D04*7C01*7Cjames.n.guichard*40futurewei.com*7Caf9cde32be65486e459d08d9e53ac90c*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C1*7C637792862928234181*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*26sdata*3Di7sTr0MtC5qfzx3twOKSpbW8LkQJzsAJBxF*2FZPLUwKc*3D*26reserved*3D0__*3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!MZ3Fw45to5uY!bzL7Vb_jHltGMCbCwne2rywfzpGjZW4o3fVr4clCr4Ir10KydDyJy5gHA8obfbMABJt0mRguJg*24&data=04*7C01*7Cjames.n.guichard*40futurewei.com*7Ca5db82494c32402334fc08d9ebdc83cf*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637800154631277005*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000&sdata=yVGpJY1y6dud5c44HOsptPjqEuXdNUa1DMzjAelvU5c*3D&reserved=0__;JSUlJSUlJSUlJSUqKioqKioqKioqKioqJSUqKioqKioqKioqKiolJSoqJSUlJSUlJSUlJSUlJSUlJSU!!MZ3Fw45to5uY!f5SSgs9VAH1xxjFWgJMfr5ZlZH93z6GJlXoOgCmY8AVbjdeh2YlaUz632nE-HqDItW-BwxdRIg$> 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:/nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fnam11.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fmailarchive.ietf.org*2Farch*2Fmsg*2Fippm*2FA0OcGQ5LlNjnjfRVp_iUTMYMrcs*2F__*3B!!MZ3Fw45to5uY!db6q3n8-5YqHkLtf3wyeBoUpO72v7UzeDtfPNhyePahNAYMo9eFdQxxBWM4C7Z0OJKHOndSFRg*24*26data*3D04*7C01*7Cjames.n.guichard*40futurewei.com*7Caf9cde32be65486e459d08d9e53ac90c*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C1*7C637792862928234181*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*26sdata*3DcHtvsgDl*2FuzSv70oS9LN5l2o5nEIwiKHDZ1sfiFJCrE*3D*26reserved*3D0__*3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSU!!MZ3Fw45to5uY!bzL7Vb_jHltGMCbCwne2rywfzpGjZW4o3fVr4clCr4Ir10KydDyJy5gHA8obfbMABJu2SsX7cg*24&data=04*7C01*7Cjames.n.guichard*40futurewei.com*7Ca5db82494c32402334fc08d9ebdc83cf*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637800154631277005*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000&sdata=Y*2BwywuTSj4SpugrjmDTquAY0MZWKoT43CMjsyha*2FnOc*3D&reserved=0__;JSUlJSUlJSUlJSUqKioqKioqKioqKioqKiolJSoqKioqKioqKioqKiUlKiolJSUlJSUlJSUlJSUlJSUlJSUl!!MZ3Fw45to5uY!f5SSgs9VAH1xxjFWgJMfr5ZlZH93z6GJlXoOgCmY8AVbjdeh2YlaUz632nE-HqDItW-FRADPxg$> 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:/nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fnam11.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*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*26data*3D04*7C01*7Cjames.n.guichard*40futurewei.com*7Caf9cde32be65486e459d08d9e53ac90c*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C1*7C637792862928234181*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*26sdata*3Di7sTr0MtC5qfzx3twOKSpbW8LkQJzsAJBxF*2FZPLUwKc*3D*26reserved*3D0__*3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!MZ3Fw45to5uY!bzL7Vb_jHltGMCbCwne2rywfzpGjZW4o3fVr4clCr4Ir10KydDyJy5gHA8obfbMABJt0mRguJg*24&data=04*7C01*7Cjames.n.guichard*40futurewei.com*7Ca5db82494c32402334fc08d9ebdc83cf*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637800154631277005*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000&sdata=yVGpJY1y6dud5c44HOsptPjqEuXdNUa1DMzjAelvU5c*3D&reserved=0__;JSUlJSUlJSUlJSUqKioqKioqKioqKioqJSUqKioqKioqKioqKiolJSoqJSUlJSUlJSUlJSUlJSUlJSU!!MZ3Fw45to5uY!f5SSgs9VAH1xxjFWgJMfr5ZlZH93z6GJlXoOgCmY8AVbjdeh2YlaUz632nE-HqDItW-BwxdRIg$> and Loopback and Active flags defined in draft-ietf-ippm-ioam-flags<https://urldefense.com/v3/__https:/nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fnam11.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fdatatracker.ietf.org*2Fdoc*2Fdraft-ietf-ippm-ioam-flags*2F__*3B!!MZ3Fw45to5uY!db6q3n8-5YqHkLtf3wyeBoUpO72v7UzeDtfPNhyePahNAYMo9eFdQxxBWM4C7Z0OJKHO7lReVw*24*26data*3D04*7C01*7Cjames.n.guichard*40futurewei.com*7Caf9cde32be65486e459d08d9e53ac90c*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C1*7C637792862928234181*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*26sdata*3D1kqtcu3xjl1C7ytQ*2BoaKdiQN96rQt94e1S2ElC0nD3M*3D*26reserved*3D0__*3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!MZ3Fw45to5uY!bzL7Vb_jHltGMCbCwne2rywfzpGjZW4o3fVr4clCr4Ir10KydDyJy5gHA8obfbMABJt8NqRRKg*24&data=04*7C01*7Cjames.n.guichard*40futurewei.com*7Ca5db82494c32402334fc08d9ebdc83cf*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637800154631277005*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000&sdata=zzcnXlewWKrtEDv4BmsNNk4pvDlMKNKvPzBZ2dZJm5k*3D&reserved=0__;JSUlJSUlJSUlJSUqKioqKioqKioqKioqJSUqKioqKioqKioqKiolJSoqJSUlJSUlJSUlJSUlJSUlJSU!!MZ3Fw45to5uY!f5SSgs9VAH1xxjFWgJMfr5ZlZH93z6GJlXoOgCmY8AVbjdeh2YlaUz632nE-HqDItW-gOuTqwg$>. 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

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 <[email-masked]<mailto:[email-masked]>> 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:/nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fnam11.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fdatatracker.ietf.org*2Fdoc*2Fdraft-ietf-sfc-ioam-nsh*2F__*3B!!MZ3Fw45to5uY!db6q3n8-5YqHkLtf3wyeBoUpO72v7UzeDtfPNhyePahNAYMo9eFdQxxBWM4C7Z0OJKHdTiRE6A*24*26data*3D04*7C01*7Cjames.n.guichard*40futurewei.com*7Caf9cde32be65486e459d08d9e53ac90c*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C1*7C637792862928234181*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*26sdata*3D9uDdhw0ViwBtWvn52V8UZ2G77lRnSye2Ols5z3U8QwQ*3D*26reserved*3D0__*3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSU!!MZ3Fw45to5uY!bzL7Vb_jHltGMCbCwne2rywfzpGjZW4o3fVr4clCr4Ir10KydDyJy5gHA8obfbMABJv33kGkLw*24&data=04*7C01*7Cjames.n.guichard*40futurewei.com*7Ca5db82494c32402334fc08d9ebdc83cf*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637800154631277005*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000&sdata=S6sx7MrrVkzKepVgj45q*2F2KPZzBMyOFnol*2BMfgRQ730*3D&reserved=0__;JSUlJSUlJSUlJSUqKioqKioqKioqKioqJSUqKioqKioqKioqKiolJSolJSUlJSUlJSUlJSUlJSUlJSUl!!MZ3Fw45to5uY!f5SSgs9VAH1xxjFWgJMfr5ZlZH93z6GJlXoOgCmY8AVbjdeh2YlaUz632nE-HqDItW-FOmuSHA$>

_______________________________________________
sfc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sfc<https://urldefense.com/v3/__https:/nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fnam11.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Fsfc__*3B!!MZ3Fw45to5uY!db6q3n8-5YqHkLtf3wyeBoUpO72v7UzeDtfPNhyePahNAYMo9eFdQxxBWM4C7Z0OJKEKMsIVaA*24*26data*3D04*7C01*7Cjames.n.guichard*40futurewei.com*7Caf9cde32be65486e459d08d9e53ac90c*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C1*7C637792862928234181*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*26sdata*3DLrdp7ipXNWqDvp3mWkIQWF*2FJoClfmd4G3TlaH2kB550*3D*26reserved*3D0__*3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!MZ3Fw45to5uY!bzL7Vb_jHltGMCbCwne2rywfzpGjZW4o3fVr4clCr4Ir10KydDyJy5gHA8obfbMABJv0WsQtHA*24&data=04*7C01*7Cjames.n.guichard*40futurewei.com*7Ca5db82494c32402334fc08d9ebdc83cf*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637800154631277005*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000&sdata=Xj4fU0JctSsPl6a36R*2Bp9N4RkQ*2Bs8m4V7s9Qm2HHIVw*3D&reserved=0__;JSUlJSUlJSUlJSUqKioqKioqKioqKioqJSUqKioqKioqKioqKiolJSoqJSUlJSUlJSUlJSUlJSUlJSUlJQ!!MZ3Fw45to5uY!f5SSgs9VAH1xxjFWgJMfr5ZlZH93z6GJlXoOgCmY8AVbjdeh2YlaUz632nE-HqDItW8h731QiA$>

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Tue, 12 Apr 2022 11:55:16 +0000

Hi Med,

Sorry for arriving late to the party. Reading through your message below, there seems to be a confusion about the scope and concept of different OAM mechanisms.

IOAM is scoped and designed to be protocol agnostic. IOAM data can be encapsulated into various protocols – and NSH is one example – but there is no semantic link between IOAM and the protocol used to encapsulate IOAM data.

Protocols can have their protocol specific OAM methods and solutions, like SFC OAM. Those protocol specific solutions (like SFC OAM as an example) are orthogonal to IOAM from a concept and scope perspective.

From an SFC OAM perspective, your draft-ietf-sfc-oam-packet-00 clearly and rightly states that “O bit: Setting this bit indicates an SFC OAM packet.” The O bit is about SFC OAM, and as such is orthogonal to “anything IOAM”. In earlier versions of draft-ietf-sfc-ioam-nsh we had text which stated that the O bit remains unchanged whether IOAM is present or not. To avoid any confusion, in -08 we removed this statement – just to make it crystal clear that there is no link between “IOAM” and “SFC OAM”.

In addition, I don’t think that draft-ietf-sfc-ioam-nsh would be the appropriate place to discuss and restrict deployment options. E.g., I’m not sure why we’d want to restrict a deployment to using a single IOAM header only. E.g., one could think of using different headers for different namespaces or groups of namespaces for operational reasons. IMHO, such a discussion – if we really need it - would belong into draft-ietf-ippm-ioam-deployment, rather than into a draft that defines the encap of IOAM into NSH.

Hope this clarifies things – and we can finish up draft-ietf-sfc-ioam-nsh :-).

Cc’ing the ippm working group as an FYI.

Thanks & Cheers, Frank

From: [email-masked] <[email-masked]>
Sent: Monday, 4 April 2022 07:40
To: Shwetha Bhandari <[email-masked]>; Greg Mirsky <[email-masked]>
Cc: [email-masked]; Frank Brockners (fbrockne) <[email-masked]>; [email-masked]; James Guichard <[email-masked]>; Tal Mizrahi <[email-masked]>; [email-masked]
Subject: RE: [sfc] WGLC for https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/

Hi Shwetha, all,

Cheers,
Med

De : sfc <[email-masked]<mailto:[email-masked]>> De la part de Shwetha Bhandari
Envoyé : lundi 4 avril 2022 02:41
À : Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Cc : [email-masked]<mailto:[email-masked]>; Frank Brockners (fbrockne) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; James Guichard <[email-masked]<mailto:[email-masked]>>; Tal Mizrahi <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Objet : Re: [sfc] WGLC for https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/

Hi Greg,

Thanks
Shwetha

Regards,
Greg

Thanks,
Shwetha

Jim

Hi Jim,

Hi Greg,

What are your thoughts?

Thanks,
Shwetha

Regards,
Greg

Thanks,
Shwetha

Jim

Hi Greg,

Hi Jim,

Thanks,
Shwetha

Regards,
Greg

Thanks,
Shwetha

Regards,
Greg

Thanks!

Jim & Joel

Thank you.

---

From: <[email-masked]>
Date: Tue, 12 Apr 2022 14:39:01 +0000

Hi Franck,

Thank you for the clarification even if I don’t think there is a confusion.

Please note that SFC OAM packet is defined as follows:

==
      Such a packet
      is any NSH-encapsulated packet that exclusively includes OAM data.
      An OAM data can be included in the Fixed-Length Context Header,
      optional Context Headers, and/or the inner packet.
==

Things are pretty clear (as per draft-ietf-sfc-oam-packet) that the O bit must be unset when IOAM data is included + user data.

The concern I had is that you are pointing to RFC8300 for the IOAM next protocol, which makes both “none” (i.e., no payload) and IOAM (as you request a new code) legitimate values.

Cheers,
Med

De : sfc <[email-masked]> De la part de Frank Brockners (fbrockne)
Envoyé : mardi 12 avril 2022 13:55
À : BOUCADAIR Mohamed INNOV/NET <[email-masked]>; Shwetha Bhandari <[email-masked]>; Greg Mirsky <[email-masked]>
Cc : [email-masked]; [email-masked]; [email-masked]; James Guichard <[email-masked]>; Tal Mizrahi <[email-masked]>; [email-masked]
Objet : Re: [sfc] WGLC for https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/

Hi Med,

Thanks & Cheers, Frank

From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Sent: Monday, 4 April 2022 07:40
To: Shwetha Bhandari <[email-masked]<mailto:[email-masked]>>; Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Frank Brockners (fbrockne) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; James Guichard <[email-masked]<mailto:[email-masked]>>; Tal Mizrahi <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [sfc] WGLC for https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/

Hi Shwetha, all,

Cheers,
Med

Hi Greg,

Thanks
Shwetha

Regards,
Greg

Thanks,
Shwetha

Jim

Hi Jim,

Hi Greg,

What are your thoughts?

Thanks,
Shwetha

Regards,
Greg

Thanks,
Shwetha

Jim

Hi Greg,

Hi Jim,

Thanks,
Shwetha

Regards,
Greg

Thanks,
Shwetha

Regards,
Greg

Thanks!

Jim & Joel

---

From: Shwetha Bhandari <[email-masked]>
Date: Tue, 12 Apr 2022 20:25:58 +0530

Med,

Thanks for the details: this is exactly what we had before the latest
revision:

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

<https://datatracker.ietf.org/doc/html/rfc8300>] the O

This was removed as per the discussion in this thread. Please check
https://mailarchive.ietf.org/arch/msg/sfc/srMit5zE8UseNOhxknAw_dqvj6M/

It looks like we are going in a loop here. This definition of SFC OAM
packet to include the OAM data that comes in inner packets via the next
protocol header chain is introduced in draft-ietf-sfc-oam-packet to update
the RFC8300.
Jim, What are you thoughts on this? Should we reintroduce the above text ?

Thanks,
Shwetha

On Tue, Apr 12, 2022 at 8:09 PM <[email-masked]> wrote:

> Things are pretty clear (as per draft-ietf-sfc-oam-packet) that the O bit
> must be unset when IOAM data is included + user data.
>
>
>
> The concern I had is that you are pointing to RFC8300 for the IOAM next
> protocol, which makes both “none” (i.e., no payload) and IOAM (as you
> request a new code) legitimate values.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* sfc <[email-masked]> *De la part de* Frank Brockners
> (fbrockne)
> *Envoyé :* mardi 12 avril 2022 13:55
> *À :* BOUCADAIR Mohamed INNOV/NET <[email-masked]>; Shwetha
> Bhandari <[email-masked]>; Greg Mirsky <
> [email-masked]>
> *Cc :* [email-masked]; [email-masked]; [email-masked]; James Guichard <
> [email-masked]>; Tal Mizrahi <[email-masked]>;
> [email-masked]
> *Objet :* Re: [sfc] WGLC for
> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/__;!!MZ3Fw45to5uY!JpBZ4H2-MNm5lJDGjooVj_3Sq-aX7gdh5qeoNPyZ69CXOFRhgdYmSOyreClzKvZDgPAiwaGN2YTO2qUw70GqHI4QEKQpGnBw0LXBXQ$>
>
>
>
> Hi Med,
>
>
>
> Sorry for arriving late to the party. Reading through your message below,
> there seems to be a confusion about the scope and concept of different OAM
> mechanisms.
>
>
>
> IOAM is scoped and designed to be protocol agnostic. IOAM data can be
> encapsulated into various protocols – and NSH is one example – but there is
> no semantic link between IOAM and the protocol used to encapsulate IOAM
> data.
>
>
>
> Protocols can have their protocol specific OAM methods and solutions, like
> SFC OAM. Those protocol specific solutions (like SFC OAM as an example) are
> orthogonal to IOAM from a concept and scope perspective.
>
>
>
> From an SFC OAM perspective, your draft-ietf-sfc-oam-packet-00 clearly and
> rightly states that “O bit: Setting this bit indicates an SFC OAM packet.”
> The O bit is about SFC OAM, and as such is orthogonal to “anything IOAM”.
> In earlier versions of draft-ietf-sfc-ioam-nsh we had text which stated
> that the O bit remains unchanged whether IOAM is present or not. To avoid
> any confusion, in -08 we removed this statement – just to make it crystal
> clear that there is no link between “IOAM” and “SFC OAM”.
>
>
>
> In addition, I don’t think that draft-ietf-sfc-ioam-nsh would be the
> appropriate place to discuss and restrict deployment options. E.g., I’m not
> sure why we’d want to restrict a deployment to using a single IOAM header
> only. E.g., one could think of using different headers for different
> namespaces or groups of namespaces for operational reasons. IMHO, such a
> discussion – if we really need it - would belong into
> draft-ietf-ippm-ioam-deployment, rather than into a draft that defines the
> encap of IOAM into NSH.
>
>
>
> *From:* [email-masked] <[email-masked]>
> *Sent:* Monday, 4 April 2022 07:40
> *To:* Shwetha Bhandari <[email-masked]>; Greg Mirsky <
> [email-masked]>
> *Cc:* [email-masked]; Frank Brockners (fbrockne) <[email-masked]>;
> [email-masked]; James Guichard <[email-masked]>; Tal
> Mizrahi <[email-masked]>; [email-masked]
> *Subject:* RE: [sfc] WGLC for
> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/__;!!MZ3Fw45to5uY!JpBZ4H2-MNm5lJDGjooVj_3Sq-aX7gdh5qeoNPyZ69CXOFRhgdYmSOyreClzKvZDgPAiwaGN2YTO2qUw70GqHI4QEKQpGnBw0LXBXQ$>
>
>
>
> Hi Shwetha, all,
>
>
>
>          identical to the Next Protocol field in [RFC8300
> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/rfc8300__;!!MZ3Fw45to5uY!JpBZ4H2-MNm5lJDGjooVj_3Sq-aX7gdh5qeoNPyZ69CXOFRhgdYmSOyreClzKvZDgPAiwaGN2YTO2qUw70GqHI4QEKQpGnDoYxXlRw$>
> ].
>
>
>
> which means that “None” is authorized. The O-bit must be set for such
> packets, while it should be unset for other values indicating user payload
> as per draft-ietf-sfc-oam-packet. Absent a pointer to the OAM packet, an
> implementer will have to guess the behavior to follow.
>
>
>
> One last comment: please update the security considerations with
> NSH-specific considerations. An approach is to simply refer to Section 5 of
> draft-ietf-sfc-oam-packet.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* sfc <[email-masked]> *De la part de* Shwetha Bhandari
> *Envoyé :* lundi 4 avril 2022 02:41
> *À :* Greg Mirsky <[email-masked]>
> *Cc :* [email-masked]; Frank Brockners (fbrockne) <[email-masked]>;
> [email-masked]; James Guichard <[email-masked]>; Tal
> Mizrahi <[email-masked]>; [email-masked]
> *Objet :* Re: [sfc] WGLC for
> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/__;!!MZ3Fw45to5uY!JpBZ4H2-MNm5lJDGjooVj_3Sq-aX7gdh5qeoNPyZ69CXOFRhgdYmSOyreClzKvZDgPAiwaGN2YTO2qUw70GqHI4QEKQpGnBw0LXBXQ$>
>
>
>
> Hi Greg,
>
>
>
>  "My only point was that in the case of IOAM the O-bit seems to be
> set then the context headers are used to obtain the OAM instructions."
>
> <https://urldefense.com/v3/__https:/www.ietf.org/id/draft-ietf-sfc-oam-packet-00.html__;!!MZ3Fw45to5uY!JYVtUwScRxFf7rDoRMpiv7YwbRTcaHXzsGIxr9eVEi_p_xSQUWAjDvFy_UhGEQbl8530VaLM0Tj7k5Wzu6YfUSVditWyZ_8$> like
> the following:
>
> <https://urldefense.com/v3/__https:/www.ietf.org/rfcdiff?url2=draft-ietf-sfc-ioam-nsh-08.txt__;!!MZ3Fw45to5uY!JYVtUwScRxFf7rDoRMpiv7YwbRTcaHXzsGIxr9eVEi_p_xSQUWAjDvFy_UhGEQbl8530VaLM0Tj7k5Wzu6YfUSVd4KRpUCA$>
>
>
>
> Thanks,
>
> Shwetha
>
>
>
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/__;!!MZ3Fw45to5uY!f5SSgs9VAH1xxjFWgJMfr5ZlZH93z6GJlXoOgCmY8AVbjdeh2YlaUz632nE-HqDItW_8pjQ1iQ$>
>
>
>
> Hi Jim,
>
>
>
> <https://urldefense.com/v3/__https:/nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Fdatatracker.ietf.org*2Fdoc*2Fhtml*2Fdraft-ietf-ippm-ioam-flags*23section-4.2&data=04*7C01*7Cjames.n.guichard*40futurewei.com*7Ca5db82494c32402334fc08d9ebdc83cf*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637800154631120774*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000&sdata=zcOpC0Gzzi8xzhttBqWaeaU3pMd0KDo*2FZYdGsEPG0uE*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUl!!MZ3Fw45to5uY!f5SSgs9VAH1xxjFWgJMfr5ZlZH93z6GJlXoOgCmY8AVbjdeh2YlaUz632nE-HqDItW_cH_6kAg$>
> :
>
> <https://urldefense.com/v3/__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!eu05ObEvXtnVX2OXFzl0g16vk36xSqTyjMReG_i6BavtG_ru2AnjQSjXHiZ_Ve3sBjJRuHMBUg*24&data=04*7C01*7Cjames.n.guichard*40futurewei.com*7Ca5db82494c32402334fc08d9ebdc83cf*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637800154631277005*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000&sdata=DvpZHlkn0PNCP5*2BzFQzGayutZGPUMxJXtPll6nR8Ay8*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!MZ3Fw45to5uY!f5SSgs9VAH1xxjFWgJMfr5ZlZH93z6GJlXoOgCmY8AVbjdeh2YlaUz632nE-HqDItW_4eduZWg$> -
> <https://urldefense.com/v3/__https:/nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fdatatracker.ietf.org*2Fdoc*2Fhtml*2Frfc6291__*3B!!MZ3Fw45to5uY!bzL7Vb_jHltGMCbCwne2rywfzpGjZW4o3fVr4clCr4Ir10KydDyJy5gHA8obfbMABJs06rKUNw*24&data=04*7C01*7Cjames.n.guichard*40futurewei.com*7Ca5db82494c32402334fc08d9ebdc83cf*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637800154631277005*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000&sdata=4wRcNgj93har9TlylAfX*2BtbW24VCqfneSZd0rD9CRzs*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!MZ3Fw45to5uY!f5SSgs9VAH1xxjFWgJMfr5ZlZH93z6GJlXoOgCmY8AVbjdeh2YlaUz632nE-HqDItW8b5uw-Yg$>
> ]).
>
> <https://urldefense.com/v3/__https:/nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fdatatracker.ietf.org*2Fdoc*2Fhtml*2Frfc8300*ref-SFC-OAM-FRAMEWORK__*3BIw!!MZ3Fw45to5uY!bzL7Vb_jHltGMCbCwne2rywfzpGjZW4o3fVr4clCr4Ir10KydDyJy5gHA8obfbMABJsisioAug*24&data=04*7C01*7Cjames.n.guichard*40futurewei.com*7Ca5db82494c32402334fc08d9ebdc83cf*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637800154631277005*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000&sdata=A6fkAO8CwRJeW5tLLEpU0GhZrqsBOm7nUiE1QiMxwVQ*3D&reserved=0__;JSUlJSUlJSUlJSUqJSUlJSUlJSUlJSUlJSUl!!MZ3Fw45to5uY!f5SSgs9VAH1xxjFWgJMfr5ZlZH93z6GJlXoOgCmY8AVbjdeh2YlaUz632nE-HqDItW_b7k_TUA$>
> ]
>
>       for one approach).
>
>
>
> <https://urldefense.com/v3/__https:/nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fdatatracker.ietf.org*2Fdoc*2Fhtml*2Fdraft-ietf-sfc-ioam-nsh-07*section-4.1__*3BIw!!MZ3Fw45to5uY!bzL7Vb_jHltGMCbCwne2rywfzpGjZW4o3fVr4clCr4Ir10KydDyJy5gHA8obfbMABJtXMLMQUw*24&data=04*7C01*7Cjames.n.guichard*40futurewei.com*7Ca5db82494c32402334fc08d9ebdc83cf*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637800154631277005*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000&sdata=w3hANsqqvVWz5oeH*2BLfPwS*2Fxwh2hNERJwCw5zwdrAMA*3D&reserved=0__;JSUlJSUlJSUlJSUqJSUlJSUlJSUlJSUlJSUlJSU!!MZ3Fw45to5uY!f5SSgs9VAH1xxjFWgJMfr5ZlZH93z6GJlXoOgCmY8AVbjdeh2YlaUz632nE-HqDItW9Fp7_C8w$>.
> <https://urldefense.com/v3/__https:/nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fdatatracker.ietf.org*2Fdoc*2Fhtml*2Frfc8300__*3B!!MZ3Fw45to5uY!bzL7Vb_jHltGMCbCwne2rywfzpGjZW4o3fVr4clCr4Ir10KydDyJy5gHA8obfbMABJuMIrqXAQ*24&data=04*7C01*7Cjames.n.guichard*40futurewei.com*7Ca5db82494c32402334fc08d9ebdc83cf*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637800154631277005*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000&sdata=a*2BVevL6noSzqRzdWg6dscjiqevlLbxcgEdTEmfJAY7U*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!MZ3Fw45to5uY!f5SSgs9VAH1xxjFWgJMfr5ZlZH93z6GJlXoOgCmY8AVbjdeh2YlaUz632nE-HqDItW92fQLzlQ$>]
> the O
>
> <https://urldefense.com/v3/__https:/nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fdatatracker.ietf.org*2Fdoc*2Fhtml*2Fdraft-ietf-sfc-multi-layer-oam*section-10.1__*3BIw!!MZ3Fw45to5uY!bzL7Vb_jHltGMCbCwne2rywfzpGjZW4o3fVr4clCr4Ir10KydDyJy5gHA8obfbMABJv1ohYIeg*24&data=04*7C01*7Cjames.n.guichard*40futurewei.com*7Ca5db82494c32402334fc08d9ebdc83cf*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637800154631277005*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000&sdata=HTLx6e4sQCvsjXZKxG1GA8XPvdswsQKEMIEABitkprw*3D&reserved=0__;JSUlJSUlJSUlJSUqJSUlJSUlJSUlJSUlJSUl!!MZ3Fw45to5uY!f5SSgs9VAH1xxjFWgJMfr5ZlZH93z6GJlXoOgCmY8AVbjdeh2YlaUz632nE-HqDItW-EwTZ2zw$>
> :
>
>
>
> <https://urldefense.com/v3/__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!bzL7Vb_jHltGMCbCwne2rywfzpGjZW4o3fVr4clCr4Ir10KydDyJy5gHA8obfbMABJu3416GCQ*24&data=04*7C01*7Cjames.n.guichard*40futurewei.com*7Ca5db82494c32402334fc08d9ebdc83cf*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637800154631277005*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000&sdata=NKz8*2Fm*2Fh7WXjK0OP8NF4j5cQ*2FYgSrSMULRmDt*2FkX*2B10*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJQ!!MZ3Fw45to5uY!f5SSgs9VAH1xxjFWgJMfr5ZlZH93z6GJlXoOgCmY8AVbjdeh2YlaUz632nE-HqDItW8EWrHtpA$>
>
>
>
> Hi Greg,
>
>
>
> <https://urldefense.com/v3/__https:/nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fnam11.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Fdatatracker.ietf.org*2Fdoc*2Fhtml*2Fdraft-ietf-sfc-ioam-nsh-07*26data*3D04*7C01*7Cjames.n.guichard*40futurewei.com*7Caf9cde32be65486e459d08d9e53ac90c*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C1*7C637792862928234181*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*26sdata*3Dpl23JSzuzl5p2F8vooPyxVcUnWRdcWx*2F26MRFfJAIh4*3D*26reserved*3D0__*3BJSUlJSUlJSUlJSUlJSUlJSUlJSU!!MZ3Fw45to5uY!bzL7Vb_jHltGMCbCwne2rywfzpGjZW4o3fVr4clCr4Ir10KydDyJy5gHA8obfbMABJvEbkwM5w*24&data=04*7C01*7Cjames.n.guichard*40futurewei.com*7Ca5db82494c32402334fc08d9ebdc83cf*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637800154631277005*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000&sdata=dpoyXLu*2F9fGVSgLtewdI7wNfSPdrkhs7FtBdD3Aq7*2B0*3D&reserved=0__;JSUlJSUlJSUlJSUqKioqKiolJSoqKioqKioqKioqKiUlKiolJSUlJSUlJSUlJSUlJSUlJSUl!!MZ3Fw45to5uY!f5SSgs9VAH1xxjFWgJMfr5ZlZH93z6GJlXoOgCmY8AVbjdeh2YlaUz632nE-HqDItW9PuM1neA$>
> <https://urldefense.com/v3/__https:/nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fnam11.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*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*26data*3D04*7C01*7Cjames.n.guichard*40futurewei.com*7Caf9cde32be65486e459d08d9e53ac90c*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C1*7C637792862928234181*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*26sdata*3Di7sTr0MtC5qfzx3twOKSpbW8LkQJzsAJBxF*2FZPLUwKc*3D*26reserved*3D0__*3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!MZ3Fw45to5uY!bzL7Vb_jHltGMCbCwne2rywfzpGjZW4o3fVr4clCr4Ir10KydDyJy5gHA8obfbMABJt0mRguJg*24&data=04*7C01*7Cjames.n.guichard*40futurewei.com*7Ca5db82494c32402334fc08d9ebdc83cf*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637800154631277005*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000&sdata=yVGpJY1y6dud5c44HOsptPjqEuXdNUa1DMzjAelvU5c*3D&reserved=0__;JSUlJSUlJSUlJSUqKioqKioqKioqKioqJSUqKioqKioqKioqKiolJSoqJSUlJSUlJSUlJSUlJSUlJSU!!MZ3Fw45to5uY!f5SSgs9VAH1xxjFWgJMfr5ZlZH93z6GJlXoOgCmY8AVbjdeh2YlaUz632nE-HqDItW-BwxdRIg$>
> <https://urldefense.com/v3/__https:/nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fnam11.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fmailarchive.ietf.org*2Farch*2Fmsg*2Fippm*2FA0OcGQ5LlNjnjfRVp_iUTMYMrcs*2F__*3B!!MZ3Fw45to5uY!db6q3n8-5YqHkLtf3wyeBoUpO72v7UzeDtfPNhyePahNAYMo9eFdQxxBWM4C7Z0OJKHOndSFRg*24*26data*3D04*7C01*7Cjames.n.guichard*40futurewei.com*7Caf9cde32be65486e459d08d9e53ac90c*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C1*7C637792862928234181*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*26sdata*3DcHtvsgDl*2FuzSv70oS9LN5l2o5nEIwiKHDZ1sfiFJCrE*3D*26reserved*3D0__*3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSU!!MZ3Fw45to5uY!bzL7Vb_jHltGMCbCwne2rywfzpGjZW4o3fVr4clCr4Ir10KydDyJy5gHA8obfbMABJu2SsX7cg*24&data=04*7C01*7Cjames.n.guichard*40futurewei.com*7Ca5db82494c32402334fc08d9ebdc83cf*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637800154631277005*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000&sdata=Y*2BwywuTSj4SpugrjmDTquAY0MZWKoT43CMjsyha*2FnOc*3D&reserved=0__;JSUlJSUlJSUlJSUqKioqKioqKioqKioqKiolJSoqKioqKioqKioqKiUlKiolJSUlJSUlJSUlJSUlJSUlJSUl!!MZ3Fw45to5uY!f5SSgs9VAH1xxjFWgJMfr5ZlZH93z6GJlXoOgCmY8AVbjdeh2YlaUz632nE-HqDItW-FRADPxg$>
> <https://urldefense.com/v3/__https:/nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fnam11.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*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*26data*3D04*7C01*7Cjames.n.guichard*40futurewei.com*7Caf9cde32be65486e459d08d9e53ac90c*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C1*7C637792862928234181*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*26sdata*3Di7sTr0MtC5qfzx3twOKSpbW8LkQJzsAJBxF*2FZPLUwKc*3D*26reserved*3D0__*3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!MZ3Fw45to5uY!bzL7Vb_jHltGMCbCwne2rywfzpGjZW4o3fVr4clCr4Ir10KydDyJy5gHA8obfbMABJt0mRguJg*24&data=04*7C01*7Cjames.n.guichard*40futurewei.com*7Ca5db82494c32402334fc08d9ebdc83cf*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637800154631277005*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000&sdata=yVGpJY1y6dud5c44HOsptPjqEuXdNUa1DMzjAelvU5c*3D&reserved=0__;JSUlJSUlJSUlJSUqKioqKioqKioqKioqJSUqKioqKioqKioqKiolJSoqJSUlJSUlJSUlJSUlJSUlJSU!!MZ3Fw45to5uY!f5SSgs9VAH1xxjFWgJMfr5ZlZH93z6GJlXoOgCmY8AVbjdeh2YlaUz632nE-HqDItW-BwxdRIg$>
> <https://urldefense.com/v3/__https:/nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fnam11.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fdatatracker.ietf.org*2Fdoc*2Fdraft-ietf-ippm-ioam-flags*2F__*3B!!MZ3Fw45to5uY!db6q3n8-5YqHkLtf3wyeBoUpO72v7UzeDtfPNhyePahNAYMo9eFdQxxBWM4C7Z0OJKHO7lReVw*24*26data*3D04*7C01*7Cjames.n.guichard*40futurewei.com*7Caf9cde32be65486e459d08d9e53ac90c*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C1*7C637792862928234181*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*26sdata*3D1kqtcu3xjl1C7ytQ*2BoaKdiQN96rQt94e1S2ElC0nD3M*3D*26reserved*3D0__*3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!MZ3Fw45to5uY!bzL7Vb_jHltGMCbCwne2rywfzpGjZW4o3fVr4clCr4Ir10KydDyJy5gHA8obfbMABJt8NqRRKg*24&data=04*7C01*7Cjames.n.guichard*40futurewei.com*7Ca5db82494c32402334fc08d9ebdc83cf*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637800154631277005*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000&sdata=zzcnXlewWKrtEDv4BmsNNk4pvDlMKNKvPzBZ2dZJm5k*3D&reserved=0__;JSUlJSUlJSUlJSUqKioqKioqKioqKioqJSUqKioqKioqKioqKiolJSoqJSUlJSUlJSUlJSUlJSUlJSU!!MZ3Fw45to5uY!f5SSgs9VAH1xxjFWgJMfr5ZlZH93z6GJlXoOgCmY8AVbjdeh2YlaUz632nE-HqDItW-gOuTqwg$>.
> <https://urldefense.com/v3/__https:/nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fnam11.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fdatatracker.ietf.org*2Fdoc*2Fdraft-ietf-sfc-ioam-nsh*2F__*3B!!MZ3Fw45to5uY!db6q3n8-5YqHkLtf3wyeBoUpO72v7UzeDtfPNhyePahNAYMo9eFdQxxBWM4C7Z0OJKHdTiRE6A*24*26data*3D04*7C01*7Cjames.n.guichard*40futurewei.com*7Caf9cde32be65486e459d08d9e53ac90c*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C1*7C637792862928234181*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*26sdata*3D9uDdhw0ViwBtWvn52V8UZ2G77lRnSye2Ols5z3U8QwQ*3D*26reserved*3D0__*3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSU!!MZ3Fw45to5uY!bzL7Vb_jHltGMCbCwne2rywfzpGjZW4o3fVr4clCr4Ir10KydDyJy5gHA8obfbMABJv33kGkLw*24&data=04*7C01*7Cjames.n.guichard*40futurewei.com*7Ca5db82494c32402334fc08d9ebdc83cf*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637800154631277005*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000&sdata=S6sx7MrrVkzKepVgj45q*2F2KPZzBMyOFnol*2BMfgRQ730*3D&reserved=0__;JSUlJSUlJSUlJSUqKioqKioqKioqKioqJSUqKioqKioqKioqKiolJSolJSUlJSUlJSUlJSUlJSUlJSUl!!MZ3Fw45to5uY!f5SSgs9VAH1xxjFWgJMfr5ZlZH93z6GJlXoOgCmY8AVbjdeh2YlaUz632nE-HqDItW-FOmuSHA$>
>
>
>
>
>
>
>

---

From: <[email-masked]>
Date: Tue, 12 Apr 2022 15:04:55 +0000

Hi Shwetha,

I suggest you simply add the following: “The O-bit MUST be handled following the rules in [I-D.ietf-sfc-oam-packet].”

Cheers,
Med

De : Shwetha Bhandari <[email-masked]>
Envoyé : mardi 12 avril 2022 16:56
À : BOUCADAIR Mohamed INNOV/NET <[email-masked]>
Cc : Frank Brockners (fbrockne) <fbrockne=[email-masked]>; Greg Mirsky <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; James Guichard <[email-masked]>; Tal Mizrahi <[email-masked]>; [email-masked]
Objet : Re: [sfc] WGLC for https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/

Med,

Thanks for the details: this is exactly what we had before the latest revision:

4.2<https://datatracker.ietf.org/doc/html/draft-ietf-sfc-ioam-nsh-06#section-4.2>.  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

   payload.

This was removed as per the discussion in this thread. Please check https://mailarchive.ietf.org/arch/msg/sfc/srMit5zE8UseNOhxknAw_dqvj6M/

It looks like we are going in a loop here. This definition of SFC OAM packet to include the OAM data that comes in inner packets via the next protocol header chain is introduced in draft-ietf-sfc-oam-packet to update the RFC8300.
Jim, What are you thoughts on this? Should we reintroduce the above text ?

Thanks,
Shwetha

On Tue, Apr 12, 2022 at 8:09 PM <[email-masked]<mailto:[email-masked]>> wrote:
Hi Franck,

==
      Such a packet

Cheers,
Med

De : sfc <[email-masked]<mailto:[email-masked]>> De la part de Frank Brockners (fbrockne)
Envoyé : mardi 12 avril 2022 13:55
À : BOUCADAIR Mohamed INNOV/NET <[email-masked]<mailto:[email-masked]>>; Shwetha Bhandari <[email-masked]<mailto:[email-masked]>>; Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Cc : [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; James Guichard <[email-masked]<mailto:[email-masked]>>; Tal Mizrahi <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Objet : Re: [sfc] WGLC for 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!JpBZ4H2-MNm5lJDGjooVj_3Sq-aX7gdh5qeoNPyZ69CXOFRhgdYmSOyreClzKvZDgPAiwaGN2YTO2qUw70GqHI4QEKQpGnBw0LXBXQ$>

Hi Med,

Thanks & Cheers, Frank

Subject: RE: [sfc] WGLC for 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!JpBZ4H2-MNm5lJDGjooVj_3Sq-aX7gdh5qeoNPyZ69CXOFRhgdYmSOyreClzKvZDgPAiwaGN2YTO2qUw70GqHI4QEKQpGnBw0LXBXQ$>

Hi Shwetha, all,

      Next Protocol:  8-bit unsigned integer that determines the type of
         header following IOAM.  The semantics of this field are
         identical to the Next Protocol field in [RFC8300<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc8300__;!!MZ3Fw45to5uY!JpBZ4H2-MNm5lJDGjooVj_3Sq-aX7gdh5qeoNPyZ69CXOFRhgdYmSOyreClzKvZDgPAiwaGN2YTO2qUw70GqHI4QEKQpGnDoYxXlRw$>].

Cheers,
Med

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 12 Apr 2022 08:53:56 -0700

Hi Shwetha,
I believe that the text you've quoted is helpful. I would suggest changing
references from [RFC8300] to [I-D.ietf-sfc-oam-packet] throughout that
paragraph.

Regards,
Greg

On Tue, Apr 12, 2022 at 7:56 AM Shwetha Bhandari <
[email-masked]> wrote:

> 4.2 <https://datatracker.ietf.org/doc/html/draft-ietf-sfc-ioam-nsh-06#section-4.2>.  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
>> *À :* BOUCADAIR Mohamed INNOV/NET <[email-masked]>;
>> Shwetha Bhandari <[email-masked]>; Greg Mirsky <
>> [email-masked]>
>> Protocols can have their protocol specific OAM methods and solutions,
>> like SFC OAM. Those protocol specific solutions (like SFC OAM as an
>> example) are orthogonal to IOAM from a concept and scope perspective.
>>
>>
>>
>> From an SFC OAM perspective, your draft-ietf-sfc-oam-packet-00 clearly
>> and rightly states that “O bit: Setting this bit indicates an SFC OAM
>> packet.” The O bit is about SFC OAM, and as such is orthogonal to “anything
>> IOAM”. In earlier versions of draft-ietf-sfc-ioam-nsh we had text which
>> stated that the O bit remains unchanged whether IOAM is present or not. To
>> avoid any confusion, in -08 we removed this statement – just to make it
>> crystal clear that there is no link between “IOAM” and “SFC OAM”.
>>
>>
>>
>> *Cc :* [email-masked]; Frank Brockners (fbrockne) <
>> [email-masked]>; [email-masked]; James Guichard <

---

From: Shwetha Bhandari <[email-masked]>
Date: Thu, 14 Apr 2022 15:35:41 +0530

Hi Med, Greg,

How about this text :

“The O-bit MUST be handled following the rules in and any updates
to [RFC8300] ."

Given that I-D.ietf-sfc-oam-packet  will update RF8300 and there could be
others in future?

Thanks,
Shwetha

On Tue, Apr 12, 2022 at 9:24 PM Greg Mirsky <[email-masked]> wrote:

>> 4.2 <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-sfc-ioam-nsh-06*section-4.2__;Iw!!MZ3Fw45to5uY!NBsrzhHEf0Y_-Sindy74K4QDA6EWJjx35STSH-UxEi3eYIX0GVli9Sn1azrOPJVcI2qUzWfezK_1D2RpyFB_FOIpJPfzrvI$>.  IOAM and the use of the NSH O-bit
>>
>>    [RFC8300] defines an "O bit" for OAM packets.  Per [RFC8300 <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/rfc8300__;!!MZ3Fw45to5uY!NBsrzhHEf0Y_-Sindy74K4QDA6EWJjx35STSH-UxEi3eYIX0GVli9Sn1azrOPJVcI2qUzWfezK_1D2RpyFB_FOIpEB5AbbE$>] the O
>> <https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/sfc/srMit5zE8UseNOhxknAw_dqvj6M/__;!!MZ3Fw45to5uY!NBsrzhHEf0Y_-Sindy74K4QDA6EWJjx35STSH-UxEi3eYIX0GVli9Sn1azrOPJVcI2qUzWfezK_1D2RpyFB_FOIp-CeLfeA$>
>>
>>> Things are pretty clear (as per draft-ietf-sfc-oam-packet) that the O
>>> bit must be unset when IOAM data is included + user data.
>>>
>>>
>>>
>>> *Cc :* [email-masked]; [email-masked]; [email-masked]; James Guichard
>>> <[email-masked]>; Tal Mizrahi <[email-masked]>;
>>> Sorry for arriving late to the party. Reading through your message
>>> below, there seems to be a confusion about the scope and concept of
>>> different OAM mechanisms.
>>>
>>>
>>>
>>> *Cc:* [email-masked]; Frank Brockners (fbrockne) <

---

From: <[email-masked]>
Date: Thu, 14 Apr 2022 11:27:52 +0000

Hi Shwetha,

I prefer we go for an explicit reference to I-D.ietf-sfc-oam-packet rather than “any update to RFC8300”. This is consistent with the usage in the other OAM draft.

Thank you.

Cheers,
Med

De : Shwetha Bhandari <[email-masked]>
Envoyé : jeudi 14 avril 2022 12:06
À : Greg Mirsky <[email-masked]>
Cc : BOUCADAIR Mohamed INNOV/NET <[email-masked]>; Frank Brockners (fbrockne) <fbrockne=[email-masked]>; [email-masked]; [email-masked]; [email-masked]; James Guichard <[email-masked]>; Tal Mizrahi <[email-masked]>; [email-masked]
Objet : Re: [sfc] WGLC for https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/

Hi Med, Greg,

How about this text :

“The O-bit MUST be handled following the rules in and any updates to [RFC8300] ."

Given that I-D.ietf-sfc-oam-packet  will update RF8300 and there could be others in future?

Thanks,
Shwetha

On Tue, Apr 12, 2022 at 9:24 PM Greg Mirsky <[email-masked]<mailto:[email-masked]>> wrote:
Hi Shwetha,
I believe that the text you've quoted is helpful. I would suggest changing references from [RFC8300] to [I-D.ietf-sfc-oam-packet] throughout that paragraph.

Regards,
Greg

On Tue, Apr 12, 2022 at 7:56 AM Shwetha Bhandari <[email-masked]<mailto:[email-masked]>> wrote:
Med,

4.2<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-sfc-ioam-nsh-06*section-4.2__;Iw!!MZ3Fw45to5uY!NBsrzhHEf0Y_-Sindy74K4QDA6EWJjx35STSH-UxEi3eYIX0GVli9Sn1azrOPJVcI2qUzWfezK_1D2RpyFB_FOIpJPfzrvI$>.  IOAM and the use of the NSH O-bit

   [RFC8300] defines an "O bit" for OAM packets.  Per [RFC8300<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc8300__;!!MZ3Fw45to5uY!NBsrzhHEf0Y_-Sindy74K4QDA6EWJjx35STSH-UxEi3eYIX0GVli9Sn1azrOPJVcI2qUzWfezK_1D2RpyFB_FOIpEB5AbbE$>] the O

   payload.

This was removed as per the discussion in this thread. Please check https://mailarchive.ietf.org/arch/msg/sfc/srMit5zE8UseNOhxknAw_dqvj6M/<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/sfc/srMit5zE8UseNOhxknAw_dqvj6M/__;!!MZ3Fw45to5uY!NBsrzhHEf0Y_-Sindy74K4QDA6EWJjx35STSH-UxEi3eYIX0GVli9Sn1azrOPJVcI2qUzWfezK_1D2RpyFB_FOIp-CeLfeA$>

Thanks,
Shwetha

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 14 Apr 2022 08:39:28 -0400

Frank, I am a little confused by your note.  draft-ietf-sfc-oam-packet 
is in last call.  That is not "early stages and still evolving".

Do you have concerns with draft-ietf-sfc-oam-packet that you have not 
sent to the list?

Given that we are finishing this draft up, and the draft is about the 
O-Bit, referring to it in draft-ietf-sfc-ioam-nsh seems the appropriate 
step.

Yours,
Joel

On 4/14/2022 8:24 AM, Frank Brockners (fbrockne) wrote:
> IMHO it would be better to refer to directly RFC8300 – since this is a 
> stable reference; and it allows us to finish up draft-ietf-sfc-ioam-nsh 
> and get the code points allocated. I-D.ietf-sfc-oam-packet is early 
> stages and still evolving.
> 
> Cheers, Frank
> 
> *From:[email-masked] <[email-masked]>
> *Sent:* Thursday, 14 April 2022 13:28
> *To:* Shwetha Bhandari <[email-masked]>; Greg Mirsky 
> <[email-masked]>
> *Cc:* Frank Brockners (fbrockne) <fbrockne=[email-masked]>; 
> [email-masked]; [email-masked]; [email-masked]; James Guichard 
> <[email-masked]>; Tal Mizrahi 
> <[email-masked]>; [email-masked]
> I prefer we go for an explicit reference to I-D.ietf-sfc-oam-packet 
> rather than “any update to RFC8300”. This is consistent with the usage 
> in the other OAM draft.
> 
> Thank you.
> 
> Cheers,
> 
> Med
> 
> *De :*Shwetha Bhandari <[email-masked] 
> <mailto:[email-masked]>>
> *Envoyé :* jeudi 14 avril 2022 12:06
> *À :* Greg Mirsky <[email-masked] <mailto:[email-masked]>>
> *Cc :* BOUCADAIR Mohamed INNOV/NET <[email-masked] 
> <mailto:[email-masked]>>; Frank Brockners (fbrockne) 
> <fbrockne=[email-masked] 
> <mailto:fbrockne=[email-masked]>>; [email-masked] 
> <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; 
> [email-masked] <mailto:[email-masked]>; James Guichard 
> <[email-masked] 
> <mailto:[email-masked]>>; Tal Mizrahi 
> <[email-masked] <mailto:[email-masked]>>; 
> [email-masked] <mailto:[email-masked]>
> <https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/>
> 
> Hi Med, Greg,
> 
> How about this text :
> 
>     I believe that the text you've quoted is helpful. I would suggest
>     changing references from [RFC8300] to [I-D.ietf-sfc-oam-packet]
>     throughout that paragraph.
> 
>     Regards,
> 
>     Greg
> 
>     On Tue, Apr 12, 2022 at 7:56 AM Shwetha Bhandari
>     <[email-masked]
>     <mailto:[email-masked]>> wrote:
> 
>         Med,
> 
>         *4.2
>         <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-sfc-ioam-nsh-06*section-4.2__;Iw!!MZ3Fw45to5uY!NBsrzhHEf0Y_-Sindy74K4QDA6EWJjx35STSH-UxEi3eYIX0GVli9Sn1azrOPJVcI2qUzWfezK_1D2RpyFB_FOIpJPfzrvI$>. 
>         <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc8300__;!!MZ3Fw45to5uY!NBsrzhHEf0Y_-Sindy74K4QDA6EWJjx35STSH-UxEi3eYIX0GVli9Sn1azrOPJVcI2qUzWfezK_1D2RpyFB_FOIpEB5AbbE$>]
>         the O
> 
>         <https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/sfc/srMit5zE8UseNOhxknAw_dqvj6M/__;!!MZ3Fw45to5uY!NBsrzhHEf0Y_-Sindy74K4QDA6EWJjx35STSH-UxEi3eYIX0GVli9Sn1azrOPJVcI2qUzWfezK_1D2RpyFB_FOIp-CeLfeA$>
> 
>         It looks like we are going in a loop here. This definition of
>         SFC OAM packet to include the OAM data that comes in inner
>         packets via the next protocol header chain is introduced in
>         draft-ietf-sfc-oam-packet to update the RFC8300.
> 
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
> 
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez 
> recu ce message par erreur, veuillez le signaler
> 
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
> electroniques etant susceptibles d'alteration,
> 
> This message and its attachments may contain confidential or privileged 
> information that may be protected by law;
>

---

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Thu, 14 Apr 2022 12:24:06 +0000

IMHO it would be better to refer to directly RFC8300 – since this is a stable reference; and it allows us to finish up draft-ietf-sfc-ioam-nsh and get the code points allocated. I-D.ietf-sfc-oam-packet is early stages and still evolving.

Cheers, Frank

From: [email-masked] <[email-masked]>
Sent: Thursday, 14 April 2022 13:28
To: Shwetha Bhandari <[email-masked]>; Greg Mirsky <[email-masked]>
Cc: Frank Brockners (fbrockne) <fbrockne=[email-masked]>; [email-masked]; [email-masked]; [email-masked]; James Guichard <[email-masked]>; Tal Mizrahi <[email-masked]>; [email-masked]
Subject: RE: [sfc] WGLC for https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/

Hi Shwetha,

Thank you.

Cheers,
Med

De : Shwetha Bhandari <[email-masked]<mailto:[email-masked]>>
Envoyé : jeudi 14 avril 2022 12:06
À : Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Cc : BOUCADAIR Mohamed INNOV/NET <[email-masked]<mailto:[email-masked]>>; Frank Brockners (fbrockne) <fbrockne=[email-masked]<mailto:fbrockne=[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; James Guichard <[email-masked]<mailto:[email-masked]>>; Tal Mizrahi <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Objet : Re: [sfc] WGLC for https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/

Hi Med, Greg,

How about this text :

Thanks,
Shwetha

Regards,
Greg

   payload.

Thanks,
Shwetha

Thank you.

---

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Thu, 14 Apr 2022 12:29:17 +0000

Forgot to add: A clause like " The O-bit MUST be handled following the rules in and any updates to [RFC8300]“ simply states the obvious. draft-ietf-sfc-ioam-nsh does not touch or redefine the O-bit – hence the statement is at best optional. The reader might even wonder why the obvious is re-stated in the document. My preference is still to avoid any mentioning of the O-bit in draft-ietf-sfc-ioam-nsh.

Frank

From: Frank Brockners (fbrockne)
Sent: Thursday, 14 April 2022 14:24
To: [email-masked]; Shwetha Bhandari <[email-masked]>; Greg Mirsky <[email-masked]>
Cc: Frank Brockners (fbrockne) <fbrockne=[email-masked]>; [email-masked]; [email-masked]; [email-masked]; James Guichard <[email-masked]>; Tal Mizrahi <[email-masked]>; [email-masked]
Subject: RE: [sfc] WGLC for https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/

Cheers, Frank

Cc: Frank Brockners (fbrockne) <fbrockne=[email-masked]<mailto:fbrockne=[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; James Guichard <[email-masked]<mailto:[email-masked]>>; Tal Mizrahi <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

Hi Shwetha,

Thank you.

Cheers,
Med

Hi Med, Greg,

How about this text :

Thanks,
Shwetha

Regards,
Greg

   payload.

Thanks,
Shwetha

Thank you.

---

From: <[email-masked]>
Date: Thu, 14 Apr 2022 12:31:57 +0000

Hi Franck,

I wished that solely referring to 8300 would suffice, but unfortunately we can’t.

I-D.ietf-sfc-oam-packet is already in the WGLC.

Cheers,
Med

De : Frank Brockners (fbrockne) <[email-masked]>
Envoyé : jeudi 14 avril 2022 14:24
À : BOUCADAIR Mohamed INNOV/NET <[email-masked]>; Shwetha Bhandari <[email-masked]>; Greg Mirsky <[email-masked]>
Cc : Frank Brockners (fbrockne) <fbrockne=[email-masked]>; [email-masked]; [email-masked]; [email-masked]; James Guichard <[email-masked]>; Tal Mizrahi <[email-masked]>; [email-masked]
Objet : RE: [sfc] WGLC for https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/

Cheers, Frank

Hi Shwetha,

Thank you.

Cheers,
Med

Hi Med, Greg,

How about this text :

Thanks,
Shwetha

Regards,
Greg

   payload.

Thanks,
Shwetha

Thank you.

---

From: <[email-masked]>
Date: Thu, 14 Apr 2022 12:38:38 +0000

Re-,

draft-ietf-sfc-ioam-nsh includes OAM data (likely with user data) but there is an ambiguity in 8300 to whether this is considered as an OAM packet. Please refer to the SFC archives where this was discussed.

Cheers,
Med

Envoyé : jeudi 14 avril 2022 14:29

Frank

To: [email-masked]<mailto:[email-masked]>; Shwetha Bhandari <[email-masked]<mailto:[email-masked]>>; Greg Mirsky <[email-masked]<mailto:[email-masked]>>

Cheers, Frank

Hi Shwetha,

Thank you.

Cheers,
Med

Hi Med, Greg,

How about this text :

Thanks,
Shwetha

Regards,
Greg

   payload.

Thanks,
Shwetha

Thank you.

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 14 Apr 2022 06:11:21 -0700

Hi Shwetha,
thank you for the proposed resolution. I agree with Med, direct normative
reference to I-D.ietf-sfc-oam-packet seems like the logical conclusion of
our discussion of the use of the NSH O bit. Please note that we're
referring to I-D.ietf-sfc-oam-packet in the Active SFC OAM draft, e.g.,:

The O bit in NSH MUST be set, according to [I-D.ietf-sfc-oam-packet].

Regards,
Greg

On Thu, Apr 14, 2022 at 4:27 AM <[email-masked]> wrote:

> Hi Shwetha,
>
>
>
> I prefer we go for an explicit reference to I-D.ietf-sfc-oam-packet rather
> than “any update to RFC8300”. This is consistent with the usage in the
> other OAM draft.
>
>
>
> Thank you.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* Shwetha Bhandari <[email-masked]>
> *Cc :* BOUCADAIR Mohamed INNOV/NET <[email-masked]>; Frank
> Brockners (fbrockne) <fbrockne=[email-masked]>;
> [email-masked]; [email-masked]; [email-masked]; James Guichard <
> *4.2 <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-sfc-ioam-nsh-06*section-4.2__;Iw!!MZ3Fw45to5uY!NBsrzhHEf0Y_-Sindy74K4QDA6EWJjx35STSH-UxEi3eYIX0GVli9Sn1azrOPJVcI2qUzWfezK_1D2RpyFB_FOIpJPfzrvI$>.  IOAM and the use of the NSH O-bit*
>
>
>
>    [RFC8300] defines an "O bit" for OAM packets.  Per [RFC8300 <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc8300__;!!MZ3Fw45to5uY!NBsrzhHEf0Y_-Sindy74K4QDA6EWJjx35STSH-UxEi3eYIX0GVli9Sn1azrOPJVcI2qUzWfezK_1D2RpyFB_FOIpEB5AbbE$>] the O
>

---

From: Shwetha Bhandari <[email-masked]>
Date: Thu, 14 Apr 2022 18:18:05 +0530

Hi Med,

Why does reference to RFC 8300 and any update to it, not work? Doesn't
I-D.ietf-sfc-oam-packet update 8300 and anyone implementing this will be
able to find 8300 and any RFCs that update it and apply the rules?

Thanks
Shwetha

On Thu, Apr 14, 2022, 6:08 PM <[email-masked]> wrote:

> Re-,
>
>
>
> draft-ietf-sfc-ioam-nsh includes OAM data (likely with user data) but
> there is an ambiguity in 8300 to whether this is considered as an OAM
> packet. Please refer to the SFC archives where this was discussed.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* Frank Brockners (fbrockne) <[email-masked]>
> *Envoyé :* jeudi 14 avril 2022 14:29
> *Cc :* Frank Brockners (fbrockne) <fbrockne=[email-masked]>;
> *Objet :* RE: [sfc] WGLC for
> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/__;!!MZ3Fw45to5uY!P-r3UTstV56mLT678QmjnilBnxUfgnF62GGWB1KzZc9aczyFl44k8Ug9OrmNYsuFT09oX0UTEcp7d4J6cmU45CEFXUZ4y_RxQ0E9Fg$>
>
>
>
> Forgot to add: A clause like " The O-bit MUST be handled following the
> rules in and any updates to [RFC8300]“ simply states the obvious.
> draft-ietf-sfc-ioam-nsh does not touch or redefine the O-bit – hence the
> statement is at best optional. The reader might even wonder why the obvious
> is re-stated in the document. My preference is still to avoid any
> mentioning of the O-bit in draft-ietf-sfc-ioam-nsh.
>
>
>
> Frank
>
>
>
> *From:* Frank Brockners (fbrockne)
> *Sent:* Thursday, 14 April 2022 14:24
> *To:* [email-masked]; Shwetha Bhandari <
> [email-masked]>; Greg Mirsky <[email-masked]>
> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/__;!!MZ3Fw45to5uY!P-r3UTstV56mLT678QmjnilBnxUfgnF62GGWB1KzZc9aczyFl44k8Ug9OrmNYsuFT09oX0UTEcp7d4J6cmU45CEFXUZ4y_RxQ0E9Fg$>
>
>
>
> stable reference; and it allows us to finish up draft-ietf-sfc-ioam-nsh and
> get the code points allocated. I-D.ietf-sfc-oam-packet is early stages and
> still evolving.
>
>
>
> Cheers, Frank
>
>
>
> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/__;!!MZ3Fw45to5uY!P-r3UTstV56mLT678QmjnilBnxUfgnF62GGWB1KzZc9aczyFl44k8Ug9OrmNYsuFT09oX0UTEcp7d4J6cmU45CEFXUZ4y_RxQ0E9Fg$>
>
>
>
> Hi Shwetha,
>
>
>
> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/__;!!MZ3Fw45to5uY!P-r3UTstV56mLT678QmjnilBnxUfgnF62GGWB1KzZc9aczyFl44k8Ug9OrmNYsuFT09oX0UTEcp7d4J6cmU45CEFXUZ4y_RxQ0E9Fg$>
>
>
>
> Hi Med, Greg,
>
>
>
> How about this text :
>
>
>