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

[[e-mail]]

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.