Re: [ippm] [sfc] WGLC for https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/

[Greg Mirsky <[e-mail]>]

Hi Shwetha,
thank you for the proposed resolution. I agree with Med, direct normative
reference to I-D.ietf-sfc-oam-packet seems like the logical conclusion of
our discussion of the use of the NSH O bit. Please note that we're
referring to I-D.ietf-sfc-oam-packet in the Active SFC OAM draft, e.g.,:

The O bit in NSH MUST be set, according to [I-D.ietf-sfc-oam-packet].


Regards,
Greg

On Thu, Apr 14, 2022 at 4:27 AM <[e-mail]> wrote:

> 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]>
> *Envoyé :* jeudi 14 avril 2022 12:06
> *À :* Greg Mirsky <[e-mail]>
> *Cc :* BOUCADAIR Mohamed INNOV/NET <[e-mail]>; Frank
> Brockners (fbrockne) <fbrockne=[e-mail]>;
> [e-mail]; [e-mail]; [e-mail]; James Guichard <
> [e-mail]>; Tal Mizrahi <[e-mail]>;
> [e-mail]
> *Objet :* Re: [sfc] WGLC for
> 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]> 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]> 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_-Sindy74K4QDA6EWJjx35STSH-UxEi3eYIX0GVli9Sn1azrOPJVcI2qUzWfezK_1D2RpyFB_FOIp-CeLfeA$>
>
> 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.
>
>