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

[Greg Mirsky <[e-mail]>]

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) <
[e-mail]> 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.
>
> I'd be ok to progress the doc to IESG with these changes.
>
> Cheers, Frank
>
> > -----Original Message-----
> > From: Joel M. Halpern <[e-mail]>
> > Sent: Thursday, 14 April 2022 15:56
> > To: Frank Brockners (fbrockne) <[e-mail]>;
> > [e-mail]; Greg Mirsky <[e-mail]>
> > Cc: [e-mail]; Carlos Pignataro (cpignata) <[e-mail]>
> > 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/)
> >
> > 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
> >
> > On 4/14/2022 9:47 AM, Frank Brockners (fbrockne) wrote:
> > > 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 <[e-mail]>
> > >> Sent: Thursday, 14 April 2022 14:39
> > >> To: Frank Brockners (fbrockne) <[e-mail]>;
> > >> [e-mail]; Greg Mirsky <[e-mail]>
> > >> Cc: [e-mail]
> > >> 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:*[e-mail]
> > >> <[e-mail]>
> > >>> *Sent:* Thursday, 14 April 2022 13:28
> > >>> *To:* Shwetha Bhandari <[e-mail]>; Greg
> > >>> Mirsky <[e-mail]>
> > >>> *Cc:* Frank Brockners (fbrockne)
> > >>> <fbrockne=[e-mail]>;
> > >>> [e-mail]; [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/
> > >>>
> > >>> 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 <[e-mail]
> > >>> <mailto:[e-mail]>>
> > >>> *Envoyé :* jeudi 14 avril 2022 12:06 *À :* Greg Mirsky
> > >>> <[e-mail] <mailto:[e-mail]>> *Cc :*
> > >>> BOUCADAIR Mohamed INNOV/NET <[e-mail]
> > >> <mailto:[e-mail]>>;
> > >>> Frank Brockners (fbrockne) <fbrockne=[e-mail]
> > >>> <mailto:fbrockne=[e-mail]>>; [e-mail]
> > >>> <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>;
> > >>> [e-mail] <mailto:[e-mail]>; James Guichard
> > >>> <[e-mail]
> > >>> <mailto:[e-mail]>>; Tal Mizrahi
> > >>> <[e-mail] <mailto:[e-mail]>>;
> > >>> [e-mail]
> > >>> <mailto:[e-mail]>
> > >>> *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 <[e-mail]
> > >>> <mailto:[e-mail]>> 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
> > >>>      <[e-mail]
> > >>>      <mailto:[e-mail]>> 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/dra
> > >> ft-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/sf
> > >>> c/
> > >>> 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.
> > >>>
>