Subject: [sfc] Murray Kucherawy's Discuss on draft-ietf-sfc-oam-framework-13: (with DISCUSS and COMMENT)

From: Murray Kucherawy via Datatracker <[email-masked]>
Date: Tue, 05 May 2020 22:32:24 -0700

Murray Kucherawy has entered the following ballot position for
draft-ietf-sfc-oam-framework-13: Discuss

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/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I think this is pretty well done.  I had little trouble following it and this
is my first foray into the realm of SFC.

One item I'd like to discuss though.  From Section 3.1.1:

“On one end of the spectrum, one might argue that an SF is sufficiently
available if the service node (physical or virtual) hosting the SF is available
and is functional.  On the other end of the spectrum, one might argue that the
SF's availability can only be concluded if the packet, after passing through
the SF, was examined and it was verified that the packet did indeed get the
expected service.”

I found this a bit surprising, especially given the critical nature of many SF
functions.  Why would it ever be the case that, say, “well, the hypervisor says
the VM is up, so the SF is up” is a safe conclusion?  For such a critical
component, I would expect only some more complete test is necessary to conclude
availability of the SF.  Shouldn't we at least be pushing implementers toward
the latter end of that spectrum?

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

I find myself almost suggesting that you don't need the BCP 14 boilerplate or
its language at all in this document.  You barely use it, and it might not even
be needed in the places you do have it especially since this is a framework
document and not a protocol document.

Finally, lots of editorial stuff:

Section 2:
* “In Figure 1, the service layer element such as …” -- s/element/elements/
* “The underlay network may comprise of …” -- s/comprise/consist/, or
alternatively, s/comprise of/comprise/ * “... nodes but not shown …” -- remove
“but”, or s/but/but these/

Section 3, all three numbered list entries:
* “... applicable at this component includes …” -- s/includes/include/

Section 3.1.1:
OLD:
"SF availability is an aspect that raises an interesting question -- How to
determine that a service function is available?." NEW: "SF availability is an
aspect that raises an interesting question: How does one determine that a
service function is available?"

* “... the packet did indeed get the got expected service.”  -- remove “got”
* This section uses both “a SF” and “an SF”.  I don’t know which one is
grammatically correct, but we should find out and use that. Or, if both are,
pick one and be consistent.

Section 3.2.1:
* “An SFC could be comprised of …” -- either remove “of”, or use “composed of”

Section 3.3:
* Either capitalize “Classifier” generally, or not at all.

Section 3.4:
* What constitutes an availability check of the underlay network?  You
discussed this in 3.1.1, but not here.  If this is covered in Section 4.1, a
forward reference would be helpful here.

Section 3.5:
* “... and are mostly transparent …” -- s/are/is/; “network” is singular
* What constitutes an availability check of the overlay network?

Section 4:
* “...for more than one SFC components.”  -- use “component”, or change “more
than one” to “multiple”

Section 4.1:
* “Verify any packet re-ordering and corruption.” -- perhaps “detect” would be
better than “verify” here

Section 4.2:
* “Ability to provision continuity check …” -- put an “a” before “continuity”
* “... supported by continuity function are as follows:” --
s/function/functions/

Section 4.3:
* “... from every transit devices …” -- s/devices/device/
* “Ability to trigger action from …” -- s/action/an action/

Section 5.1:
* I would quote “ping” and “trace”.
* “Table 3 below is not exhaustive” -- needs a period at the end
* Table 3 needs a bit of tidying in terms of alignment.

Section 6.1:
* “... network layer must mark the packet …” -- why isn’t that a MUST?

Section 6.2:
* “... skipping an SF might have implication …” -- s/implication/implications/
* “Any SFC-aware node that initiates an OAM packet must set …” -- why isn’t
that a MUST?

Section 6.3:
* “... indicates it as OAM packet …” -- s/as/as an/

Section 6.4.1:
* “[RFC0792] and [RFC4443] describes …” -- s/describes/describe/
* “... verify the availability of SF or SFC.” -- s/SF/an SF/
* “... can generate ICMP echo …” -- s/ICMP/an ICMP/
* “... from last SFF and thereby …” -- add comma after “SFF”
* “Alternately, …  Alernatively, … ” -- use “Alternatively” for the first one,
and “or” for the second, all in one sentence

Section 6.4.2:
* “[RFC5880] defines Bidirectional …” -- s/defines/defines the/
* “... to perform continuity function …” -- “functions”, or “the continuity
function” * “... value as last SFF …” -- s/last/the last/ * “... with relevant
DIAG code.” -- s/with/with the/  (or “a”)

Section 6.4.3:
* “... transported using NSH header.” -- s/using/using the/

Section 6.4.4:
* “... is implemented in Open Daylight and available.”  -- s/and/and is/

Section 7:
* Table 4 needs some work on spacing consistency.

Section 8:
* “... are applicable for this document.” -- s/are/is/, as “consideration” is
singular * “The OAM information from service layer …” -- s/from/from the/ *
“... service function paths etc.” -- s/paths etc./paths, etc./ * “...
information from SFC layer raises a need for careful security considerations”
-- s/from/from the/, and the sentence is missing a period * “... SFC and SF OAM
may provide mechanism …” -- s/mechanism/mechanisms/ * “... the OAM solution for
SF component should …” -- s/component/components/

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 7 May 2020 03:00:21 +0000

Hello, Murray,

Thank you for taking time to review this document, and for surfacing the one item to discuss.

We will be addressing all the comments from you and other ADs, one by one and comprehensively. We will be doing that all in one editorial pass, since there is some repetition of comments.

Before that, however, I wanted to address your DISCUSS. For that, please see inline.

> 2020/05/06 午前1:32、Murray Kucherawy via Datatracker <[email-masked]>のメール:
> 
> I think this is pretty well done.

Many thanks for this! We, the WG, appreciate this comment.

>  I had little trouble following it and this

You extracted a couple of sentences from a larger passage. Part of the discussion you expect is actually in the paragraph that follows your excerpt, which you did not include. Engineering is about tradeoffs, and what this paragraph and section presents is such engineering gradient of choices.

As the paragraph that follows explains, the SF treatment and expected service could well be dropping a packet, which is indistinguishable by observation from a black hole from a bug.

The text that follows first explains the tradeoff:

   The former approach will likely not provide sufficient confidence to
   the actual SF availability, i.e. a service node and a SF are two
   different entities.  The latter approach is capable of providing an
   extensive verification, but comes at a cost. 

Then describes the difficulty in generalizing a test for SFs which can have super different behaviors, from a Firewall to a telemetry counter:

   Some SFs make direct
   modifications to packets, while others do not.  Additionally, the
   purpose of some SFs may be to, conditionally, drop packets
   intentionally.  In such cases, it is normal behavior that certain
   packets will not be egressing out from the service function.

There’s additional text exemplifying the tradeoff, but the section ends like 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.

I believe we could add a final sentence saying:

   Implementations are encouraged to find the maximum pushing towards
   a more comprehensive and test closer to the expected SF service, 
   while not compromising complexity, scalability, or reusability of a
   solution.

I appreciate that text can be a bit to generic, in which case I would really appreciate if you can help us craft this final sentence to be concrete about "pushing towards the latter"

Thanks again,

—
Carlos Pignataro, [email-masked]

“Sometimes I use big words that I do not fully understand, to make myself sound more photosynthesis."

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 6 May 2020 21:38:24 -0700

Hi Carlos,

On Wed, May 6, 2020 at 8:00 PM Carlos Pignataro (cpignata) <
[email-masked]> wrote:

> You extracted a couple of sentences from a larger passage. Part of the
> discussion you expect is actually in the paragraph that follows your
> excerpt, which you did not include. Engineering is about tradeoffs, and
> what this paragraph and section presents is such engineering gradient of
> choices.
>
> As the paragraph that follows explains, the SF treatment and expected
> service could well be dropping a packet, which is indistinguishable by
> observation from a black hole from a bug.
> [...]
>

I did read the whole section, yet still I came away from it feeling like
the encouragement toward the latter end of the spectrum was a little
short.  That's why I felt it worthy of a discussion, especially since as a
new reviewer I don't have the benefit of your context.

The text that follows first explains the tradeoff:
> Then describes the difficulty in generalizing a test for SFs which can
> have super different behaviors, from a Firewall to a telemetry counter:
>
>    Some SFs make direct

Those paragraphs appear to talk about determining availability of the SF
via passive observation of its input and its output.  I was surprised to
see the absence of a mechanism to directly interrogate an SF to ask it for
its state or health.  I can tell a lot more about an HTTP service, for
example, by dropping a "GET /" on port 80 and looking at the reply than I
can by using ICMP to ping the machine on which I believe that service is
running.  In an SFC OAM environment, there would be added benefit if the
status query/response was standardized, because then as SFs evolve, they
still reply to a known query in a known way, and some of the complexity
about which you're cautioning above is mitigated.

You don't need to use that mechanism specifically, but that's where my head
went when I read this section.

I believe we could add a final sentence saying:
> I appreciate that text can be a bit to generic, in which case I would
> really appreciate if you can help us craft this final sentence to be
> concrete about "pushing towards the latter"
>

I'd love to hear what you think of my comment above, and then I'd be happy
to work with you on text.

-MSK

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 7 May 2020 05:09:39 +0000

Hi, Murray,

2020/05/07 午前0:38、Murray S. Kucherawy <[email-masked]<mailto:[email-masked]>>のメール:

Hi Carlos,

On Wed, May 6, 2020 at 8:00 PM Carlos Pignataro (cpignata) <[email-masked]<mailto:[email-masked]>> wrote:
You extracted a couple of sentences from a larger passage. Part of the discussion you expect is actually in the paragraph that follows your excerpt, which you did not include. Engineering is about tradeoffs, and what this paragraph and section presents is such engineering gradient of choices.

I did read the whole section, yet still I came away from it feeling like the encouragement toward the latter end of the spectrum was a little short.  That's why I felt it worthy of a discussion, especially since as a new reviewer I don't have the benefit of your context.

I see, thank you for this additional color of your reaction to the text. It is useful, and welcome this discussion. Please see below.

   Some SFs make direct

   More

Those paragraphs appear to talk about determining availability of the SF via passive observation of its input and its output.  I was surprised to see the absence of a mechanism to directly interrogate an SF to ask it for its state or health.

This is a good observation.

Part of the rational for this approach is that, during the WG discussions, there was a conclusion that since SFs can be so diverse (a load-balancer, NATs, a FW, WAN and application acceleration, HTTP Header Enrichment, etc.), it did not make sense to attempt to generalize a mechanism here on this doc, and instead it was decided to keep SF availability out of scope:

   More

I can tell a lot more about an HTTP service, for example, by dropping a "GET /" on port 80 and looking at the reply than I can by using ICMP to ping the machine on which I believe that service is running.

Yes, but what do you learn about the various SFs chained between your keyboard and the HTTP service? The scope is at the service layer.

In an SFC OAM environment, there would be added benefit if the status query/response was standardized, because then as SFs evolve, they still reply to a known query in a known way, and some of the complexity about which you're cautioning above is mitigated.

That does not mean that such an approach can be explored in detail elsewhere and not in this framework document.

You don't need to use that mechanism specifically, but that's where my head went when I read this section.

I'd love to hear what you think of my comment above, and then I'd be happy to work with you on text.

I tend to think that an SF interrogation mechanism is a bit too specific to detail or call out on this service-layer framework document.

At the same time, I would not want to give the impression that it is OK to settle with VM/Container up implies service UP…

As such, weighting on the “another hand side” as a goal seems to alleviate your concern without redefine scope.

Thoughts?

Thanks,

Carlos.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 7 May 2020 09:19:14 -0700

On Wed, May 6, 2020 at 10:09 PM Carlos Pignataro (cpignata) <
[email-masked]> wrote:

> its state or health.
> Part of the rational for this approach is that, during the WG discussions,
> there was a conclusion that since SFs can be so diverse (a load-balancer,
> NATs, a FW, WAN and application acceleration, HTTP Header Enrichment,
> etc.), it did not make sense to attempt to generalize a mechanism here on
> this doc, and instead it was decided to keep SF availability out of scope:
>
>    More
Now that you point that out, I think we might consider changing this text a
bit.  To my mind, it effectively punts on the entire issue, and maybe
instead we can say something more encouraging here to those that work on
what comes next.  Perhaps you'd be comfortable with this?

"Specific mechanisms to characterize SF-specific OAM to validate the
service offering will be considered and may be proposed in the solution
documents derived from this framework."

In an SFC OAM environment, there would be added benefit if the status
> query/response was standardized, because then as SFs evolve, they still
> reply to a known query in a known way, and some of the complexity about
> which you're cautioning above is mitigated.
>
> That does not mean that such an approach can be explored in detail
> elsewhere and not in this framework document.
>

Absolutely agreed.  I think my goal here is to specifically encourage doing
so.

I tend to think that an SF interrogation mechanism is a bit too specific to
> detail or call out on this service-layer framework document.
>
> At the same time, I would not want to give the impression that it is OK to
> settle with VM/Container up implies service UP…
>

I think that's completely fair.  And so, is that proposed replacement
sentence acceptable?

-MSK

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 7 May 2020 12:37:07 -0400

<chair hat set aside>
I have a concern about going very far on monitoring SFs.  This comes 
from two pieces.

First, monitoring whether an SF is actually doing its job is at least 
specific to the kind of SF, and may even be specific to details of how 
the SF is configured.  (To check whether a firewall is blocking things, 
you need to know what it is configured to block.)  This is very far from 
generic OAM.

On the other hand, the general monitoring of compute platforms and their 
resource behavior is not a topic that the Routing Area of the IETF ought 
to be getting into.  It is arguable whether it is a topic the IETF ought 
to be getting into, but that is more your area.

Hence, as a participant, I am concerned that your discuss is pushing for 
an emphasis that does not belong in the work of this working group or 
this framework.

Yours,
Joel
</look for hat>

On 5/7/2020 12:19 PM, Murray S. Kucherawy wrote:
> On Wed, May 6, 2020 at 10:09 PM Carlos Pignataro (cpignata) 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>>
>>     Those paragraphs appear to talk about determining availability of
>>     the SF via passive observation of its input and its output.  I was
>>     surprised to see the absence of a mechanism to directly
>>     interrogate an SF to ask it for its state or health.
> 
>     Part of the rational for this approach is that, during the WG
>     discussions, there was a conclusion that since SFs can be so diverse
>     (a load-balancer, NATs, a FW, WAN and application acceleration, HTTP
>     Header Enrichment, etc.), it did not make sense to attempt to
>     generalize a mechanism here on this doc, and instead it was decided
>     to keep SF availability out of scope:
> 
>         More
> Now that you point that out, I think we might consider changing this 
> text a bit.  To my mind, it effectively punts on the entire issue, and 
> maybe instead we can say something more encouraging here to those that 
> work on what comes next.  Perhaps you'd be comfortable with this?
> 
>>     In an SFC OAM environment, there would be added benefit if the
>>     status query/response was standardized, because then as SFs
>>     evolve, they still reply to a known query in a known way, and some
>>     of the complexity about which you're cautioning above is mitigated.
> 
> Absolutely agreed.  I think my goal here is to specifically encourage 
> doing so.
> 
>     I tend to think that an SF interrogation mechanism is a bit too
>     specific to detail or call out on this service-layer framework
>     document.
> 
>     At the same time, I would not want to give the impression that it is
>     OK to settle with VM/Container up implies service UP…
> 
>     As such, weighting on the “another hand side” as a goal seems to
>     alleviate your concern without redefine scope.
> 
>     Thoughts?
> 
>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 7 May 2020 17:29:21 +0000

Thank you Murray and Joel!

Surfacing the issue to the top of the post, we have:

Current:
   More

Proposad:
   Specific mechanisms to characterize SF-specific OAM to validate the
   service offering will be considered and may be proposed in the solution
   documents derived from this framework.

I am not uncomfortable with this change, but at the same time, the pragmatic in me thinks that this will not be part of relevant work in SFC.

Joel,

Perhaps something ‘in-between’ these two?

Thanks!

—
Carlos Pignataro, [email-masked]<mailto:[email-masked]>

2020/05/07 午後0:37、Joel M. Halpern <[email-masked]<mailto:[email-masked]>>のメール:

<chair hat set aside>
I have a concern about going very far on monitoring SFs.  This comes from two pieces.

First, monitoring whether an SF is actually doing its job is at least specific to the kind of SF, and may even be specific to details of how the SF is configured.  (To check whether a firewall is blocking things, you need to know what it is configured to block.)  This is very far from generic OAM.

On the other hand, the general monitoring of compute platforms and their resource behavior is not a topic that the Routing Area of the IETF ought to be getting into.  It is arguable whether it is a topic the IETF ought to be getting into, but that is more your area.

Hence, as a participant, I am concerned that your discuss is pushing for an emphasis that does not belong in the work of this working group or this framework.

Yours,
Joel
</look for hat>

On 5/7/2020 12:19 PM, Murray S. Kucherawy wrote:
On Wed, May 6, 2020 at 10:09 PM Carlos Pignataro (cpignata) <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>> wrote:

Now that you point that out, I think we might consider changing this text a bit.  To my mind, it effectively punts on the entire issue, and maybe instead we can say something more encouraging here to those that work on what comes next.  Perhaps you'd be comfortable with this?
"Specific mechanisms to characterize SF-specific OAM to validate the service offering will be considered and may be proposed in the solution documents derived from this framework."
Absolutely agreed.  I think my goal here is to specifically encourage doing so.
I think that's completely fair.  And so, is that proposed replacement sentence acceptable?
-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 7 May 2020 11:03:47 -0700

On Thu, May 7, 2020 at 10:29 AM Carlos Pignataro (cpignata) <
[email-masked]> wrote:

> I am not uncomfortable with this change, but at the same time, the
> pragmatic in me thinks that this will not be part of relevant work in SFC.
>

If there's not much that can be done practically to lean this more toward
the "second" end of that spectrum than what's already there -- because, as
you said, such work isn't likely to be done anyway -- then I think I've
gotten as much out of this discussion as is practical.  Thanks for
indulging me.

I'm rather puzzled by Joel's comments about a way to query your own
components for even basic status being out of scope, but I guess that's
something else for me to go learn about.

-MSK

---

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

HI Murray,

Thank you for the great discussion and comments. Please find the response for the your comments inline..

On 5/6/20, 1:32 AM, "Murray Kucherawy via Datatracker" <[email-masked]> wrote:

    

    

    
    
<Nagendra> The draft is being updated to remove any use of normative statements.

    Section 2:
    
<Nagendra> Fixed all the above.

<Nagendra> Fixed.

    Section 3.1.1:
    OLD:

<Nagendra> Fixed.

    Section 3.2.1:
    
<Nagendra> Fixed as "An SFC could comprise varying..."

    Section 3.3:
    
<Nagendra> Fixed.

    Section 3.4:
    
<Nagendra> We updated this section with a forward reference to 5.1. 

    Section 3.5:

<Nagendra> Fixed.

<Nagendra> We updated this section with a forward reference to 5.1.

    Section 4:
    
<Nagendra> Fixed.

    Section 4.1:
    
<Nagendra> Fixed.

    Section 4.2:

<Nagendra> Fixed.

<Nagendra> Fixed.
    
    Section 4.3:

<Nagendra> Fixed.

<Nagendra> Fixed.
    
    Section 5.1:

<Nagendra> The other documents don’t seem to be quoting while referring to these terms. So I am leaving this as it is.

<Nagendra> Fixed.

<Nagendra> Fixed.
    
    Section 6.1:
    
<Nagendra> We removed the use of normative statements based on the comments from different reviewers.

    Section 6.2:

<Nagendra> Fixed.

<Nagendra> We removed the use of normative statements based on the comments from different reviewers.

    Section 6.3:
    
<Nagendra> Fixed.

    Section 6.4.1:

<Nagendra> Fixed.

<Nagendra> Fixed.

<Nagendra> Fixed.

<Nagendra> Fixed.

<Nagendra> Fixed.
    
    Section 6.4.2:
    
<Nagendra> Fixed all the above.

    Section 6.4.3:
    
<Nagendra> Fixed.

    Section 6.4.4:
    
<Nagendra> Fixed.

    Section 7:
    
<Nagendra> Fixed.

    Section 8:
    
<Nagendra> Fixed.
    
Once again, thanks a lot for the great comments.

Regards,
Nagendra