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

["Frank Brockners (fbrockne)" <[e-mail]>]

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