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

[Joel Halpern <[e-mail]>]

Can we have just a sentence or two saying that if there are multiple 
iOAM options, the SFF must check all of them for relevance and act on 
all relevant ones?


Yours,

Joel

On 5/3/2022 8:26 PM, Shwetha Bhandari wrote:
> Hi Greg, Joel,
>
> The purpose of these options are different. Reiterating the use cases 
> described in the draft-ietf-ippm-ioam-deployment draft : hop by hop 
> tracing related options are -pre-allocated, incremental,direct export. 
> The edge-to-edge option is not collecting trace but metrics at the 
> edge and helps in correlation e.g sequence number is inserted and used 
> to identify packet loss rate. The proof-of-transit option is used to 
> prove that the packet has traversed the check points in the networks.
> There is also IOAM namespace that is used to collect specific data 
> types in trace options and a node can be configured to process trace 
> options with a specific namespace, this is useful when we have nodes 
> with varying implementation of trace option data types defined.
> Restricting IOAM option in NSH to a specific number will make it 
> difficult to deploy. Hence I don't see a need to update the current 
> draft to add any of this restrictions. Let's use 
> draft-ietf-ippm-ioam-deployment to understand the use cases and 
> deployment modes.
>
> Thanks
> Shwetha
>
>
> On Wed, May 4, 2022, 3:01 AM Greg Mirsky <[e-mail]> wrote:
>
>     Hi Joel,
>     thank you for highlighting this question, I've missed it.
>
>     As we've discussed earlier, several IOAM trace options have been
>     defined:
>
>       * pre-allocated
>       * incremental
>       * edge-to-edge
>       * proof-of-transit
>       * direct export
>       * hybrid two-step
>
>     I cannot find a scenario when using more than one IOAM trace
>     option that could be beneficial, and useful for an operator. I
>     think that if there is no use case, then the restricting number of
>     IOAM trace options used is reasonable and helps implementors in
>     developing interoperable implementations.
>
>     Regards,
>     Greg
>
>     On Mon, May 2, 2022 at 2:42 PM Joel Halpern <[e-mail]>
>     wrote:
>
>         (Sorry, catching up on some emails I missed.)
>
>         If we want to allow multiple iOAM headers (up to the WG) then
>         I think the document needs to be clear on the meaning.  If
>         there are multiple are all supposed to be processed, just the
>         top one until something removes it, a random one of the
>         receivers choice?  (Yes, that last is unlikely.)
>
>         Yours,
>
>         Joel
>
>         On 4/27/2022 4:44 AM, Shwetha Bhandari wrote:
>>         Hi Med,
>>
>>         Thanks for the confirmation and quick review.
>>
>>         On,
>>
>>             This means the new requested TBD_IOAM value will also be
>>             a valid next protocol. However, I wonder whether IOAM in
>>             IOAM in NSH is really something you want to have. If not,
>>             I suggest the text is updated to exclude it from the
>>             allowed value in the above excerpt. 
>>
>>         Per earlier discussion in this thread, quoting Frank's mail
>>         here for reference:
>>
>>             In addition, I don’t think that draft-ietf-sfc-ioam-nsh
>>             would be the appropriate place to discuss and restrict
>>             deployment options. E.g., I’m not sure why we’d want to
>>             restrict a deployment to using a single IOAM header only.
>>             E.g., one could think of using different headers for
>>             different namespaces or groups of namespaces for
>>             operational reasons. IMHO, such a discussion – if we
>>             really need it - would belong into
>>             draft-ietf-ippm-ioam-deployment, rather than into a draft
>>             that defines the encap of IOAM into NSH.
>>
>>         I think the text on Next Protocol should be as is. We should
>>         not add restrictions on number of IOAM headers that could be
>>         added to the packet.
>>
>>         Thanks,
>>         Shwetha
>>
>>
>>
>>         On Wed, Apr 27, 2022 at 1:46 PM
>>         <[e-mail]> wrote:
>>
>>             Hi Shwetha, all,
>>
>>             The changes look great. Thanks.
>>
>>             There is one specific point not addressed in previous
>>             replies. This is related to this text:
>>
>>                   Next Protocol:  8-bit unsigned integer that
>>             determines the type of
>>
>>                      header following IOAM.  The semantics of this
>>             field are
>>
>>             identical to the Next Protocol field in [RFC8300].
>>
>>             This means the new requested TBD_IOAM value will also be
>>             a valid next protocol. However, I wonder whether IOAM in
>>             IOAM in NSH is really something you want to have. If not,
>>             I suggest the text is updated to exclude it from the
>>             allowed value in the above excerpt.
>>
>>             Other than that, I think that the draft is ready to move
>>             forward.
>>
>>             Cheers,
>>
>>             Med
>>
>>             *De :* Shwetha Bhandari <[e-mail]>
>>             *Envoyé :* mercredi 27 avril 2022 10:06
>>             *À :* James Guichard <[e-mail]>;
>>             [e-mail]
>>             *Cc :* BOUCADAIR Mohamed INNOV/NET
>>             <[e-mail]>; Frank Brockners
>>             (fbrockne) <fbrockne=[e-mail]>;
>>             [e-mail]; [e-mail]; Tal Mizrahi
>>             <[e-mail]>;
>>             [e-mail]; Greg Mirsky
>>             <[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!NGDq-VFOnDYhCxrwRIz1KbT5hb_RKKqKigks-nyqK1RKq5UgpwytWb7clzmlN3o0X0XBWL0KnE3aQfL7wrrx5ZezQN_YdhHpnETuWA$>
>>
>>             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!NGDq-VFOnDYhCxrwRIz1KbT5hb_RKKqKigks-nyqK1RKq5UgpwytWb7clzmlN3o0X0XBWL0KnE3aQfL7wrrx5ZezQN_YdhFd29kDew$>
>>
>>
>>             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.
>>
>>             _________________________________________________________________________________________________________________________
>>
>>             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.
>>
>         _______________________________________________
>         ippm mailing list
>         [e-mail]
>         https://www.ietf.org/mailman/listinfo/ippm
>         <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ippm__;!!MZ3Fw45to5uY!KzP7tEXj2r_E1qNyQ90q9rykJ0iG0HA0CecIGBFXEIXiWITYay7wwoC0HbiFfO2GyUarxht3JEY45vcV4uCtZ8Xkud0uv58$>
>