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

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

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