Re: [Last-Call] [sfc] Last Call: <draft-ietf-sfc-oam-framework-11.txt> (Service Function Chaining (SFC) Operations, Administration and Maintenance (OAM) Framework) to Informational RFC

Greg Mirsky <gregimirsky@xxxxxxxxx> · Thu, 9 Apr 2020 15:04:20 -0700

Dear All,
I have reviewed the draft and wanted to share my comments on the draft-ietf-sfc-oam-framework. Please find them organized into two sections - general and according to the text of the draft.
General:
SFC OAM Architecture
The document includes three components in the SFC OAM architecture: Service Function (SF), Service Function Chain (SFC), which is equivalent to the collection of all SFPs, and Classifier. Firstly, making SFC OAM a component of SFC OAM appears as an unfortunate selection of terminology that might be a source of confusion and misinterpretation (how one identifies the context of using "SFC OAM"?). The inclusion of an SF in the SFC OAM reference model is to provide the ability to verify "whether the SF is providing its intended service". Such a goal appears as a layer violation, in part of OAM, since the verification of the correctness of a service provided by the SFC is in the scope of Service OAM to which SFC OAM plays the role of transport OAM. In addition, the document notes that the fact of existing and deployed SFs is likely to leave SF OAM being implementation-specific. Combining these two aspects, the inclusion of the SF OAM component in the SFC OAM reference model is questionable as it doesn't seem to provide a good opportunity for the standardization given, on one hand, the lack drafts and, on the other hand, the growing number of deployed implementations. Figure 2 that illustrates SFC OAM components does not provide clarity to the relationships between SFC OAM and SF OAM components of the reference model as SF OAM is depicted both as the separate entity as well as part of SFC OAM component.

The interpretation of 'availability' in SFC OAM
The document extensively discusses an SFC OAM characteristic, availability sections on SF and SFC availability, as well as references to the particular OAM tool as being capable to check the availability). Availability is well-defined for some technologies, e.g. constant bit-rate paths, while not being used at all in many other networking technologies, e.g., packet switching networks. The definition of the availability for the constant bit-rate paths can be found in G.826. The specification firstly defines the opposite, the state of unavailability. Also, note that both states of unavailability and availability are defined as being continuous in time, at least 10 seconds interval long. I couldn't find any definition of the availability in IETF documents I'm familiar with. The most comprehensive IETF document on OAM, RFC 7276, doesn't use the availability as one of the OAM states or performance metrics detected or measured by OAM methods analyzed in it. The draft-ietf-sfc-oam-framework uses the term 'availability' in many places referring to the availability of SFC elements like SFF and SF without providing the definition. As a result, it is not clear what the availability of SFC OAM is and how it can be detected or measured. It appears that the term in this document is being used colloquially rather than as the technical terminology. Such a manner of using terminology does affect the technical accuracy of the document and very likely leave a reader familiar with the existing definitions of the term in a state of confusion.

Going through the text:
section 3.1.1 in the last paragraph states:
   This framework document provides a RECOMMENDED framework where a
   generalized approach is taken to verify that a SF is sufficiently
   available (i.e., an adequate granularity to provide a basic SF
   service). 
That "RECOMMENDED framework" seems like a deviation from the scope of the document defined in the Abstract and Document Scope:
   The focus of this document is to provide an architectural framework
   for SFC OAM, particularly focused on the aspect of the Operations
   component within OAM.
the definition of connectivity in Section 4.1 appears as using circular logic by defining itself through connectivity verification whereas it is a composition of verifying that packets that belong to the monitored flow are reaching the egress node and only packets that belong to that flow are received by the egress (the case when a packet that belongs to a different flow is detected constitutes miscommunication defect and may lead to miscommunication state).
also in Section 4.1, the path MTU discovery and monitoring, packet re-ordering and/or corruption, arbitrary path monitoring are misattributed to connectivity verification function
notification to other application (Section 4.2) is not part of OAM and is implementation-specific
'PM' in PM OAM is usually expanded as 'Performance Monitoring', sometimes 'Performance Measurement". Used in the document "Performance Management" is extremely unusual, if not misleading.
In Section 4.4 delay variance (variation)/jitter is listed as a measurable performance metric even though it can be only calculated using a set of delay measurements. On the other hand, most performance monitoring active OAM protocols are well-equipped to detect packet re-ordering, unwarranted packet duplication.
Further in Section 4, jitter, i.e. delay variation is being mentioned as a measurable performance metric. That is not the case. Latency, i.e. delay, is a measurable metric but jitter (delay variation) can only be calculated.
Table 3 in Section 5.1 raises several questions:
Is listing E-OAM is to suggest that an overlay network supporting SFC NSH can be instantiated directly over the Ethernet network? Can you illustrate that with an example?
It appears that some of the information presented in Table 3 contradicts other material in the draft, for example, Section 6.4.1. The section indicates that ICMP may be used as a connectivity verification tool for both SF and SFC OAM.
In Section 6.4.1 ICMP is positioned as a suitable mechanism to "test the network reachability" (that seems like a new OAM function being introduced in the section). Because SFC can be realized over a number of combinations of underlay and overlay technologies, I believe, an example (or a couple of examples would be much better) demonstrating the encapsulation of an ICMP message and, particularly, triggering ICMP Echo Reply on the proper element of the SFP. I have to admit, I couldn't imagine the encapsulation that would make ICMP-over-SFC work as IP Ping/traceroute.
Section 6.4.2 makes the positioning statement for BFD and S-BFD as follows:
BFD or S-BFD could be leveraged to perform continuity function for SF or SFC.
The statement, in regard to BFD, contradicts with RFC 5880 which explains the goal of BFD as follows:
   ... a protocol intended to detect faults in the
   bidirectional path between two forwarding engines, including
   interfaces, data link(s), and to the extent possible the forwarding
   engines themselves ...
And the text in the second paragraph on Section 6.4.2 appears to describe a way of using S-BFD, not of BFD.
Section 6.4.3 suggests that iOAM could be used "perform SF availability and SFC availability or performance measurement". I agree with that statement in part of performance measurement but the references to the "SF availability and SFC availability", without the definition of availability in the context of SFC OAM, appear as not sufficiently justified.
Section 6.4.4 makes a reference to an individual draft that was last updated some four and a half years ago. It appears that such a long time is an indication of a lack of interest to work on the proposed solution by the authors or anyone else..
Section 7 and, in particular, Table 4 seems as not closely relevant to the subject or OAM. Especially since the title of Table 4 is not reflecting the content of the table itself. RFC 6291 recommends using Mgmt acronym for Management and O&M - for OAM and Management. Acronym OAM is recommended to be expanded and used in the IETF document solely for Operations, Administration, and Maintenance.

Summarizing my comments, I find so many problematic parts in the text that I've to question the usefulness of the requirement in the Introduction
   SFC OAM solution documents should refer to this document to indicate
   the SFC OAM component and the functionality they target.
and the value of publishing this document in its current form.

Regards,
Greg

---------- Forwarded message ---------
From: The IESG <iesg-secretary@xxxxxxxx>
Date: Thu, Mar 26, 2020 at 8:47 AM
Subject: [sfc] Last Call: <draft-ietf-sfc-oam-framework-11.txt> (Service Function Chaining (SFC) Operations, Administration and Maintenance (OAM) Framework) to Informational RFC
To: IETF-Announce <ietf-announce@xxxxxxxx>
Cc: <sfc-chairs@xxxxxxxx>, <draft-ietf-sfc-oam-framework@xxxxxxxx>, <martin.vigoureux@xxxxxxxxx>, <tal.mizrahi.phd@xxxxxxxxx>, <sfc@xxxxxxxx>

The IESG has received a request from the Service Function Chaining WG (sfc)
to consider the following document: - 'Service Function Chaining (SFC)
Operations, Administration and
   Maintenance (OAM) Framework'
  <draft-ietf-sfc-oam-framework-11.txt> as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@xxxxxxxx mailing lists by 2020-04-09. Exceptionally, comments may
be sent to iesg@xxxxxxxx instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract

   This document provides a reference framework for Operations,
   Administration and Maintenance (OAM) for Service Function Chaining
   (SFC).

The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-sfc-oam-framework/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-sfc-oam-framework/ballot/

The following IPR Declarations may be related to this I-D:

   https://datatracker.ietf.org/ipr/3440/
   https://datatracker.ietf.org/ipr/3121/

_______________________________________________
sfc mailing list
sfc@xxxxxxxx
https://www.ietf.org/mailman/listinfo/sfc
-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call