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

[Joel Halpern Direct <[e-mail]>]

Your suggested text below works well for me.  If the authors and 
Shepherd agree, we can do that.  I hope that will also improve the 
situation for Alvaro.

I have some experiential reasons for not wanting to define the API you 
allude to.  I (and others) did think about it.  But those are not the 
WGs reasons.  We can chat about that in some informal context.

As chair, a big part of my concern is that I have enough trouble getting 
the WG to engage on the existing necessary work.  Committing to 
something else seems a bad idea.  Jim and I are having enough trouble 
getting substantive WG engagement on our commitment to the IESG to deal 
with security.

So, again, the text suggestion below makes sense to me, and my thanks 
for your crafting it.

Yours,
Joel

On 5/17/2020 3:29 PM, Murray S. Kucherawy wrote:
> 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] 
> <mailto:[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]>
>      > <mailto:[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
>