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

From: Alvaro Retana via Datatracker <[email-masked]>
Date: Thu, 07 May 2020 06:39:56 -0700

Alvaro Retana has entered the following ballot position for
draft-ietf-sfc-oam-framework-13: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-sfc-oam-framework/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I support Murray's DISCUSS.

I appreciate the fact that "More specifics on the mechanism to characterize
SF-specific OAM to validate the service offering are outside the scope of this
document." (§3.1.1)

The issue I want to point out, which I believe is a significant omission in
this document, is the lack of mention in §4 and §5 of the validation of the
service offering as an SFC OAM function or in the gap analysis.  IOW, the
availability of the SF from the point of view of its ability to provide the
service is pointed out as important in §3.1.1, but there is no further
consideration later in the document.

[I believe that this issue borders on a DISCUSS -- and while I would really
like to see further consideration in the text, I decided to trust that the
authors and the responsible AD will take care of it.]

---

From: "Nagendra Kumar Nainar (naikumar)" <[email-masked]>
Date: Sat, 16 May 2020 14:36:25 +0000

Hi Alvaro,

Thank you for the comments. Please see inline for the response.

    

<Nagendra> We will address the DISCUSS comments from Murray.

    
    
    <Nagendra> I think, this can be addressed by adding the below bullet point in Section 4.1

"Ability to validate the service functionality of an SF."

Please let me know if this address your concern. Please feel free to suggest any text improvement.

Thanks,
Nagendra

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 16 May 2020 12:44:00 -0400

Can we please be careful not to get too far into monitoring the 
functioning of the SF.  That is explicitly out of scope for the 
document.  This modification seems to move dangerously in that direction.

Yours,
Joel

On 5/16/2020 10:36 AM, Nagendra Kumar Nainar (naikumar) wrote:
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc
>

---

From: Joel Halpern <[email-masked]>
Date: Sun, 17 May 2020 12:07:41 -0400

Alvaro, Murray no longer has a Discuss.  So I am not sure what your 
stance is.

And the particular change the authors have proposed seems to me to go 
too far, apparently promising that SFC OAM will validity SF 
functionality.  That is out of scope for the document.

Can you please clarify whether you feel there is still a discuss level 
issue here?  And if you can live without this change?

Thank you,
Joel

On 5/16/2020 12:44 PM, Joel M. Halpern wrote:
>>      Please refer to 
>> https://www.ietf.org/iesg/statement/discuss-criteria.html

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 17 May 2020 10:47:33 -0700

> Alvaro, Murray no longer has a Discuss.  So I am not sure what your

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 17 May 2020 13:58:37 -0400

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 <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> 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.
> 
> document could perhaps explain why that is, because it certainly feels 
> like it needs more attention.
> 
> -MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 17 May 2020 12:29:00 -0700

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

---

From: Joel Halpern Direct <[email-masked]>
Date: Sun, 17 May 2020 15:35:52 -0400

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:
> 
> 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.
> 
> 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 <[email-masked] 
>     <mailto:[email-masked]>
>      > <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>      >

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Sun, 17 May 2020 21:08:22 +0000

I believe the text suggested by Murray improves the doc, and works well as an addition for me. 

Thank you for the discussion. 

Thumb typed by Carlos Pignataro.
Excuze typofraphicak errows

> 2020/05/17 午後3:36、Joel Halpern Direct <[email-masked]>のメール:
> 
> 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
> 
>> 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 <[email-masked] <mailto:[email-masked]>> wrote:

---

From: "Nagendra Kumar Nainar (naikumar)" <[email-masked]>
Date: Mon, 18 May 2020 09:43:48 +0000

Hi Murray,

Thank you for the suggestion. We will update the document accordingly.

Regards,
Nagendra

On 5/17/20, 5:08 PM, "Carlos Pignataro (cpignata)" <[email-masked]> wrote:

---

From: Alvaro Retana <[email-masked]>
Date: Mon, 18 May 2020 10:44:19 -0400

On May 17, 2020 at 12:07:47 PM, Joel Halpern wrote:

Joel:

Hi!

> Alvaro, Murray no longer has a Discuss. So I am not sure what your

I've seen the proposed text and resolution to the DISCUSS.   I can
live with the resolution.

> issue here? And if you can live without this change?

In reading your other comments, I see your concern of setting
expectations beyond what the WG, or even the RTG Area, would have
expertise on.  Personally, I think there's a difference between what
an informational framework document may say and the expected product
of the WG.  IOW, a mention in the document shouldn't immediately
translate into a work item.

Because the document mentions the SF's ability to provide the service
as important, then I still think that not mentioning that as a gap
means that the document is incomplete.  I am not looking for a
solution in this document, and Murray's proposed text works for me --
maybe something could be added to it to explain why:

Current>
   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.

Add (Suggestion)>

   ...  Any such mechanism would be far from a typical OAM function, so it is
   not explored as part of the analysis in Sections 4 and 5.

Just a suggestion -- I am ok either way.

Thanks!!

Alvaro.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 18 May 2020 11:29:33 -0400

Thanks Alvaro.  I will leave this up to the authors and whelpherd, and 
get back out of the way.

Yours,
Joel

---

From: "Nagendra Kumar Nainar (naikumar)" <[email-masked]>
Date: Mon, 18 May 2020 17:39:51 +0000

Hi Alvaro,

Thank you for the suggestion. I tried combining the text below. We will update the draft accordingly.

"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. Any such mechanism would be far from a typical OAM function, so it is not explored as part of the analysis in Sections 4 and 5."

Thanks,
Nagendra

On 5/18/20, 10:44 AM, "Alvaro Retana" <[email-masked]> wrote:

    Joel:
    
    Hi!

    

    Current>
       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.
    
    Add (Suggestion)>

    Thanks!!
    
    Alvaro.