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

[Shwetha Bhandari <[e-mail]>]

Hi Med,

Why does reference to RFC 8300 and any update to it, not work? Doesn't
I-D.ietf-sfc-oam-packet update 8300 and anyone implementing this will be
able to find 8300 and any RFCs that update it and apply the rules?

Thanks
Shwetha

On Thu, Apr 14, 2022, 6:08 PM <[e-mail]> wrote:

> Re-,
>
>
>
> draft-ietf-sfc-ioam-nsh includes OAM data (likely with user data) but
> there is an ambiguity in 8300 to whether this is considered as an OAM
> packet. Please refer to the SFC archives where this was discussed.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* Frank Brockners (fbrockne) <[e-mail]>
> *Envoyé :* jeudi 14 avril 2022 14:29
> *À :* BOUCADAIR Mohamed INNOV/NET <[e-mail]>; 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]
> *Objet :* RE: [sfc] WGLC for
> https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/
> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/__;!!MZ3Fw45to5uY!P-r3UTstV56mLT678QmjnilBnxUfgnF62GGWB1KzZc9aczyFl44k8Ug9OrmNYsuFT09oX0UTEcp7d4J6cmU45CEFXUZ4y_RxQ0E9Fg$>
>
>
>
> Forgot to add: A clause like " The O-bit MUST be handled following the
> rules in and any updates to [RFC8300]“ simply states the obvious.
> draft-ietf-sfc-ioam-nsh does not touch or redefine the O-bit – hence the
> statement is at best optional. The reader might even wonder why the obvious
> is re-stated in the document. My preference is still to avoid any
> mentioning of the O-bit in draft-ietf-sfc-ioam-nsh.
>
>
>
> Frank
>
>
>
> *From:* Frank Brockners (fbrockne)
> *Sent:* Thursday, 14 April 2022 14:24
> *To:* [e-mail]; 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/
> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/__;!!MZ3Fw45to5uY!P-r3UTstV56mLT678QmjnilBnxUfgnF62GGWB1KzZc9aczyFl44k8Ug9OrmNYsuFT09oX0UTEcp7d4J6cmU45CEFXUZ4y_RxQ0E9Fg$>
>
>
>
> 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/
> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/__;!!MZ3Fw45to5uY!P-r3UTstV56mLT678QmjnilBnxUfgnF62GGWB1KzZc9aczyFl44k8Ug9OrmNYsuFT09oX0UTEcp7d4J6cmU45CEFXUZ4y_RxQ0E9Fg$>
>
>
>
> 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/
> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/__;!!MZ3Fw45to5uY!P-r3UTstV56mLT678QmjnilBnxUfgnF62GGWB1KzZc9aczyFl44k8Ug9OrmNYsuFT09oX0UTEcp7d4J6cmU45CEFXUZ4y_RxQ0E9Fg$>
>
>
>
> 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.
>
> _________________________________________________________________________________________________________________________
>
> 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.
>
>