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 <gregimirsky@gmail.com> 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) <
> naikumar@cisco.com> 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://tools.ietf.org/html/draft-ietf-bfd-large-packets-00>. 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 <sfc-bounces@ietf.org> on behalf of Greg Mirsky <
>> gregimirsky@gmail.com>
>> *Date: *Monday, July 22, 2019 at 10:44 AM
>> *To: *James Guichard <james.n.guichard@futurewei.com>
>> *Cc: *"sfc@ietf.org" <sfc@ietf.org>
>> *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 <
>> james.n.guichard@futurewei.com> 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
>> sfc@ietf.org
>> https://www.ietf.org/mailman/listinfo/sfc
>>
>>