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

[Shwetha Bhandari <[e-mail]>]

Hi Greg,

Thanks for the confirmation on changes.
There are 4 IOAM Option types defined in the draft-ietf-ippm-ioam-data that
includes tracing, proof of transit and edge to edge option types. Then
there is DEX Option type defined in draft-ietf-ippm-ioam-direct-export.
Given this I think the current diagram covers all of this and any future
Option types in a generic way to be carried in NSH. Hence I propose to keep
the structure as is.

Thanks
Shwetha


On Wed, Apr 27, 2022, 7:12 PM Greg Mirsky <[e-mail]> wrote:

> 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
>> <https://urldefense.com/v3/__https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-ioam-nsh-09__;!!MZ3Fw45to5uY!PZhbt-ci_ieWRj9gKXMxkUhuRogi2KAeHYJn2uVuDLllnCenK6ZB-uj9t3KrrvRpZ_ok6S1hT2dPOP-r4IowU8hjPRT12bU$>
>>
>> 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.
>>>>
>>>>