Re: [sfc] Progression of OAM work in the SFC WG - OAM Packet

["Carlos Pignataro (cpignata)" <[e-mail]>]

Joel,

Happy to.

No, that is not what I meant. I am not sure where (or why) you added the word “external”, but that was key to showing a disconnect (I might not have been clear and/or you might not have read correctly).

Let me try different way:

There is an I-D now, sfc-multi-layer-oam, that sends “SFC Active OAM" packets with a new SFC next protocol for a newly created protocol. In this case, the SFC next protocol is not expected to be used in user packets, at least for now (or people have not thought about that in hierarchical cases)

Imagine now that BFD or ICMP want to be used as an SFC Active OAM protocols, instead of the sfc-multi-layer-oam one. Those can be encapsulated in IP (even with a 127/8 destination). Using the O-bit set and SFC NP as IP is the RFC 8300 expected way. (I imagine creating a new SFC next protocol for “BFD-in-IP-used-in-SFC” so as to avoid an SFC NP expected on external packets would be an approach if there was no O-bit defined)

Best,

Carlos.

2/14/22 午前7:05、Joel M. Halpern <[e-mail]<mailto:[e-mail]>>のメール:

Thank you for taking the time to provide a careful reply.

It appears, from your description of ICMP packets that your understanding of 8300 is that in SFC an external ICMP packet will get the O bit set in the NSH header.  Presumably, base on this, the SFF or SF are supposed to look through and notice this content?   (Otherwise, why set the bit?)  This seems an undesirable and expensive implications which other readers have not drawn from the RFC 8300 text.  (It also requires the encapsulating node to do extra checking to discover this case.)

Am I reading your expectation correctly?

Yours,
Joel

On 2/13/2022 11:06 PM, Carlos Pignataro (cpignata) wrote:
Replying to this specific email in the thread, only because it is the latest one at this point in time, but bundling comments from various places on the thread. Please find some follow-up comments and questions marked “CMP”, indicating the “From”, and organized chronologically:
*James N Guichard <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]>>:*
1) The chairs have reviewed the O bit definition in RFC 8300.  That definition is at best open to interpretation and therefore incomplete.  For example, the clear intention is only to mark packets which are intended for SFC OAM at the SFC service layer.  But that is not what the current text says.  There is also, unfortunately, ambiguity as to what constitutes an OAM packet.  So it is reasonable for documents to update 8300 to clarify the exact applicability and action for the O-bit.
CMP: It is unclear to me what exact issues the chairs are calling out. There are two issues mentioned:
CMP: 1. "But that is not what the current text says.” —> what does the text say precisely?  Can you point to the specific RFC 8300 text that is believed to be incomplete, and a detailed use case that showcases the potential issue? An extrapolated counter-example just to make a point: the text does not  say what days of the week OAM packets can be marked, yet there’s an expectation that they will work Mondays and Saturdays all the same — even holidays.
CMP: 2. What specifically is the ambiguity with what an OAM packet is? Please grep the RFC series for “oam packet”, it is not a new term.
CMP: Net-net, O-bit=1, OAM packet.
2) However, related to point 1), we can't have multiple documents updating the definition differently.  As such, the authors of the SFC iOAM draft and the SFC multi-layer-oam draft need to come together and figure out what the clarification is for the definition of that bit. We do not believe as chairs that either of these documents can move forward from the WG until such clarity has been reached.
CMP: If there is still believed to be an ambiguity or a clear opportunity for improving the definition, I agree with consolidating that update. I had suggested before that if such new text or real clarification is agreed, a separate document that only makes that O-bit clarification is the most clear and clean way to go. That doc should be a one-pager or less. I’d be happy to contribute to that minimal doc, if it is shown to be needed.
CMP: For completeness also, the "SFC multi-layer-oam” document has many outstanding issues besides the O-bit.
*Greg Mirsky <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]>>*
I've reviewed our SFC OAM documents and draft-ietf-sfc-nsh-tlv. As I understand these documents, the Active SFC OAM and IOAM are identified by the respective values for the NSH Next Protocol field (to be assigned by IANA).
CMP: There is a major issue with the sentence above. Active SFC OAM (as a category), as per RFC 8300, needs to be identified by setting the O-bit. No way around that based on RFC 8300. However, the text "the Active SFC OAM” creates confusion since it refer to a specific OAM protocol which has the same name as a the category as well. That name collision is quite unfortunate in my opinion.
At the same time, so far no OAM-specific meta data TLV has been defined. Thus, it appears that one way forward could be to not involve the O bit in the active SFC OAM or IOAM altogether. In other words, to deprecate the NSH O bit.
CMP: RFC 8924 already includes ICMP and BFD as example SFC Action OAM protocols. Those can be encapsulated in IP, in which the Next-Protocol indicates IP — and (as per RFC 8300) the O-bit is set to indicate an OAM packet.
CMP: The proposal of deprecating the O-bit breaks those SFC OAM protocols already included in an RFC.
CMP: That proposal of deprecating the O-bit also breaks Section 4.1 of IOAM.
CMP: This expired I-D yet implemented in open source uses the O-bit: https://www.ietf.org/archive/id/draft-penno-sfc-trace-03.txt <https://www.ietf.org/archive/id/draft-penno-sfc-trace-03.txt>
*Gyan Mishra <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]>>*
I agree that what makes sense to me as a path forward is to deprecate the O bit and not use in SFC Multilayer OAM and SFC IOAM, as both SFC Multilayer OAM and SFC IOAM are identified by the respective values for the NSH Next Protocol field (to be assigned by IANA), as well as so far no OAM-specific meta data TLV has been yet defined.
CMP: What is the “SFC Multilayer OAM”?
CMP: The O-bit (reading RFC 8300) does not indicate if there is OAM Metadata. It indicates an OAM packet.
*"Joel M. Halpern" <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]>>*
As far as I can tell, if we deprecate the O-bit and rely on the next protocol field, we are saying that in practice (not by rule) NSH metadata can not be used for OAM.  That's fine with me as long as we agree on that.
CMP: I do not fully follow this. Can you explain the relationship of the O-bit with Metadata?
CMP: Here’s an example: RFC 8924 shows ICMP as Active OAM. The SFC next protocol is IP, the IP next protocol is ICMP, the O-bit needs to be set.
CMP: Consider the following document, independent submission and in the RFC Publication queue already:
CMP: https://datatracker.ietf.org/doc/draft-mymb-sfc-nsh-allocation-timestamp/ <https://datatracker.ietf.org/doc/draft-mymb-sfc-nsh-allocation-timestamp/>
CMP: Is a Timestamp in Metadata an OAM element?
CMP: Consider this proposal https://datatracker.ietf.org/doc/draft-mirsky-sfc-pmamm/ <https://datatracker.ietf.org/doc/draft-mirsky-sfc-pmamm/>
CMP: Where the base header borrows a bit for an OAM function.
CMP: Neither of those have any impact on the O-bit.
*Greg Mirsky <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]>>*
I agree that, as we find SFC NSH now, no OAM metadata has been defined. It appears to me that deprecating the O bit does not affect any of the already defined mechanisms in the SFC NSH.
CMP: It actually does, see my example above.
I think that if a new, for example, MD Type = 2 TLV that is used for any OAM functionality to be proposed in the future, deprecated the O bit would not prevent using such NSH TLV.
CMP: I agree with this — because there is no correlation between MD Type field and O-bit as defined.
Best,
Carlos.
2/13/22 午後12:32、Gyan Mishra <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]>>のメール:

Hi Joel

I am in agreement as well with what you have stated that once the O bit is deprecated that NSH metadata cannot be used for OAM and that we would have to now from that point forward rely on the next protocol field as we will be doing for SFC Multilayer and SFC IOAM drafts as well as will have backwards compatible with any already existing defined mechanisms in SFC NSH.

I don’t see any issues or impact with moving forward.

Kind Regards

Gyan

On Sun, Feb 13, 2022 at 12:04 PM Greg Mirsky <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]>> wrote:

   Hi Joel,
   I agree that, as we find SFC NSH now, no OAM metadata has been
   defined. It appears to me that deprecating the O bit does not
   affect any of the already defined mechanisms in the SFC NSH. I
   think that if a new, for example, MD Type = 2 TLV that is used for
   any OAM functionality to be proposed in the future, deprecated the
   O bit would not prevent using such NSH TLV.
   What do you think?

   Regards,
   Greg

   On Sun, Feb 13, 2022 at 6:55 AM Joel M. Halpern
   <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]>> wrote:

       There is an implication of deprecating the O-bit that I would
       like to
       hear from more WG participants about.

       As far as I can tell, if we deprecate the O-bit and rely on
       the next
       protocol field, we are saying that in practice (not by rule) NSH
       metadata can not be used for OAM.  That's fine with me as long
       as we
       agree on that.

       Yours,
       Joel

       On 2/13/2022 2:52 AM, Gyan Mishra wrote:
       >
       > Hi Jim, Joel & SFC WG,
       >
       > I agree that the RFC 8300 definition of O bit is incomplete
       and not
       > clear as to its intended use.
       >
       > That is a problem that I agree needs to be rectified.
       >
       > I understand that we need to get this resolved before we can
       progress
       > Multilayer SFC OAM draft-ietf-sfc-multi-layer-oam-18 and SFC
       IOAM.
       >
       > I agree that what makes sense to me as a path forward is to
       deprecate
       > the O bit and not use in SFC Multilayer OAM and SFC IOAM, as
       both SFC
       > Multilayer OAM and SFC IOAM are identified by the respective
       values for
       > the NSH Next Protocol field (to be assigned by IANA), as
       well as so far
       > no OAM-specific meta data TLV has been yet defined.
       >
       > So we have I believe solid solution and path forward and I
       support
       > deprecating the O bit.
       >
       > Kind Regards
       >
       > Gyan
       >
       > On Wed, Feb 2, 2022 at 5:42 PM Greg Mirsky
       <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]>
       > <mailto:[e-mail]
       <mailto:[e-mail]>>> wrote:
       >
       >     Thank you, Jim and Joel, for guiding the SFC OAM work
       and pointing
       >     out the issue that must be addressed.
       >
       >     I've reviewed our SFC OAM documents and
       draft-ietf-sfc-nsh-tlv. As I
       >     understand these documents, the Active SFC OAM and IOAM are
       >     identified by the respective values for the NSH Next
       Protocol field
       >     (to be assigned by IANA). At the same time, so far no
       OAM-specific
       >     meta data TLV has been defined. Thus, it appears that
       one way
       >     forward could be to not involve the O bit in the active
       SFC OAM or
       >     IOAM altogether. In other words, to deprecate the NSH O bit.
       >
       >     I greatly appreciate your comments on the proposal to
       deprecate the
       >     NSH O bit.
       >
       >     Regards,
       >     Greg
       >
       >     On Wed, Feb 2, 2022 at 10:36 AM James Guichard
       >     <[e-mail]<mailto:[e-mail]>
       <mailto:[e-mail]>
       >     <mailto:[e-mail]
       <mailto:[e-mail]>>> wrote:
       >
       >         Hi WG:____
       >
       >         __ __
       >
       >         Having reviewed all of the OAM related documents in
       our WG, the
       >         chairs would like to provide a few comments to hopefully
       >         generate discussion and forward progress of this
       work:____
       >
       >         __ __
       >
       >         1) The chairs have reviewed the O bit definition in
       RFC 8300.
       >         That definition is at best open to interpretation
       and therefore
       >         incomplete.  For example, the clear intention is
       only to mark
       >         packets which are intended for SFC OAM at the SFC
       service
       >         layer.  But that is not what the current text says.         There is
       >         also, unfortunately, ambiguity as to what
       constitutes an OAM
       >         packet.  So it is reasonable for documents to update
       8300 to
       >         clarify the exact applicability and action for the
       O-bit.____
       >
       >         __ __
       >
       >         2) However, related to point 1), we can't have multiple
       >         documents updating the definition differently.  As
       such, the
       >         authors of the SFC iOAM draft and the SFC
       multi-layer-oam draft
       >         need to come together and figure out what the
       clarification is
       >         for the definition of that bit. We do not believe as
       chairs that
       >         either of these documents can move forward from the
       WG until
       >         such clarity has been reached. ____
       >
       >         __ __
       >
       >         3) Related to the SFC iOAM, we need a clear
       definition of iOAM.
       >         There seem to be differences between the definitions in
       >         published RFCs, the usage (which is not a
       definition) in the SFC
       >         draft, and the various ippm drafts.  Any such
       definition will
       >         need to be vetted with the ippm working group.____
       >
       >         __ __
       >
       >         Again, it would be good if members of the working
       group beyond
       >         the two author teams spoke up about their readings
       of the
       >         documents, and their understandings of what we need.____
       >
       >         __ __
       >
       >         Yours,____
       >
       >         Jim and Joel____
       >
       >         __ __
       >
       >         __ __
       >
       >         __ __
       >
       >         _______________________________________________
       >         sfc mailing list
       > [e-mail]<mailto:[e-mail]> <mailto:[e-mail]> <mailto:[e-mail]
       <mailto:[e-mail]>>
       > https://www.ietf.org/mailman/listinfo/sfc
       <https://www.ietf.org/mailman/listinfo/sfc>
       >         <https://www.ietf.org/mailman/listinfo/sfc
       <https://www.ietf.org/mailman/listinfo/sfc>>
       >
       >     _______________________________________________
       >     sfc mailing list
       > [e-mail]<mailto:[e-mail]> <mailto:[e-mail]> <mailto:[e-mail]
       <mailto:[e-mail]>>
       > https://www.ietf.org/mailman/listinfo/sfc
       <https://www.ietf.org/mailman/listinfo/sfc>
       >     <https://www.ietf.org/mailman/listinfo/sfc
       <https://www.ietf.org/mailman/listinfo/sfc>>
       >
       > --
       >
       > <http://www.verizon.com/ <http://www.verizon.com/>>
       >
       > *Gyan Mishra*
       >
       > /Network Solutions A//rchitect /
       >
       > /Email [e-mail]<mailto:[e-mail]>
       <mailto:[e-mail]>
       <mailto:[e-mail]
       <mailto:[e-mail]>>//
       > /
       >
       > /M 301 502-1347
       >
       > /
       >
       >

--

<http://www.verizon.com/>

*Gyan Mishra*
/Network Solutions A//rchitect /
/Email [e-mail]<mailto:[e-mail]> <mailto:[e-mail]>//
/
/M 301 502-1347

/

_______________________________________________
sfc mailing list
[e-mail]<mailto:[e-mail]> <mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/sfc
_______________________________________________
sfc mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/sfc