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

[[e-mail]]

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