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

[Greg Mirsky <[e-mail]>]

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]> 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]>> 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]>> 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]>
> >         https://www.ietf.org/mailman/listinfo/sfc
> >         <https://www.ietf.org/mailman/listinfo/sfc>
> >
> >     _______________________________________________
> >     sfc mailing list
> >     [e-mail] <mailto:[e-mail]>
> >     https://www.ietf.org/mailman/listinfo/sfc
> >     <https://www.ietf.org/mailman/listinfo/sfc>
> >
> > --
> >
> > <http://www.verizon.com/>
> >
> > *Gyan Mishra*
> >
> > /Network Solutions A//rchitect /
> >
> > /Email [e-mail] <mailto:[e-mail]>//
> > /
> >
> > /M 301 502-1347
> >
> > /
> >
> >
>