Re: [sfc] WG Last Call draft-ietf-sfc-oam-framework-06

[Greg Mirsky <[e-mail]>]

Dear Authors, Jim, Joel, et al.,
please find my comments to this draft below:

   - Section 2
      - An SFC layering model is introduced. I couldn't find it being
      mentioned in section 1.1, where the scope of the document is defined.
      - What VMx symbolize in Figure 1? To which layer of SFC they belong?
      - What is being symbolized by 'o' in Overlay network, Underlay
      network, and Link layers respectively?
      - What is the purpose of Figure 1 outside Section 2
      - what is the purpose of Section 2? For only one sentence in Section
      3 that states the obvious:

The SFC operates at the service layer.


   - Section 3
      - In "testing the service functions from any SFC-aware network
      devices (i.e.classifiers, controllers, other service nodes)", what is the
      scope of testing expected? Testing, for example, NAT? Also, what
are "other
      service nodes"? Neither RFC 7665 nor this draft define service
nodes in SFC.
      - In "validate the correlation between a Service Function Chain and
      the actual forwarding path followed by a packet matching that SFC, etc.",
      is "the actual forwarding path followed" Rendered Service Path? If it is
      so, then what is validated? That RSP is part of SFP? Also, what "etc."
      refers to? Anything else?
      - Figure 2, SF OAM. I can envision a Controller generating test
      packets for the specific SF, SF3 in the figure. But where OAM
packets come
      from for SF3 and SF5 (line interconnecting two SFs)?
   - Section 3.1.1
      - I hoped to find the definition of availability, which is a
      performance metric, and how it is measured in SFC OAM. For example, MEF
      defines Availability Performance in MEF 10.3 (it's rather
lengthy to quote
      all, so just two sentences):

Availability Performance is the percentage of time within a specified time
interval *T* during which the Frame Loss Ratio is small.

Availability Performance is based on Service Frame loss during a sequence
of consecutive small time intervals.


   - Section 3.1.2
      - It opens with "Second SFC OAM requirement ..." but I couldn't find
      where the first requirement was listed.
      - Then the text explains that the scope of performance measurement of
      a service function component is "check the loss and delay induced by a
      specific service function". Would delay variation be of interest
too? Also,
      as noted above, availability is another performance metric that
      characterizes the loss ratio over a period of time. Should it be
discussed
      in the same paragraph or this paragraph title specifically refer to loss
      and delay performance metrics since only these two metrics being
discussed?
   - Section 3.2.1
      - The text slides into the discussion of path connectivity
      verification and tracing RSPs. These are essential OAM functions but, I
      believe, are not part of measuring the availability of an SFC.
   - Section 3.3
      - Is validation of a Classifier functioning is all that is required
      in Classifier OAM? Where are Classifier performance metrics, e.g., loss
      ratio, delay, and availability?
   - Section 4
      - In the first sentence s/is/are
      - Could you kindly help me understand "which many will be applicable
      to"?
      - "Various SFC OAM requirements listed in Section 3
      <https://tools.ietf.org/html/draft-ietf-sfc-oam-framework-06#section-3>"
      I found only one explicitly called out, in Section 3.1.2. Where
are others?
      - "Many of the OAM functions at different layers are already defined
      and in existence." Could you please support this statement with
references?
      - Besides s/service/the service/ something else seems missing in the
      closing of the sentence "In order to apply such OAM functions at service
      layer, they have to be enhanced to operate a single SF/SFF to multiple
      SFs/SFFs in an SFC and also in multiple SFCs."
      - Section 4.1
      - I think that the first sentence be would be clearer if it opens
      with "Connectivity verification ..."
      - I cannot agree that "Connectivity is mainly an on-demand function".
      If that's your view, in which category you place CFM (IEEE
802.1ag)? Also,
      ping is not actual connectivity verification function as it
doesn't detect
      misconnection.
      - In the last bullet, is it suggesting to use ping as proactive CC?
   - Section 4.2
      - CC OAM, e.g., BFD, does not monitor a device but, using positioning
      statement from RFC 5880, "path between two forwarding engines, including
      interfaces, data link(s), and to the extent possible the
forwarding engines
      themselves."
      - The last bullet reads awkwardly "Notifying the failure upon failure
      detection for other OAM functions to take appropriate action." Also, can
      other applications receive failure notification?
   - Section 4.3
      - I think that the first two bullets should apply to any arbitrary
      set of SFC elements, not only to every component of the given SFC.
   - Section 4.4
      - I think that the second sentence can be improved by
      s/measurements/performance metrics/, so that it reads "These performance
      metrics could be measured pro-actively and on-demand."
      - Second para, first sentence. s/perform/measure/?
      - What the third and fourth sentences of the second para trying to
      convey? What is "approximation of packet loss"? Can you define it or give
      the reference to the definition of this performance metric?
      - The definition of a delay in SFC in the third para is confusing.
      What does it mean "delay is measured from time"? And when the second
      timestamp at the egress SFF should be taken?
      - Delay variation, I believe, is calculated, not measured.
      - What are resolution and accuracy for the delay and delay variation
      SFC PM OAM tools are required to provide, given that you expect
to measure
      them for an SF? I believe that would be very helpful to state in the
      document.
      - Also, considering the scale of measuring a delay introduced by an
      SF, what are the methods of obtaining accurate ToD?
   - Section 5.1
      - Again, regarding "connectivity" and "continuity". None of IP, MPLS
      (except MPLS-TP), or overlay OAM tools so far provides actual
connectivity
      verification. If these terms are used interchangeably in this document,
      that must be clearly stated. Alternatively, definitions of terms must be
      provided, preferably with references to well-established in the industry
      documents.
      - Information in Table 3 is outdated. With SFC WG draft on Active
      OAM, Ping and Trace columns must be set to Yes.
      - Why in Table 4 Netconf is not listed in the Notification column?
      - Assuming SF and SFC have data models and thus can be configured
      using, for example, Netconf. Why the same models cannot be used for
      orchestration? And how certain you are that there are no TOSCA models for
      orchestration?
      - What prevents an implementation of SF or SFC from generating syslog
      notification?
   - Section 6.1
      - It refers only to RFC 8300 SFC NSH. Any consideration is given
      for RFC 8595 An MPLS-Based Forwarding Plane for Service Function Chaining?
   - Section 6.2
      - RFC 5880 has no definition for "BFD reply packet". Please clarify.
   - Section 6.4.1
      - Without clear definition of the terms "SFF availability" and "SF
      availability" it is hard to agree that ICMP can be used to measure this
      performance metric (see my notes at the top).
      - "...it can be used for basic OAM functions." Could you provide the
      reference to the document that defines the list of "basic OAM functions".
      Or provide the list itself in this draft.
   - Section 6.4.2
      - Applicability of S-BFD is discussed but not of BFD, as defined in
      RFC 5880. I couldn't find the explanation for excluding BFD from
      consideration.
   - Section 6.4.3
      -    Without the definition of availability for this draft, the
      following statement is subjective, at best "In-Situ OAM could be
used with
      O bit set and perform SF availability, SFC availability of performance
      measurement."
      - Section 6.4.4
      - Clearly is missing reference to draft-ietf-sfc-multilayer-oam.
      Surprisingly, the sectin refers to the draft that expired April 2, 2016.

 After reviewing how fundamental are outstanding, in my opinion, questions,
how numerous are problems with the text and how many statements are not
supported by definitions or proper references, I believe that the document
cannot be published in its current form.

Regards,
Greg


On Tue, May 28, 2019 at 7:37 AM James Guichard <
[e-mail]> wrote:

> Dear WG:
>
>
>
> This message starts a new two week WG Last Call on advancing
> https://datatracker.ietf.org/doc/draft-ietf-sfc-oam-framework/
> <https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-sfc-oam-framework%2F&data=02%7C01%7Cjames.n.guichard%40futurewei.com%7Ce47e5eb13f224f18c46408d6e378b2f7%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636946504868870205&sdata=lkKvAgmKik7lkqGANQpnIvBRdbjKAqYtzTUdTfB9f3Y%3D&reserved=0>
> for publication as an Informational RFC.
>
>
>
> Substantive comments and statements of support for publishing this
> document should be directed to the mailing list. Editorial suggestions can
> be sent to the authors.  This last call will end on 11th June 2019.
>
>
>
> Thanks!
>
>
>
> Jim & Joel
>
>
>
>
> _______________________________________________
> sfc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sfc
>