[sfc] Fwd: New Version Notification for draft-ietf-sfc-multi-layer-oam-03.txt

[Greg Mirsky <[e-mail]>]

Dear All,
the update to the draft addresses the comment received from Joel at the
meeting in Prague:
- Joel: if we get an echo request we can't parse, how do we know that it is
an echo request, and do we have the information to return it to the correct
source?
- Greg: we will clarify this in the draft. It has to practical so the
sender can understand the situation. We introduced two classes of TLVs:
mandatory and optional. Will add clearer text.

A new TLV, Errored TLVs, introduced to be optionally used to pass in an
echo reply mandatory TLVs that were not understood because either the
implementation on the receiver does not support them or couldn't parse them
correctly.

Also, please review the update to the interpretation of O-bit and the value
of the Next Protocol field to address Adrian's comments at the meeting in
Bangkok:
The rules of
   interpreting the values of O bit and the Next Protocol field are as
   follows:

   o  O bit set, and the Next Protocol value is not one of identifying
      active or hybrid OAM protocol (per [RFC7799] definitions), e.g.,
      defined in this specification Active SFC OAM - a Fixed-Length
      Context Header or Variable-Length Context Header(s) contain OAM
      command or data.  and the type of payload determined by the Next
      Protocol field;

   o  O bit set, and the Next Protocol value is one of identifying
      active or hybrid OAM protocol - the payload that immediately
      follows SFC NSH contains OAM command or data;

   o  O bit is clear - no OAM in a Fixed-Length Context Header or
      Variable-Length Context Header(s) and the payload determined by
      the value of the Next Protocol field;

   o  O bit is clear and the Next Protocol value is one of identifying
      active or hybrid OAM protocol MUST be identified and reported as
      the erroneous combination.  An implementation MAY have control to
      enable processing of the OAM payload.

   From the above-listed rules follows the recommendation to avoid
   combination of OAM in a Fixed-Length Context Header or Variable-
   Length Context Header(s) and in the payload immediately following the
   SFC NSH because there is no unambiguous way to identify such
   combination using the O bit and the Next Protocol field.

Regards,
Greg

---------- Forwarded message ---------
From: <[e-mail]>
Date: Wed, May 8, 2019 at 10:21 PM
Subject: New Version Notification for draft-ietf-sfc-multi-layer-oam-03.txt
To: <[e-mail]>, Gregory Mirsky <[e-mail]>, Bhumip
Khasnabish <[e-mail]>, Wei Meng <[e-mail]>, Cui(Linda)
Wang <[e-mail]>



A new version of I-D, draft-ietf-sfc-multi-layer-oam-03.txt
has been successfully submitted by Greg Mirsky and posted to the
IETF repository.

Name:           draft-ietf-sfc-multi-layer-oam
Revision:       03
Title:          Active OAM for Service Function Chains in Networks
Document date:  2019-05-08
Group:          sfc
Pages:          18
URL:
https://www.ietf.org/internet-drafts/draft-ietf-sfc-multi-layer-oam-03.txt
Status:
https://datatracker.ietf.org/doc/draft-ietf-sfc-multi-layer-oam/
Htmlized:
https://tools.ietf.org/html/draft-ietf-sfc-multi-layer-oam-03
Htmlized:
https://datatracker.ietf.org/doc/html/draft-ietf-sfc-multi-layer-oam
Diff:
https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-multi-layer-oam-03

Abstract:
   A set of requirements for active Operation, Administration and
   Maintenance (OAM) of Service Function Chains (SFCs) in networks is
   presented.  Based on these requirements an encapsulation of active
   OAM message in SFC and a mechanism to detect and localize defects
   described.  Also, this document updates RFC 8300 in the definition of
   O (OAM) bit in the Network Service Header (NSH) and defines how the
   active OAM message identified in SFC NSH.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat