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

[Gyan Mishra <[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]> 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]>
> 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
>> >
>> > /
>> >
>> >
>>
> --

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

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [e-mail] <[e-mail]>*



*M 301 502-1347*