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

[Greg Mirsky <[e-mail]>]

Hi Nagendra,
thank you for your expedient response to my comments and questions. I am at
IETF this week and will respond with my notes after IETF. Apologies for the
delay, hope you'll understand.

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.
>
>
>
> 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]> 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]
> https://www.ietf.org/mailman/listinfo/sfc
>
>