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

["Carlos Pignataro (cpignata)" <[e-mail]>]

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]<mailto:[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]<mailto:[e-mail]>> wrote:
Hello, Greg,

> On Jun 10, 2019, at 2:49 AM, [e-mail]<mailto:[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]><mailto:[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<mailto:[e-mail]><mailto:[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]><mailto:[e-mail]<mailto:[e-mail]>>
> https://www.ietf.org/mailman/listinfo/sfc
> _______________________________________________
> sfc mailing list
> [e-mail]<mailto:[e-mail]><mailto:[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]<mailto:[e-mail]>
> www.zte.com.cn<http://www.zte.com.cn/>

_______________________________________________
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