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

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

Thank you Jim for closing the loop and the WGLC, and providing an explanation/description and perspective of the changes and choices made as part of this WGLC.

Dear Greg,

Thank you for investing your time in providing a thorough set of reviews and sharing open feedback and input on this document and associated WGLC.

I feel this document improved significantly from rev -06 until the current rev -10, all during the ~ 2.5 months of WGLC:
https://tools.ietf.org/rfcdiff?url2=draft-ietf-sfc-oam-framework-10.txt&url1=draft-ietf-sfc-oam-framework-06.txt

As evidenced in those diffs, the overall framing of the document is more structured and better organized, assumptions and scope is clearer, a comprehensive set of acronyms and terminology protects the TLA-unprepared reader, the security considerations section is much more robust, and a large number of editorials, typos, grammos, and nit fixes were made.

In regards to your comment about O&M, we followed the proposal made to the WG of that new section, which in turn sits on the foundations of RFC 5706 which describes the need for Manageability Considerations.

I also feel we expeditiously and comprehensively responded to all comments, suggestions, and concerns, not only the 5 independent top-level threads you forked, but also all threads and follow-ups.
https://mailarchive.ietf.org/arch/msg/sfc/C0gWtHLW6K7eA97H97RWR8l7oxI

Thanks again for the reviews and comments!

Best,

Carlos Pignataro


On Aug 14, 2019, at 12:55 PM, James Guichard <[e-mail]<mailto:[e-mail]>> wrote:

Hi Greg,

Looking at your concern about the word "availability" as it is used in the document, this seems to be as much a stylistic issue as a substantive one.  The word is used in a consistent fashion that seems likely to be clear to the reader.  There does not seem to be a need for the level of precision used for some other terms, due to the lack of ambiguity. Further, you ask about the inclusion of the SF component in the document.  If there were no references to the SF component, you could equally object to that.  The document seems to walk a good line, including enough information to show that it is discussed, while also indicating that "fine-grained mechanisms are implementation and deployment specific" thus indicating scope limits on what the document is addressing.

The authors appear to have made changes to table 3 as well as add new definitions and a correction to the acronyms and terminology section based upon your feedback. This can clearly be seen in the diffs here ->https://tools.ietf.org/rfcdiff?url2=draft-ietf-sfc-oam-framework-10.txt<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-sfc-oam-framework-10.txt&data=02%7C01%7Cjames.n.guichard%40futurewei.com%7C0e3f8cb11eee45a4ee0408d720bf75d6%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637013879003945456&sdata=NY6rcVee64xPdujF%2BGu6%2B6Yh3BrhiXKm3l63ooI2PLY%3D&reserved=0>. In addition, while manageability is not the focus in the scope of the document one would expect to see some mention of this for completeness and indeed the authors have moved that discussion to its own section at the end of the document again in response to your previous feedback.

For the above reasons, and the fact that there are no further objections coming from the WG, the chairs feel that consensus has been reached by the WG to close this WGLC and move the document forward for publication.

Thanks!

Jim & Joel


From: Greg Mirsky <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, August 13, 2019 9:20 PM
To: James Guichard <[e-mail]<mailto:[e-mail]>>
Cc: Nagendra Kumar Nainar (naikumar) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: [sfc] WG Last Call draft-ietf-sfc-oam-framework-06

Dear Jim and Joel,
the term "availability" is included to the title of two sections of this document and is mentioned sixteen more times in the text. And that all without any definition or a reference to a credible definition of the term. Thus it is not clear whether availability is part of Fault Management or is a performance metric that can be directly measured or calculated, Some protocols and mechanisms mentioned in the draft are being credited for supporting "availability checking" even though, as noted above, we don't know what "availability" means in this document. The document suggests that there is a multiplicity of availabilities and new mechanisms to check them will be needed. That raises a fair question How would we know that a new proposed OAM mechanism checks availability if there's no definition of one? Doesn't that look as an example of the circular reasoning?
Also, what is the value of including SF into the scope of SFC OAM if the document acknowledges that "fine-grained mechanisms are implementation and deployment-specific"?
And lastly, Tables 3 and 4. Table 3 is filled with inaccuracies that I've pointed out earlier. And Table 4 is just out of context, out of place and, clearly, out of the scope of this document. Table 4 is about Operations and Management, i.e., O&M, while the scope of the document on Operations, Administration, and Maintenance (OAM).

Regards,
Greg

On Fri, Aug 9, 2019 at 10:43 AM James Guichard <[e-mail]<mailto:[e-mail]>> wrote:
Greg,

At this late stage it is not helpful to go back and forth arguing over terminology or trying to add further wording for clarity or explanation of terms; please list any technical inaccuracies that you feel the editors need to address so that we can move this document forward to publication. Given that there are no other objections from the working group, unless there are specific technical inaccuracies that the editors and/or other members of the WG agree should be corrected, the chairs will advance this document to the next stage of the standardization process by COB 8/16 (1 week from today).

Thanks!

Jim & Joel


From: Greg Mirsky <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, August 08, 2019 11:06 PM
To: Nagendra Kumar Nainar (naikumar) <[e-mail]<mailto:[e-mail]>>
Cc: James Guichard <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>;[e-mail]<mailto:[e-mail]>
Subject: Re: [sfc] WG Last Call draft-ietf-sfc-oam-framework-06

Dear Nagendra,
please kindly review my questions below. Looking forward to hearing from you soon.

Regards,
Greg

On Tue, Jul 30, 2019 at 6:12 AM Greg Mirsky <[e-mail]<mailto:[e-mail]>> wrote:
Hi Nagendra,
much appreciate your responses. Please find my notes in-line tagged GIM>>.

Regards,
Greg

On Tue, Jul 23, 2019 at 1:58 PM Nagendra Kumar Nainar (naikumar) <[e-mail]<mailto:[e-mail]>> wrote:
Hi Greg,

Thank you for the comments. Please see our responses below.

in regard to the applicability of ICMP the statement in Section 4.1.1 is "ICMP could be leveraged for connectivity function (defined in Section 4.1) to verify the availability of SF or SFC." When I looked through Section 4.1 I find some discussion of a Fault Management function but no clear definition of what is connectivity verification in SFC.

<Authors> Section 4.1 already list some of the OAM functions that can be performed as part of connectivity function.
GIM>> My question was about the definition of the connectivity verification function used in the document. Also, do you believe that connectivity verification is a composite function that includes other OAM functions?

More so, it appears that connectivity verification is being mixed with re-ordering detection, Path MTU Discovery, data integrity monitoring,

<Authors> Please refer Section 2.2.7 of RFC7276 that explains MTU verification as part of Connectivity verification. Section 3.1.1 already explains the rationale behind including policy verification.
GIM>> Thank you for the reference to RFC 7276 but it does not state that Path MTU Discovery (PMTUD) is part of CV. I believe that PMTUD can as well be supported by the continuity check function and one of the examples is the method described in draft-ietf-bfd-large-packets<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-bfd-large-packets-00&data=02%7C01%7Cjames.n.guichard%40futurewei.com%7C5de87af84dda4ef20c4f08d720557f70%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637013423907001654&sdata=Vma4Z7ZMYLja8YleUETHMWBFJ0JwnsTgkT51zwyuH5g%3D&reserved=0>. So, I don't feel you've addressed my question.

and some sort of policy verification. Real kitchen sink.

<Authors> The intention is to capture/highlight various OAM functions based on the unique characteristics of SFC. Please read section 3.1.1 about SF availability. It is already explained about what is (or why) policy verification for SF availability. Accordingly, we humbly deny on this comment.
GIM>> " Accordingly, we humbly deny on this comment." Which leaves me with no other option but to state that you've failed to resolve my technical comment.

At the same time, in other documents on network OAM, connectivity verification has been firmly defined as a function that verifies that data have been received only form the expected source over the expected path. In conjunction with this, a misconnection error is defined to indicate that packets from another connection have been received. In other words, the connectivity verification function verifies not only that packets from A reach node B but that they arrive only on the red wire, not on blue or yellow. Said all that, the interpretation of connectivity function in SFC may be different but, in my opinion, Section 4.1 does not provide anything.

<Authors> We dont understand your concern here. SFC OAM components explains what is availability and PM for SF/SFC (Refer section 3.1.x and 3.2.x) and tied it up with the function in section 4. The relevant sections also highlight the difference in SFC (For example, what is availability in terms of SF).
GIM>> "SFC OAM components explains what is availability ..."
Can you provide the quote from this or other SFC OAM document that defines the SFC availability? I've been asking for one to no avail. Thank you in advance for clarifying this.
GIM>> "The relevant sections also highlight the difference in SFC (For example, what is availability in terms of SF)."
So, do you believe that SFC availability has some differences from SF availability? What are they? Is there a difference in measuring method or measurement units between the availability of an SFC and an SF? Please clarify.

Also, it is not clear how the last bullet "Proactively test alternate or protected paths to ensure reliability of network configurations" is specific to and requires the use of a connectivity function and why it cannot be addressed by, for example, continuity check function.

<Authors> Thanks for highlighting this. We will add the same point under Section 4.2. Hope that satisfies your concern.
GIM>> Not really. Section 4.1 opens with "Connectivity is mainly an on-demand function ..." and closes with "Proactively test alternate or protected paths ..". That draws the question How on-demand function can be used to proactively monitor a path? Perhaps you can add an example.

Also, the very last sentence of Section 4.1 concludes that ICMP in SFC "can be used for basic OAM functions". But I cannot find anywhere in the document where the term, notion of "basic OAM functions" has been discussed or defined. Which functions considered as basic? ICMP can be used as the fault management tool, to some extent because it is relatively processing extensive, but its value in performance monitoring is very low. Is PM OAM not part of the basic OAM functions?

<Authors> Thanks. To avoid any confusion, we modified it as below. Does the below modification help?

"It could be observed that ICMP at its current stage may not be able
   to perform all required SFC OAM functions, but as explained above, it
   can be used for some of the connectivity functions."
GIM>> The text is an improvement, thank you. But it refers to "all required SFC OAM functions" and I cannot find such list in the document. Can you propose another text?


Section 6.4.2, in my opinion, may provide some context to how to interpret the use of "availability". From "BFD or S-BFD could be leveraged to perform SF or SFC availability" it appears that the availability is viewed as part of Fault Management OAM. (I'm still awaiting a response to my earlier questions specifically on the interpretation of "availability" in the OAM Framework for SFC.

<Authors> Thanks, this looks like a valid point. We can change the same as below:

"BFD or S-BFD could be leveraged to perform continuity function for SF or SFC."
GIM>> Thank you, that works.

Further, in Section 6.4.2 the possible use is described as "Upon receiving the control packet, the last SFF in the SFC will reply back with relevant DIAG code." But this is not how BFD in the Asynchronous mode operates, that is how only S-BFD works. The first sentence of the second paragraph refers to both BFD and S-BFD. But the rest of the paragraph describes the operation of S-BFD only, not of BFD in Asynchronous mode. I believe that either the positioning statement must be modified or explanation of the operation of BFD in Asynchronous mode over SFP provided.

<Authors> The intention is not to explain how it works for each BFD mode. But to explain the common behavior. AFAIK/R, setting relevant DIAG code in the response packet is common for both BFD and S-BFD. So we dont see any confusion here.
GIM>> I am not saying that there's "any confusion", I'm pointing to clear technical mistake in the description of how BFD in Asynchronous mode operates. You may split the description of the mechanism for BFD and S-BFD or find another way to fix the erroneous text.


Section 6.4.3 includes the statement about the applicability of iOAM to availability: "In-Situ OAM could be used with O bit set to perform SF availability and SFC availability or performance measurement." I interpret this conclusion as the indication that availability is considered as part of the Fault Management OAM toolset. If that is the case, I question the value of using one-way OAM for fault management because only the egress node may have the state and even that is not demonstrated in existing iOAM documents. In order to detect path failure, a node must have information that can be used to detect the packet loss. That can be either monotonically increasing sequence numbers or the notion that packets must be arriving at pre-determined intervals. Which mechanism can be used by iOAM? Also, since iOAM, in regard to availability, appears as single-way FM OAM mechanism, that uses the actual data flow, what is its advantage comparing to, for example, collecting and comparing counters from ingress and egress? In other words, even if the egress can detect the loss of its availability for the particular SFP, how such a notion can be used?

<Authors> Section 6.4 is all about the applicability of different tools. It neither concludes nor prefers one over the other. How the data is collected, interpreted, used for failure detection or signaled back to the Initiator are expected to be explained in the solution document that proposes iOAM as the tool for SFC OAM. As mentioned in the document scope, any solution specific info is outside the scope of this document and accordingly we dont see a reason to include those details in this document.
GIM>> I cannot find in your response what is being detected by iOAM. How, from OAM PoV, is the reception of iOAM packet at the edge SFF is different from receiving any data packet of the same flow? Without the clearly stated distinction, without explaining the benefit of using iOAM for this function the statement has no technical foundation and doesn't stand.

I, again, have to point out that Section 6.4.4 references the individual draft that had expired 3+ years ago. Usually, that is the indication that neither authors nor the community are interested in the idea.

<Authors> This was already clarified by Carlos in different thread. The concept in the draft is already implemented and available in ODL.
GIM>> I cannot evaluate how the implementation is compared to the long-ago expired draft, so using that draft as the reference is not helpful to a reader. Can yu find another source?

Hope the above clarifies your queries. We are addressing the agreed comments and editorial comments that you raised in the other thread. We will submit a new version with the fixes.

Thanks,
Nagendra


From: sfc <[e-mail]<mailto:[e-mail]>> on behalf of Greg Mirsky <[e-mail]<mailto:[e-mail]>>
Date: Monday, July 22, 2019 at 10:44 AM
To: James Guichard <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [sfc] WG Last Call draft-ietf-sfc-oam-framework-06

Dear Jim, Joe, et al.,
I'd like to share my comments on Section of 6.4 of the draft. Much appreciate your consideration and response to my questions.

  *   in regard to the applicability of ICMP the statement in Section 4.1.1 is "ICMP could be leveraged for connectivity function (defined in Section 4.1) to verify the availability of SF or SFC." When I looked through Section 4.1 I find some discussion of a Fault Management function but no clear definition of what is connectivity verification in SFC. More so, it appears that connectivity verification is being mixed with re-ordering detection, Path MTU Discovery, data integrity monitoring, and some sort of policy verification. Real kitchen sink. At the same time, in other documents on network OAM, connectivity verification has been firmly defined as a function that verifies that data have been received only form the expected source over the expected path. In conjunction with this, a misconnection error is defined to indicate that packets from another connection have been received. In other words, the connectivity verification function verifies not only that packets from A reach node B but that they arrive only on the red wire, not on blue or yellow. Said all that, the interpretation of connectivity function in SFC may be different but, in my opinion, Section 4.1 does not provide anything. Also, it is not clear how the last bullet "Proactively test alternate or protected paths to ensure reliability of network configurations" is specific to and requires the use of a connectivity function and why it cannot be addressed by, for example, continuity check function.
  *   Also, the very last sentence of Section 4.1 concludes that ICMP in SFC "can be used for basic OAM functions". But I cannot find anywhere in the document where the term, notion of "basic OAM functions" has been discussed or defined. Which functions considered as basic? ICMP can be used as the fault management tool, to some extent because it is relatively processing extensive, but its value in performance monitoring is very low. Is PM OAM not part of the basic OAM functions?
  *   Section 6.4.2, in my opinion, may provide some context to how to interpret the use of "availability". From "BFD or S-BFD could be leveraged to perform SF or SFC availability" it appears that the availability is viewed as part of Fault Management OAM. (I'm still awaiting a response to my earlier questions specifically on the interpretation of "availability" in the OAM Framework for SFC.
  *   Further, in Section 6.4.2 the possible use is described as "Upon receiving the control packet, the last SFF in the SFC will reply back with relevant DIAG code." But this is not how BFD in the Asynchronous mode operates, that is how only S-BFD works. The first sentence of the second paragraph refers to both BFD and S-BFD. But the rest of the paragraph describes the operation of S-BFD only, not of BFD in Asynchronous mode. I believe that either the positioning statement must be modified or explanation of the operation of BFD in Asynchronous mode over SFP provided.
  *   Section 6.4.3 includes the statement about the applicability of iOAM to availability: "In-Situ OAM could be used with O bit set to perform SF availability and SFC availability or performance measurement." I interpret this conclusion as the indication that availability is considered as part of the Fault Management OAM toolset. If that is the case, I question the value of using one-way OAM for fault management because only the egress node may have the state and even that is not demonstrated in existing iOAM documents. In order to detect path failure, a node must have information that can be used to detect the packet loss. That can be either monotonically increasing sequence numbers or the notion that packets must be arriving at pre-determined intervals. Which mechanism can be used by iOAM? Also, since iOAM, in regard to availability, appears as single-way FM OAM mechanism, that uses the actual data flow, what is its advantage comparing to, for example, collecting and comparing counters from ingress and egress? In other words, even if the egress can detect the loss of its availability for the particular SFP, how such a notion can be used?
  *   I, again, have to point out that Section 6.4.4 references the individual draft that had expired 3+ years ago. Usually, that is the indication that neither authors nor the community are interested in the idea.

Regards,
Greg

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

Dear WG:



This message starts a new two week WG Last Call on advancinghttps://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%7C5de87af84dda4ef20c4f08d720557f70%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637013423907011651&sdata=KM7IndIH7SqYK9mOzq%2FysZUQNIOOdH5KnEV3C3W6HbA%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]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/sfc<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsfc&data=02%7C01%7Cjames.n.guichard%40futurewei.com%7C5de87af84dda4ef20c4f08d720557f70%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637013423907011651&sdata=BHiABVxm5rPF8BTnb22BXTCqL5kun6YHhO6EdbKzqsw%3D&reserved=0>