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

[Shwetha Bhandari <[e-mail]>]

Ack, will add text to this effect.

Thanks
Shwetha

On Wed, May 4, 2022, 9:23 AM Joel Halpern <[e-mail]> wrote:

> If we do not tell the implementors that there can be multiple iOAM
> headers, and how they are required to process them, then some implementors
> will follow logic we do not want.
>
>
> For example, you have various selective iOAM headers.  So an SFF looks at
> the next header to check for iOAM.  Seems it is iOAM.  And then seems the
> content is iOAM it can ignore.  A naive implementation might well stop
> right there and proceed with normal SFF processing.  Since you don't want
> that, just write into the spec what the WG expects.
>
>
> Yours,
>
> Joel
> On 5/3/2022 11:22 PM, Shwetha Bhandari wrote:
>
> Why do we need to call that out explicitly in this draft? Isn't that part
> of header processing anyway?
>
> Thanks
> Shwetha
>
> On Wed, May 4, 2022, 6:24 AM Joel Halpern <[e-mail]> wrote:
>
>> 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$>
>>>>
>>>