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

[Greg Mirsky <[e-mail]>]

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]> 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]>
> *Sent:* Thursday, August 08, 2019 11:06 PM
> *To:* Nagendra Kumar Nainar (naikumar) <[e-mail]>
> *Cc:* James Guichard <[e-mail]>;
> [e-mail]; [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]> 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]> 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%7C2fc5bd2c30f1445d6e2c08d71c7697b7%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637009168007774071&sdata=LUPMnGqpMMSgNPW0FlbsP1qgabNzgXDir8w8kW9uzF8%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]> 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]> 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%7C2fc5bd2c30f1445d6e2c08d71c7697b7%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637009168007774071&sdata=pghdQ4ndkVzI%2BdVTWzLD9UG3pmuk1%2FWcLPAA81fPXUE%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
> <https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsfc&data=02%7C01%7Cjames.n.guichard%40futurewei.com%7C2fc5bd2c30f1445d6e2c08d71c7697b7%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637009168007784062&sdata=7W4xw7WTvACMupTAj%2BtwdWupfCLmurc4FGQmQjgJPu4%3D&reserved=0>
>
>