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

["Joel M. Halpern" <[e-mail]>]

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