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

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

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-01
>>>>>
>>>>
>>>> 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-packe
>>>> 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.
>