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

[Joel Halpern <[e-mail]>]

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