Re: [sfc] TR: I-D Action: draft-boucadair-sfc-oam-packet-00.txt

["Joel M. Halpern" <[e-mail]>]

Thanks.  I think that captures it nicely.

Yours,
Joel

On 2/24/2022 8:59 AM, [e-mail] wrote:
> Re-,
> 
> Sure. I made some minor edits. The NEW text looks as follows:
> 
>        When an OAM data is included in the inner packet, the Next
>        Protocol field is set to reflect the structure of that inner OAM
>        packet.  The setting and processing of the O bit neither assumes
>        nor expects detailed analysis of the content of any inner IP
>        packet carried by the NSH.  As such, SFFs, SFC-aware SFs, and SFC
>        Proxies SHOULD discard any NSH packets with the O bit set and Next
>        Protocol set to something that is not itself an OAM protocol.
>        This includes discarding the packet when the O bit is set and the
>        Next Protocol is set to 0x01 (IPv4), 0x02 (IPv6), 0x03 (MPLS), or
>        0x05 (Ethernet).
> 
> Thanks.
> 
> Cheers,
> Med
> 
>> -----Message d'origine-----
>> De : Joel M. Halpern <[e-mail]>
>> Envoyé : jeudi 24 février 2022 14:40
>> À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>om>; Greg
>> Mirsky <[e-mail]>
>> Cc : [e-mail]
>> Objet : Re: [sfc] TR: I-D Action: draft-boucadair-sfc-oam-packet-00.txt
>>
>> May a suggest a small refinement?
>>       The setting and processing of the O bit neither assumes nor expects
>> detailed analysis of the contents of any IP packets carried by NSH.  As
>> such, SFFs and SFs SHOULD discard any NSH packets with the O bit set and
>> Next protocol set to something that is not itself an OAM protocol.  THis
>> includes discarding the packet when O bit is set and the Next Protocol
>> is set to 0x01 (IPv4), 0x02 (IPv6), 0x03 (MPLS), or 0x05 (Ethernet).
>>
>> Yours,
>> Joel
>>
>> On 2/24/2022 2:56 AM, [e-mail] wrote:
>>> Hi Joel, all,
>>>
>>> FWIW, I updated -02 with the following to reflect one of the points
>> discussed below:
>>>
>>>         When an OAM data is included in the inner packet, the Next
>>>         Protocol field is set to reflect the structure of that inner
>>>         packet.  By default, SFFs SHOULD discard NSH packets with O bit
>>>         set and Next Protocol set to 0x1 (IPv4), 0x2 (IPv6), 0x3
>> (MPLS),
>>>         or 0x5 (Ethernet).
>>>
>>> Cheers,
>>> Med
>>>
>>>> -----Message d'origine-----
>>>> De : sfc <[e-mail]> De la part de
>>>> [e-mail] Envoyé : jeudi 17 février 2022 08:14 À :
>>>> Joel M. Halpern <[e-mail]>om>; Greg Mirsky
>>>> <[e-mail]> Cc : [e-mail] Objet : Re: [sfc] TR: I-D
>>>> Action: draft-boucadair-sfc-oam-packet-00.txt
>>>>
>>>> Hi Joel,
>>>>
>>>>> If the NSH payload is an IP packet, and that packet is addressed to
>>>>> something other than this node, and that packet is carrying  an ICMP
>>>>> echo, is that an SFC OAM packet requiring the O-bit being set?
>>>>
>>>> Med: The NSH can be added by a classifier or directly by an SFC OAM
>>>> controller that issues the packet. If the original IP/ICMP packet is
>>>> received by a classifier, the classifier must not set the O bit as
>>>> per draft-boucadair-sfc-oam-packet because that packet is seen as
>>>> data packet.
>>>>
>>>> Let's now focus on the SFC OAM controller case:
>>>> * Does it makes sense for an SFC OAM controller to "leverage" IP/ICMP
>>>> for SFC OAM purposes while it can do it directly using ICMP (without
>>>> the IP header)?
>>>>
>>>> I personally don't see any.
>>>>
>>>> * Does it makes sense for an SFC OAM controller to "supply" an
>>>> IP/ICMP as an input for specific OAM purposes?
>>>>
>>>> This is in theory possible for SF testing purposes (e.g., test the
>>>> behavior of a firewall against such packet. The output of the test
>>>> will be used to assess if the FW configuration is OK/NOK). However,
>>>> such test OAM packets have to be unambiguously identified as such.
>>>> The Next Protocol won't be set to IP but to the value assigned to an
>>>> OAM protocol.
>>>>
>>>>     And
>>>>> conversely, is an SFF required to check for that case if it sees an
>>>>> NSH with the O-bit set?
>>>>
>>>> Med: SFFs have to support policies whether some OAM messages can be
>>>> forwarded to SFs. These policies may include a filter on valid next
>>>> protocol values. I don't have an objection to discard by default
>>>> packets with O bit set and next protocol = IP/MPLS/Ethernet
>>>>
>>>> Cheers,
>>>> Med
>>>>
>>>>> -----Message d'origine-----
>>>>> De : Joel M. Halpern <[e-mail]> Envoyé : mercredi 16
>>>>> février 2022 17:30 À : BOUCADAIR Mohamed INNOV/NET
>>>>> <[e-mail]>om>; Greg Mirsky <[e-mail]>
>>>> Cc
>>>>> : [e-mail] Objet : Re: [sfc] TR: I-D Action:
>>>>> draft-boucadair-sfc-oam-packet-00.txt
>>>>>
>>>>> Thank you for writing this.  I look forward to more dscussion by
>>>>> more WG members.
>>>>>
>>>>> I want to ask one clarifying quesiton about an example that was
>>>>> raised earlier.
>>>>>
>>>>> If the NSH payload is an IP packet, and that packet is addressed to
>>>>> something other than this node, and that packet is carrying  an ICMP
>>>>> echo, is that an SFC OAM packet requiring the O-bit being set?  And
>>>>> conversely, is an SFF required to check for that case if it sees an
>>>>> NSH with the O-bit set?
>>>>>
>>>>> Yours,
>>>>> Joel
>>>>>
>>>>> On 2/16/2022 11:21 AM, [e-mail] wrote:
>>>>>> Re-,
>>>>>>
>>>>>> This is determined by the entity that issues the OAM packet. This
>>>>>> is typically a dedicated OAM controller or an SFC element
>>>>>> (classifier for the ioam case, for example).
>>>>>>
>>>>>> BTW, I updated the draft to reflect your comments and also those
>>>>>> from
>>>>>> Jim:
>>>>>> https://www.ietf.org/rfcdiff?url2=draft-boucadair-sfc-oam-packet-01
>>>>>> <https://www.ietf.org/rfcdiff?url2=draft-boucadair-sfc-oam-packet-0
>>>>>> 1
>>>>>>>
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Med
>>>>>>
>>>>>> *De :* Greg Mirsky <[e-mail]> *Envoyé :* mercredi 16
>>>>>> février 2022 16:52 *À :* BOUCADAIR Mohamed INNOV/NET
>>>>>> <[e-mail]> *Cc :* [e-mail] *Objet :* Re:
>>>>>> [sfc]
>>>>>> TR: I-D Action: draft-boucadair-sfc-oam-packet-00.txt
>>>>>>
>>>>>> Hi Med,
>>>>>>
>>>>>> thank you for your expedient response. I have a follow-up question:
>>>>>>
>>>>>>       How does one determine the nature, OAM or not-OAM, of data
>>>>> elements
>>>>>>       in the NSH Context header?
>>>>>>
>>>>>> As I understand it, draft-ietf-sfc-nsh-tlv does not provide that.
>>>>>> Do we need to add it? Appreciate your thoughts on that.
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Greg
>>>>>>
>>>>>> On Wed, Feb 16, 2022 at 7:30 AM <[e-mail]
>>>>>> <mailto:[e-mail]>> wrote:
>>>>>>
>>>>>>       Hi Greg,
>>>>>>
>>>>>>       Please see inline.
>>>>>>
>>>>>>       Cheers,
>>>>>>
>>>>>>       Med
>>>>>>
>>>>>>       *De :* Greg Mirsky <[e-mail]
>>>>>>       <mailto:[e-mail]>>
>>>>>>       *Envoyé :* mercredi 16 février 2022 16:13
>>>>>>       *À :* BOUCADAIR Mohamed INNOV/NET
>> <[e-mail]
>>>>>>       <mailto:[e-mail]>>
>>>>>>       *Cc :* [e-mail] <mailto:[e-mail]>
>>>>>>       *Objet :* Re: [sfc] TR: I-D Action:
>>>>>>       draft-boucadair-sfc-oam-packet-00.txt
>>>>>>
>>>>>>       Hi Med,
>>>>>>
>>>>>>       many thanks for taking the lead and putting the proposal on
>>>>>> the
>>>>> table.
>>>>>>
>>>>>>       I have a question on the proposed new text for the O bit and
>> its
>>>>>>       possible effect on IOAM:
>>>>>>
>>>>>>           O bit:  Setting this bit indicates an SFC OAM packet.
>>>>>> Such a packet
>>>>>>
>>>>>>              is any NSH-encapasulated packet that exclusively
>>>>>> includes an OAM
>>>>>>
>>>>>>              command and/or OAM data.
>>>>>>
>>>>>>       My understanding of the new definition of the O bit is that
>>>>>> the
>>>>> NSH
>>>>>>       includes and/or encapsulates only OAM command and/or data.
>>>>>> IOAM,
>>>>> as
>>>>>>       I understand its application in NSH, may follow the NSH and
>> have
>>>>>>       user payload after the IOAM data.
>>>>>>
>>>>>>       *//*
>>>>>>
>>>>>>       */[Med] Packets that include also user data are not considered
>>>> as
>>>>>>       “OAM packets” as per the new definition./*
>>>>>>
>>>>>>       And another scenario, if Flow ID TLV is used to influence user
>>>>> data
>>>>>>       through SFP, OAM will apply the same Flow ID value. Would such
>>>>>>       packet still be considered as "exclusively includes OAM
>> command
>>>>>>       and/or data"?
>>>>>>
>>>>>>       *//*
>>>>>>
>>>>>>       */[Med] Yes, they are. Flow id is just a constraint, if you
>>>> will,
>>>>>>       that is used to influence how OAM commands will be executed.
>>>>>> /*
>>>>>>
>>>>>>       Regards,
>>>>>>
>>>>>>       Greg
>>>>>>
>>>>>>       On Wed, Feb 16, 2022 at 6:40 AM <[e-mail]
>>>>>>       <mailto:[e-mail]>> wrote:
>>>>>>
>>>>>>           Hi all,
>>>>>>
>>>>>>           A proposal to clarify the intent of SFC OAM packet.
>>>>>> Comments
>>>>> are
>>>>>>           welcome.
>>>>>>
>>>>>>           Cheers,
>>>>>>           Med
>>>>>>
>>>>>>           -----Message d'origine-----
>>>>>>           De : I-D-Announce <[e-mail]
>>>>>>           <mailto:[e-mail]>> De la part de
>>>>>>           [e-mail] <mailto:[e-mail]>
>>>>>>           Envoyé : mercredi 16 février 2022 15:38
>>>>>>           À : [e-mail] <mailto:[e-mail]>
>>>>>>           Objet : I-D Action: draft-boucadair-sfc-oam-packet-00.txt
>>>>>>
>>>>>>
>>>>>>           A New Internet-Draft is available from the on-line
>>>>>>           Internet-Drafts directories.
>>>>>>
>>>>>>
>>>>>>                    Title           : Clarifying Ambiguity related to
>>>>>>           Network Service Header (NSH) OAM Packet
>>>>>>                    Author          : Mohamed Boucadair
>>>>>>                    Filename        : draft-boucadair-sfc-oam-packet-
>>>>> 00.txt
>>>>>>                    Pages           : 5
>>>>>>                    Date            : 2022-02-16
>>>>>>
>>>>>>           Abstract:
>>>>>>               This document clarifies an ambiguity in the Network
>>>>> Service
>>>>>>           Header
>>>>>>               (NSH) specification related to the handling of O-
>>>> bit.  In
>>>>>>           particular,
>>>>>>               this document clarifies the meaning of "OAM packet".
>>>>>>
>>>>>>               This document updates RFC8300.
>>>>>>
>>>>>>
>>>>>>           The IETF datatracker status page for this draft is:
>>>>>>           https://datatracker.ietf.org/doc/draft-boucadair-sfc-oam-
>>>>> packet/
>>>>>>
>>>>>> <https://datatracker.ietf.org/doc/draft-boucadair-sfc-oam-packet/>
>>>>>>
>>>>>>           There is also an htmlized version available at:
>>>>>>
>>>>>> https://datatracker.ietf.org/doc/html/draft-boucadair-sfc-oam-
>>>>> packet-00
>>>>>>
>>>>>> <https://datatracker.ietf.org/doc/html/draft-boucadair-sfc-oam-pack
>>>>>> e
>>>>>> t-
>>>>>> 00>
>>>>>>
>>>>>>
>>>>>>           Internet-Drafts are also available by rsync at
>>>>>>           rsync.ietf.org::internet-drafts
>>>>>>
>>>>>>
>>>>>>           _______________________________________________
>>>>>>           I-D-Announce mailing list
>>>>>>           [e-mail] <mailto:[e-mail]>
>>>>>>           https://www.ietf.org/mailman/listinfo/i-d-announce
>>>>>>           <https://www.ietf.org/mailman/listinfo/i-d-announce>
>>>>>>           Internet-Draft directories:
>> http://www.ietf.org/shadow.html
>>>>>>           <http://www.ietf.org/shadow.html> or
>>>>>>           ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>>>>>           <ftp://ftp.ietf.org/ietf/1shadow-sites.txt>
>>>>>>
>>>>>>
>>>>>> ___________________________________________________________________
>>>>>> _ __ ___________________________________________________
>>>>>>
>>>>>>           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.
>>>>>>
>>>>>>           _______________________________________________
>>>>>>           sfc mailing list
>>>>>>           [e-mail] <mailto:[e-mail]>
>>>>>>           https://www.ietf.org/mailman/listinfo/sfc
>>>>>>           <https://www.ietf.org/mailman/listinfo/sfc>
>>>>>>
>>>>>>
>>>>>> ___________________________________________________________________
>>>>>> _ __ ___________________________________________________
>>>>>>
>>>>>>       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.
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> sfc mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/sfc
>>>>
>>>> _____________________________________________________________________
>>>> ___ _________________________________________________
>>>>
>>>> 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.
>>>>
>>>> _______________________________________________
>>>> sfc mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/sfc
>>>
>>> ______________________________________________________________________
>>> ___________________________________________________
>>>
>>> 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.
>