Subject: [sfc] Adoption call for draft-boucadair-sfc-oam-packet-03.txt

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 7 Mar 2022 09:52:49 -0500

This starts the SFC adoption call for

https://datatracker.ietf.org/doc/html/draft-boucadair-sfc-oam-packet-03

Please respond indicating support or opposition to this adoption call. 
With explanation of why you support or oppose this.

We will run this call through the end of the IETF meeting, i.e. Through 
March 25-2022.

Also, authors (and contributors if any) please confirm to the list that 
all known IPR has been disclosed.

Thank you,
Joel

---

From: <[email-masked]>
Date: Mon, 7 Mar 2022 15:22:11 +0000

Hello sfc,

I support the adoption of draft-boucadair-sfc-oam-packet-03.txt as a sfc WG document. The text proposed to elaborate what's currently documented in Section 2.2 of RFC8300 is indeed useful, as it clarifies O bit setting rules.

Cheers,

Christian.

Orange Restricted

-----Message d'origine-----
De : sfc <[email-masked]> De la part de Joel M. Halpern
Envoyé : lundi 7 mars 2022 15:53
À : [email-masked]
Objet : [sfc] Adoption call for draft-boucadair-sfc-oam-packet-03.txt

We will run this call through the end of the IETF meeting, i.e. Through March 25-2022.

Also, authors (and contributors if any) please confirm to the list that all known IPR has been disclosed.

Thank you,
Joel

_______________________________________________
sfc mailing list
[email-masked]
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.

---

From: <[email-masked]>
Date: Mon, 7 Mar 2022 15:42:28 +0000

Hi Joel, 

I don't have any IPR nor I'm aware of any related to this draft. 

Cheers,
Med

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 7 Mar 2022 07:48:31 -0800

Dear All,
yes/support adoption of this draft.
The draft addresses an essential aspect of NSF helping resolve the issue
that affects SFC OAM work. I appreciate the work Med put into this draft.

Regards,
Greg

---

From: <[email-masked]>
Date: Wed, 9 Mar 2022 13:41:05 +0000

Dear all,
I support adoption of the useful draft updating RFC8300 regarding the specified O(AM) bit - without that a consistent treatment of any upcoming SFC OAM procedures would not be possible IMO.

BTW I suggest to correct the following nits on p.3 in the net version:

is any NSH-encapasulated packet => is any NSH-encapsulated packet
sepcific SFC-aware SF, => specific SFC-aware SF,

Thanks!
Best regards
Dirk

-----Ursprüngliche Nachricht-----
Von: sfc <[email-masked]> Im Auftrag von Joel M. Halpern
Gesendet: Montag, 7. März 2022 15:53
An: [email-masked]
Betreff: [sfc] Adoption call for draft-boucadair-sfc-oam-packet-03.txt

Thank you,
Joel

---

From: <[email-masked]>
Date: Wed, 9 Mar 2022 15:49:09 +0000

Hi Dirk, 

Thank you for the comments. 

Fixed as you can see here: https://tinyurl.com/sfc-oam-packet-latest 

Cheers,
Med

> De : sfc <[email-masked]> De la part de [email-masked]
> Envoyé : mercredi 9 mars 2022 14:41
> À : [email-masked]; [email-masked]
> Objet : Re: [sfc] Adoption call for draft-boucadair-sfc-oam-packet-
> 03.txt
> 
> Dear all,
> I support adoption of the useful draft updating RFC8300 regarding the
> specified O(AM) bit - without that a consistent treatment of any
> upcoming SFC OAM procedures would not be possible IMO.
>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 24 Mar 2022 18:19:49 +0000

Hi, Joel, WG,

I support this adoption call.

I feel the approach of a surgical, self-contained approach to clarifying the O-bit behavior is most effective, and support this approach.

I believe that the content is clear, deliberate, unambiguous, and useful. More than a great start.

Many thanks Med for taking on this work an producing this I-D.

A couple of questions / comments for consideration:

  *   Is the document about "OAM Behavior” in NSH, “O-bit” in the NSH header (as S2.2 of RFC 8300), or both? The title should reflect that. The abstract says it’s about the NSH header and definition of OAM Packet.
  *   S2 terminology: The OAM control element “generates” OAM packets. What about an element that can “process” OAM packets?
  *   S2 terminology: OAM Data: it says refers to an “OAM command” but that terminology does not exist in RFC 7276.
  *   S3, last paragraph, or Security Considerations — might be useful to also cite / reference RFC 8924.

Thanks again,

Carlos.

On Mar 7, 2022, at 9:52 AM, Joel M. Halpern <[email-masked]<mailto:[email-masked]>> wrote:

Please respond indicating support or opposition to this adoption call. With explanation of why you support or oppose this.

Thank you,
Joel

---

From: <[email-masked]>
Date: Fri, 25 Mar 2022 07:29:39 +0000

Hi Carlos,

Thank you much for this feedback. I updated the text to reflect your input as you can see at: https://tinyurl.com/sfc-oam-packet-latest

Please see also inline for more context.

If any further changes are needed, please let me know. Thanks.

Cheers,
Med

De : sfc <[email-masked]> De la part de Carlos Pignataro (cpignata)
Envoyé : jeudi 24 mars 2022 19:20
À : Joel M. Halpern <[email-masked]>
Cc : [email-masked]
Objet : Re: [sfc] Adoption call for draft-boucadair-sfc-oam-packet-03.txt

Hi, Joel, WG,

  *   Is the document about "OAM Behavior” in NSH, “O-bit” in the NSH header (as S2.2 of RFC 8300), or both? The title should reflect that. The abstract says it’s about the NSH header and definition of OAM Packet.
[Med] Agree. Went for “OAM Packet and Behavior in the Network Service Header (NSH)”

  *   S2 terminology: The OAM control element “generates” OAM packets. What about an element that can “process” OAM packets?
[Med] That element can set the bit if a response is triggered as part of that processing. Otherwise, the element follows: “The O bit MUST NOT be modified along the SFP”. Do you have in mind something more to say there? Thanks.

  *   S2 terminology: OAM Data: it says refers to an “OAM command” but that terminology does not exist in RFC 7276.
[Med] Yes. This term is a generalization of methods such as those defined in 7276 as per this text: “refers to an OAM command (e.g., Connectivity Verification and Continuity Checks [RFC7276]),”. I changed that term to “OAM request” to be close to what we can kind find in 7276. Hope that is better.

[Med] Agree.

Thanks again,

Carlos.

Thank you,
Joel

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

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Fri, 25 Mar 2022 12:10:56 +0000

Agree on all the follow ups below, Med. Thank you! 🙏

Thumb typed by Carlos Pignataro.
Excuze typofraphicak errows

On Mar 25, 2022, at 3:30 AM, [email-masked] wrote:

Hi Carlos,

Cheers,
Med

Hi, Joel, WG,

Thanks again,

Carlos.

Thank you,
Joel