Re: [sfc] Alvaro Retana's No Objection on draft-ietf-sfc-oam-framework-13: (with COMMENT)

["Murray S. Kucherawy" <[e-mail]>]

Emphatically, these are only comments at this point.  I'm not out to ruin
the document or the WG's product.  The document is free to proceed.  But
since we're still discussing it, I might have more to offer here.

To me, the only prose in 3.1.1 of the current version that alludes to the
challenges to which you're referring is this:

"More specifics on the mechanism to characterize SF-specific OAM to
validate the service offering are outside the scope of this document. Those
fine-grained mechanisms are implementation- and deployment-specific."

If I think of an SF as an application (and you appear to concur that that's
basically what they are), it seems to me they could, for example, expose a
common status API that answers a simple query, to which a positive answer
means "I am up and providing the service you configured me to provide".
The fine-grained, implementation-specific concerns would be hidden behind
that API.  Naturally, you have to trust the SF's response not to be a lie,
but this is to my mind far more palatable than the cheaper "availability"
query the document also discusses.  As this is a framework document, it
could propose such a thing, even if it's ultimately an optional thing for
SF implementers to consider.

It nags at me that the above is impossible for some reason, and the
document doesn't explain why.  Still, I don't write or use SFs or query
them, so I'm happy to cede ground to the working group on this topic.
Maybe they discussed including this and decided not to, and that's fine too.

In the spirit of contributing, perhaps capturing some of what you said
would help:

"The task of evaluating the true availability of a Service Function is a
complex activity, currently having no simple, unified solution.  There is
currently no standard means of doing so, and accordingly none is proposed
here."

If that were in the document, I would've taken your word for it.  (I might
ask why you're not proposing one, given my possibly simple-minded view, but
I probably wouldn't have DISCUSSed it.)  It tells me the WG thought about
this, but made the deliberate decision not to include it.  If the current
text was meant to say that, I simply didn't get it.  All the current text
says to me (and admittedly I'm paraphrasing here, leaning toward being
flippant) is "You can be lazy about it, or you can do a thorough job."
Thus, I wondered why you would enable anyone leaning toward the left part
of that sentence when there are other possibilities, and my DISCUSS was
meant to dig a little deeper here.

At your service,

-MSK


On Sun, May 17, 2020 at 10:58 AM Joel M. Halpern <[e-mail]>
wrote:

> The reason it (monitoring of SF functioning) is out of scope is that
> properly monitoring applications (which is fundamentally what service
> functions are) is a complex activity (art, from what I know of it).  It
> can not be done simply with data plane packets flowing through the
> service function path.  In fact, many of the most obvious techniques
> produce misleading and incorrect results.  I expect you know better than
> I what the current state of the art is for systems that monitor the
> liveness and correct operation of applications (including packet
> handling applications).
>
> I fear that even trying to put text explaining this in the document
> could be confusing.
>
> What I was reacting to specifically was the proposed text that seemed to
> imply that SFC would undertake work in this area.  That is not in our
> charter, and I do not want to mislead readers into believing that we
> will solve this problem for them.  As far as I know there is no IETF
> working group tackling this, or I would be happy to point at that work.
>
> Yours,
> Joel
>
> On 5/17/2020 1:47 PM, Murray S. Kucherawy wrote:
> > On Sun, May 17, 2020 at 9:07 AM Joel Halpern <[e-mail]
> > <mailto:[e-mail]>> wrote:
> >
> >     Alvaro, Murray no longer has a Discuss.  So I am not sure what your
> >     stance is.
> >
> >
> > I cleared my DISCUSS because the discussion I wanted to have took
> > place.  As my comment now shows, I'm still left with the feeling that
> > this is a weak point in the document, but I'm not sufficiently concerned
> > as to obstruct its progress.
> >
> > However, I think it's significant that two other Area Directors also
> > remarked about it, one expressly referencing my DISCUSS.
> >
> > I suggest that if this aspect of the work is truly out of scope, the
> > document could perhaps explain why that is, because it certainly feels
> > like it needs more attention.
> >
> > -MSK
>