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

[Greg Mirsky <[e-mail]>]

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 <
[e-mail]> wrote:

> 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
>    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 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 <[e-mail]> wrote:
>
>> 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 <[e-mail]> *De la part de* Frank Brockners
>> (fbrockne)
>> *Envoyé :* mardi 12 avril 2022 13:55
>> *À :* BOUCADAIR Mohamed INNOV/NET <[e-mail]>;
>> Shwetha Bhandari <[e-mail]>; Greg Mirsky <
>> [e-mail]>
>> *Cc :* [e-mail]; [e-mail]; [e-mail]; James Guichard <
>> [e-mail]>; Tal Mizrahi <[e-mail]>;
>> [e-mail]
>> *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,
>>
>>
>>
>> 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:* [e-mail] <[e-mail]>
>> *Sent:* Monday, 4 April 2022 07:40
>> *To:* Shwetha Bhandari <[e-mail]>; Greg Mirsky <
>> [e-mail]>
>> *Cc:* [e-mail]; Frank Brockners (fbrockne) <[e-mail]>;
>> [e-mail]; James Guichard <[e-mail]>; Tal
>> Mizrahi <[e-mail]>; [e-mail]
>> *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,
>>
>>
>>
>> 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://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.
>>
>>
>>
>> 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 <[e-mail]> *De la part de* Shwetha Bhandari
>> *Envoyé :* lundi 4 avril 2022 02:41
>> *À :* Greg Mirsky <[e-mail]>
>> *Cc :* [e-mail]; Frank Brockners (fbrockne) <
>> [e-mail]>; [e-mail]; James Guichard <
>> [e-mail]>; Tal Mizrahi <[e-mail]>;
>> [e-mail]
>> *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 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 <[e-mail]> 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 <
>> [e-mail]> 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 <
>> [e-mail]> 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 <[e-mail]>
>> *Sent:* Wednesday, February 9, 2022 9:57 AM
>> *To:* Greg Mirsky <[e-mail]>
>> *Cc:* James Guichard <[e-mail]>;
>> [e-mail]; [e-mail]; [e-mail]
>> *Subject:* Re: [sfc] WGLC for
>> https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/
>> <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 <[e-mail]> 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 <
>> [e-mail]> 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 <
>> [e-mail]> 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 <[e-mail]>
>> *Sent:* Monday, January 31, 2022 11:25 PM
>> *To:* Greg Mirsky <[e-mail]>
>> *Cc:* James Guichard <[e-mail]>;
>> [e-mail]; [e-mail]; [e-mail]
>> *Subject:* Re: [sfc] WGLC for
>> https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/
>> <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 <[e-mail]>
>> wrote:
>>
>> Hi Shwetha,
>>
>> thank you for the detailed response to my comments. Please feel free to
>> share any updates you're considering for the next version. I'll be glad to
>> work together on these.
>>
>> I have several follow-up notes in-lined below under the GIM>> tag.
>>
>>
>>
>> Regards,
>>
>> Greg
>>
>>
>>
>> On Tue, Oct 26, 2021 at 6:51 PM Shwetha Bhandari <
>> [e-mail]> wrote:
>>
>> Hi Greg,
>>
>>
>>
>> Sorry for the very late reply. Please find responses to your comments
>> inline @Shwetha:
>>
>>
>>
>>
>>
>>
>>
>> On Wed, Sep 8, 2021 at 3:30 AM Greg Mirsky <[e-mail]> 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 <
>> [e-mail]> wrote:
>>
>> Dear WG:
>>
>>
>>
>> This email starts a 2 week Working Group Last Call for
>> draft-ietf-sfc-ioam-nsh [1].
>>
>>
>>
>> Please read this document if you haven’t read the most recent version and
>> send your comments to the SFC WG list no later than September 1st 2021.
>>
>>
>>
>> If you are raising a point which you expect will be specifically debated
>> on the mailing list, consider using a specific email/thread for this point.
>>
>>
>>
>> Lastly, if you are an author or contributor please response to indicate
>> whether you know of any undisclosed IPR related to this document.
>>
>>
>>
>> Thanks!
>>
>>
>>
>> Jim & Joel
>>
>>
>>
>> [1] https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/
>> <https://urldefense.com/v3/__https:/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
>> [e-mail]
>>
>> _________________________________________________________________________________________________________________________
>>
>> 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.
>>
>>