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

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

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