Re: [sfc] TR: I-D Action: draft-boucadair-sfc-oam-packet-00.txt

Hi Med,
thank you for your expedient response. I have a follow-up question:

How does one determine the nature, OAM or not-OAM, of data elements in the
NSH Context header?

As I understand it, draft-ietf-sfc-nsh-tlv does not provide that. Do we
need to add it? Appreciate your thoughts on that.

Regards,
Greg

On Wed, Feb 16, 2022 at 7:30 AM <mohamed.boucadair@orange.com> wrote:

> Hi Greg,
>
>
>
> Please see inline.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* Greg Mirsky <gregimirsky@gmail.com>
> *Envoyé :* mercredi 16 février 2022 16:13
> *À :* BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com>
> *Cc :* sfc@ietf.org
> *Objet :* Re: [sfc] TR: I-D Action: draft-boucadair-sfc-oam-packet-00.txt
>
>
>
> Hi Med,
>
> many thanks for taking the lead and putting the proposal on the table.
>
> I have a question on the proposed new text for the O bit and its possible
> effect on IOAM:
>
>    O bit:  Setting this bit indicates an SFC OAM packet.  Such a packet
>
>       is any NSH-encapasulated packet that exclusively includes an OAM
>
>       command and/or OAM data.
>
> My understanding of the new definition of the O bit is that the NSH
> includes and/or encapsulates only OAM command and/or data. IOAM, as I
> understand its application in NSH, may follow the NSH and have user payload
> after the IOAM data.
>
>
>
> *[Med] Packets that include also user data are not considered as “OAM
> packets” as per the new definition.*
>
>
>
> And another scenario, if Flow ID TLV is used to influence user data
> through SFP, OAM will apply the same Flow ID value. Would such packet
> still be considered as "exclusively includes OAM command and/or data"?
>
>
>
> *[Med] Yes, they are. Flow id is just a constraint, if you will, that is
> used to influence how OAM commands will be executed.  *
>
>
>
> Regards,
>
> Greg
>
>
>
> On Wed, Feb 16, 2022 at 6:40 AM <mohamed.boucadair@orange.com> wrote:
>
> Hi all,
>
> A proposal to clarify the intent of SFC OAM packet. Comments are welcome.
>
> Cheers,
> Med
>
> -----Message d'origine-----
> De : I-D-Announce <i-d-announce-bounces@ietf.org> De la part de
> internet-drafts@ietf.org
> Envoyé : mercredi 16 février 2022 15:38
> À : i-d-announce@ietf.org
> Objet : I-D Action: draft-boucadair-sfc-oam-packet-00.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
>         Title           : Clarifying Ambiguity related to Network Service
> Header (NSH) OAM Packet
>         Author          : Mohamed Boucadair
>         Filename        : draft-boucadair-sfc-oam-packet-00.txt
>         Pages           : 5
>         Date            : 2022-02-16
>
> Abstract:
>    This document clarifies an ambiguity in the Network Service Header
>    (NSH) specification related to the handling of O-bit.  In particular,
>    this document clarifies the meaning of "OAM packet".
>
>    This document updates RFC8300.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-boucadair-sfc-oam-packet/
>
> There is also an htmlized version available at:
> https://datatracker.ietf.org/doc/html/draft-boucadair-sfc-oam-packet-00
>
>
> Internet-Drafts are also available by rsync at rsync.ietf.org:
> :internet-drafts
>
>
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html or
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
> _________________________________________________________________________________________________________________________
>
> 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.
>
> _______________________________________________
> sfc mailing list
> sfc@ietf.org
> https://www.ietf.org/mailman/listinfo/sfc
>
> _________________________________________________________________________________________________________________________
>
> 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.
>
>