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

[Greg Mirsky <[e-mail]>]

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
>