[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]>]

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