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

[Greg Mirsky <[e-mail]>]

Hi Shwetha,
thank you and the authors for the update. I agree with the updates.
In the course of reviewing the latest version I came up with a question and
appreciate your thoughts on it. The figure that displayed the format of an
NSH with IOAM IOAM Option and Optional IOAM Data presented as a single
field. At the same time, there's no IOAM Option construct defined in
draft-ietf-ippm-ioam-data. As I understand it, IOAM Option relates to IOAM
Option Trace headers defined:

   - Pre-allocated and Incremental
   - Edge-to-Edge
   - Proof-ot-Transit
   - Direct Export
   - Hybrid Two-Step

Considering all that, I think it would be helpful to separate the IOAM
Option field, renaming it as IOAM Option Trace Header. And the Optional
IOAM Data field to follow.
What do you think?

Regards,
Greg


On Wed, Apr 27, 2022 at 1:06 AM Shwetha Bhandari <
[e-mail]> wrote:

> Dear SFC chairs,
>
> A new version of the draft I-D.ietf-sfc-ioam-nsh has been submitted per
> the discussion in this thread.
> https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-ioam-nsh-09
> Can we please progress this draft to IESG if there are no further comments?
>
> Thanks,
> Shwetha
>
> On Thu, Apr 14, 2022 at 6:41 PM Greg Mirsky <[e-mail]> wrote:
>
>> 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/
>>> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/__;!!MZ3Fw45to5uY!LWQuxxxKpUum5gUoK44-znjehj2YRtlGMOATxfRVSc-7JOrPsk4BA4iP0oLQE4d0rObPhOCG_1iiipywftwMIMOEWh8lJI4$>
>>>
>>>
>>>
>>> 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.
>>>
>>>