Subject: [sfc] Regarding last call for draft-ietf-sfc-multi-layer-oam

From: Joel Halpern Direct <[email-masked]>
Date: Mon, 1 Nov 2021 14:50:40 -0400

I have received a polite request with explanation for delay asking for 
more time to read and review the subject document.  Given the state of 
the working group, i want to encourage any and all review.  So I am 
extending the last call by two additional weeks.

Please read and review the document.
Also, if you are willing to serve as shepherd for this, please let the 
chairs know.  (Don't worry if you have not shepherded a document before. 
  The chairs are more than happy to help you with the process.)

Thank you,
Joel

---

From: <[email-masked]>
Date: Thu, 4 Nov 2021 15:54:50 +0000

Dear all,
I have quickly checked and reviewed the document and think it is well written and quite completely describes the requirements and exemplary OAM messages for SFC. My only comment would be for sect. 6.3.1.:

Length is a two-octets-long field, and the value equals the length of the Value field in octets. => Length is a two-octets-long field, and the value equals the length of the data following the Length field counted in octets. 
[As in sect. 6.6.3 as there is no 'Value field' defined for Source TLV!]

Also, I wonder whether in sect. 6.4.1. one should add a Figure describing the format of the 'sub-TLVs' - similar as to Fig. 10 for 'SF Information Sub-TLV' ?

Thanks!
Best regards
Dir[k
-----Original Message-----
From: sfc <[email-masked]> On Behalf Of Joel Halpern Direct
Sent: Montag, 1. November 2021 19:51
To: [email-masked]
Cc: James Guichard <[email-masked]>; Greg Mirsky <[email-masked]>
Subject: [sfc] Regarding last call for draft-ietf-sfc-multi-layer-oam

I have received a polite request with explanation for delay asking for more time to read and review the subject document.  Given the state of the working group, i want to encourage any and all review.  So I am extending the last call by two additional weeks.

Please read and review the document.
Also, if you are willing to serve as shepherd for this, please let the chairs know.  (Don't worry if you have not shepherded a document before. 
  The chairs are more than happy to help you with the process.)

Thank you,
Joel

_______________________________________________
sfc mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sfc

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 4 Nov 2021 10:11:02 -0700

Hi Dirk,
thank you so much for the review and your suggestions. All are very helpful
and are accepted with much appreciation. (I've noticed misalignment in
Figure 10 when I followed your comment).
I've added a figure in Section 6.4.1 illustrating the sub-TLV encoding of
the errored TLV.
Attached, please find the new working version and the diff highlighting the
changes (most are resulting from the added figure). I hope that the updates
address your comments.

Best regards,
Greg

On Thu, Nov 4, 2021 at 8:54 AM <[email-masked]> wrote:

> Dear all,
> I have quickly checked and reviewed the document and think it is well
> written and quite completely describes the requirements and exemplary OAM
> messages for SFC. My only comment would be for sect. 6.3.1.:
>
> Length is a two-octets-long field, and the value equals the length of the
> Value field in octets. => Length is a two-octets-long field, and the value
> equals the length of the data following the Length field counted in octets.
> Also, I wonder whether in sect. 6.4.1. one should add a Figure describing
> the format of the 'sub-TLVs' - similar as to Fig. 10 for 'SF Information
> Sub-TLV' ?
>
> Thanks!
> Best regards
> Dir[k
> more time to read and review the subject document.  Given the state of the
> working group, i want to encourage any and all review.  So I am extending
> the last call by two additional weeks.
>

---

From: Donald Eastlake <[email-masked]>
Date: Fri, 5 Nov 2021 01:38:05 -0400

I support publication of this draft. However, I have a few
suggestions/questions below. I also have a bunch of other suggestions,
mostly editorial, in the attached.

Section 6: I found the following text and nearby material confusing:
   "TLV is a variable-length field.  Multiple TLVs MAY be placed in an
   SFC Echo Request/Reply packet.  Additional TLVs may be enclosed
   within a given TLV, subject to the semantics of the (outer) TLV in
   question.  If more than one TLV is to be included, the value of the
   Type field of the outmost outer TLV MUST be set to "Multiple TLVs
   Used" (TBA12), ..."
Starting at the beginning, The field I think that is being referred to
is labeled "TLVs", not "TLV".
Then it says "Multiple TLVs MAY be placed in an SFC Echo Request/Reply
packet." which sounds fine. The usual thing when TLVs are allowed is
to allow multiple of them in sequence. But then there is the later
text that seems to imply that if there is more than on TLV, there has
to be a single(?) top level "Multiple TLVs" type TLV that encloses
all(?) the others (presumably in its Value field). Why? Is the nesting
only one level? (Also, "outmost" should be "outermost".)

I also think that Figure 4 should be moved down a little. The "TLV"
(should be "TLVs"?) field described right after Figure 4 is actually
from Figure 3, I think. Maybe you could take the paragraph after
Figure 4, split it just before the last sentence in that paragraph,
put Figure 4 there, and adjust wording appropriately.

Section 6.4: What exactly is "NSH Service Index (SI) expiration" and
how is this different from being the terminal SFF of an SFP?

Section 6.4.1: TLVs inside the "Errored TLVs" TLV are here called
"sub-TLVs" but when nested TLVs were being talked about earlier,
"sub-TLVs" was not used

Section 6.5.2: I notice that this section has numeric values for many
Return Codes. Since these are in a new Registry being set up by this
document, I think that is the way to go and recommend putting all
values being initially assigned in new Registries numerically in the
new Registry tables in the IANA Considerations Section.

Sections 6.6 / 6.6.1: It is a bit confusing that this talks about
using these CVReq and CVRep messages before they have been specified.
I suggest putting a pointer to 6.6.1 early in 6.6 or swapping 6.6 and
6.6.1.

Section 6.6.2: It is very confusing to have "SFF Information Record
TLV" and "SF Information Record TLV" with such similar names. Suggest
that the SF Information Record always be called a Sub-TLV as it is in
the Figure. Suggest making it clear that the SF Information Record
Sub-TLV only appears inside the SFF Information Record, not directly
at the top level in the CVRep.
   In the first sentence after Figure 9, should that be "SFFs" or "SFs"?
   Why does the 2nd sentence after Figure 9 say "Figure 9 presents the
format of an SFC Echo Request/ Reply TLV, ..." when the  caption of
Figure 9 and Figure 9 itself make it appear to be an "SFF Information
Record TLV"?

Section 6.6.3: I don't understand the first sentence of this section.
   The "SF Type" field explanation should probably reference the IANA registry.
   How is "SF Identifiers" formatted if it is a list of identifiers?

Section 9: I wouldn't bother to set up either of the Version
Registries (9.2.1, 9.3.1) in this document. Seems unlikely that a new
version will be specified anytime soon, if ever. But if you do keep
the Version Registries, since there are only 4 values available, I
would make assignment be based on Standards Action.

Section 9: When a document is the first to set up a Registry and
assign values in that Registry, you should just go ahead and make
these initial assignments. There is no reason to make more work for
IANA and the RFC Editor in this case by setting up a table with no
assignments and then separately asking for the assignments. So you can
get rid of a bunch of TBAs.

Section 9.2.2, Table 4: Only the first and last entries should be
Reserved. The others should be Unassigned. But also, the "request" to
IANA verbiage should be dropped and the assigned value in Table 5 just
put into Table 4. You are creating the registry, you can set the
initial assignments as desired and approved by the normal document
approval path. IANA normally has nothing to do with the initial
assignment decisions for a registry. All values in the Reference
column should be '[this document]". See attached markup including
multiple other cases that should have similar treatment.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [email-masked]

---

From: <[email-masked]>
Date: Mon, 8 Nov 2021 11:14:14 +0800 (CST)

Dear Chair and SFCers，

I support the publication of this draft.

Thank you,

Yuehua Wei

原始邮件

发件人：JoelHalpernDirect
收件人：[email-masked];
抄送人：James Guichard;Greg Mirsky;
日 期 ：2021年11月02日 02:51
主 题 ：[sfc] Regarding last call for draft-ietf-sfc-multi-layer-oam

 
Thank you,
Joel

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 10 Nov 2021 06:47:12 -0800

Hi Donald,
many thanks for your detailed review and thoughtful suggestions. Your help
in improving this document is much appreciated. Please find my responses
in-lined below under the GIM>> tag.
Attached, please find the copy of the new working version of the draft and
its diff to -16.

Regards,
Greg

> is labeled "TLVs", not "TLV".
GIM>> Thank you for pointing this out. I think that the intention was to
refer to the Value field. Then the text will read like this:
"TLV is a variable-length construct."
Would it be better?

> only one level? (Also, "outmost" should be "outermost".)
GIM>> Great point, thanks. I think that this construct was put in "in-case"
and never used. We have a close case, Errored TLVs TLV, but nothing that
uses Multiple TLVs type. I propose the following update:
OLD TEXT:
   Multiple TLVs MAY be placed in an
   SFC Echo Request/Reply packet.  Additional TLVs may be enclosed
   within a given TLV, subject to the semantics of the (outer) TLV in
   question.  If more than one TLV is to be included, the value of the
   Type field of the outmost outer TLV MUST be set to "Multiple TLVs
   Used" (TBA12), as assigned by IANA according to Section 9.4.
NEW TEXT:
   Multiple TLVs MAY be placed in an
   SFC Echo Request/Reply packet. None, one or more sub-TLVs may be enclosed
   in a TLV, subject to the semantics of the (outer) TLV.

And I remove the Multiple TLVs type from the IANA section. What do you
think about these updates?

> put Figure 4 there, and adjust wording appropriately.
GIM>> I've moved Figure 4, please let me know if it is better connected to
the text. I think that the name Value reflects is the part of the TLV
format and would like not to change it. Would that be acceptable?

> how is this different from being the terminal SFF of an SFP?
GIM>> I normal operation, I agree, these SI == 0 should not happen. But as
TTL, SI is a loop-prevention mechanism for SFs. And, as TTL expiration, SI
expiration can be used as OAM exception mechanism based on the last
sentence in Section 2.3 RFC 8300:
   In addition, an SFF that is not the
   terminal SFF for an SFP will discard any NSH packet with an SI of 0,
   as there will be no valid next SF information.

> "sub-TLVs" but when nested TLVs were being talked about earlier,
GIM>> Yes, thank you for pointing out this inconsistency in terminology. As
proposed above, the updated text now is as follows:
   TLV is a variable-length consruct.  Multiple TLVs MAY be placed in an
   SFC Echo Request/Reply packet.  None, one or more sub-TLVs may be
   enclosed in a TLV, subject to the semantics of the (outer) TLV.

> new Registry tables in the IANA Considerations Section.
GIM>> Agreed. Please check the updated IANA Considerations section.

> I suggest putting a pointer to 6.6.1 early in 6.6 or swapping 6.6 and
GIM>> I've put the forward reference to Section 6.6.1. Please let me know
if it addresses your concern.

> at the top level in the CVRep.
GIM>> Agree and updated. Please let me know if it reads more logical.

GIM>> Good catch. Fixed by s/all SFFs mapped to the particular SFF
instance/all SFs mapped to the particular SFF instance/

> Figure 9 and Figure 9 itself make it appear to be an "SFF Information
GIM>> Sorry for this cut-n-paste error and thank you for another good
catch. Fixed.

>    The "SF Type" field explanation should probably reference the IANA
GIM>> Agreed and added.

>    How is "SF Identifiers" formatted if it is a list of identifiers?
GIM>> Should be singular. Also, removed the reference to a list of SFs.
Each SF mapped to the SFF must be listed in the separate SF Information
sub-TLV.

> would make assignment be based on Standards Action.
GIM>> Makes sense to remove both.

> get rid of a bunch of TBAs.
GIM>> Agreed, please check the updated version.

> multiple other cases that should have similar treatment.
GIM>> Thank you for the suggestion. Accepted.

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Sun, 14 Nov 2021 07:50:07 +0000

Hello, WG,

In reviewing draft-ietf-sfc-multi-layer-oam-16, I find that the issues listed below are such that I cannot support publication.

Observing what appears to be a single non-author response to the original WGLC email, and one more after this extension, I also perceive the energy level to work on this to be low.

Please find some review comments and observations, I hope these are useful:

                Active OAM for Service Function Chaining
                   draft-ietf-sfc-multi-layer-oam-16

Abstract

   A set of requirements for active Operation, Administration, and
   Maintenance (OAM) of Service Function Chains (SFCs) in a network is
   presented in this document.  Based on these requirements, an
   encapsulation of active OAM messages in SFC and a mechanism to detect
   and localize defects are described.

First, a generic comment on the whole document: Even though the WG produces an SFC OAM framework in rfc8924, I cannot find exactly how draft-ietf-sfc-multi-layer-oam follows or maps to such framework.

  *   rfc8924 lists requirements in S4, but this document mentions them in passing. Instead, as per the Abstract above, this document creates new requirements and based on them creates a new OAM protocol.
  *   rfc8924 lists candidate SFC OAM tools, but this document does not consider them. Or compare requirements to options. Perhaps I could be pointed to the discussion on the list?

Additionally, I wonder: Why the file name “sfc-multi-layer-oam”?

   Active OAM tools,
   conformant to the requirements listed in Section 3, improve, for
   example, troubleshooting efficiency and defect localization in SFP
   because they specifically address the architectural principles of
   NSH.  For that purpose, SFC Echo Request and Echo Reply are specified
   in Section 6.

I do not fully follow these cause-consequence pair of sentences. They seem to be foundational to the rational of the document, is this why a new OAM protocol is used?

Specifically, I feel this document over-reaches in that it presumes that the only “Active OAM” protocol for NSH SFCs is this new protocol, whereas some of the existing protocols listed in rfc8924 are also “Active OAM”.

   This mechanism enables on-demand Continuity Check,
   Connectivity Verification, among other operations over SFC in
   networks, addresses functionalities discussed in Sections 4.1, 4.2,
   and 4.3 of [RFC8924].

This could be well the case — however many others (including existing) mechanisms also enable in these broad terms all the connectivity+continuity+trace functions.
At the same time, this mechanisms is very complex.
I would like to see a study of comparative benefits of this added complexity vis-a-vis existing approaches that can be extended.

   The ingress may be
   capable of recovering from the failure, e.g., using redundant SFC
   elements.  Thus, it is beneficial for the egress to signal the new
   defect state to the ingress, which in this example is the Classifier.
   Hence the following requirement:

      REQ#3: SFC OAM MUST support Remote Defect Indication notification
      by the egress to the ingress.

I see a gap between “it is beneficial” and “MUST”. What is "Remote Defect Indication” in the context of SFC OAM since it is not in the OAM framework? Is this "Remote Defect Indication” the only way to achieve the rerouting or redundancy triggering?

4.  Active OAM Identification in the NSH

   The O bit in the NSH is defined in [RFC8300] as follows:

      O bit: Setting this bit indicates an OAM packet.

   This document updates that definition as follows:

      O bit: Setting this bit indicates an OAM command and/or data in
      the NSH Context Header or packet payload.

   Active SFC OAM is defined as a combination of OAM commands and/or
   data included in a message that immediately follows the NSH.  To
   identify the active OAM message, the "Next Protocol" field MUST be
   set to Active SFC OAM (TBA1) (Section 9.1).

This is an example of over-reach. A “Next Protocol” pointing to IPv4, in turn pointing to ICMP, in turn pointing to Echo is already one example of “Active SFC OAM”. I wonder if this new protocol might be best served by choosing a name that is not so generic? It could be called “One of many active SFC OAM protocols” :-)

Otherwise, the “MUST” in the last sentence seems to not follow.

   The rules for
   interpreting the values of the O bit and the "Next Protocol" field
   are as follows:

I am extremely concerned about this attempted re-definition (of the O-bit and Protocol fields). On several fronts as explained below. During RFC8300 the WG evaluated these and provided a solution already.

   *  O bit set and the "Next Protocol" value does not match one of
      identifying active or hybrid OAM protocols (per classification
      defined in [RFC7799]), e.g., defined in Section 9.1 Active SFC OAM
      (TBA1).

This potentially breaks the concept of nodes not understanding OAM (i.e,. Partial deployment of a new protocol)

         - a Fixed-Length Context Header or Variable-Length Context
         Header(s) contain an OAM command or data.

         - the "Next Protocol" field determines the type of payload.

The semantic of Context Headers is outside this definition. For example the types in MD Type 2 define the variable headers.

This potentially breaks also OAM, since things like ECMP can be encoded in context headers that the OAM needs. (e.g., "Flow ID” from draft-ietf-sfc-nsh-tlv).

Further, is this describing a Hybrid OAM use?

   *  O bit set and the "Next Protocol" value matches one of identifying
      active or hybrid OAM protocols:

         - the payload that immediately follows the NSH MUST contain an
         OAM command or data.

This is also unclear — what is an OAM command or data? If the O-bit is set, it is an OAM packet.

   *  O bit is clear:

         - no OAM in a Fixed-Length Context Header or Variable-Length
         Context Header(s).

         - the payload determined by the "Next Protocol" field MUST be
         present.

It is unclear the rational for this.

   *  O bit is clear, and the "Next Protocol" field identifies active or
      hybrid OAM protocol MUST be identified and reported as an
      erroneous combination.  An implementation MAY have control to
      enable processing of the OAM payload.

This seems to break the existing usage in draft-ietf-sfc-ioam-nsh. Section 4.2 of draft-ietf-sfc-ioam-nsh says clearly:

4.2.  IOAM and the use of the NSH O-bit

   [RFC8300] defines an "O bit" for OAM packets.  Per [RFC8300] the O
   bit must be set for OAM packets and must not be set for non-OAM
   packets.  Packets with IOAM data included MUST follow this
   definition, i.e. the O bit MUST NOT be set for regular customer
   traffic which also carries IOAM data and the O bit MUST be set for
   OAM packets which carry only IOAM data without any regular data
   payload.

5.  Active SFC OAM Header

   As demonstrated in Section 4 [RFC8924] and Section 3 of this
   document, SFC OAM is required to perform multiple tasks.  Several
   active OAM protocols could be used to address all the requirements.
   When IP/UDP encapsulation of an SFC OAM control message is used,
   protocols can be demultiplexed using the destination UDP port number.
   But extra IP/UDP headers, especially in an IPv6 network, add
   noticeable overhead.  This document defines Active OAM Header
   (Figure 2) to demultiplex active OAM protocols on an SFC.

Does this paragraph imply that the main reason for this protocol is this perceived overhead? If so, experience seems to show that in practice IP-encaped OAM works fine (as e.g., for LSP Ping).

Alternatively, “Next Protocols” could be defined for “raw” existing protocols.

      Msg Type - six bits long field identifies OAM protocol, e.g., Echo
      Request/Reply or Bidirectional Forwarding Detection.

Why does BFD get encapsulated in this new protocol, as opposed to using a “Next Protocol” for it? That looks like unnecessary overhead and indirection.

      Flags - eight bits long field carries bit flags that define
      optional capability and thus processing of the SFC active OAM
      control packet, e.g., optional timestamping.

Does this timestamp conflict with context header timestamps? E.g., rfc8592 or draft-mymb-sfc-nsh-allocation-timestamp.

6.  Echo Request/Echo Reply for SFC

   Echo Request/Reply is a well-known active OAM mechanism extensively
   used to verify a path's continuity, detect inconsistencies between a
   state in control and the data planes, and localize defects in the
   data plane.  ICMP ([RFC0792] for IPv4 and [RFC4443] for IPv6
   networks, respectively) and [RFC8029] are examples of broadly used
   active OAM protocols based on the Echo Request/Reply principle.  The
   SFC Echo Request/Reply defined in this document addresses several
   requirements listed in Section 3.  Specifically, it can be used to
   check the continuity of an SFP, trace an SFP, or localize the failure
   within an SFP.  The SFC Echo Request/Reply control message format is
   presented in Figure 3.

This seems to be an important paragraph — would be useful to also understand how other existing and broadly used protocols cannot fulfill requirements.

      Length - two-octet-long field equal to the Value field's length in
      octets.

There are several nested lengths defined in this document — would be useful to analyze that they do not result in issues such as piggybacking unaccounted data.

6.3.1.  Source TLV

   Responder to the SFC Echo Request encapsulates the SFC Echo Reply
   message in IP/UDP packet if the Reply mode is "Reply via an IPv4/IPv6
   UDP Packet".  Because the NSH does not identify the ingress node that
   generated the Echo Request, the source ID MUST be included in the
   message and used as the IP destination address and destination UDP
   port number of the SFC Echo Reply.  The sender of the SFC Echo
   Request MUST include an SFC Source TLV (Figure 5).

This seems to negate the benefit of less overhead, if the IP/UDP fields are embedded as OAM TLVs.

This also seems to be a bit of an invitation for an attack.

6.4.1.  Errored TLVs TLV

I wonder at this point if it is easier to use LSP Ping directly instead of re-define it.

6.5.1.  SFC Reply Path TLV

…

   *  Service Index: the value for the Service Index field in the NSH of
      the SFC Echo Reply message.

How is the service index in a reply constructed?

6.5.3.  SFC Echo Reply Reception

   An SFF SHOULD NOT accept SFC Echo Reply unless the received message
   passes the following checks:

   *  the received SFC Echo Reply is well-formed;

   *  it has an outstanding SFC Echo Request sent from the UDP port that
      matches destination UDP port number of the received packet;

Is the demultiplexing based on UDP, OAM handle, or combination?

6.6.  Verification of the SFP Consistency

   *  Collect information of the traversed by the CVReq packet SFs and
      send it to the ingress SFF as CVRep packet over IP network;

What if NSH is not over IP?

   SF Type: Two octets long field.  It is defined in [RFC9015] and
   indicates the type of SF, e.g., Firewall, Deep Packet Inspection, WAN
   optimization controller, etc.

Is RFC 9015 a hard dependency to implement this OAM?

   IANA is requested to assign a new type from the SFC Active OAM
   Message Type sub-registry as follows:

          +=======+=============================+===============+
          | Value |         Description         | Reference     |
          +=======+=============================+===============+
          | TBA2  | SFC Echo Request/Echo Reply | This document |
          +-------+-----------------------------+---------------+

Is there a single value for both Request and Reply?

9.2.1.  Version in the Active SFC OAM Header

9.3.1.  SFC Echo Request/Reply Version

There seems to be a version for the OAM and a version for the msg type. Is this correct? Are they hierarchical versions? Or independent?
This seems to overly complicate parsing and compliance.

9.3.3.  SFC Echo Request/Echo Reply Message Types

Does this mean that there’s a protocol number for “Active OAM” with a protocol number for “Request/Reply” with a protocol number for either request or reply?

   Values defined for the Return Codes sub-registry are listed in
   Table 14.

Various values in this table are not defined in the document. The procedures seem lacking.

9.7.  SF Identifier Types

This document seems to be creating a space for identifying SFs — which I thought was mostly outside the scope of OAM to test SFs.

Does this further imply that there’s a new requirement to have unique identifiers within the domain for all SFs?

I hope these comments and review questions and concerns are useful for the WG discussion and consideration.

Thanks,

Carlos.

Nov 1, 2021 2:50 PM、Joel Halpern Direct <[email-masked]<mailto:[email-masked]>>のメール:

Please read and review the document.
Also, if you are willing to serve as shepherd for this, please let the chairs know.  (Don't worry if you have not shepherded a document before.  The chairs are more than happy to help you with the process.)

Thank you,
Joel

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

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 19 Nov 2021 16:11:05 -0800

Dear Carlos,
thank you for your thorough review and detailed comments. Please find
responses in-lined below under the GIM>> tag.

Regards,
Greg (on behalf of the authors)

On Sat, Nov 13, 2021 at 11:50 PM Carlos Pignataro (cpignata) <
[email-masked]> wrote:

> Hello, WG,
>
> In reviewing draft-ietf-sfc-multi-layer-oam-16, I find that the issues
> listed below are such that I cannot support publication.
>
> Observing what appears to be a single non-author response to the original
> WGLC email, and one more after this extension, I also perceive the energy
> level to work on this to be low.
>
> First, a generic comment on the whole document: Even though the WG
> produces an SFC OAM framework in rfc8924, I cannot find exactly how
> draft-ietf-sfc-multi-layer-oam follows or maps to such framework.
>
>    - rfc8924 lists requirements in S4, but this document mentions them in
>    passing. Instead, as per the Abstract above, this document creates new
>    requirements and based on them creates a new OAM protocol.
>
> GIM>> We've followed the requirements listed in RFC 8924 and used them
when designing SFC Echo Request/Reply. SFC Echo Request/Reply addresses the
essential requirements in Section 4 of RFC 8924.

>
>    - rfc8924 lists candidate SFC OAM tools, but this document does not
>    consider them. Or compare requirements to options. Perhaps I could be
>    pointed to the discussion on the list?
>
> GIM>> RFC 8924 already provides the analysis and pointed out gaps in
listed protocols. RFC 8924 has concluded that none of the available tools
complies with the requirements.

> Additionally, I wonder: Why the file name “sfc-multi-layer-oam”?
GIM>> It is historical.

> I do not fully follow these cause-consequence pair of sentences. They seem
> to be foundational to the rational of the document, is this why a new OAM
> protocol is used?
>
GIM>> Indeed. Based on the analysis in RFC 8924, we've learned that none of
the available OAM tools can address the requirements for active SFP OAM.
The SFC Echo Request/Reply is specifically designed to address these
requirements.

>
> Specifically, I feel this document over-reaches in that it presumes that
> the only “Active OAM” protocol for NSH SFCs is this new protocol, whereas
> some of the existing protocols listed in rfc8924 are also “Active OAM”.
>
GIM>> I think that the document is positioned not as a general active OAM
protocol but as one of the active SFC NSH OAM protocols.

> This could be well the case — however many others (including existing)
> mechanisms also enable in these broad terms all the
> connectivity+continuity+trace functions.
>
GIM>> We are not questioning that there are other solutions. But these
mechanisms are not supported by specifications that ensure independent
interoperable implementations.

> I would like to see a study of comparative benefits of this added
> complexity vis-a-vis existing approaches that can be extended.
>
GIM>> In the face of absence of sufficient and up to date documentation
describing proprietary solutions, I don't see that any comparison can be
comprehensive.

> I see a gap between “it is beneficial” and “MUST”. What is "Remote Defect
> Indication” in the context of SFC OAM since it is not in the OAM framework?
> Is this "Remote Defect Indication” the only way to achieve the rerouting or
> redundancy triggering?
>
GIM>> That is one of possible solutions. Other mechanisms may conform to
the requirement using different approach.

> This is an example of over-reach. A “Next Protocol” pointing to IPv4, in
> turn pointing to ICMP, in turn pointing to Echo is already one example of
> “Active SFC OAM”. I wonder if this new protocol might be best served by
> choosing a name that is not so generic? It could be called “One of many
> active SFC OAM protocols” :-)
>
GIM>> Will clarify that throughout the document "active OAM" and "active
SFC OAM" refers to specially constructed packets that immediately follow
the SFC Active OAM Header (Figure 2).

> I am extremely concerned about this attempted re-definition (of the O-bit
> and Protocol fields). On several fronts as explained below. During RFC8300
> the WG evaluated these and provided a solution already.
>
GIM>> Can you clarify what do you mean by "nodes not understanding OAM"?
Partial deployment is, in my opinion, an operational issue. An operator
plans deployments of new releases according to new features and their
intended use.

> The semantic of Context Headers is outside this definition. For example
> the types in MD Type 2 define the variable headers.
>
> This potentially breaks also OAM, since things like ECMP can be encoded in
> context headers that the OAM needs. (e.g., "Flow ID”
> from draft-ietf-sfc-nsh-tlv).
>
GIM>> As I understand it, MD Type 2 Flow ID TLV is recommended to identify
a flow in SFC NSH. The document makes the use of this method.

> Further, is this describing a Hybrid OAM use?
GIM>> No, the document does not describe the use of hybrid OAM (per RFC
7799).

> set, it is an OAM packet.
GIM>> What is an OAM packet? Is an SFC NSH packet with IOAM an OAM packet
or not? If an SFC NSH packet is part of flow under the Alternate Marking,
is it an OAM packet because the Alternate Marking method is an example of
the hybrid OAM?

> It is unclear the rational for this.
GIM>> Can you please clarify your interpretation, so we can look for ways
to improve the text?

> This seems to break the existing usage in draft-ietf-sfc-ioam-nsh. Section
> 4.2 of draft-ietf-sfc-ioam-nsh says clearly:
>
GIM>> I don't see any problem. In fact, both definitions are in sync.
According to draft-ietf-sfc-ioam-nsh if the Next Protocol field identifies
a use data payload, e.g., IPv6, then O bit MUST NOT be set. If the Next
Protocol is set to IOAM, then the O-bit MUST be set. We agree in how O-bit
works in presence of IOAM that accompanies user data and without it.

> Does this paragraph imply that the main reason for this protocol is this
> perceived overhead? If so, experience seems to show that in practice
> IP-encaped OAM works fine (as e.g., for LSP Ping).
>
GIM>> Isn't IP/UDP encapsulation, and IPv6 in particular, is a larger
overhead?

> Why does BFD get encapsulated in this new protocol, as opposed to using a
> “Next Protocol” for it? That looks like unnecessary overhead and
> indirection.
>
GIM>> Are you proposing assigning different Next Protocol values for every
possible active OAM protocol?

> Does this timestamp conflict with context header timestamps? E.g., rfc8592
> or draft-mymb-sfc-nsh-allocation-timestamp.
>
GIM>> What do you see as a potential conflict?

> This seems to be an important paragraph — would be useful to also
> understand how other existing and broadly used protocols cannot fulfill
> requirements.
>
GIM>> RFC 8924 already provided a comprehensive analysis and concluded that
none of the available tools can fully conform to the requirements listed in
Section 4.

> There are several nested lengths defined in this document — would be
> useful to analyze that they do not result in issues such as piggybacking
> unaccounted data.
>
GIM>> Do you see any scenario when that might be the case?

> are embedded as OAM TLVs.
GIM>> Only the Source ID is required, not the whole set of IP and UDP
headers.

> I wonder at this point if it is easier to use LSP Ping directly instead of
GIM>> If someone wants to explore that option, of course.

> How is the service index in a reply constructed?
GIM>> It is provided by the sender of the SFC Echo Request.

> Is the demultiplexing based on UDP, OAM handle, or combination?
GIM>> The values of the Sender's Handle and  Sequence Number fields can be
used.

> What if NSH is not over IP?
GIM>> Then the operator will specify another method using the Reply mode.

> Is RFC 9015 a hard dependency to implement this OAM?
GIM>> RFC 9015 established the IANA registry of SF Type and any new SF
types must be registered.

>    Message Type sub-registry as follows:
GIM>> Yes, it is a single value. Echo Request and Echo Reply are identified
in the Message Type field (Figure 3).

> There seems to be a version for the OAM and a version for the msg type. Is
> this correct? Are they hierarchical versions? Or independent?
GIM>> All versions are independent.

> Does this mean that there’s a protocol number for “Active OAM” with a
> protocol number for “Request/Reply” with a protocol number for either
> request or reply?
>
GIM>> These are not all protocol numbers. Only the Active OAM is a new
protocol number. Others are message types.

> Various values in this table are not defined in the document. The
GIM>> Other specifications may define additional code points in the
registry.

>
> 9.7.  SF Identifier Types
>
> This document seems to be creating a space for identifying SFs — which I
> thought was mostly outside the scope of OAM to test SFs.
>
GIM>> The registry is of SF Identifiers, not of SF Types (that already
exists). Hope that clarifies the issue.

>
> Does this further imply that there’s a new requirement to have unique
> identifiers within the domain for all SFs?
>
> Nov 1, 2021 2:50 PM、Joel Halpern Direct <[email-masked]>のメール:
>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Sat, 20 Nov 2021 01:33:27 +0000

Dear Greg,

Thank you for replying to my email. Please find a couple follow-ups inline, as I invite other WG interested parties to the discussion.

11/19/21 午後7:11、Greg Mirsky <[email-masked]<mailto:[email-masked]>>のメール:

Dear Carlos,
thank you for your thorough review and detailed comments. Please find responses in-lined below under the GIM>> tag.

Regards,

On Sat, Nov 13, 2021 at 11:50 PM Carlos Pignataro (cpignata) <[email-masked]<mailto:[email-masked]>> wrote:
Hello, WG,

Abstract

GIM>> We've followed the requirements listed in RFC 8924 and used them when designing SFC Echo Request/Reply. SFC Echo Request/Reply addresses the essential requirements in Section 4 of RFC 8924.

CMP: That’s an issue, those are not requirements for a new protocol. Neither for a single protocol to perform all functions.

CMP: Specifically, RFC 8924 says:

CMP:   “7.  Candidate SFC OAM Tools”

CMP: Why were candidates descarted? When it is shown how they can address some of the functions.

GIM>> RFC 8924 already provides the analysis and pointed out gaps in listed protocols. RFC 8924 has concluded that none of the available tools complies with the requirements.

CMP: I do not see that conclusion in RFC 8924, perhaps you can quote / copy/paste the relevant text. The specific text that includes a conclusion. And specific text that says that none of the tools comply with the requirements.

CMP: In any case, there is also no implication that creating a new protocol for all requirements and ignoring the analysis of existing protocols that can be used or extended is in the best interest of SFC’s OAM.

CMP: Additionally, I did not see the discussion on the list of this comparison (since it does not exist in the draft).

   Active OAM tools,

I do not fully follow these cause-consequence pair of sentences. They seem to be foundational to the rational of the document, is this why a new OAM protocol is used?
GIM>> Indeed. Based on the analysis in RFC 8924, we've learned that none of the available OAM tools can address the requirements for active SFP OAM. The SFC Echo Request/Reply is specifically designed to address these requirements.

CMP: This is a very useful response. As I responded above, there’s no implication that if no existing tools address all requirements, the path is to create a brand new one ignoring the existing ones.

Specifically, I feel this document over-reaches in that it presumes that the only “Active OAM” protocol for NSH SFCs is this new protocol, whereas some of the existing protocols listed in rfc8924 are also “Active OAM”.
GIM>> I think that the document is positioned not as a general active OAM protocol but as one of the active SFC NSH OAM protocols.

This could be well the case — however many others (including existing) mechanisms also enable in these broad terms all the connectivity+continuity+trace functions.
GIM>> We are not questioning that there are other solutions. But these mechanisms are not supported by specifications that ensure independent interoperable implementations.

CMP: Can you please point to independent interoperable implementations of draft-ietf-sfc-multi-layer-oam?

CMP: Part of my point is that any partial solution can be extended interoperably.

At the same time, this mechanisms is very complex.
I would like to see a study of comparative benefits of this added complexity vis-a-vis existing approaches that can be extended.
GIM>> In the face of absence of sufficient and up to date documentation describing proprietary solutions, I don't see that any comparison can be comprehensive.

CMP: I am not sure if you are answering a different question, but there’s no reference to any proprietary solutions.

CMP: ICMP, BFD, iOAM, SFC-Tracceroute, all documented in I-Ds and with open source implementations.

   The ingress may be

I see a gap between “it is beneficial” and “MUST”. What is "Remote Defect Indication” in the context of SFC OAM since it is not in the OAM framework? Is this "Remote Defect Indication” the only way to achieve the rerouting or redundancy triggering?
GIM>> That is one of possible solutions. Other mechanisms may conform to the requirement using different approach.

This is an example of over-reach. A “Next Protocol” pointing to IPv4, in turn pointing to ICMP, in turn pointing to Echo is already one example of “Active SFC OAM”. I wonder if this new protocol might be best served by choosing a name that is not so generic? It could be called “One of many active SFC OAM protocols” :-)
GIM>> Will clarify that throughout the document "active OAM" and "active SFC OAM" refers to specially constructed packets that immediately follow the SFC Active OAM Header (Figure 2).

CMP: The “SFC Active OAM Header” is therefore not part of the “active SFC OAM” packet?

   The rules for

This potentially breaks the concept of nodes not understanding OAM (i.e,. Partial deployment of a new protocol)
GIM>> Can you clarify what do you mean by "nodes not understanding OAM"? Partial deployment is, in my opinion, an operational issue. An operator plans deployments of new releases according to new features and their intended use.

CMP: Apologies, I meant not s/understanding/parsing/.

CMP: I agree it is an operational issue — an issue of operations. Like the “O” in “OAM”. Should Operational Considerations be included as well?

This potentially breaks also OAM, since things like ECMP can be encoded in context headers that the OAM needs. (e.g., "Flow ID” from draft-ietf-sfc-nsh-tlv).
GIM>> As I understand it, MD Type 2 Flow ID TLV is recommended to identify a flow in SFC NSH. The document makes the use of this method.

CMP: How?

Further, is this describing a Hybrid OAM use?
GIM>> No, the document does not describe the use of hybrid OAM (per RFC 7799).

This is also unclear — what is an OAM command or data? If the O-bit is set, it is an OAM packet.
GIM>> What is an OAM packet? Is an SFC NSH packet with IOAM an OAM packet or not? If an SFC NSH packet is part of flow under the Alternate Marking, is it an OAM packet because the Alternate Marking method is an example of the hybrid OAM?

CMP: This reads like not answering by asking questions.

CMP: A user packet with marking, implicitly or explicitly, is not an OAM packet.

   *  O bit is clear:

It is unclear the rational for this.
GIM>> Can you please clarify your interpretation, so we can look for ways to improve the text?

CMP: Same as above. It is unclear why these rules. It is not a matter of interpretation.

This seems to break the existing usage in draft-ietf-sfc-ioam-nsh. Section 4.2 of draft-ietf-sfc-ioam-nsh says clearly:
GIM>> I don't see any problem. In fact, both definitions are in sync. According to draft-ietf-sfc-ioam-nsh if the Next Protocol field identifies a use data payload, e.g., IPv6, then O bit MUST NOT be set. If the Next Protocol is set to IOAM, then the O-bit MUST be set.

CMP: Sorry, but you do not seem to be actually reading draft-ietf-sfc-ioam-nsh. Please refer to:

CMP: https://datatracker.ietf.org/doc/html/draft-ietf-sfc-ioam-nsh#section-4.2

CMP: 4.2.  IOAM and the use of the NSH O-bit

CMP: Please note the “MUST NOT” in the paragraph immediately above.

We agree in how O-bit works in presence of IOAM that accompanies user data and without it.

CMP: I do not see that agreement.

5.  Active SFC OAM Header

Does this paragraph imply that the main reason for this protocol is this perceived overhead? If so, experience seems to show that in practice IP-encaped OAM works fine (as e.g., for LSP Ping).
GIM>> Isn't IP/UDP encapsulation, and IPv6 in particular, is a larger overhead?

CMP: I am sorry Greg to call this out, but you are choosing again to not answer the question and instead ask another one.

CMP: I am happy to answer: it is larger. It also does not matter. And further it is proven to work in LSP Ping.

CMP: My question again: is the whole purpose of this new protocol to be overhead efficient? I am sure there are ways of encasulating that are more overhead-efficient than draft-ietf-sfc-multi-layer-oam.

Why does BFD get encapsulated in this new protocol, as opposed to using a “Next Protocol” for it? That looks like unnecessary overhead and indirection.
GIM>> Are you proposing assigning different Next Protocol values for every possible active OAM protocol?

CMP: I am not proposing anything. I am simply asking a question.

CMP: Two timestamps in different parts of a packet.

This seems to be an important paragraph — would be useful to also understand how other existing and broadly used protocols cannot fulfill requirements.
GIM>> RFC 8924 already provided a comprehensive analysis and concluded that none of the available tools can fully conform to the requirements listed in Section 4.

CMP: As per above, I do not see that conclusion.

CMP: And frankly even if that was the case, there’s no implication that using the existing pieces is not sufficient, or that it is not easier to extend the candidate protocols.

6.3.1.  Source TLV

This seems to negate the benefit of less overhead, if the IP/UDP fields are embedded as OAM TLVs.
GIM>> Only the Source ID is required, not the whole set of IP and UDP headers.

6.4.1.  Errored TLVs TLV

…

CMP: Does this mean it skips hops? Apologies I do not understand.

Is the demultiplexing based on UDP, OAM handle, or combination?
GIM>> The values of the Sender's Handle and  Sequence Number fields can be used.

CMP: I understand several values can be used.
CMP: Which one is actually used?
CMP: If the Handles and sequences match but not the port?

CMP: Sorry that does not answer my question. The text in question is not contextual to a specified reply mode.

Is RFC 9015 a hard dependency to implement this OAM?
GIM>> RFC 9015 established the IANA registry of SF Type and any new SF types must be registered.

Is there a single value for both Request and Reply?
GIM>> Yes, it is a single value. Echo Request and Echo Reply are identified in the Message Type field (Figure 3).

CMP: Is this document defining a full 64k space for a single value? If so it appears to be wasteful.

CMP: This seems like an operational unnecessary complexity, in keeping a matrix of supported combination of versions. If there was an Operational Considerations section, this should be included.

Does this mean that there’s a protocol number for “Active OAM” with a protocol number for “Request/Reply” with a protocol number for either request or reply?
GIM>> These are not all protocol numbers. Only the Active OAM is a new protocol number. Others are message types.

CMP: Apologies I was not clear.
CMP: The “SFC Active OAM” is actually a "SFC Next Protocol”.
CMP: My intention of using “protocol number” is in a generic way. To get to some OAM function, a node needs to recursively parse 3 TLVs. Correct? This seems overly complex.

Various values in this table are not defined in the document. The procedures seem lacking.
GIM>> Other specifications may define additional code points in the registry.

CMP: Thank you. The procedures still seem lacking.

CMP: Best,

CMP: — Carlos.

9.7.  SF Identifier Types

This document seems to be creating a space for identifying SFs — which I thought was mostly outside the scope of OAM to test SFs.
GIM>> The registry is of SF Identifiers, not of SF Types (that already exists). Hope that clarifies the issue.

Thanks,

Carlos.

Thank you,
Joel

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 19 Nov 2021 23:02:20 -0500

Dear Chairs & All

As co-author I support publication of this draft.

This specification fills a crucial gap for operators for new OAM functionality,
with an Active Multi layer OAM model, by defining extensibility with Active
OAM messages, in NSH,  to troubleshoot faults in the data plane SFC forwarding
plane, SFP E2E path in the service plane framework.

Kind Regards

Gyan
Verizon

On Fri, Nov 19, 2021 at 8:33 PM Carlos Pignataro (cpignata) <cpignata=
[email-masked]> wrote:

> Dear Greg,
>
> Thank you for replying to my email. Please find a couple follow-ups
> inline, as I invite other WG interested parties to the discussion.
>
> 11/19/21 午後7:11、Greg Mirsky <[email-masked]>のメール:
>
> Dear Carlos,
>>    - rfc8924 lists requirements in S4, but this document mentions them
>>    in passing. Instead, as per the Abstract above, this document creates new
> CMP: That’s an issue, those are not requirements for a new protocol.
> Neither for a single protocol to perform all functions.
>
> CMP: I do not see that conclusion in RFC 8924, perhaps you can quote /
> copy/paste the relevant text. The specific text that includes a conclusion.
> And specific text that says that none of the tools comply with the
> requirements.
>
> CMP: In any case, there is also no implication that creating a new
> protocol for all requirements and ignoring the analysis of existing
> protocols that can be used or extended is in the best interest of SFC’s OAM.
>
> CMP: Additionally, I did not see the discussion on the list of this
> comparison (since it does not exist in the draft).
>
>
>> I do not fully follow these cause-consequence pair of sentences. They
>> seem to be foundational to the rational of the document, is this why a new
>> OAM protocol is used?
>>
> GIM>> Indeed. Based on the analysis in RFC 8924, we've learned that none
> of the available OAM tools can address the requirements for active SFP OAM.
> CMP: This is a very useful response. As I responded above, there’s no
> implication that if no existing tools address all requirements, the path is
> to create a brand new one ignoring the existing ones.
>
>
> CMP: I am not sure if you are answering a different question, but there’s
> no reference to any proprietary solutions.
>
> CMP: I agree it is an operational issue — an issue of operations. Like
> the “O” in “OAM”. Should Operational Considerations be included as well?
>
>
>> This potentially breaks also OAM, since things like ECMP can be encoded
>> in context headers that the OAM needs. (e.g., "Flow ID”
>> This seems to break the existing usage in draft-ietf-sfc-ioam-nsh.
>> Section 4.2 of draft-ietf-sfc-ioam-nsh says clearly:
>>
> Protocol is set to IOAM, then the O-bit MUST be set.
>
>
> CMP: Sorry, but you do not seem to be actually reading
> draft-ietf-sfc-ioam-nsh. Please refer to:
>
> CMP:
> https://datatracker.ietf.org/doc/html/draft-ietf-sfc-ioam-nsh#section-4.2
>
> CMP: I am sorry Greg to call this out, but you are choosing again to not
> answer the question and instead ask another one.
>
> CMP: I am happy to answer: it is larger. It also does not matter. And
> further it is proven to work in LSP Ping.
>
> CMP: My question again: is the whole purpose of this new protocol to be
> overhead efficient? I am sure there are ways of encasulating that are more
> overhead-efficient than draft-ietf-sfc-multi-layer-oam.
>
>
>> Does this timestamp conflict with context header timestamps?
>> E.g., rfc8592 or draft-mymb-sfc-nsh-allocation-timestamp.
>>
> GIM>> RFC 8924 already provided a comprehensive analysis and concluded
> that none of the available tools can fully conform to the requirements
> listed in Section 4.
>
>
> CMP: And frankly even if that was the case, there’s no implication that
> using the existing pieces is not sufficient, or that it is not easier to
> extend the candidate protocols.
>
>
> GIM>> Yes, it is a single value. Echo Request and Echo Reply are
> identified in the Message Type field (Figure 3).
>
>
>> There seems to be a version for the OAM and a version for the msg type.
>> Is this correct? Are they hierarchical versions? Or independent?
> CMP: This seems like an operational unnecessary complexity, in keeping a
> matrix of supported combination of versions. If there was an Operational
> Considerations section, this should be included.
>
>
> CMP: My intention of using “protocol number” is in a generic way. To get
> to some OAM function, a node needs to recursively parse 3 TLVs. Correct?
> This seems overly complex.
>
>
-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 19 Nov 2021 23:27:23 -0500

Dear operators in the SFC WG

This draft is extremely beneficial for any operators deploying SFC with
 requirements for enhancements to E2E service plane troubleshooting
capabilities by the NOC.

Kind Regards

Gyan
Verizon

On Fri, Nov 19, 2021 at 11:02 PM Gyan Mishra <[email-masked]> wrote:

> with an Active Multi layer OAM model, by defining extensibility with
> Active OAM messages, in NSH,  to troubleshoot faults in the data plane SFC forwarding
>>> Observing what appears to be a single non-author response to the
>>> original WGLC email, and one more after this extension, I also perceive the
>>> energy level to work on this to be low.
>>>
>> CMP: I am not sure if you are answering a different question, but
>> there’s no reference to any proprietary solutions.
>>
>>> I see a gap between “it is beneficial” and “MUST”. What is "Remote
>>> Defect Indication” in the context of SFC OAM since it is not in the OAM
>>> framework? Is this "Remote Defect Indication” the only way to achieve the
>>> rerouting or redundancy triggering?
>>>
>>> I am extremely concerned about this attempted re-definition (of the
>>> O-bit and Protocol fields). On several fronts as explained below. During
>>> RFC8300 the WG evaluated these and provided a solution already.
>>>
>>> This potentially breaks the concept of nodes not understanding OAM
>>> (i.e,. Partial deployment of a new protocol)
>>>
>> GIM>> As I understand it, MD Type 2 Flow ID TLV is recommended to
>> identify a flow in SFC NSH. The document makes the use of this method.
>>
>>
>> CMP: How?
>>
>>
>>> Why does BFD get encapsulated in this new protocol, as opposed to using
>>> a “Next Protocol” for it? That looks like unnecessary overhead and
>>> indirection.
>>>
>>> Nov 1, 2021 2:50 PM、Joel Halpern Direct <[email-masked]
>>> >のメール:
>>>

*Gyan Mishra*

*M 301 502-1347*

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Sat, 20 Nov 2021 04:39:26 +0000

Dear Gyan,

I hope all is well!

Could I please ask three short clarifying questions, follow-ons on your statement below?

1. When you write "with an Active Multi layer OAM model”, can you please explain what exactly is “Multi layer” about this “OAM model”, and why is important? You highlight it in your top-post but I cannot find that text in the draft.

When I asked your co-author Greg Mirsky, he said:
Additionally, I wonder: Why the file name “sfc-multi-layer-oam”?
GIM>> It is historical.

2. When you write "fills a crucial gap for operators”, are you aware of interoperable implementations (which I expect is what operators need for it to be useful in an actual deployment)? Perhaps an RFC 7942 "Implementation Status” section could be added?

3. When you write “for new OAM functionality”, could you please clearly describe or explicitly enumerate the specific *new* functionality you refer to, on top of what existing OAMs provide, and how you find that crucial, specifically?

Many thanks in advance, I am just trying to understand.

Best,

Carlos.

11/19/21 午後11:02、Gyan Mishra <[email-masked]<mailto:[email-masked]>>のメール:

Dear Chairs & All

This specification fills a crucial gap for operators for new OAM functionality, with an Active Multi layer OAM model, by defining extensibility with Active OAM messages, in NSH,  to troubleshoot faults in the data plane SFC forwarding plane, SFP E2E path in the service plane framework.

Kind Regards

Gyan
Verizon

On Fri, Nov 19, 2021 at 8:33 PM Carlos Pignataro (cpignata) <cpignata=[email-masked]<mailto:[email-masked]>> wrote:
Dear Greg,

Dear Carlos,

Regards,

Abstract

   Active OAM tools,

   The ingress may be

   The rules for

CMP: How?

   *  O bit is clear:

5.  Active SFC OAM Header

6.3.1.  Source TLV

6.4.1.  Errored TLVs TLV

…

CMP: Best,

CMP: — Carlos.

9.7.  SF Identifier Types

Thanks,

Carlos.

Thank you,
Joel

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<http://www.verizon.com/>

Gyan Mishra
Network Solutions Architect
Email [email-masked]<mailto:[email-masked]>
M 301 502-1347

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 20 Nov 2021 10:36:45 -0500

Hi Carlos

Many Thanks for your feedback

Responses in-line

On Fri, Nov 19, 2021 at 11:39 PM Carlos Pignataro (cpignata) <
[email-masked]> wrote:

> 1. When you write "*with an Active Multi layer OAM model*”, can you
> please explain what exactly is “Multi layer” about this “OAM model”, and
> why is important? You highlight it in your top-post but I cannot find that
> text in the draft.
>
>> OAM has historic connotations but for good technical reasons as called
> multi layer as it provides a different job of managing different layers of
> the network thus the nomenclature “multi layer”
>

We can add some verbiage to the draft as we have the draft and file name
with “multi layer” in the name.

LIME is a concluded WG on OAM that has discuss the OAM management of the
various layers of the network.

https://datatracker.ietf.org/wg/lime/about/

OPSWG has this draft which hones in on the multi layer OAM aspects of PM
and Fault management of SFC.
https://datatracker.ietf.org/doc/html/draft-ww-opsawg-multi-layer-oam-02

This draft talks about a transport independent OAM where OAM mechanisms are
data plane transport dependent thus the concept of multi layer OAM
requirements of multiple discrete layers of OAM to map to each layer of the
network.  This document also talks about E2E OAM inter layer OAM
considerations in SFC as the fault may occur with the service functions at
different OSI layers being chained and different  network layers.

> 2. When you write "*fills a crucial gap for operators*”, are you aware of
> interoperable implementations (which I expect is what operators need for it
> to be useful in an actual deployment)? Perhaps an RFC 7942 "Implementation
> Status” section could be added?
>

Gyan> I am not aware of any implementations however Ican review with the
authors on adding the section.  Thank you

>
>
> 3. When you write “*for new OAM functionality*”, could you please clearly
> describe or explicitly enumerate the specific *new* functionality you refer
> to, on top of what existing OAMs provide, and how you find that crucial,
> specifically?
>

Troubleshooting SFC is a complex tax for operators and having additional
OAM capabilities that can provide value to operators in E2E SFC
troubleshooting is a major gain for operators.

RFC 8924 defines the base specification for SFC OAM, requirements analysis
and generically existing OAM mechanisms used at various layers  and how
they can apply to SFC defined in section 7.

This draft provides a comprehensive SFC OAM solution and takes the base SFC
OAM RFC 8924 and existing network layer mechanisms and applies them to SFC
OAM localized SFC fault isolation with a  new Active OAM header,
Authenticated Echo Request/Reply message and Source TLV.

The new functionality in this draft is defining a new procedure  for Active
OAM message on RSP in NSH updating NSH RFC 8300 definition of the O bit
which indicates an OAM command and/or data in NSH header or packet payload
discussed in section 4.

Section 5  talks about the issue related to additional IP/UDP headers in an
IPv6 network adds noticeable overhead and this draft defines a new active
OAM header to demultiplex Active OAM protocols on an SFC.

Section 6 defines a new Active OAM based Authenticated  Echo Request/Reply
message for SFC that addresses additional requirements, fate sharing,
monitoring of continuity between SFPs, RDI by ingress to egress,
connectivity verification, fault localization and tracing to discover RSP
and finally on-demand FM with response back to initiator.

This draft also provides OAM integrity check with authentication of
request/reply message in conjunction with use of source TLV to prevent DDOS
attack vector with SFC OAM.

The critical new functionality provided for operators with Active OAM is
the honed in focus on troubleshooting continuity of an SFP, trace an SFP ,
consistency verification of SFP and fault isolation and localizing of a
failure within an SFP as well as valuable SFF record TLV, SFF information
TLV/Sub-TLV  for multiple SFs as hops of SFP or multiple SFs for load
balancing using SFP consistency verification procedures.

Many Thanks!!

Gyan

> 11/19/21 午後11:02、Gyan Mishra <[email-masked]>のメール:
>
>
>
> Dear Chairs & All
>
> *M 301 502-1347 *

*Gyan Mishra*

*M 301 502-1347*

---

From: Greg Mirsky <[email-masked]>
Date: Sun, 21 Nov 2021 15:03:03 -0800

Dear Carlos,
     One of your key concerns seems to be the question of why we need
anything.  You seem to have said that RFC 8924 does not identify any
gaps.   As section 5.2 Missing OAM Functions says:
    As shown in Table 1, there are no standards-based tools available at
    the time of this writing that can be used natively (i.e., without
    enhancement) for the verification of SFs and SFCs.
Does that not seem to indicate a gap?  The SFC aspect of that is what we
are trying to cover.
Also, I'd stress that the described in the draft SFC NSH Echo Request/Reply
is an OAM tool that complements OAM protocols analyzed in RFC 8924, e.g.,
BFD.

Regards,
Greg

> CMP: Why were candidates descarted? When it is shown how they can address
GIM2>> Indeed.

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Sun, 21 Nov 2021 23:45:39 +0000

Dear Greg,

As you renamed this thread, I expect this is a fork and all outstanding questions and requests will be answered.

In regards to your message immediately below, you say:
1.     "One of your key concerns seems to be the question of why we need anything."

And

2. "You seem to have said that RFC 8924 does not identify any
gaps."

I am concerned by you attributing these statements to me (module “seems to” softener).

Could you please share where exactly did I question:
1. "why we need anything”
And where exactly I wrote that:
2. "RFC 8924 does not identify any gaps"

This is otherwise a proprietary straw man :-) I am clear on what I wrote which is not represented by what you write I said.

Let me try again — I am not passing judgement or conclusions. Simply *observationally* noting: where is the analysis of how this new proposed all-encompassing protocol complements versus overlaps with existing tools, and why building this is simpler and cheaper and better than extending other existing proven protocols?

I understand you make a statement when you say: "an OAM tool that complements OAM protocols analyzed in RFC 8924, e.g., BFD”.

Where is the actual explanation and analysis beyond that statement?  The acronym “BFD” is not in this document and "Bidirectional Forwarding Detection” only as a "Msg Type”.

By the way, as I searched for “BFD” I re-read S5 of draft-ietf-sfc-multi-layer-oam, to which I have another technical question and concern: Why would this newly defined "Active SFC OAM Header” include a value for BFD, is the NSH Next Protocol already exists?

Is your document suggesting that all OAM protocols suddenly need to use this "Active SFC OAM Header”? This is becoming an MPLS-TP G-ACh!

Carlos.

11/21/21 午後6:03、Greg Mirsky <[email-masked]<mailto:[email-masked]>>のメール:

Dear Carlos,
     One of your key concerns seems to be the question of why we need anything.  You seem to have said that RFC 8924 does not identify any
gaps.   As section 5.2 Missing OAM Functions says:
    As shown in Table 1, there are no standards-based tools available at
    the time of this writing that can be used natively (i.e., without
    enhancement) for the verification of SFs and SFCs.
Does that not seem to indicate a gap?  The SFC aspect of that is what we are trying to cover.
Also, I'd stress that the described in the draft SFC NSH Echo Request/Reply is an OAM tool that complements OAM protocols analyzed in RFC 8924, e.g., BFD.

Regards,
Greg

On Fri, Nov 19, 2021 at 5:33 PM Carlos Pignataro (cpignata) <[email-masked]<mailto:[email-masked]>> wrote:
Dear Greg,

Dear Carlos,

Regards,

Abstract

   Active OAM tools,

   The ingress may be

   The rules for

CMP: How?

   *  O bit is clear:

5.  Active SFC OAM Header

6.3.1.  Source TLV

6.4.1.  Errored TLVs TLV

…

CMP: Best,

CMP: — Carlos.

9.7.  SF Identifier Types

Thanks,

Carlos.

Thank you,
Joel

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Sun, 21 Nov 2021 23:52:17 +0000

Hi, Gyan,

Thank you for your response!

On #1, I recall LIME (I co-chaired), but there’s no “LIME” reference in draft-ietf-sfc-multi-layer-oam, not I see the relationship. The draft you quote on https://datatracker.ietf.org/doc/html/draft-ww-opsawg-multi-layer-oam-02 seems to have expired many years ago.

Further, Greg Mirsky wrote that it was for “Historical” reasons. Which one is it?

On #2, thanks for suggesting that section to be added. I agree.

On #3, thanks for the description of the various sections of draft-ietf-sfc-multi-layer-oam.

For the record I still do not see how foundational changes like the O-bit redefinition are needed.
While you write that "trace an SFP” is a new functionality, there’s open source running code I-D documented tools which do that.

Best,

Carlos.

11/20/21 午前10:36、Gyan Mishra <[email-masked]<mailto:[email-masked]>>のメール:

Hi Carlos

Responses in-line

On Fri, Nov 19, 2021 at 11:39 PM Carlos Pignataro (cpignata) <[email-masked]<mailto:[email-masked]>> wrote:
Dear Gyan,

I hope all is well!

When I asked your co-author Greg Mirsky, he said:
Additionally, I wonder: Why the file name “sfc-multi-layer-oam”?
GIM>> It is historical.
OAM has historic connotations but for good technical reasons as called multi layer as it provides a different job of managing different layers of the network thus the nomenclature “multi layer”

We can add some verbiage to the draft as we have the draft and file name with “multi layer” in the name.

LIME is a concluded WG on OAM that has discuss the OAM management of the various layers of the network.

OPSWG has this draft which hones in on the multi layer OAM aspects of PM and Fault management of SFC.
https://datatracker.ietf.org/doc/html/draft-ww-opsawg-multi-layer-oam-02

This draft talks about a transport independent OAM where OAM mechanisms are data plane transport dependent thus the concept of multi layer OAM requirements of multiple discrete layers of OAM to map to each layer of the network.  This document also talks about E2E OAM inter layer OAM considerations in SFC as the fault may occur with the service functions at different OSI layers being chained and different  network layers.

Gyan> I am not aware of any implementations however Ican review with the authors on adding the section.  Thank you

Troubleshooting SFC is a complex tax for operators and having additional OAM capabilities that can provide value to operators in E2E SFC troubleshooting is a major gain for operators.

RFC 8924 defines the base specification for SFC OAM, requirements analysis and generically existing OAM mechanisms used at various layers  and how they can apply to SFC defined in section 7.

This draft provides a comprehensive SFC OAM solution and takes the base SFC OAM RFC 8924 and existing network layer mechanisms and applies them to SFC OAM localized SFC fault isolation with a  new Active OAM header, Authenticated Echo Request/Reply message and Source TLV.

The new functionality in this draft is defining a new procedure  for Active OAM message on RSP in NSH updating NSH RFC 8300 definition of the O bit which indicates an OAM command and/or data in NSH header or packet payload discussed in section 4.

Section 5  talks about the issue related to additional IP/UDP headers in an IPv6 network adds noticeable overhead and this draft defines a new active OAM header to demultiplex Active OAM protocols on an SFC.

Section 6 defines a new Active OAM based Authenticated  Echo Request/Reply message for SFC that addresses additional requirements, fate sharing, monitoring of continuity between SFPs, RDI by ingress to egress, connectivity verification, fault localization and tracing to discover RSP and finally on-demand FM with response back to initiator.

This draft also provides OAM integrity check with authentication of request/reply message in conjunction with use of source TLV to prevent DDOS attack vector with SFC OAM.

The critical new functionality provided for operators with Active OAM is the honed in focus on troubleshooting continuity of an SFP, trace an SFP , consistency verification of SFP and fault isolation and localizing of a failure within an SFP as well as valuable SFF record TLV, SFF information TLV/Sub-TLV  for multiple SFs as hops of SFP or multiple SFs for load balancing using SFP consistency verification procedures.

Many Thanks!!

Gyan

Best,

Carlos.

Dear Chairs & All

Kind Regards

Gyan
Verizon

Dear Carlos,

Regards,

Abstract

   Active OAM tools,

   The ingress may be

   The rules for

CMP: How?

   *  O bit is clear:

5.  Active SFC OAM Header

6.3.1.  Source TLV

6.4.1.  Errored TLVs TLV

…

CMP: Best,

CMP: — Carlos.

9.7.  SF Identifier Types

Thanks,

Carlos.

Thank you,
Joel

Gyan Mishra

--

Gyan Mishra

---

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Mon, 22 Nov 2021 19:56:09 +0000

Just saw this thread – and the section on the O-bit in section 4 caught might attention.

   *  O bit is clear, and the "Next Protocol" field identifies active or
      hybrid OAM protocol MUST be identified and reported as an
      erroneous combination.  An implementation MAY have control to
      enable processing of the OAM payload.
Per what is mentioned below, the statement contradicts the principles of IOAM operation. A packet with O-bit cleared can very well have a hybrid OAM protocol in the next protocol field. IOAM is classified as a “Hybrid Type I” protocol per RFC 7799.
A key objective of IOAM is to trace packets through the network as if they weren’t observed, i.e., the packet forwarding operation of a packet with IOAM is expected to be that of a plain packet, i.e., a packet without IOAM. Consequently, draft-ietf-sfc-ioam-nsh states clearly that the O-bit isn’t changed when IOAM is added to an NSH-tagged packet: https://datatracker.ietf.org/doc/html/draft-ietf-sfc-ioam-nsh#section-4.2

I’d strongly suggest to re-word section 4 to either avoid the reference to “hybrid IOAM” entirely, or to explicitly list which hybrid OAM approaches the section applies to – and that way ensure, that IOAM is not affected. An even simpler approach would be – as discussed below – so simply avoid the redefinition of the O-Bit.

Thanks, Frank

From: sfc <[email-masked]> On Behalf Of Carlos Pignataro (cpignata)
Sent: Monday, 22 November 2021 00:52
To: Gyan Mishra <[email-masked]>
Cc: James N Guichard <[email-masked]>; Greg Mirsky <[email-masked]>; [email-masked]; Joel Halpern Direct <[email-masked]>
Subject: Re: [sfc] Regarding last call for draft-ietf-sfc-multi-layer-oam

Hi, Gyan,

Best,

Carlos.

Hi Carlos

Responses in-line

I hope all is well!

Many Thanks!!

Gyan

Best,

Carlos.

Dear Chairs & All

Kind Regards

Gyan
Verizon

Dear Carlos,

Regards,

Abstract

   Active OAM tools,

   in Section 6.

   and 4.3 of [RFC8924].

   The ingress may be

   The rules for

   are as follows:

      (TBA1).

CMP: How?

         OAM command or data.

   *  O bit is clear:

         Context Header(s).

         present.

   payload.

5.  Active SFC OAM Header

   presented in Figure 3.

      octets.

6.3.1.  Source TLV

6.4.1.  Errored TLVs TLV

   Table 14.

CMP: Best,

CMP: — Carlos.

9.7.  SF Identifier Types

Thanks,

Carlos.

Thank you,
Joel

[Image removed by sender.]<http://www.verizon.com/>

--
[Image removed by sender.]<http://www.verizon.com/>
Gyan Mishra
Network Solutions Architect
Email [email-masked]<mailto:[email-masked]>
M 301 502-1347

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 22 Nov 2021 14:15:50 -0800

Hi Frank,
thank you for your comment describing an interesting IOAM use case in SFC
NSH. I've thought about this case and I have several questions. I greatly
appreciate your help clarifying them to me:

   - Is it envisioned that the IOAM can be part of NSH payload but not to
   immediately follow the SFC NSH? Perhaps such a case can be referred to as
   "IOAM inside NSH payload" to differentiate from "IOAM on top of NSH
   payload"? For example, assuming that the client payload is IPv6, then NSH
   is followed by an IPv6 packet, which, in turn, is followed by IOAM.
   - If IOAM inside NSH payload is a viable use case, which SFC element is
   the intended addressee - SFF or SF/SF Proxy? If it is the former, what are
   the requirements for an SFF to handle this scenario? If it is the latter,
   what happens with the client packet if an SF/SF Proxy does  not support
   IOAM in NSH but only NSH per RFC 8300?

I've looked through draft-ietf-sfc-ioam-nsh but I couldn't find answers to
these questions (I admit, I could have missed it).
Also, I think that your suggestion to avoid any reference to a hybrid OAM
protocol concentrating on the active OAM identification in the update to
O-bit definition is logical and reasonable. Below, please find the proposed
update:
OLD TEXT:
   *  O bit set and the "Next Protocol" value does not match one of
      identifying active or hybrid OAM protocols (per classification
      defined in [RFC7799]), e.g., defined in Section 9.1 Active SFC OAM
      (TBA1).

   *  O bit is clear:

NEW TEXT:
   *  O bit set and the "Next Protocol" value does not match defined in
      Section 9.1 Active SFC OAM (TBA1).

   *  O bit set and the "Next Protocol" value matches Active SFC OAM
      (TBA1) value:

         - the payload that immediately follows the NSH MUST be the
         Active OAM Header (Section 5).

   *  O bit is clear:

   *  O bit is clear, and the "Next Protocol" field is set to Active SFC
      OAM (TBA1) MUST be identified and reported as an erroneous
      combination.  An implementation MAY have control to enable
      processing of the OAM payload.

I hope that the proposed update addresses your concern.

Regards,
Greg

On Mon, Nov 22, 2021 at 11:56 AM Frank Brockners (fbrockne) <
[email-masked]> wrote:

> Per what is mentioned below, the statement contradicts the principles of
> IOAM operation. A packet with O-bit cleared can very well have a hybrid OAM
> protocol in the next protocol field. IOAM is classified as a “Hybrid Type
> I” protocol per RFC 7799.
> A key objective of IOAM is to trace packets through the network as if they
> weren’t observed, i.e., the packet forwarding operation of a packet with
> IOAM is expected to be that of a plain packet, i.e., a packet without IOAM.
> Consequently, draft-ietf-sfc-ioam-nsh states clearly that the O-bit isn’t
> changed when IOAM is added to an NSH-tagged packet:
> I’d strongly suggest to re-word section 4 to either avoid the reference to
> “hybrid IOAM” entirely, or to explicitly list which hybrid OAM approaches
> the section applies to – and that way ensure, that IOAM is not affected. An
> even simpler approach would be – as discussed below – so simply avoid the
> redefinition of the O-Bit.
>
>
>
> Thanks, Frank
>
>
>
>
>
> *From:* sfc <[email-masked]> *On Behalf Of *Carlos Pignataro
> (cpignata)
> *Sent:* Monday, 22 November 2021 00:52
> *To:* Gyan Mishra <[email-masked]>
> *Cc:* James N Guichard <[email-masked]>; Greg Mirsky <
> [email-masked]>; [email-masked]; Joel Halpern Direct <
> [email-masked]>
> *Subject:* Re: [sfc] Regarding last call for
> draft-ietf-sfc-multi-layer-oam
>
>
>
> Hi, Gyan,
>
>
>
> On #1, I recall LIME (I co-chaired), but there’s no “LIME” reference
> in draft-ietf-sfc-multi-layer-oam, not I see the relationship. The draft
> you quote on
> https://datatracker.ietf.org/doc/html/draft-ww-opsawg-multi-layer-oam-02 seems
> to have expired many years ago.
>
>
>
> While you write that "trace an SFP” is a new functionality, there’s open
> source running code I-D documented tools which do that.
>
>
>
> Best,
>
>
>
> Carlos.
>
>
>
>
>
> 11/20/21 午前10:36、Gyan Mishra <[email-masked]>のメール:
>
>
>
> Hi Carlos
>
>
>
> This draft talks about a transport independent OAM where OAM mechanisms
> are data plane transport dependent thus the concept of multi layer OAM
> This draft provides a comprehensive SFC OAM solution and takes the base
> SFC OAM RFC 8924 and existing network layer mechanisms and applies them to
> SFC OAM localized SFC fault isolation with a  new Active OAM header,
> The new functionality in this draft is defining a new procedure  for
> Active OAM message on RSP in NSH updating NSH RFC 8300 definition of the O
> bit which indicates an OAM command and/or data in NSH header or packet
> payload discussed in section 4.
>
>
>
> Section 5  talks about the issue related to additional IP/UDP headers in
> an IPv6 network adds noticeable overhead and this draft defines a new
> active OAM header to demultiplex Active OAM protocols on an SFC.
>
>
>
> This specification fills a crucial gap for operators for
> new OAM functionality, with an Active Multi layer OAM model, by defining
> extensibility with Active OAM messages, in NSH,  to troubleshoot faults in
> the data plane SFC forwarding plane, SFP E2E path in the service plane
> framework.
>
>
>
> Kind Regards
>
>
>
> Gyan
>
> Verizon
>
>
>
> CMP: I agree it is an operational issue — an issue of operations. Like the
> “O” in “OAM”. Should Operational Considerations be included as well?
>
>
>
>
>
> *Network Solutions Architect *
>
> *Network Solutions Architect *
>

---

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Tue, 23 Nov 2021 14:33:14 +0000

Hi Greg,

Thanks for the quick reply. Please see inline.

From: Greg Mirsky <[email-masked]>
Sent: Monday, 22 November 2021 23:16
To: Frank Brockners (fbrockne) <[email-masked]>
Cc: Carlos Pignataro (cpignata) <cpignata=[email-masked]>; Gyan Mishra <[email-masked]>; James N Guichard <[email-masked]>; [email-masked]; Joel Halpern Direct <[email-masked]>
Subject: Re: [sfc] Regarding last call for draft-ietf-sfc-multi-layer-oam

Hi Frank,
thank you for your comment describing an interesting IOAM use case in SFC NSH. I've thought about this case and I have several questions. I greatly appreciate your help clarifying them to me:

  *   Is it envisioned that the IOAM can be part of NSH payload but not to immediately follow the SFC NSH? Perhaps such a case can be referred to as "IOAM inside NSH payload" to differentiate from "IOAM on top of NSH payload"? For example, assuming that the client payload is IPv6, then NSH is followed by an IPv6 packet, which, in turn, is followed by IOAM.
  *   If IOAM inside NSH payload is a viable use case, which SFC element is the intended addressee - SFF or SF/SF Proxy? If it is the former, what are the requirements for an SFF to handle this scenario? If it is the latter, what happens with the client packet if an SF/SF Proxy does  not support IOAM in NSH but only NSH per RFC 8300?
…FB: The scenario that you outline, i.e. NSH over “IPv6 with IOAM encapsulation”, sounds valid to me; and it could even be that NSH would also leverage IOAM, in which case, it would become a case of “IOAM Layering” as described in https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-deployment-00#section-7.2. As outlined in the draft-ietf-ippm-ioam-deployment, IOAM-Data-Fields are specific to the layer (and the associated protocol) that they’re encapsulated into. As such, in the case of NSH over “IPv6 with IOAM encapsulation” it would be the IPv6 forwarder that would handle the IOAM processing. SFF/SF would be orthogonal/ships-in-the night.
I've looked through draft-ietf-sfc-ioam-nsh but I couldn't find answers to these questions (I admit, I could have missed it).
Also, I think that your suggestion to avoid any reference to a hybrid OAM protocol concentrating on the active OAM identification in the update to O-bit definition is logical and reasonable. Below, please find the proposed update:
OLD TEXT:
   *  O bit set and the "Next Protocol" value does not match one of
      identifying active or hybrid OAM protocols (per classification
      defined in [RFC7799]), e.g., defined in Section 9.1 Active SFC OAM
      (TBA1).

   *  O bit is clear:

NEW TEXT:

…FB: The new text looks better. Couple of additional thoughts inline below.

…FB: The above sentence doesn’t sound complete. Likely you wanted to say something like “O bit set and the "Next Protocol" value does not match any of the SFC Next Protocol values define defined in Section 9.1 Active SFC OAM (TBA1).”

…FB: Given that it applies to both, fixed and variable – how about simplifying to “Context-header(s) that contain active OAM commands and/or data.”

   *  O bit is clear:

         - no OAM in a Fixed-Length Context Header or Variable-Length
         Context Header(s).
…FB: Similar to the note above, “No Context-header(s) that contain active OAM commands and/or data.” might be simpler

…FB: Isn’t this obvious? The reader might wonder why this is even stated. IMHO we could safely remove this bullet.

…FB: Just cosmetic, but it would be good to stay with the pattern of “condition: action” of this paragraph, e.g.

* O but is clear and the "Next Protocol" field is set to Active SFC
      OAM (TBA1):

   - Erroneous combination. The combination MUST be identified and reported.

In addition, what would be good,  is to expand a bit on how that reporting is supposed to happen – as well as what is supposed to happen with the packet that contains the erroneous combination. Is it going to be forwarded or dropped? Is the node detecting the error supposed to remove the active IOAM header, etc., …?

Thanks again, Frank

Regards,
Greg

On Mon, Nov 22, 2021 at 11:56 AM Frank Brockners (fbrockne) <[email-masked]<mailto:[email-masked]>> wrote:

Thanks, Frank

From: sfc <[email-masked]<mailto:[email-masked]>> On Behalf Of Carlos Pignataro (cpignata)
Sent: Monday, 22 November 2021 00:52
To: Gyan Mishra <[email-masked]<mailto:[email-masked]>>
Cc: James N Guichard <[email-masked]<mailto:[email-masked]>>; Greg Mirsky <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Joel Halpern Direct <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sfc] Regarding last call for draft-ietf-sfc-multi-layer-oam

Hi, Gyan,

Best,

Carlos.

Hi Carlos

Responses in-line

I hope all is well!

Many Thanks!!

Gyan

Best,

Carlos.

Dear Chairs & All

Kind Regards

Gyan
Verizon

Dear Carlos,

Regards,

Abstract

   Active OAM tools,

   in Section 6.

   and 4.3 of [RFC8924].

   The ingress may be

   The rules for

   are as follows:

      (TBA1).

CMP: How?

         OAM command or data.

   *  O bit is clear:

         Context Header(s).

         present.

   payload.

5.  Active SFC OAM Header

   presented in Figure 3.

      octets.

6.3.1.  Source TLV

6.4.1.  Errored TLVs TLV

   Table 14.

CMP: Best,

CMP: — Carlos.

9.7.  SF Identifier Types

Thanks,

Carlos.

Thank you,
Joel

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 23 Nov 2021 14:43:35 +0000

Frank, Greg,

Do you see a reason to redefine the O-bit?

Thanks,

Carlos.

11/23/21 午前9:33、Frank Brockners (fbrockne) <fbrockne=[email-masked]<mailto:fbrockne=[email-masked]>>のメール:

Hi Greg,

From: Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Sent: Monday, 22 November 2021 23:16
To: Frank Brockners (fbrockne) <[email-masked]<mailto:[email-masked]>>
Cc: Carlos Pignataro (cpignata) <cpignata=[email-masked]<mailto:cpignata=[email-masked]>>; Gyan Mishra <[email-masked]<mailto:[email-masked]>>; James N Guichard <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Joel Halpern Direct <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sfc] Regarding last call for draft-ietf-sfc-multi-layer-oam

Hi Frank,

   *  O bit is clear:

NEW TEXT:

   *  O bit is clear:

Thanks again, Frank

Regards,
Greg

Thanks, Frank

Hi, Gyan,

Best,

Carlos.

Hi Carlos

Responses in-line

I hope all is well!

Many Thanks!!

Gyan

Best,

Carlos.

Dear Chairs & All

Kind Regards

Gyan
Verizon

Dear Carlos,

Regards,

Abstract

   Active OAM tools,

   in Section 6.

   and 4.3 of [RFC8924].

   The ingress may be

   The rules for

   are as follows:

      (TBA1).

CMP: How?

         OAM command or data.

   *  O bit is clear:

         Context Header(s).

         present.

   payload.

5.  Active SFC OAM Header

   presented in Figure 3.

      octets.

6.3.1.  Source TLV

6.4.1.  Errored TLVs TLV

…

   Table 14.

CMP: Best,

CMP: — Carlos.

9.7.  SF Identifier Types

Thanks,

Carlos.

Thank you,
Joel

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 23 Nov 2021 09:30:11 -0800

Hi Frank,
thank you for your suggestions to improve the proposed text. I'll work with
the text and return with the updated version. I thought about the IOAM
layering case. Wouldn't for SFC NSH it be just an IPv6 payload? As
you've mentioned, an IPv6 packet that has the IOAM Header and data-fields
would not be processed by an SFF or SF. Thus, from SFC NSH, it should not
be identified as an OAM packet and the O-bit must be clear. What do you
think?

Regards,
Greg

On Tue, Nov 23, 2021 at 6:33 AM Frank Brockners (fbrockne) <
[email-masked]> wrote:

> *From:* Greg Mirsky <[email-masked]>
> *Sent:* Monday, 22 November 2021 23:16
> *To:* Frank Brockners (fbrockne) <[email-masked]>
> *Cc:* Carlos Pignataro (cpignata) <cpignata=[email-masked]>;
> Gyan Mishra <[email-masked]>; James N Guichard <
> [email-masked]>; [email-masked]; Joel Halpern Direct <
>    - If IOAM inside NSH payload is a viable use case, which SFC element
>    is the intended addressee - SFF or SF/SF Proxy? If it is the former, what
>    are the requirements for an SFF to handle this scenario? If it is the
>    latter, what happens with the client packet if an SF/SF Proxy does  not
>    support IOAM in NSH but only NSH per RFC 8300?
>
> …FB: The scenario that you outline, i.e. NSH over “IPv6 with IOAM
> encapsulation”, sounds valid to me; and it could even be that NSH would
> also leverage IOAM, in which case, it would become a case of “IOAM
> Layering” as described in
> https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-deployment-00#section-7.2.
> As outlined in the draft-ietf-ippm-ioam-deployment, IOAM-Data-Fields are
> specific to the layer (and the associated protocol) that they’re
> encapsulated into. As such, in the case of NSH over “IPv6 with IOAM
> encapsulation” it would be the IPv6 forwarder that would handle the IOAM
> processing. SFF/SF would be orthogonal/ships-in-the night.
>
> …FB: The above sentence doesn’t sound complete. Likely you wanted to say
> something like “O bit set and the "Next Protocol" value does not match any
> of the SFC Next Protocol values define defined in Section 9.1 Active SFC
> OAM (TBA1).”
>
>
>
>
>
> …FB: Given that it applies to both, fixed and variable – how about
> simplifying to “Context-header(s) that contain active OAM commands and/or
> data.”
>
>
>
> …FB: Similar to the note above, “No Context-header(s) that contain active
> OAM commands and/or data.” might be simpler
>
>
>
> …FB: Just cosmetic, but it would be good to stay with the pattern of
> “condition: action” of this paragraph, e.g.
>
>
>
> In addition, what would be good,  is to expand a bit on how that reporting
> is supposed to happen – as well as what is supposed to happen with the
> packet that contains the erroneous combination. Is it going to be forwarded
> or dropped? Is the node detecting the error supposed to remove the active
> IOAM header, etc., …?
>
>
>
> Thanks again, Frank
>
>
>
>
>

---

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Tue, 23 Nov 2021 20:59:55 +0000

Hi Greg,

Please see inline.

Sent: Tuesday, 23 November 2021 18:30

Hi Frank,
thank you for your suggestions to improve the proposed text. I'll work with the text and return with the updated version. I thought about the IOAM layering case. Wouldn't for SFC NSH it be just an IPv6 payload? As you've mentioned, an IPv6 packet that has the IOAM Header and data-fields would not be processed by an SFF or SF. Thus, from SFC NSH, it should not be identified as an OAM packet and the O-bit must be clear. What do you think?

…FB: Yes – an IPv6 packet with IOAM in an extension header would be just a “regular” packet for NSH – and the O-bit would be clear.
And for the case, where IOAM would be encapsulated with NSH (as a next header), the O-bit would also be clear if regular user traffic is carried.
The O-bit would only be set if the traffic is active OAM traffic.

Cheers, Frank

Regards,
Greg

On Tue, Nov 23, 2021 at 6:33 AM Frank Brockners (fbrockne) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg,

Cc: Carlos Pignataro (cpignata) <cpignata=[email-masked]<mailto:[email-masked]>>; Gyan Mishra <[email-masked]<mailto:[email-masked]>>; James N Guichard <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Joel Halpern Direct <[email-masked]<mailto:[email-masked]>>

Hi Frank,

   *  O bit is clear:

NEW TEXT:

   *  O bit is clear:

Thanks again, Frank

Regards,
Greg

Thanks, Frank

Hi, Gyan,

Best,

Carlos.

Hi Carlos

Responses in-line

I hope all is well!

Many Thanks!!

Gyan

Best,

Carlos.

Dear Chairs & All

Kind Regards

Gyan
Verizon

Dear Carlos,

Regards,

Abstract

   Active OAM tools,

   in Section 6.

   and 4.3 of [RFC8924].

   The ingress may be

   The rules for

   are as follows:

      (TBA1).

CMP: How?

         OAM command or data.

   *  O bit is clear:

         Context Header(s).

         present.

   payload.

5.  Active SFC OAM Header

   presented in Figure 3.

      octets.

6.3.1.  Source TLV

6.4.1.  Errored TLVs TLV

   Table 14.

CMP: Best,

CMP: — Carlos.

9.7.  SF Identifier Types

Thanks,

Carlos.

Thank you,
Joel

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 23 Nov 2021 15:30:08 -0800

Hi Frank,
thank you for your comments and suggestions on the updated text. Below is
the its new version:
The rules for
   interpreting the values of the O bit and the "Next Protocol" field
   are as follows:

   *  O bit set and the "Next Protocol" value does not match the value
      Active SFC OAM (TBA1), defined in Section 9.1:

         - An SFC NSH Context Header(s) contain an OAM command or data.

         - The "Next Protocol" field determines the type of the payload.

         - The payload that immediately follows the NSH MUST be the
         Active OAM Header (Section 5).

   *  O bit is clear:

         - No OAM in an SFC NSH Context Header(s).

         - The payload determined by the "Next Protocol" field MUST be
         present.

         - Erroneous combination.  An implementation MUST report it.
         The notification mechanism is outside the scope of this
         specification.  The packet SHOULD be dropped.  An
         implementation MAY have control to enable processing of the OAM
         payload.

I also have a question. You've noted:

Then, as I understand it, O-bit would not indicate the content of SFC NSH
Context Headers. Right? If we, the SFC WG, agree with this definition of
the O-bit, then we can use it to replace the proposed in the draft:
 OLD TEXT:
      O bit: Setting this bit indicates an OAM command and/or data in
      the NSH Context Header or packet payload.
NEW TEXT:
      O bit: Setting this bit indicates an active OAM in the NSH packet
payload.

What are your thoughts?

Regards,
Greg

On Tue, Nov 23, 2021 at 1:00 PM Frank Brockners (fbrockne) <
[email-masked]> wrote:

> *Sent:* Tuesday, 23 November 2021 18:30
> thank you for your suggestions to improve the proposed text. I'll work
> with the text and return with the updated version. I thought about the IOAM
> …FB: Yes – an IPv6 packet with IOAM in an extension header would be just a
> “regular” packet for NSH – and the O-bit would be clear.
> And for the case, where IOAM would be encapsulated with NSH (as a next
> header), the O-bit would also be clear if regular user traffic is carried.

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 24 Nov 2021 07:44:15 -0800

Dear Carlos,
please find more responses in-line below under the GIM2>> tag.

Regards,
Greg

> CMP: Why were candidates descarted? When it is shown how they can address
GIM2>> I don't think that the proposed mechanism discards or negates any of
the tools listed in RFC 8924. SFC NSH Echo Request/Reply is targeted to
specifically SFC NSH operational needs is not to replace but to complement
other OAM tools. The choice of which tool from the SFC OAM toolbox to use
is, as always, with vendors and operators.

> to create a brand new one ignoring the existing ones.
GIM2>> I believe that the WG has demonstrated its support for the proposed
solution. Anyone can propose an alternative technical solution in the
traditional IETF form.

> of draft-ietf-sfc-multi-layer-oam?
GIM2>> I was told of interest in developing implementations based on the
mechanism defined. Certain hesitation to be an early adopter is
understandable to me.

> open source implementations.
GIM2>> Looking at this list, the SFC NSH Echo Request/Reply mechanism is
not an alternative to BFD or IOAM.

> CMP: The “SFC Active OAM Header” is therefore not part of the “active SFC
GIM2>> SFC Active OAM Header is a part of an active SFC NSH OAM packet.

> the “O” in “OAM”. Should Operational Considerations be included as well?
GIM2>> I think that it is helpful to provide some operational suggestions
in the Operational Considerations section. Will work with co-authors.

> a flow in SFC NSH. The document makes the use of this method.
GIM2>> In Section 6.5.4 of the draft:
    Suppose a specialized information element (e.g., IPv6 Flow Label
   [RFC6437] or Flow ID [I-D.ietf-sfc-nsh-tlv]) is used for distributing
   the load across Equal Cost Multi-Path or Link Aggregation Group
   paths.  In that case, such an element MAY also be used for the SFC
   OAM traffic.  Doing so is meant to induce the SFC Echo Request to
   follow the same RSP as the monitored flow.

> CMP: This reads like not answering by asking questions.
GIM2>> I am trying to understand the question. RFC 7799, as I understand
it, defines an active OAM packet as a specifically constructed test packet.

> CMP: A user packet with marking, implicitly or explicitly, is not an OAM
GIM2>> Frank has brought very good points and suggested excluding hybrid
OAM. Now the text is applicable only to active SFC NSH OAM:
The rules for
   interpreting the values of the O bit and the "Next Protocol" field
   are as follows:

   *  O bit is clear:

> CMP: Please note the “MUST NOT” in the paragraph immediately above.
GIM2>> We've agreed with Frank to not discuss hybrid SFC NSH OAM in this
draft.

> overhead-efficient than draft-ietf-sfc-multi-layer-oam.
GIM2>> The purpose of the specification is to address specific SFC NSH OAM
requirements. The proposed solution is one of possible that can be
implemented. Encapsulation efficiency is a benefit.

> CMP: I am not proposing anything. I am simply asking a question.
GIM2>> draft-ietf-sfc-multi-layer-oam does not include BFD in SFC NSH in
its scope.

> CMP: Two timestamps in different parts of a packet.
GIM2>> RFC 8592 has been published through the Independent Stream Editor.
As I understand it, draft-mymb-sfc-nsh-allocation-timestamp is also in the
ISE track. I'll reach out to the authors
of draft-mymb-sfc-nsh-allocation-timestamp to see if any considerations
should be added in their document.

> extend the candidate protocols.
GIM2>> I think that RFC 8924 has firmly established that none of the
analyzed OAM tools completely addresses all the SFC NSH OAM requirements.
Can a combination of tools do the job? I don't know. What is easier seems a
subjective issue.  If anyone has an alternative technical solution, I'll be
glad to discuss that. Otherwise, it appears as hypothetical.

> CMP: Does this mean it skips hops? Apologies I do not understand.
GIM2>> The sender of the SFC Echo Request includes SFC Reply Path TLV. The
responder must use the Service Index field in the NSH that encapsulates SFC
NSH Echo Reply. I hope that clarifies how the Service Index field is used.

> CMP: If the Handles and sequences match but not the port?
GIM2>> I assume you are thinking of IP/UDP encapsulation of SFC NSH. The
receiver of SFC NSH Echo Reply would not check for port. Or are you
referring to a different port?

> contextual to a specified reply mode.
GIM2>> We'll address that in the new Operational Considerations section.

> Considerations section, this should be included.
GIM2>> Thank you for the suggestion. We'll mention that in the Operational
Considerations section.

> This seems overly complex.
GIM2>> The NSH's Next Protocol field is in the fixed position. Getting to
SFC NSH active OAM doesn't seem to require parsing TLVs, SFC NSH Context
Headers can be simply skipped.

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 24 Nov 2021 16:08:54 +0000

Dear Greg,

Please see inline.

Best,

Carlos.

On Nov 24, 2021, at 10:44 AM, Greg Mirsky <[email-masked]<mailto:[email-masked]>> wrote:

Dear Carlos,

Regards,
Greg

Dear Carlos,

Regards,

Abstract

CMP: Why were candidates descarted? When it is shown how they can address some of the functions.
GIM2>> I don't think that the proposed mechanism discards or negates any of the tools listed in RFC 8924. SFC NSH Echo Request/Reply is targeted to specifically SFC NSH operational needs is not to replace but to complement other OAM tools. The choice of which tool from the SFC OAM toolbox to use is, as always, with vendors and operators.

CMP2: Sorry if I was not clear, let me ask differently. Where is the documented tradeoff and decision for creating a new protocol versus extending existing ones which partially address requirements? Indeed, I agree operators and vendors have a choice, my question is in regards to the WG decision to build new vs. extend.

CMP2: You seem to have missed these 3 comments. Could you please address?

   Active OAM tools,

CMP: This is a very useful response. As I responded above, there’s no implication that if no existing tools address all requirements, the path is to create a brand new one ignoring the existing ones.
GIM2>> I believe that the WG has demonstrated its support for the proposed solution.

CMP2: I thought statements like these are within the scope of a WG chair.
CMP2: From a technical perspective, it is a useful engineering piece of data to understand why a new protocol.

Anyone can propose an alternative technical solution in the traditional IETF form.

CMP: Can you please point to independent interoperable implementations of draft-ietf-sfc-multi-layer-oam?
GIM2>> I was told of interest in developing implementations based on the mechanism defined. Certain hesitation to be an early adopter is understandable to me.

CMP2: Shall I understand this as you cannot point to any implementation?

CMP: ICMP, BFD, iOAM, SFC-Tracceroute, all documented in I-Ds and with open source implementations.
GIM2>> Looking at this list, the SFC NSH Echo Request/Reply mechanism is not an alternative to BFD or IOAM.

CMP2: ICMP?

   The ingress may be

CMP2: In that case, shall I understand that the “SFC Active OAM Header” cannot be part of other OAM packet. In that case I am very confused as I read:
CMP2: "      Msg Type - six bits long field identifies OAM protocol, e.g., Echo"
CMP2: "      Request/Reply or Bidirectional Forwarding Detection."
CMP2: Why would BFD be carried in the middle of SFC Active OAM? Why not use the NSH Next Protocol as intended?

   The rules for

CMP: I agree it is an operational issue — an issue of operations. Like the “O” in “OAM”. Should Operational Considerations be included as well?
GIM2>> I think that it is helpful to provide some operational suggestions in the Operational Considerations section. Will work with co-authors.

CMP: How?

CMP2: I may have misunderstood — if so apologies in advance — however, when I read "a Fixed-Length Context Header or Variable-Length Context Header(s) contain an OAM command or data” I thought Context Header (e.g., MD Type 1) was user for OAM, it could not be used for Flow ID as well.

CMP: This reads like not answering by asking questions.
GIM2>> I am trying to understand the question. RFC 7799, as I understand it, defines an active OAM packet as a specifically constructed test packet.

CMP2: RFC 7799 does not include the terms “OAM Command” or “OAM Data"

CMP: A user packet with marking, implicitly or explicitly, is not an OAM packet.
GIM2>> Frank has brought very good points and suggested excluding hybrid OAM. Now the text is applicable only to active SFC NSH OAM:

CMP2: I agree with removing any Hybrid OAM from the “SFC Active OAM” document. For sure.
CMP2: at the same time, what specifically needs to be redefined for the O-bit (as opposed to say “use it as intended in 8300”)?

The rules for

   *  O bit is clear:

   *  O bit is clear:

CMP: Please note the “MUST NOT” in the paragraph immediately above.
GIM2>> We've agreed with Frank to not discuss hybrid SFC NSH OAM in this draft.

CMP2: Sounds good — why does the O-bit need to be discussed in any case?

5.  Active SFC OAM Header

CMP: My question again: is the whole purpose of this new protocol to be overhead efficient? I am sure there are ways of encasulating that are more overhead-efficient than draft-ietf-sfc-multi-layer-oam.
GIM2>> The purpose of the specification is to address specific SFC NSH OAM requirements. The proposed solution is one of possible that can be implemented. Encapsulation efficiency is a benefit.

CMP: I am not proposing anything. I am simply asking a question.
GIM2>> draft-ietf-sfc-multi-layer-oam does not include BFD in SFC NSH in its scope.

CMP2: The text in the document that I quoted above seems to contradict your statement.

CMP: Two timestamps in different parts of a packet.
GIM2>> RFC 8592 has been published through the Independent Stream Editor. As I understand it, draft-mymb-sfc-nsh-allocation-timestamp is also in the ISE track. I'll reach out to the authors of draft-mymb-sfc-nsh-allocation-timestamp to see if any considerations should be added in their document.

CMP2: I would suggest that this document also needs to figure out non-clashing proposals.

CMP: And frankly even if that was the case, there’s no implication that using the existing pieces is not sufficient, or that it is not easier to extend the candidate protocols.
GIM2>> I think that RFC 8924 has firmly established that none of the analyzed OAM tools completely addresses all the SFC NSH OAM requirements. Can a combination of tools do the job? I don't know. What is easier seems a subjective issue.  If anyone has an alternative technical solution, I'll be glad to discuss that. Otherwise, it appears as hypothetical.

CMP2: I disagree with this approach in principle, as I’d expect the WG to compare feasibility and ROI of approaches before embarking in text. Just my humble opinion.

6.3.1.  Source TLV

6.4.1.  Errored TLVs TLV

…

CMP: Does this mean it skips hops? Apologies I do not understand.
GIM2>> The sender of the SFC Echo Request includes SFC Reply Path TLV. The responder must use the Service Index field in the NSH that encapsulates SFC NSH Echo Reply. I hope that clarifies how the Service Index field is used.

CMP2: I am sorry, it doesn’t. How does the sender of the request (i.e., based on what criteria) chooses the Service Index field value in the SFC Reply Path TLV in the SFC Active OAM packet?

CMP: I understand several values can be used.
CMP: Which one is actually used?
CMP: If the Handles and sequences match but not the port?
GIM2>> I assume you are thinking of IP/UDP encapsulation of SFC NSH. The receiver of SFC NSH Echo Reply would not check for port. Or are you referring to a different port?

CMP2: I am referring to the port that S6.5.3 of draft-ietf-sfc-multi-layer-oam mentions. "it has an outstanding SFC Echo Request sent from the UDP port that matches destination UDP port number of the received packet;”
CMP2: Based on that the question stands.

CMP2: Look forward to reviewing. The text in Section 6.6 still has issues.

CMP2: You seem to have skipped this comment.

CMP: This seems like an operational unnecessary complexity, in keeping a matrix of supported combination of versions. If there was an Operational Considerations section, this should be included.
GIM2>> Thank you for the suggestion. We'll mention that in the Operational Considerations section.

CMP: Apologies I was not clear.
CMP: The “SFC Active OAM” is actually a "SFC Next Protocol”.
CMP: My intention of using “protocol number” is in a generic way. To get to some OAM function, a node needs to recursively parse 3 TLVs. Correct? This seems overly complex.
GIM2>> The NSH's Next Protocol field is in the fixed position. Getting to SFC NSH active OAM doesn't seem to require parsing TLVs, SFC NSH Context Headers can be simply skipped.

CMP2: Concern stands. What is the value of this linked protocol identification check?

CMP2: Thanks again, and best,

CMP2: Carlos.

CMP: Best,

CMP: — Carlos.

9.7.  SF Identifier Types

Thanks,

Carlos.

Thank you,
Joel

---

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Wed, 24 Nov 2021 17:53:03 +0000

Hi Greg,

Thanks – please see inline.

Sent: Wednesday, 24 November 2021 00:30

Hi Frank,
thank you for your comments and suggestions on the updated text. Below is the its new version:
The rules for
   interpreting the values of the O bit and the "Next Protocol" field
   are as follows:

…FB: Thinking about things again – “OAM processing instructions” might be a better term than “OAM command”. Thoughts?

   *  O bit is clear:

…FB: Could we be specific and say “No active OAM in the…” ?

I also have a question. You've noted:
The O-bit would only be set if the traffic is active OAM traffic.
Then, as I understand it, O-bit would not indicate the content of SFC NSH Context Headers. Right? If we, the SFC WG, agree with this definition of the O-bit, then we can use it to replace the proposed in the draft:
 OLD TEXT:
      O bit: Setting this bit indicates an OAM command and/or data in
      the NSH Context Header or packet payload.
NEW TEXT:
      O bit: Setting this bit indicates an active OAM in the NSH packet payload.

…FB: Per the note above – in general terms, I would assume that the O-bit indicates that the packet is an *active* OAM packet. NSH may or may not know whether the NSH payload is active OAM. Rather than having NSH “speculate” what is in the payload (which might be encrypted), wouldn’t it make sense to tie the O-bit to *active OAM for NSH* - which could be draft-ietf-sfc-multi-layer-oam, or eventually a future spec? That way, the spec would be about NSH and its OAM solution – rather than try to provide information about something that NSH does not control and might not even know.

Cheers, Frank

What are your thoughts?

Regards,
Greg

On Tue, Nov 23, 2021 at 1:00 PM Frank Brockners (fbrockne) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg,

Please see inline.

Hi Frank,

Cheers, Frank

Regards,
Greg

Hi Frank,

   *  O bit is clear:

NEW TEXT:

   *  O bit is clear:

Thanks again, Frank

Regards,
Greg

Thanks, Frank

Hi, Gyan,

Best,

Carlos.

Hi Carlos

Responses in-line

I hope all is well!

Many Thanks!!

Gyan

Best,

Carlos.

Dear Chairs & All

Kind Regards

Gyan
Verizon

Dear Carlos,

Regards,

Abstract

   Active OAM tools,

   in Section 6.

   and 4.3 of [RFC8924].

   The ingress may be

   The rules for

   are as follows:

      (TBA1).

CMP: How?

         OAM command or data.

   *  O bit is clear:

         Context Header(s).

         present.

   payload.

5.  Active SFC OAM Header

   presented in Figure 3.

      octets.

6.3.1.  Source TLV

6.4.1.  Errored TLVs TLV

   Table 14.

CMP: Best,

CMP: — Carlos.

9.7.  SF Identifier Types

Thanks,

Carlos.

Thank you,
Joel

---

From: <[email-masked]>
Date: Thu, 25 Nov 2021 11:32:39 +0000

Hi Greg, all,
I am fine with your changes in the draft which completely address my comments.
Thanks for that!
I support progress of the document.
Best regards
Dirk

From: Greg Mirsky <[email-masked]>
Sent: Donnerstag, 4. November 2021 18:11
To: von Hugo, Dirk <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [sfc] Regarding last call for draft-ietf-sfc-multi-layer-oam

Hi Dirk,
thank you so much for the review and your suggestions. All are very helpful and are accepted with much appreciation. (I've noticed misalignment in Figure 10 when I followed your comment).
I've added a figure in Section 6.4.1 illustrating the sub-TLV encoding of the errored TLV.
Attached, please find the new working version and the diff highlighting the changes (most are resulting from the added figure). I hope that the updates address your comments.

Best regards,
Greg

On Thu, Nov 4, 2021 at 8:54 AM <[email-masked]<mailto:[email-masked]>> wrote:
Dear all,
I have quickly checked and reviewed the document and think it is well written and quite completely describes the requirements and exemplary OAM messages for SFC. My only comment would be for sect. 6.3.1.<http://6.3.1.>:

Thanks!
Best regards
Dir[k
-----Original Message-----
From: sfc <[email-masked]<mailto:[email-masked]>> On Behalf Of Joel Halpern Direct
Sent: Montag, 1. November 2021 19:51
To: [email-masked]<mailto:[email-masked]>
Cc: James Guichard <[email-masked]<mailto:[email-masked]>>; Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Subject: [sfc] Regarding last call for draft-ietf-sfc-multi-layer-oam

Thank you,
Joel

---

From: Huzhibo <[email-masked]>
Date: Fri, 26 Nov 2021 02:10:15 +0000

Hi WG：

   Support . Troubleshooting SFC is a complex tax for operators and having additional OAM capabilities that can provide value to operators in E2E SFC troubleshooting is a major gain for operators.

Best regards

Zhibo

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Joel Halpern Direct
Sent: Tuesday, November 2, 2021 2:51 AM
To: [email-masked]
Cc: James Guichard <[email-masked]>; Greg Mirsky <[email-masked]>
Subject: [sfc] Regarding last call for draft-ietf-sfc-multi-layer-oam

Thank you,
Joel

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 26 Nov 2021 12:37:18 -0800

Hi Frank,
many thanks for your comments and suggestions. Please find my follow-up
notes in-line below tagged by GIM2>>. Top-posting the current version of
the O-bit related text:
NEW TEXT:
The rules for
   interpreting the values of the O bit and the "Next Protocol" field
   are as follows:

         - An SFC NSH Context Header(s) contain an OAM processing
         instructions or data.

   *  O bit is clear:

         - No active OAM in an SFC NSH Context Header(s).

What is your opinion of the current version?

Regards,
Greg

On Wed, Nov 24, 2021 at 9:53 AM Frank Brockners (fbrockne) <
[email-masked]> wrote:

> *Sent:* Wednesday, 24 November 2021 00:30
> …FB: Thinking about things again – “OAM processing instructions” might be
> a better term than “OAM command”. Thoughts?
>
GIM2>> Yes, it is better. Accepted.

> …FB: Could we be specific and say “No active OAM in the…” ?
GIM2>> I agree. Done.

> …FB: Per the note above – in general terms, I would assume that the O-bit
> indicates that the packet is an **active** OAM packet. NSH may or may not
> know whether the NSH payload is active OAM. Rather than having NSH
> “speculate” what is in the payload (which might be encrypted), wouldn’t it
> make sense to tie the O-bit to **active OAM for NSH** - which could be
> draft-ietf-sfc-multi-layer-oam, or eventually a future spec? That way, the
> spec would be about NSH and its OAM solution – rather than try to provide
> information about something that NSH does not control and might not even
> know.
>
GIM2>> I think that the O bit, with the updated text in
draft-ietf-sfc-multi-layer-oam, can indicate not only active OAM in NSH
payload but OAM in Context Header(s). And both cases can be clearly
disambiguated based on the value of the Next Protocol field. True, so far
there are no cases of OAM use of the NSH Context Header but something might
be specified in the future. I think that, with a great deal of your help,
the definition of the O bit is clear and future-proof.

---

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Fri, 26 Nov 2021 21:07:10 +0000

Hi Greg,

Thanks. The below text looks good to me.

Cheers, Frank

Sent: Friday, 26 November 2021 21:37

Hi Frank,
many thanks for your comments and suggestions. Please find my follow-up notes in-line below tagged by GIM2>>. Top-posting the current version of the O-bit related text:
NEW TEXT:
The rules for
   interpreting the values of the O bit and the "Next Protocol" field
   are as follows:

   *  O bit is clear:

Regards,
Greg

On Wed, Nov 24, 2021 at 9:53 AM Frank Brockners (fbrockne) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg,

Hi Frank,

   *  O bit is clear:

…FB: Per the note above – in general terms, I would assume that the O-bit indicates that the packet is an *active* OAM packet. NSH may or may not know whether the NSH payload is active OAM. Rather than having NSH “speculate” what is in the payload (which might be encrypted), wouldn’t it make sense to tie the O-bit to *active OAM for NSH* - which could be draft-ietf-sfc-multi-layer-oam, or eventually a future spec? That way, the spec would be about NSH and its OAM solution – rather than try to provide information about something that NSH does not control and might not even know.
GIM2>> I think that the O bit, with the updated text in draft-ietf-sfc-multi-layer-oam, can indicate not only active OAM in NSH payload but OAM in Context Header(s). And both cases can be clearly disambiguated based on the value of the Next Protocol field. True, so far there are no cases of OAM use of the NSH Context Header but something might be specified in the future. I think that, with a great deal of your help, the definition of the O bit is clear and future-proof.

Cheers, Frank

What are your thoughts?

Regards,
Greg

Please see inline.

Hi Frank,

Cheers, Frank

Regards,
Greg

Hi Frank,

   *  O bit is clear:

NEW TEXT:

   *  O bit is clear:

Thanks again, Frank

Regards,
Greg

Thanks, Frank

Hi, Gyan,

Best,

Carlos.

Hi Carlos

Responses in-line

I hope all is well!

Many Thanks!!

Gyan

Best,

Carlos.

Dear Chairs & All

Kind Regards

Gyan
Verizon

Dear Carlos,

Regards,

Abstract

   Active OAM tools,

   in Section 6.

   and 4.3 of [RFC8924].

   The ingress may be

   The rules for

   are as follows:

      (TBA1).

CMP: How?

         OAM command or data.

   *  O bit is clear:

         Context Header(s).

         present.

   payload.

5.  Active SFC OAM Header

   presented in Figure 3.

      octets.

6.3.1.  Source TLV

6.4.1.  Errored TLVs TLV

   Table 14.

CMP: Best,

CMP: — Carlos.

9.7.  SF Identifier Types

Thanks,

Carlos.

Thank you,
Joel

---

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Fri, 26 Nov 2021 21:09:15 +0000

Hi Carlos,

Personally I don’t see a strong need to evolve the definition of the O-bit – but if the working group decides to do so, IMHO it would be good to ensure that the O-bit indeed signals the fact that active OAM information related to NSH is carried.

Cheers, Frank

From: Carlos Pignataro (cpignata) <cpignata=[email-masked]>
Sent: Tuesday, 23 November 2021 15:44
To: Frank Brockners (fbrockne) <[email-masked]>
Cc: Greg Mirsky <[email-masked]>; Gyan Mishra <[email-masked]>; James N Guichard <[email-masked]>; [email-masked]; Joel Halpern Direct <[email-masked]>
Subject: Re: [sfc] Regarding last call for draft-ietf-sfc-multi-layer-oam

Frank, Greg,

Thanks,

Carlos.

Hi Greg,

Hi Frank,

   *  O bit is clear:

NEW TEXT:

   *  O bit is clear:

Thanks again, Frank

Regards,
Greg

Thanks, Frank

Hi, Gyan,

Best,

Carlos.

Hi Carlos

Responses in-line

I hope all is well!

Many Thanks!!

Gyan

Best,

Carlos.

Dear Chairs & All

Kind Regards

Gyan
Verizon

Dear Carlos,

Regards,

Abstract

   Active OAM tools,

   in Section 6.

   and 4.3 of [RFC8924].

   The ingress may be

   The rules for

   are as follows:

      (TBA1).

CMP: How?

         OAM command or data.

   *  O bit is clear:

         Context Header(s).

         present.

   payload.

5.  Active SFC OAM Header

   presented in Figure 3.

      octets.

6.3.1.  Source TLV

6.4.1.  Errored TLVs TLV

   Table 14.

CMP: Best,

CMP: — Carlos.

9.7.  SF Identifier Types

Thanks,

Carlos.

Thank you,
Joel

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 26 Nov 2021 13:19:03 -0800

Many thank for the discussion and your suggestions. I'll upload the new
version with updates addressing comments from you, Dirk, Donald, and Linda.
We will continue working on the new Operational Consideration section as
suggested by Carlos.

Regards,
Greg

On Fri, Nov 26, 2021 at 1:07 PM Frank Brockners (fbrockne) <
[email-masked]> wrote:

> *Sent:* Friday, 26 November 2021 21:37

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Sat, 27 Nov 2021 03:10:38 +0000

Thank you Frank and Greg — what is the actual behavioral change in the proposed redefinition of the O-bit from the processing and rules defined in RFC8300?

Thanks,

Carlos.

On Nov 26, 2021, at 4:09 PM, Frank Brockners (fbrockne) <fbrockne=[email-masked]<mailto:fbrockne=[email-masked]>> wrote:

Hi Carlos,

Cheers, Frank

From: Carlos Pignataro (cpignata) <cpignata=[email-masked]<mailto:cpignata=[email-masked]>>
Sent: Tuesday, 23 November 2021 15:44
To: Frank Brockners (fbrockne) <[email-masked]<mailto:[email-masked]>>
Cc: Greg Mirsky <[email-masked]<mailto:[email-masked]>>; Gyan Mishra <[email-masked]<mailto:[email-masked]>>; James N Guichard <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Joel Halpern Direct <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sfc] Regarding last call for draft-ietf-sfc-multi-layer-oam

Frank, Greg,

Thanks,

Carlos.

Hi Greg,

Hi Frank,

   *  O bit is clear:

NEW TEXT:

   *  O bit is clear:

Thanks again, Frank

Regards,
Greg

Thanks, Frank

Hi, Gyan,

Best,

Carlos.

Hi Carlos

Responses in-line

I hope all is well!

Many Thanks!!

Gyan

Best,

Carlos.

Dear Chairs & All

Kind Regards

Gyan
Verizon

Dear Carlos,

Regards,

Abstract

   Active OAM tools,

   in Section 6.

   and 4.3 of [RFC8924].

   The ingress may be

   The rules for

   are as follows:

      (TBA1).

CMP: How?

         OAM command or data.

   *  O bit is clear:

         Context Header(s).

         present.

   payload.

5.  Active SFC OAM Header

   presented in Figure 3.

      octets.

6.3.1.  Source TLV

6.4.1.  Errored TLVs TLV

…

   Table 14.

CMP: Best,

CMP: — Carlos.

9.7.  SF Identifier Types

Thanks,

Carlos.

Thank you,
Joel

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 26 Nov 2021 19:30:17 -0800

Dear Carlos,
I believe that the proposed new text clarifies several aspects of O bit:

   - active SFC NSH OAM packet is identified by the combination of O bit
   set and the value of the NSH' Next Protocol field is Active SFC OAM;
   - the combination of O bit clear and the Next Protocol set to the Active
   SFC OAM value - erroneous and must be reported;
   - O bit set and the Next Protocol is not Active SFC OAM - Context
   Header(s) include OAM processing instructions or data.

Would you agree that these are helpful clarifications?

Regards,
Greg

On Fri, Nov 26, 2021 at 7:10 PM Carlos Pignataro (cpignata) <
[email-masked]> wrote:

> Thank you Frank and Greg — what is the actual behavioral change in the
> proposed redefinition of the O-bit from the processing and rules defined in
> RFC8300?
>
> Thanks,
>
> Carlos.
>
> On Nov 26, 2021, at 4:09 PM, Frank Brockners (fbrockne) <
> fbrockne=[email-masked]> wrote:
>
> Hi Carlos,
>
> Personally I don’t see a strong need to evolve the definition of the O-bit
> – but if the working group decides to do so, IMHO it would be good to
> ensure that the O-bit indeed signals the fact that active OAM information
> related to NSH is carried.
>
> Cheers, Frank
>
> *From:* Carlos Pignataro (cpignata) <cpignata=[email-masked]>
> *Sent:* Tuesday, 23 November 2021 15:44
> *Cc:* Greg Mirsky <[email-masked]>; Gyan Mishra <
> [email-masked]>; James N Guichard <[email-masked]>;
>  [email-masked]; Joel Halpern Direct <[email-masked]>
> 11/23/21 午前9:33、Frank Brockners (fbrockne) <
> fbrockne=[email-masked]>のメール:
>
> Hi Greg,
>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Sat, 27 Nov 2021 04:17:58 +0000

Dear Greg,

I disagree. My perspective is that they go from not helpful to plain harmful.

Let’s look at those three aspects one-by-one (changing the bulleted list into a numbered list for ease of tracking):

  1.  This is no different than RFC 8300. The O bit specifies the packet being OAM, the Next Protocol specifies the type of packet which can be “Active SFC OAM”
     *   Stating however that the identification is based on a combination of fields is incorrect.
  2.  This is not a generic behavior that needs specifying or updating. It is part of the specific NSH Next Protocol value behavior for the NSH Next Protocol being defined as “Active SFC OAM”.
  3.  This is incorrect and a serious over-reach. Specifically:
     *   If the O bit is set and the Next protocol is not “Active SFC OAM”, the definition is much beyond the scope of this document — since this document specifies behaviors for one specific SFC OAM protocol which is “One Active SFC OAM” (name to be narrowscoped as per other pending thread)
     *   If the O bit is set and the Next protocol is not “Active SFC OAM”, and this document somehow concludes that the OAM is in the Context Header, then it is:
        *   Breaking other OAM protocols including other Active SFC OAM protocols encapsulated in IPv4, in IPv6, SFC Trace. It is valid to have O=1, NSH NP as IPv4, and an OAM packet encapsulated.
        *   Breaking the use of context headers, since they need context that ought to equally apply to OAMs and to data packets, as for example a Flow Label, a Forwarding context, etc. Re-writing Context Headers breaks that.

I’d encourage the WG, shepherd, and WG Chairs to more closely inspect and review this document, specifically whether is defining one SFC Active OAM protocol, or breaking functionality while redefining base RFC 8300 behavior.

Although these were brought up before, highlighting a couple of comments:

1.  Introduction
   Also, this document updates Section 2.2 of [RFC8300] in part of the
   definition of O bit in the NSH.

CMP: I do not see the need to redefine the O bit in the NSH.

CMP: There is, as shown above, no need for this.

CMP: As shown above, this 1. breaks functionality (e.g., Flow Label in context) and 2. has absolutely *no* need to be included in this specific OAM protocol document.

5.  Active SFC OAM Header

   This document defines Active OAM Header
   (Figure 2) to demultiplex active OAM protocols on an SFC.

CMP: The identification of OAM protocols is already solved directly in RFC 8300 by using the NSH Next Protocol.
CMP: This meta-header is redundant at best.

CMP: First, why would BFD be carried as “One SFC Active OAM protocol” -> G-ACh-like meta-header with BFD Msg Type?
CMP: Second, I believe this also explains that what this document is defining is the “Echo Request/Reply” Active OAM Protocol.

CMP: Since the name of the active OAM protocol defined in this document is "Echo Request/Reply”, could I please request to:
CMP: 1. Provide a more specific name (since Echo Request/Reply can easily be confused with using ICMP)
CMP: 2. Rename the title of this document to clearly define its scope for one specific SFC Active OAM protocol, by name, and not all Active OAM Protocols?

Best,

Carlos.

On Nov 26, 2021, at 10:30 PM, Greg Mirsky <[email-masked]<mailto:[email-masked]>> wrote:

Dear Carlos,

  *   active SFC NSH OAM packet is identified by the combination of O bit set and the value of the NSH' Next Protocol field is Active SFC OAM;
  *   the combination of O bit clear and the Next Protocol set to the Active SFC OAM value - erroneous and must be reported;
  *   O bit set and the Next Protocol is not Active SFC OAM - Context Header(s) include OAM processing instructions or data.

Regards,
Greg

On Fri, Nov 26, 2021 at 7:10 PM Carlos Pignataro (cpignata) <[email-masked]<mailto:[email-masked]>> wrote:
Thank you Frank and Greg — what is the actual behavioral change in the proposed redefinition of the O-bit from the processing and rules defined in RFC8300?

Thanks,

Carlos.

Hi Carlos,

Cheers, Frank

Frank, Greg,

Thanks,

Carlos.

Hi Greg,

Hi Frank,

   *  O bit is clear:

NEW TEXT:

   *  O bit is clear:

Thanks again, Frank

Regards,
Greg

Thanks, Frank

Hi, Gyan,

Best,

Carlos.

Hi Carlos

Responses in-line

I hope all is well!

Many Thanks!!

Gyan

Best,

Carlos.

Dear Chairs & All

Kind Regards

Gyan
Verizon

Dear Carlos,

Regards,

Abstract

   Active OAM tools,

   in Section 6.

   and 4.3 of [RFC8924].

   The ingress may be

   The rules for

   are as follows:

      (TBA1).

CMP: How?

         OAM command or data.

   *  O bit is clear:

         Context Header(s).

         present.

   payload.

5.  Active SFC OAM Header

   presented in Figure 3.

      octets.

6.3.1.  Source TLV

6.4.1.  Errored TLVs TLV

…

   Table 14.

CMP: Best,

CMP: — Carlos.

9.7.  SF Identifier Types

Thanks,

Carlos.

Thank you,
Joel