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

["Nagendra Kumar Nainar (naikumar)" <[e-mail]>]

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.

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.

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.

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).

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.

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."


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."

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.


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.

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.

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]> on behalf of Greg Mirsky <[e-mail]>
Date: Monday, July 22, 2019 at 10:44 AM
To: James Guichard <[e-mail]>
Cc: "[e-mail]" <[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 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]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/sfc