Subject: [sfc] draft-ietf-sfc-oam-packet-00 status & comments (was RE: WGLC for https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/)

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Thu, 14 Apr 2022 13:47:08 +0000

Hi Joel,

Looking at https://datatracker.ietf.org/wg/sfc/documents/ - it does not list draft-ietf-sfc-oam-packet-00 as in last call. The WGLC statement got me by surprise - I really missed that.

Reading through draft-ietf-sfc-oam-packet-00, the clause that Med mentioned earlier could be misread, as in "NSH could interfere with the operation of other protocols". Or in other words, the O-bit can only be about SFC OAM data, which is what SFC control. Otherwise we could go wild and argue for adding additional bits like "D-Bit: Packet contains data from a data base" or "C-Bit: Packet contains data of the CEO of the company"...

Suggested change:

OLD:
      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.

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

Cheers, Frank

> -----Original Message-----
> From: Joel M. Halpern <[email-masked]>
> Sent: Thursday, 14 April 2022 14:39
> To: Frank Brockners (fbrockne) <[email-masked]>;
> [email-masked]; Greg Mirsky <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [sfc] WGLC for https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-
> nsh/
> 
> Frank, I am a little confused by your note.  draft-ietf-sfc-oam-packet is in last
> call.  That is not "early stages and still evolving".
> 
> Do you have concerns with draft-ietf-sfc-oam-packet that you have not sent to
> the list?
> 
> Given that we are finishing this draft up, and the draft is about the O-Bit,
> referring to it in draft-ietf-sfc-ioam-nsh seems the appropriate step.
> 
> Yours,
> Joel
> 
> On 4/14/2022 8:24 AM, Frank Brockners (fbrockne) wrote:
> > IMHO it would be better to refer to directly RFC8300 – since this is a
> > stable reference; and it allows us to finish up
> > draft-ietf-sfc-ioam-nsh and get the code points allocated.
> > I-D.ietf-sfc-oam-packet is early stages and still evolving.
> >
> > Cheers, Frank
> >
> > *From:[email-masked]
> <[email-masked]>
> > *Sent:* Thursday, 14 April 2022 13:28
> > *To:* Shwetha Bhandari <[email-masked]>; Greg Mirsky
> > <[email-masked]>
> > *Cc:* Frank Brockners (fbrockne)
> > <fbrockne=[email-masked]>;
> > [email-masked]; [email-masked]; [email-masked]; James Guichard
> > <[email-masked]>; Tal Mizrahi
> > <[email-masked]>; [email-masked]
> > *Subject:* RE: [sfc] WGLC for
> > https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/
> >
> > Hi Shwetha,
> >
> > I prefer we go for an explicit reference to I-D.ietf-sfc-oam-packet
> > rather than “any update to RFC8300”. This is consistent with the usage
> > in the other OAM draft.
> >
> > Thank you.
> >
> > Cheers,
> >
> > Med
> >
> > *De :*Shwetha Bhandari <[email-masked]
> > <mailto:[email-masked]>>
> > *Envoyé :* jeudi 14 avril 2022 12:06
> > *À :* Greg Mirsky <[email-masked]
> > <mailto:[email-masked]>> *Cc :* BOUCADAIR Mohamed INNOV/NET
> > <[email-masked]
> <mailto:[email-masked]>>;
> > Frank Brockners (fbrockne) <fbrockne=[email-masked]
> > <mailto:fbrockne=[email-masked]>>; [email-masked]
> > <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>;
> > [email-masked] <mailto:[email-masked]>; James Guichard
> > <[email-masked]
> > <mailto:[email-masked]>>; Tal Mizrahi
> > <[email-masked] <mailto:[email-masked]>>;
> > [email-masked]
> > <mailto:[email-masked]>
> > *Objet :* Re: [sfc] WGLC for
> > https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/
> > <https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/>
> >
> > Hi Med, Greg,
> >
> > How about this text :
> >
> > “The O-bit MUST be handled following the rules in and any updates to
> > [RFC8300] ."
> >
> > Given that I-D.ietf-sfc-oam-packet  will update RF8300 and there could
> > be others in future?
> >
> > Thanks,
> >
> > Shwetha
> >
> > On Tue, Apr 12, 2022 at 9:24 PM Greg Mirsky <[email-masked]
> > <mailto:[email-masked]>> wrote:
> >
> >     Hi Shwetha,
> >
> >     I believe that the text you've quoted is helpful. I would suggest
> >     changing references from [RFC8300] to [I-D.ietf-sfc-oam-packet]
> >     throughout that paragraph.
> >
> >     Regards,
> >
> >     Greg
> >
> >     On Tue, Apr 12, 2022 at 7:56 AM Shwetha Bhandari
> >     <[email-masked]
> >     <mailto:[email-masked]>> wrote:
> >
> >         Med,
> >
> >         Thanks for the details: this is exactly what we had before the
> >         latest revision:
> >
> >         *4.2
> >
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-
> sfc-ioam-nsh-06*section-4.2__;Iw!!MZ3Fw45to5uY!NBsrzhHEf0Y_-
> Sindy74K4QDA6EWJjx35STSH-
> UxEi3eYIX0GVli9Sn1azrOPJVcI2qUzWfezK_1D2RpyFB_FOIpJPfzrvI$>.
> >         IOAM and the use of the NSH O-bit*
> >
> >             [RFC8300] defines an "O bit" for OAM packets.  Per [RFC8300
> >
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc8300__;!
> !MZ3Fw45to5uY!NBsrzhHEf0Y_-Sindy74K4QDA6EWJjx35STSH-
> UxEi3eYIX0GVli9Sn1azrOPJVcI2qUzWfezK_1D2RpyFB_FOIpEB5AbbE$>]
> >         the O
> >
> >             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/
> >
> > <https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/sfc/
> > srMit5zE8UseNOhxknAw_dqvj6M/__;!!MZ3Fw45to5uY!NBsrzhHEf0Y_-
> Sindy74K4QD
> > A6EWJjx35STSH-UxEi3eYIX0GVli9Sn1azrOPJVcI2qUzWfezK_1D2RpyFB_FOIp-
> CeLfe
> > A$>
> >
> >         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
> >
> >
> _________________________________________________________________
> _____
> > ___________________________________________________
> >
> > 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: "Joel M. Halpern" <[email-masked]>
Date: Thu, 14 Apr 2022 09:56:20 -0400

Authors, WG participants?  That edit looks acceptable to me?
Frank, assuming we make that change, are you okay with this being sent 
to the IESG for publication as an RFC?

Yours,
Joel

---

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

If we do this change, which I strongly suggest we do, then we should also re-check other occurrences of "OAM" and ensure that we always refer to "SFC OAM". There are quite a few mentions of "OAM" - which is non specific and could be anything.

I'd be ok to progress the doc to IESG with these changes.

Cheers, Frank

> Sent: Thursday, 14 April 2022 15:56
> Cc: [email-masked]; Carlos Pignataro (cpignata) <[email-masked]>
> Subject: Re: draft-ietf-sfc-oam-packet-00 status & comments (was RE: [sfc]
> WGLC for https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/)
> 
> Frank, assuming we make that change, are you okay with this being sent to the
> IESG for publication as an RFC?
> 
> Yours,
> Joel
> 
> > Looking at https://datatracker.ietf.org/wg/sfc/documents/ - it does not list
> draft-ietf-sfc-oam-packet-00 as in last call. The WGLC statement got me by
> surprise - I really missed that.
> >
> > Reading through draft-ietf-sfc-oam-packet-00, the clause that Med mentioned
> earlier could be misread, as in "NSH could interfere with the operation of other
> protocols". Or in other words, the O-bit can only be about SFC OAM data, which
> is what SFC control. Otherwise we could go wild and argue for adding additional
> bits like "D-Bit: Packet contains data from a data base" or "C-Bit: Packet
> contains data of the CEO of the company"...
> >
> > Suggested change:
> >
> > OLD:
> >        SFC OAM data can be included in the Fixed-Length Context Header,
> >> Subject: Re: [sfc] WGLC for
> >> Frank, I am a little confused by your note.
> >> draft-ietf-sfc-oam-packet is in last call.  That is not "early stages and still
> evolving".
> >>
> >> Do you have concerns with draft-ietf-sfc-oam-packet that you have not
> >> sent to the list?
> >>
> >> Given that we are finishing this draft up, and the draft is about the
> >> O-Bit, referring to it in draft-ietf-sfc-ioam-nsh seems the appropriate step.
> >>
> >> Yours,
> >> Joel
> >>
> >>> IMHO it would be better to refer to directly RFC8300 – since this is
> >>> a stable reference; and it allows us to finish up
> >>> *To:* Shwetha Bhandari <[email-masked]>; Greg
> >>> Mirsky <[email-masked]>
> >>> rather than “any update to RFC8300”. This is consistent with the
> >>> usage in the other OAM draft.
> >>>
> >>> Thank you.
> >>>
> >>> Cheers,
> >>>
> >>> Med
> >>>
> >>> *Envoyé :* jeudi 14 avril 2022 12:06 *À :* Greg Mirsky
> >>> <[email-masked] <mailto:[email-masked]>> *Cc :*
> >>> BOUCADAIR Mohamed INNOV/NET <[email-masked]
> >>> Given that I-D.ietf-sfc-oam-packet  will update RF8300 and there
> >>> could be others in future?
> >>>
> >>> Thanks,
> >>>
> >>> Shwetha
> >>>
> >>>              OAM packets which carry only IOAM data without any
> >>> regular data
> >>>
> >>>              payload.
> >>>
> >>> 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.
> >>>
> >>> As emails may be altered, Orange is not liable for messages that
> >>> have been modified, changed or falsified.
> >>>
> >>> Thank you.
> >>>

---

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

Hi Joel, Franck, 

OK for me. 

See the full candidate changes at: https://tinyurl.com/oam-packet-latest

Cheers,
Med

> -----Message d'origine-----
> De : Joel M. Halpern <[email-masked]>
> Envoyé : jeudi 14 avril 2022 15:56
> À : Frank Brockners (fbrockne) <[email-masked]>; BOUCADAIR
> Mohamed INNOV/NET <[email-masked]>; Greg Mirsky
> <[email-masked]>
> Cc : [email-masked]; Carlos Pignataro (cpignata)
> <[email-masked]>
> Objet : Re: draft-ietf-sfc-oam-packet-00 status & comments (was
> RE: [sfc] WGLC for https://datatracker.ietf.org/doc/draft-ietf-
> sfc-ioam-nsh/)
> 
> Frank, assuming we make that change, are you okay with this being
> sent to the IESG for publication as an RFC?
> 
> Yours,
> Joel
> 
> > Looking at https://datatracker.ietf.org/wg/sfc/documents/ - it
> does not list draft-ietf-sfc-oam-packet-00 as in last call. The
> WGLC statement got me by surprise - I really missed that.
> >
> > Reading through draft-ietf-sfc-oam-packet-00, the clause that
> Med mentioned earlier could be misread, as in "NSH could interfere
> with the operation of other protocols". Or in other words, the O-
> bit can only be about SFC OAM data, which is what SFC control.
> Otherwise we could go wild and argue for adding additional bits
> like "D-Bit: Packet contains data from a data base" or "C-Bit:
> Packet contains data of the CEO of the company"...
> >
> > Suggested change:
> >
> > OLD:
> >        SFC OAM data can be included in the Fixed-Length Context
> Header, optional Context Headers, and/or the inner packet.
> >
> >
> > Cheers, Frank
> >
> >
> >

_________________________________________________________________________________________________________________________

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: Greg Mirsky <[email-masked]>
Date: Thu, 14 Apr 2022 08:53:00 -0700

Hi Frank,
thank you for the proposed text. I support the update. Also, if we are
going to be precise in using the terminology, I think that "SFC NSH OAM"
seems like what we are working with. "SFC OAM" might be also attributed to
RFC 8595 which defines what can be branded as SFC-MPLS.

Regards,
Greg

On Thu, Apr 14, 2022 at 7:02 AM Frank Brockners (fbrockne) <
[email-masked]> wrote:

> If we do this change, which I strongly suggest we do, then we should also
> re-check other occurrences of "OAM" and ensure that we always refer to "SFC
> OAM". There are quite a few mentions of "OAM" - which is non specific and
> could be anything.
>
> > >        Such a packet is any NSH-encapsulated packet that exclusively
> includes
> > OAM data.
> > >        Such a packet is any NSH-encapsulated packet that exclusively
> includes SFC
> > OAM data.
> > <
> https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc8300__
> ;!

---

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

Hi Greg,
“SFC NSH OAM” is even more accurate.
Agree that we should use that one.
Cheers, Frank

From: Greg Mirsky <[email-masked]>
Sent: Thursday, 14 April 2022 17:53
To: Frank Brockners (fbrockne) <[email-masked]>
Cc: Joel M. Halpern <[email-masked]>; [email-masked]; [email-masked]; Carlos Pignataro (cpignata) <[email-masked]>
Subject: Re: draft-ietf-sfc-oam-packet-00 status & comments (was RE: [sfc] WGLC for https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/)

Hi Frank,
thank you for the proposed text. I support the update. Also, if we are going to be precise in using the terminology, I think that "SFC NSH OAM" seems like what we are working with. "SFC OAM" might be also attributed to RFC 8595 which defines what can be branded as SFC-MPLS.

Regards,
Greg

On Thu, Apr 14, 2022 at 7:02 AM Frank Brockners (fbrockne) <[email-masked]<mailto:[email-masked]>> wrote:
If we do this change, which I strongly suggest we do, then we should also re-check other occurrences of "OAM" and ensure that we always refer to "SFC OAM". There are quite a few mentions of "OAM" - which is non specific and could be anything.

Cheers, Frank

> From: Joel M. Halpern <[email-masked]<mailto:[email-masked]>>
> To: Frank Brockners (fbrockne) <[email-masked]<mailto:[email-masked]>>;
> [email-masked]<mailto:[email-masked]>; Greg Mirsky <[email-masked]<mailto:[email-masked]>>
> Cc: [email-masked]<mailto:[email-masked]>; Carlos Pignataro (cpignata) <[email-masked]<mailto:[email-masked]>>
> >> From: Joel M. Halpern <[email-masked]<mailto:[email-masked]>>
> >> To: Frank Brockners (fbrockne) <[email-masked]<mailto:[email-masked]>>;
> >> [email-masked]<mailto:[email-masked]>; Greg Mirsky <[email-masked]<mailto:[email-masked]>>
> >> Cc: [email-masked]<mailto:[email-masked]>
> >>> *From:[email-masked]<mailto:[email-masked]>
> >> <[email-masked]<mailto:[email-masked]>>
> >>> *To:* Shwetha Bhandari <[email-masked]<mailto:[email-masked]>>; Greg
> >>> Mirsky <[email-masked]<mailto:[email-masked]>>
> >>> <fbrockne=[email-masked]<mailto:[email-masked]>>;
> >>> [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; James Guichard
> >>> <[email-masked]<mailto:[email-masked]>>; Tal Mizrahi
> >>> <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
> >>> *De :*Shwetha Bhandari <[email-masked]<mailto:[email-masked]>
> >>> <mailto:[email-masked]<mailto:[email-masked]>>>
> >>> <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>> *Cc :*
> >>> BOUCADAIR Mohamed INNOV/NET <[email-masked]<mailto:[email-masked]>
> >> <mailto:[email-masked]<mailto:[email-masked]>>>;
> >>> Frank Brockners (fbrockne) <fbrockne=[email-masked]<mailto:[email-masked]>
> >>> <mailto:fbrockne<mailto:fbrockne>=[email-masked]<mailto:[email-masked]>>>; [email-masked]<mailto:[email-masked]>
> >>> <mailto:[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>;
> >>> [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>; James Guichard
> >>> <[email-masked]<mailto:[email-masked]>
> >>> <mailto:[email-masked]<mailto:[email-masked]>>>; Tal Mizrahi
> >>> <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>;
> >>> [email-masked]<mailto:[email-masked]>
> >>> <mailto:[email-masked]<mailto:[email-masked]>>
> >>> On Tue, Apr 12, 2022 at 9:24 PM Greg Mirsky <[email-masked]<mailto:[email-masked]>
> >>> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
> >>>
> >>>      Hi Shwetha,
> >>>
> >>>      <[email-masked]<mailto:[email-masked]>
> >>>      <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
> >>>
> >>>          Med,
> >>>

---

From: <[email-masked]>
Date: Fri, 15 Apr 2022 05:07:04 +0000

Hi Greg, all,

I suggest we simply use “NSH OAM packet” + “SFC OAM data” for better clarity. Please see the full candidate changes at: https://tinyurl.com/oam-packet-latest.

Cheers,
Med

De : Greg Mirsky <[email-masked]>
Envoyé : jeudi 14 avril 2022 17:53
À : Frank Brockners (fbrockne) <[email-masked]>
Cc : Joel M. Halpern <[email-masked]>; BOUCADAIR Mohamed INNOV/NET <[email-masked]>; [email-masked]; Carlos Pignataro (cpignata) <[email-masked]>
Objet : Re: draft-ietf-sfc-oam-packet-00 status & comments (was RE: [sfc] WGLC for https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/)

Hi Frank,

Regards,
Greg

Cheers, Frank