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

From: <[email-masked]>
Date: Wed, 16 Feb 2022 14:40:11 +0000

Hi all, 

A proposal to clarify the intent of SFC OAM packet. Comments are welcome.

Cheers,
Med

-----Message d'origine-----
De : I-D-Announce <[email-masked]> De la part de [email-masked]
Envoyé : mercredi 16 février 2022 15:38
À : [email-masked]
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
[email-masked]
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.

---

From: James Guichard <[email-masked]>
Date: Wed, 16 Feb 2022 14:47:13 +0000

Hi Med,

Thank you for doing this!

I think the following questions are relevant and should be clarified as part of the draft text:

(1) Should the O-bit be set ONLY for OAM packets that are specific to the SFC service layer?
(2) Should the O-bit be set in the cases where a solution uses the next protocol field in the NSH header? In this case what is the purpose of the O-bit given that the next protocol field already indicates the expected behavior?
(3) If the O-bit is set is it the expected behavior to find relevant SFC service layer OAM information ONLY in the context headers?
(4) If the answer to (3) is no then what is the sequence of behavior to find the OAM information? (1) look in context headers and then next protocol?, (2) look at next protocol and if not an OAM protocol look in context headers?, (3) some other sequence?

Jim

-----Original Message-----
From: sfc <[email-masked]> On Behalf Of [email-masked]
Sent: Wednesday, February 16, 2022 9:40 AM
To: [email-masked]
Subject: [sfc] TR: I-D Action: draft-boucadair-sfc-oam-packet-00.txt

Hi all, 

Cheers,
Med

-----Message d'origine-----
De : I-D-Announce <[email-masked]> De la part de [email-masked] Envoyé : mercredi 16 février 2022 15:38 À : [email-masked] Objet : I-D Action: draft-boucadair-sfc-oam-packet-00.txt

Abstract:

The IETF datatracker status page for this draft is:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-boucadair-sfc-oam-packet%2F&amp;data=04%7C01%7Cjames.n.guichard%40futurewei.com%7Ca3484be3413e4d7f0ded08d9f15a462e%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637806192321886192%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=InMITh%2FD%2FNkAnNh0rvL5EeeshzdTbrxXeGKwOCVNyAA%3D&amp;reserved=0

There is also an htmlized version available at:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-boucadair-sfc-oam-packet-00&amp;data=04%7C01%7Cjames.n.guichard%40futurewei.com%7Ca3484be3413e4d7f0ded08d9f15a462e%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637806192321886192%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=XzLwiIMGzlBD0rM6Q%2Bf4v68iFYlcee3Kegm08FVcUmw%3D&amp;reserved=0

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fi-d-announce&amp;data=04%7C01%7Cjames.n.guichard%40futurewei.com%7Ca3484be3413e4d7f0ded08d9f15a462e%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637806192321886192%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=W3MJq4OJvBesWQg5t6FS%2FJQH7BSK7GQqAQzQV5rT2gY%3D&amp;reserved=0
Internet-Draft directories: https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.ietf.org%2Fshadow.html&amp;data=04%7C01%7Cjames.n.guichard%40futurewei.com%7Ca3484be3413e4d7f0ded08d9f15a462e%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637806192321886192%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=8fnzdUA6tJApFT%2FhR3fgCImL7TNZen3Qox4%2FAWEqknU%3D&amp;reserved=0 or https://nam11.safelinks.protection.outlook.com/?url=ftp%3A%2F%2Fftp.ietf.org%2Fietf%2F1shadow-sites.txt&amp;data=04%7C01%7Cjames.n.guichard%40futurewei.com%7Ca3484be3413e4d7f0ded08d9f15a462e%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637806192321886192%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=HGYz6%2BCCQ%2Bnv7ZTVibxMJgujKFpHcXMj0XpmOEba0Ww%3D&amp;reserved=0

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
[email-masked]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsfc&amp;data=04%7C01%7Cjames.n.guichard%40futurewei.com%7Ca3484be3413e4d7f0ded08d9f15a462e%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637806192321886192%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=Q6Wls3Pms3n4YDK1Ert9f1GRoiFaaX2kVPgUlmjTm8A%3D&amp;reserved=0

---

From: <[email-masked]>
Date: Wed, 16 Feb 2022 15:08:31 +0000

Hi Jim, 

Great questions and I hope to hear more from the WG. 

Please see inline my current thoughts on this.

Cheers,
Med

> De : sfc <[email-masked]> De la part de James Guichard
> Envoyé : mercredi 16 février 2022 15:47
> À : BOUCADAIR Mohamed INNOV/NET <[email-masked]>;
> [email-masked]
> Objet : Re: [sfc] I-D Action: draft-boucadair-sfc-oam-packet-00.txt
> 
> Hi Med,
> 

[Med] The proposed update less restrictive as it allows to include an OAM command/data even in the inner packet. 

> (2) Should the O-bit be set in the cases where a solution uses the next
> protocol field in the NSH header? In this case what is the purpose of the
> O-bit given that the next protocol field already indicates the expected
> behavior?

[Med] The proposed update allows for this. Setting the O-bit allows to make sure that all traversed SFC elements supports that OAM functionality. The packet will get dropped if so.  This is deterministic if we want the OAM outcome to be reliable, otherwise there is a risk that the OAM data does not reflect the full path. 

> (3) If the O-bit is set is it the expected behavior to find relevant SFC
> service layer OAM information ONLY in the context headers?

[Med] The proposed update is less restrictive as it allows to have it in context headers or even the payload. The next-protocol will help interpreting the data. The O-bit is allowed to be unset only when the OAM data is jointly sent with the user data.  

> (4) If the answer to (3) is no then what is the sequence of behavior to
> find the OAM information? (1) look in context headers and then next
> protocol?, (2) look at next protocol and if not an OAM protocol look in
> context headers?, (3) some other sequence?

[Med] The exact sequence will depend on the definition of the context header and the data identified by the next-protocol. I'm not sure we can impose a generic sequence here, but I may be wrong. 

> De : I-D-Announce <[email-masked]> De la part de internet-
> [email-masked] Envoyé : mercredi 16 février 2022 15:38 À : i-d-
> [email-masked] Objet : I-D Action: draft-boucadair-sfc-oam-packet-00.txt
> 
> 
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatrack
> er.ietf.org%2Fdoc%2Fdraft-boucadair-sfc-oam-
> packet%2F&amp;data=04%7C01%7Cjames.n.guichard%40futurewei.com%7Ca3484be3413
> e4d7f0ded08d9f15a462e%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C63780619
> 2321886192%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJB
> TiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=InMITh%2FD%2FNkAnNh0rvL5Eeeshzd
> TbrxXeGKwOCVNyAA%3D&amp;reserved=0
> 
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatrack
> er.ietf.org%2Fdoc%2Fhtml%2Fdraft-boucadair-sfc-oam-packet-
> 00&amp;data=04%7C01%7Cjames.n.guichard%40futurewei.com%7Ca3484be3413e4d7f0d
> ed08d9f15a462e%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637806192321886
> 192%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1
> haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=XzLwiIMGzlBD0rM6Q%2Bf4v68iFYlcee3Kegm0
> 8FVcUmw%3D&amp;reserved=0
> 
> 
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.
> org%2Fmailman%2Flistinfo%2Fi-d-
> announce&amp;data=04%7C01%7Cjames.n.guichard%40futurewei.com%7Ca3484be3413e
> 4d7f0ded08d9f15a462e%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637806192
> 321886192%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBT
> iI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=W3MJq4OJvBesWQg5t6FS%2FJQH7BSK7G
> QqAQzQV5rT2gY%3D&amp;reserved=0
> Internet-Draft directories:
> https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.ietf.o
> rg%2Fshadow.html&amp;data=04%7C01%7Cjames.n.guichard%40futurewei.com%7Ca348
> 4be3413e4d7f0ded08d9f15a462e%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C6
> 37806192321886192%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM
> zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=8fnzdUA6tJApFT%2FhR3fgCI
> mL7TNZen3Qox4%2FAWEqknU%3D&amp;reserved=0 or
> https://nam11.safelinks.protection.outlook.com/?url=ftp%3A%2F%2Fftp.ietf.or
> g%2Fietf%2F1shadow-
> sites.txt&amp;data=04%7C01%7Cjames.n.guichard%40futurewei.com%7Ca3484be3413
> e4d7f0ded08d9f15a462e%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C63780619
> 2321886192%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJB
> TiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=HGYz6%2BCCQ%2Bnv7ZTVibxMJgujKFp
> HcXMj0XpmOEba0Ww%3D&amp;reserved=0
> 
> ___________________________________________________________________________
> ______________________________________________
> 
> 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; they should not be distributed,
> used or copied without authorisation.
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.
> org%2Fmailman%2Flistinfo%2Fsfc&amp;data=04%7C01%7Cjames.n.guichard%40future
> wei.com%7Ca3484be3413e4d7f0ded08d9f15a462e%7C0fee8ff2a3b240189c753a1d5591fe
> dc%7C1%7C0%7C637806192321886192%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDA
> iLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=Q6Wls3Pms3
> n4YDK1Ert9f1GRoiFaaX2kVPgUlmjTm8A%3D&amp;reserved=0
> 
> https://www.ietf.org/mailman/listinfo/sfc

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 16 Feb 2022 07:13:12 -0800

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.
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"?

Regards,
Greg

On Wed, Feb 16, 2022 at 6:40 AM <[email-masked]> wrote:

> Internet-Draft directories: http://www.ietf.org/shadow.html or
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
> 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,
> information that may be protected by law;

---

From: <[email-masked]>
Date: Wed, 16 Feb 2022 15:30:34 +0000

Hi Greg,

Please see inline.

Cheers,
Med

De : Greg Mirsky <[email-masked]>
Envoyé : mercredi 16 février 2022 16:13
À : BOUCADAIR Mohamed INNOV/NET <[email-masked]>
Cc : [email-masked]
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 <[email-masked]<mailto:[email-masked]>> wrote:
Hi all,

Cheers,
Med

-----Message d'origine-----
De : I-D-Announce <[email-masked]<mailto:[email-masked]>> De la part de [email-masked]<mailto:[email-masked]>
Envoyé : mercredi 16 février 2022 15:38
À : [email-masked]<mailto:[email-masked]>
Objet : I-D Action: draft-boucadair-sfc-oam-packet-00.txt

Abstract:

[email-masked]<mailto:[email-masked]>

_______________________________________________
sfc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sfc

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 16 Feb 2022 07:51:44 -0800

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 <[email-masked]> wrote:

> Hi Greg,
>
>
>
> Please see inline.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* Greg Mirsky <[email-masked]>
> *Envoyé :* mercredi 16 février 2022 16:13
> *À :* BOUCADAIR Mohamed INNOV/NET <[email-masked]>
> *Cc :* [email-masked]
> *Objet :* Re: [sfc] TR: I-D Action: draft-boucadair-sfc-oam-packet-00.txt
>
>
>
> Hi Med,
>
> *[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
>
>
>

---

From: <[email-masked]>
Date: Wed, 16 Feb 2022 16:21:58 +0000

Re-,

This is determined by the entity that issues the OAM packet. This is typically a dedicated OAM controller or an SFC element (classifier for the ioam case, for example).

BTW, I updated the draft to reflect your comments and also those from Jim: https://www.ietf.org/rfcdiff?url2=draft-boucadair-sfc-oam-packet-01

Cheers,
Med

De : Greg Mirsky <[email-masked]>
Envoyé : mercredi 16 février 2022 16:52
À : BOUCADAIR Mohamed INNOV/NET <[email-masked]>
Cc : [email-masked]
Objet : 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 <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg,

Please see inline.

Cheers,
Med

De : Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Envoyé : mercredi 16 février 2022 16:13
À : BOUCADAIR Mohamed INNOV/NET <[email-masked]<mailto:[email-masked]>>
Cc : [email-masked]<mailto:[email-masked]>
Objet : Re: [sfc] TR: I-D Action: draft-boucadair-sfc-oam-packet-00.txt

Hi Med,

Regards,
Greg

Cheers,
Med

-----Message d'origine-----
De : I-D-Announce <[email-masked]<mailto:[email-masked]>> De la part de [email-masked]<mailto:[email-masked]>
Envoyé : mercredi 16 février 2022 15:38
À : [email-masked]<mailto:[email-masked]>
Objet : I-D Action: draft-boucadair-sfc-oam-packet-00.txt

Abstract:

Thank you.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 16 Feb 2022 11:29:38 -0500

Thank you for writing this.  I look forward to more dscussion by more WG 
members.

I want to ask one clarifying quesiton about an example that was raised 
earlier.

If the NSH payload is an IP packet, and that packet is addressed to 
something other than this node, and that packet is carrying  an ICMP 
echo, is that an SFC OAM packet requiring the O-bit being set?  And 
conversely, is an SFF required to check for that case if it sees an NSH 
with the O-bit set?

Yours,
Joel

On 2/16/2022 11:21 AM, [email-masked] wrote:
> Re-,
> 
> This is determined by the entity that issues the OAM packet. This is 
> typically a dedicated OAM controller or an SFC element (classifier for 
> the ioam case, for example).
> 
> BTW, I updated the draft to reflect your comments and also those from 
> Jim: https://www.ietf.org/rfcdiff?url2=draft-boucadair-sfc-oam-packet-01 
> <https://www.ietf.org/rfcdiff?url2=draft-boucadair-sfc-oam-packet-01>
> 
> Cheers,
> 
> Med
> 
> *Envoyé :* mercredi 16 février 2022 16:52
> On Wed, Feb 16, 2022 at 7:30 AM <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Hi Greg,
> 
>     Please see inline.
> 
>     Cheers,
> 
>     Med
> 
>     *De :* Greg Mirsky <[email-masked]
>     <mailto:[email-masked]>>
>     *À :* BOUCADAIR Mohamed INNOV/NET <[email-masked]
>     <mailto:[email-masked]>>
>     *Cc :* [email-masked] <mailto:[email-masked]>
>     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./*
> 
>     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 <[email-masked]
>     <mailto:[email-masked]>> wrote:
> 
>         Hi all,
> 
>         De : I-D-Announce <[email-masked]
>         <mailto:[email-masked]>> De la part de
>         [email-masked] <mailto:[email-masked]>
>         À : [email-masked] <mailto:[email-masked]>
>         <https://datatracker.ietf.org/doc/draft-boucadair-sfc-oam-packet/>
> 
>         <https://datatracker.ietf.org/doc/html/draft-boucadair-sfc-oam-packet-00>
> 
> 
>         [email-masked] <mailto:[email-masked]>
>         <https://www.ietf.org/mailman/listinfo/i-d-announce>
>         Internet-Draft directories: http://www.ietf.org/shadow.html
>         <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,
>         This message and its attachments may contain confidential or
>         privileged information that may be protected by law;
>         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.
> 
>         [email-masked] <mailto:[email-masked]>
>         <https://www.ietf.org/mailman/listinfo/sfc>
>

---

From: <[email-masked]>
Date: Thu, 17 Feb 2022 07:13:50 +0000

Hi Joel, 

> echo, is that an SFC OAM packet requiring the O-bit being set?

Med: The NSH can be added by a classifier or directly by an SFC OAM controller that issues the packet. If the original IP/ICMP packet is received by a classifier, the classifier must not set the O bit as per draft-boucadair-sfc-oam-packet because that packet is seen as data packet. 

Let's now focus on the SFC OAM controller case: 
* Does it makes sense for an SFC OAM controller to "leverage" IP/ICMP for SFC OAM purposes while it can do it directly using ICMP (without the IP header)? 

I personally don't see any. 

* Does it makes sense for an SFC OAM controller to "supply" an IP/ICMP as an input for specific OAM purposes?  

This is in theory possible for SF testing purposes (e.g., test the behavior of a firewall against such packet. The output of the test will be used to assess if the FW configuration is OK/NOK). However, such test OAM packets have to be unambiguously identified as such. The Next Protocol won't be set to IP but to the value assigned to an OAM protocol.  

  And
> conversely, is an SFF required to check for that case if it sees an NSH

Med: SFFs have to support policies whether some OAM messages can be forwarded to SFs. These policies may include a filter on valid next protocol values. I don't have an objection to discard by default packets with O bit set and next protocol = IP/MPLS/Ethernet

Cheers,
Med

> De : Joel M. Halpern <[email-masked]>
> Envoyé : mercredi 16 février 2022 17:30
> À : BOUCADAIR Mohamed INNOV/NET <[email-masked]>; Greg
> Mirsky <[email-masked]>
> Cc : [email-masked]
> > Jim:
> > https://www.ietf.org/rfcdiff?url2=draft-boucadair-sfc-oam-packet-01
> > *De :* Greg Mirsky <[email-masked]> *Envoyé :* mercredi 16
> > février 2022 16:52 *À :* BOUCADAIR Mohamed INNOV/NET
> > <[email-masked]> *Cc :* [email-masked] *Objet :* Re: [sfc]
> > TR: I-D Action: draft-boucadair-sfc-oam-packet-00.txt
> >
> > Hi Med,
> >
> >     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
> >
> >         A proposal to clarify the intent of SFC OAM packet. Comments
> are
> >         welcome.
> >
> >         Cheers,
> >         Med
> >
> >             This document clarifies an ambiguity in the Network
> Service
> >         Header
> > ______________________________________________________________________
> > ___________________________________________________
> >
> >         Orange decline toute responsabilite si ce message a ete
> altere,
> >         deforme ou falsifie. Merci.
> >
> > ______________________________________________________________________
> > ___________________________________________________
> >
> >     pas etre diffuses, exploites ou copies sans autorisation. Si vous
> > avez recu ce message par erreur, veuillez le signaler
> >
> >     If you have received this email in error, please notify the sender
> and delete this message and its attachments.
> >
> > ______________________________________________________________________
> > ___________________________________________________
> >
> > 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.
> >
> > privileged information that may be protected by law; they should not
> be distributed, used or copied without authorisation.

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 23 Feb 2022 16:22:42 -0800

Hi Med,
thank you for your proposal. I believe that it solves the problem and helps
the Active SFC OAM. If I may, I'm proposing the WG Chairs consider the WG
AP on this document. And for the record:

I've read the document and support its adoption by the SFC WG.

Regards,
Greg

---

From: <[email-masked]>
Date: Thu, 24 Feb 2022 07:56:04 +0000

Hi Joel, all, 

FWIW, I updated -02 with the following to reflect one of the points discussed below:

      When an OAM data is included in the inner packet, the Next
      Protocol field is set to reflect the structure of that inner
      packet.  By default, SFFs SHOULD discard NSH packets with O bit
      set and Next Protocol set to 0x1 (IPv4), 0x2 (IPv6), 0x3 (MPLS),
      or 0x5 (Ethernet).

Cheers,
Med

> De : sfc <[email-masked]> De la part de
> [email-masked]
> Envoyé : jeudi 17 février 2022 08:14
> À : Joel M. Halpern <[email-masked]>; Greg Mirsky
> <[email-masked]>
> Cc : [email-masked]
> Med: The NSH can be added by a classifier or directly by an SFC OAM
> controller that issues the packet. If the original IP/ICMP packet is
> received by a classifier, the classifier must not set the O bit as per
> draft-boucadair-sfc-oam-packet because that packet is seen as data
> packet.
> 
> * Does it makes sense for an SFC OAM controller to "leverage" IP/ICMP
> for SFC OAM purposes while it can do it directly using ICMP (without the
> IP header)?
> 
> This is in theory possible for SF testing purposes (e.g., test the
> behavior of a firewall against such packet. The output of the test will
> be used to assess if the FW configuration is OK/NOK). However, such test
> OAM packets have to be unambiguously identified as such. The Next
> Protocol won't be set to IP but to the value assigned to an OAM
> protocol.
> 
>   And
> > conversely, is an SFF required to check for that case if it sees an
> > NSH with the O-bit set?
> 
> Med: SFFs have to support policies whether some OAM messages can be
> forwarded to SFs. These policies may include a filter on valid next
> protocol values. I don't have an objection to discard by default packets
> with O bit set and next protocol = IP/MPLS/Ethernet
> 
> Cheers,
> Med
> 
> > De : Joel M. Halpern <[email-masked]> Envoyé : mercredi 16
> > février 2022 17:30 À : BOUCADAIR Mohamed INNOV/NET
> > <[email-masked]>; Greg Mirsky <[email-masked]>
> Cc
> > : [email-masked] Objet : Re: [sfc] TR: I-D Action:
> > draft-boucadair-sfc-oam-packet-00.txt
> >
> > Thank you for writing this.  I look forward to more dscussion by more
> > WG members.
> >
> > conversely, is an SFF required to check for that case if it sees an
> > NSH with the O-bit set?
> >
> > Yours,
> > Joel
> >
> > > typically a dedicated OAM controller or an SFC element (classifier
> > > for the ioam case, for example).
> > >
> > > <https://www.ietf.org/rfcdiff?url2=draft-boucadair-sfc-oam-packet-01
> > > >
> > >
> > > Cheers,
> > >
> > > Med
> > >
> > >             (NSH) specification related to the handling of O-
> bit.  In
> > >         particular,
> > > <https://datatracker.ietf.org/doc/html/draft-boucadair-sfc-oam-packe
> > > t-
> > > 00>
> > >
> > >
> > > ____________________________________________________________________
> > > __ ___________________________________________________
> > >
> > > ____________________________________________________________________
> > > __ ___________________________________________________
> > >
> > > sender
> > > ____________________________________________________________________
> > > __ ___________________________________________________
> > >
> > > 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
> ________________________________________________________________________
> _________________________________________________
> 
> pieces jointes. Les messages electroniques etant susceptibles
> information that may be protected by law; they should not be
> distributed, used or copied without authorisation.

---

From: <[email-masked]>
Date: Thu, 24 Feb 2022 07:57:41 +0000

Hi Greg,

I hope to see it adopted as well. Thank you.

If/once adopted, I expect Section 4.1 of draft-ietf-sfc-ioam-nsh (or at least its normative language) to be removed but point to draft-boucadair-sfc-oam-packet for O bit handling.

Idem for Section 4 of draft-ietf-sfc-multi-layer-oam.

Cheers,
Med

De : Greg Mirsky <[email-masked]>
Envoyé : jeudi 24 février 2022 01:23
À : BOUCADAIR Mohamed INNOV/NET <[email-masked]>
Cc : [email-masked]
Objet : Re: [sfc] TR: I-D Action: draft-boucadair-sfc-oam-packet-00.txt

Hi Med,
thank you for your proposal. I believe that it solves the problem and helps the Active SFC OAM. If I may, I'm proposing the WG Chairs consider the WG AP on this document. And for the record:
I've read the document and support its adoption by the SFC WG.

Regards,
Greg

Cheers,
Med

-----Message d'origine-----
De : I-D-Announce <[email-masked]<mailto:[email-masked]>> De la part de [email-masked]<mailto:[email-masked]>
Envoyé : mercredi 16 février 2022 15:38
À : [email-masked]<mailto:[email-masked]>
Objet : I-D Action: draft-boucadair-sfc-oam-packet-00.txt

Abstract:

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 24 Feb 2022 08:40:01 -0500

May a suggest a small refinement?
     The setting and processing of the O bit neither assumes nor expects 
detailed analysis of the contents of any IP packets carried by NSH.  As 
such, SFFs and SFs SHOULD discard any NSH packets with the O bit set and 
Next protocol set to something that is not itself an OAM protocol.  THis 
includes discarding the packet when O bit is set and the Next Protocol 
is set to 0x01 (IPv4), 0x02 (IPv6), 0x03 (MPLS), or 0x05 (Ethernet).

Yours,
Joel

---

From: <[email-masked]>
Date: Thu, 24 Feb 2022 13:59:20 +0000

Re-,

Sure. I made some minor edits. The NEW text looks as follows: 

      When an OAM data is included in the inner packet, the Next
      Protocol field is set to reflect the structure of that inner OAM
      packet.  The setting and processing of the O bit neither assumes
      nor expects detailed analysis of the content of any inner IP
      packet carried by the NSH.  As such, SFFs, SFC-aware SFs, and SFC
      Proxies SHOULD discard any NSH packets with the O bit set and Next
      Protocol set to something that is not itself an OAM protocol.
      This includes discarding the packet when the O bit is set and the
      Next Protocol is set to 0x01 (IPv4), 0x02 (IPv6), 0x03 (MPLS), or
      0x05 (Ethernet).

Thanks. 

Cheers,
Med

> Envoyé : jeudi 24 février 2022 14:40
> >> [email-masked] Envoyé : jeudi 17 février 2022 08:14 À :
> >> Joel M. Halpern <[email-masked]>; Greg Mirsky
> >> <[email-masked]> Cc : [email-masked] Objet : Re: [sfc] TR: I-D
> >> Action: draft-boucadair-sfc-oam-packet-00.txt
> >>
> >> Hi Joel,
> >>
> >> received by a classifier, the classifier must not set the O bit as
> >> per draft-boucadair-sfc-oam-packet because that packet is seen as
> >> data packet.
> >>
> >> for SFC OAM purposes while it can do it directly using ICMP (without
> >> the IP header)?
> >>
> >> * Does it makes sense for an SFC OAM controller to "supply" an
> >> IP/ICMP as an input for specific OAM purposes?
> >>
> >> behavior of a firewall against such packet. The output of the test
> >> will be used to assess if the FW configuration is OK/NOK). However,
> >> such test OAM packets have to be unambiguously identified as such.
> >> The Next Protocol won't be set to IP but to the value assigned to an
> >> OAM protocol.
> >>
> >>    And
> >> protocol values. I don't have an objection to discard by default
> >> packets with O bit set and next protocol = IP/MPLS/Ethernet
> >>
> >> Cheers,
> >> Med
> >>
> >>> Thank you for writing this.  I look forward to more dscussion by
> >>> more WG members.
> >>>
> >>> I want to ask one clarifying quesiton about an example that was
> >>> raised earlier.
> >>>
> >>>> This is determined by the entity that issues the OAM packet. This
> >>>> is typically a dedicated OAM controller or an SFC element
> >>>> (classifier for the ioam case, for example).
> >>>>
> >>>> 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
> >>>>
> >>>>      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:
> >>>>
> >>>>      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
> http://www.ietf.org/shadow.html
> >>>> ___________________________________________________________________
> >>>> _ __ ___________________________________________________
> >>>>
> >>>>          a l'expediteur et le detruire ainsi que les pieces
> jointes.
> >>> Les
> >>>>          As emails may be altered, Orange is not liable for
> >>>> messages
> >>> that
> >>>> ___________________________________________________________________
> >>>> _ __ ___________________________________________________
> >>>>
> >>>>      a l'expediteur et le detruire ainsi que les pieces jointes.
> >>>> Les messages electroniques etant susceptibles d'alteration,
> >>>>
> >>>> ___________________________________________________________________
> >>>> _ __ ___________________________________________________
> >>>>
> >>> 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.
> >>>>
> >> _____________________________________________________________________
> >> ___ _________________________________________________
> >>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 24 Feb 2022 09:02:12 -0500

Thanks.  I think that captures it nicely.

Yours,
Joel

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 24 Feb 2022 06:31:29 -0800

Hi Med,
I agree with the changes you've proposed to the
draft-ietf-sfc-multi-layer-oam .

Regards,
Greg

On Wed, Feb 23, 2022 at 11:57 PM <[email-masked]> wrote:

> If/once adopted, I expect Section 4.1 of draft-ietf-sfc-ioam-nsh (or at
> least its normative language) to be removed but point to
> draft-boucadair-sfc-oam-packet for O bit handling.
>
>
>
> *Envoyé :* jeudi 24 février 2022 01:23
> thank you for your proposal. I believe that it solves the problem and
> helps the Active SFC OAM. If I may, I'm proposing the WG Chairs consider
> the WG AP on this document. And for the record:
>