Re: [sfc] Comments on draft-ietf-sfc-oam-framework

[Greg Mirsky <[e-mail]>]

Hi Carlos,
I believe that RFC 5880, that uses the "liveness" term technically only
three times, hardly can be characterized as the document that "introduced
"liveness". More so, RFC 5880 considers BFD, failure detection protocol, as
the mechanism to monitor liveness. BFD, being the active OAM Fault
Management protocol, is the right tool and interchangeable use of
"liveness" and "failure detection", in my view, is appropriate. As for
"availability", RFC 5880 uses the term only once.  And so, for example, RFC
8029 - one time for "availability, one time for "liveness". And these are
both active FM OAM tools. But the draft we're discussing suggests that
availability, or liveness, if you prefer, can be measured by a hybrid OAM,
i.e., in-situ OAM as a performance metric
   In-Situ OAM could be used with O bit set and perform SF availability,
   SFC availability of performance measurement.
Hence, whether it is referred to as availability or liveness and since IPPM
WG, as you've correctly have noted in your suggestion, has not yet formally
defined it, how In-Situ OAM does measure it for SF and/or SFC?

Regards,
Greg

On Mon, Jun 17, 2019 at 10:59 AM Carlos Pignataro (cpignata) <
[e-mail]> wrote:

> Hi, Greg,
>
> Now that I understand your concern, please find inline my final set of
> replies on the single remaining comment, closing this thread from my side.
>
> On Jun 16, 2019, at 1:21 AM, Greg Mirsky <[e-mail]> wrote:
>
> Hi Carlos,
> please find my followup comments in-line tagged GIM2>>.
> Looking forward to the updated draft.
>
> Regards,
> Greg
>
> On Sun, Jun 16, 2019 at 12:33 PM Carlos Pignataro (cpignata) <
> [e-mail]> wrote:
>
>> Hello, Greg,
>>
>> > On Jun 10, 2019, at 2:49 AM, [e-mail] wrote:
>> >
>> > Hi Carlos,
>> > thank you for your expedient response to my comments.
>>
>> You are welcome.
>>
>> > I'll be expecting updated text to review how my comments were addressed.
>>
>> Thanks in advance for, after a new revision is posted, verifying we are
>> not missing any typographical correction; and thanks again for the thorough
>> set of editorial comments.
>>
>> > In the meantime, you seemed to equate availability and uptime in the
>> following response:
>> > "Section 3.1.1 is about availability / uptime ..."
>> > Is my understanding of your response is correct and you believe that
>> availability is another term for uptime and both can be used
>> interchangeably?
>>
>> Greg, first, “/“ does not mean “equate”. Where did I write that those two
>> terms are equal, and can be used interchangeably? Where did you conjure
>> that understanding from? Please, again, refrain for putting words that I
>> did not write in my response.
>>
> GIM2>> I've asked for clarification, nothing else. If you consider
> "availability" is a different metric from uptime, then I hope the draft
> will explain how it is measured, e.g., second, meters, packets or else.
>
>>
>> Second, taking half a sentence out of context is not the best way to
>> clarify understanding.
>>
>> Third, in regards to your comment on “availability", I asked you this:
>>         "If you have a specific suggestion as a replacement for
>> “availability’, please share.”
>> But you chose to not share a suggestion.
>>
> GIM2>> On the contrary. In my first comments, I've referenced the MEF
> document that includes the definition of the availability of ME service. As
> I understand, you've dismissed it. Well, if you don't agree with my
> recommendation, then you surely have an idea of your own.
>
>>
>> Fourth, Section 3.1.1 explains the choice of term quite well:
>> https://tools.ietf.org/html/draft-ietf-sfc-oam-framework-06#section-3.1.1
>> Oversimplifying, somewhere in the continuum of liveness and full
>> functionality.
>>
> GIM2>> If you believe that the section you've referred to provides the
> adequate definition of the availability as a performance metric, then you
> would not be hard to provide the quote that explains how this metric is
> measured or calculated. The availability is the performance metric, you
> agree to that?
>
>
> Actually, this document is not defining performance metrics, nor treating
> availability as a performance metric.
>
> Consequently, comment out of scope and to me without merit.
>
> That said, we will review the usage of this term, and evaluate
> improvements (without recursing to crafting a strict metric definition on
> virtual stone).
>
>
>> If the WG believes that the latter is largely out of scope, we can
>> clarify that and use the former (i.e., liveness).
>>
> GIM2>> In that case, I'll ask the same questions about "liveness" - in
> what it is measured, how it is calculated.
>
>
> In fact, I believe the level of over-definition you are seeking as per a
> MEF document is not required nor needed in these kind of IETF documents
> defining a framework. In fact, not for many IETF documents defining
> protocols either.
>
> For example, RFC 5880 introduced “liveness”, many RFCs use “availability”
> and “high availability”.
>
> I recommend that, if you are looking for that definition, you can write a
> draft in IPPM, maybe citing and rationalizing from Y.1540 or elsewhere.
>
> Best,
>
> Carlos.
>
>
>> I trust that will help,
>>
>> Carlos.
>>
>>
>> >
>> > Regards,
>> > Greg
>> >
>> > Greg,
>> >
>> > Thank you for taking the time to review this important document.
>> >
>> > My analysis of your review is that the vast majority ((almost) all) of
>> your comments are editorial in nature — from typos to readability
>> suggestions. We will make updates to the document to address your comments
>> and suggestions, and thus improve the readability of the document.
>> >
>> > A new revision will address all the comments (all typos you called out,
>> editorial issues and improvements, except where there’s only a personal
>> editorial preference) as replied to below.
>> >
>> > From the less editorial: We will also add some text to clarify "BFD
>> applicability" and to clarity “Availability”, and all others have been
>> responded to below including whether there were references missing (BTW we
>> will move [ICMPv4] and [ICMPv6] as Informational as per Adrian’s comment).
>> >
>> > Please see inline for some specific answers.
>> >
>> > On Jun 8, 2019, at 1:11 PM, Greg Mirsky <[e-mail]<mailto:
>> [e-mail]>> wrote:
>> >
>> > 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.
>> >
>> > A model is explained, not introduced. This follows the SFC models.
>> >
>> >      *   What VMx symbolize in Figure 1? To which layer of SFC they
>> belong?
>> >
>> > Virtual Machine.
>> >
>> >      *   What is being symbolized by 'o' in Overlay network, Underlay
>> network, and Link layers respectively?
>> >
>> > What Adrian referred to as “legs”. We will slightly update this as per
>> Adrian’s comment.
>> >
>> >      *   What is the purpose of Figure 1 outside Section 2
>> >
>> > I do not understand this question.
>> >
>> >      *   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.
>> >
>> > I apologize I do no follow the meaning of your note. But, S2 explains
>> the model which is used in the doc, and “obvious” is in the eye of the
>> beholder. Note that IETF documents have cross functional review, might not
>> be obvious to all readers.
>> >
>> >   *   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.
>> >
>> > Good editorial point, we can change “service node” throughout the
>> document if it makes it easier, bu RFC 8300 does use the term “service
>> node”.
>> >
>> >      *   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?
>> >
>> > What is tested is the correlation. We can add RSP and remove the etc as
>> editorial comments.
>> >
>> >
>> >      *   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)?
>> >
>> > This figure is exemplary and ilustrative for highlighting the three
>> defined components.
>> >
>> >   *   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.
>> >
>> >
>> > I’m not sure of the relevance of the MEF comment, but solutions can
>> define what they measure.
>> >
>> > If you have a specific suggestion as a replacement for “availability’,
>> please share. However, I’ll say that “availability” is used in other RFCs
>> as a general term.
>> >
>> >   *   Section 3.1.2
>> >      *   It opens with "Second SFC OAM requirement ..." but I couldn't
>> find where the first requirement was listed.
>> >
>> > Section 3.1.1 begins with “One SFC OAM requirement”.
>> >
>> >
>> >      *   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.1.1 is about availability / uptime, Section 3.1.2. about
>> specific PM such as delay, loss.
>> >
>> >   *   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.
>> >
>> > Only Section 3.1.1 is about availability. Section 3.2.1 is parallel to
>> 3.1.1 and a different topic.
>> >
>> >   *   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?
>> >
>> > Are there specific OAM functions on the classifier that you believe are
>> missing? Do you believe delay in the classifier is important? Please share
>> some text about it.
>> >
>> >   *   Section 4
>> >      *   In the first sentence s/is/are
>> >
>> > Agreed. Thank you.
>> >
>> >      *   Could you kindly help me understand "which many will be
>> applicable to”?
>> >
>> > Yes. Many functions applicable to many components. We can reword for
>> ease of clarity.
>> >
>> >      *   "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?
>> >
>> > Section 3.1.1 for example.
>> >
>> >      *   "Many of the OAM functions at different layers are already
>> defined and in existence." Could you please support this statement with
>> references?
>> >
>> > We can do better — see Section 5.1.
>> >
>> >      *   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.”
>> >
>> > We will fix this editorial.
>> >
>> >   *   Section 4.1
>> >      *   I think that the first sentence be would be clearer if it
>> opens with "Connectivity verification …”
>> >
>> > It would be redundant with “ function to verify"
>> >
>> >      *   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.
>> >
>> > We can change to LSP Ping.
>> >
>> >      *   In the last bullet, is it suggesting to use ping as proactive
>> CC?
>> >
>> > No.
>> >
>> >   *   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.”
>> >
>> > Good point, we can remove “device"
>> >
>> >      *   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?
>> >
>> > We can reword if you find it confusing.
>> >
>> >   *   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?
>> >
>> > Yes, we can make these editorial suggestions above.
>> >
>> >      *   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?
>> >
>> > Can you please provide a definition?
>> >
>> >      *   Delay variation, I believe, is calculated, not measured.
>> >
>> > OK.
>> >
>> >      *   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.
>> >
>> > We are using IETF nomenclatures.
>> >
>> >      *   Information in Table 3 is outdated. With SFC WG draft on
>> Active OAM, Ping and Trace columns must be set to Yes.
>> >
>> > No. This table covers existing OAM Functions fully defined, and/or with
>> running code. This include OAM functions that can actually be used
>> (normatively in documents or in practice on an actual wire).
>> >
>> >      *   Why in Table 4 Netconf is not listed in the Notification
>> column?
>> >
>> > Good point! Will add.
>> >
>> >      *   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?
>> >
>> > If you know of any additional model, please share.
>> >
>> >      *   What prevents an implementation of SF or SFC from generating
>> syslog notification?
>> >
>> > Someone defining it and someone coding it?
>> >
>> >   *   Section 6.1
>> >      *   It refers only to RFC 8300 SFC NSH.
>> >
>> > See the last sentence of the Abstract of RFC 8300.
>> >
>> >      *   Any consideration is given for RFC 8595 An MPLS-Based
>> Forwarding Plane for Service Function Chaining?
>> >
>> > Do you have any suggestion beyond the existing text that says that
>> >    Any other overlay encapsulations used in future must have a way to
>> >    mark the packet as OAM packet.
>> >
>> >
>> >
>> >   *   Section 6.2
>> >      *   RFC 5880 has no definition for "BFD reply packet". Please
>> clarify.
>> >
>> > Typo. Will fix.
>> >
>> >   *   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.
>> >
>> > We will clarify these both editorially.
>> >
>> >   *   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.
>> >
>> > The text already mentions BFD, but we can expand a bit.
>> >
>> >   *   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.”
>> >
>> > See above.
>> >
>> >   *   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.
>> >
>> > Not surprising, and not missing. See above.
>> >
>> >  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.
>> >
>> > Thank you again for taking time to review this document. See above.
>> >
>> >
>> > Regards,
>> > Greg
>> >
>> >
>> > On Tue, May 28, 2019 at 7:37 AM James Guichard <
>> james.n.guichard@futurewei..com <[e-mail]><mailto:
>> [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.
>> >
>> > Please let me know if there’s anything that was missed on this reply.
>> >
>> > Thanks,
>> >
>> > Carlos.
>> >
>> > This last call will end on 11th June 2019.
>> >
>> >
>> >
>> > Thanks!
>> >
>> >
>> >
>> > Jim & Joel
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > sfc mailing list
>> > [e-mail]<mailto:[e-mail]>
>> > https://www.ietf.org/mailman/listinfo/sfc
>> > _______________________________________________
>> > sfc mailing list
>> > [e-mail]<mailto:[e-mail]>
>> > https://www.ietf.org/mailman/listinfo/sfc
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > Greg Mirsky
>> >
>> >
>> >
>> > Sr. Standardization Expert
>> > 预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R&D
>> Institute/Wireline Product Operation Division
>> >
>> >
>> >
>> >
>> > <9ae3e214c17d49ed935d87c674ba3ee2.jpg>
>> <24242e5637af428891c4db731e7765ad.jpg>
>> > E: [e-mail]
>> > www.zte.com.cn
>>
>> _______________________________________________
>> sfc mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/sfc
>>
> _______________________________________________
> sfc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sfc
>
>
>