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

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 <
james.n.guichard@futurewei.com> 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
> sfc@ietf.org
> https://www.ietf.org/mailman/listinfo/sfc
>