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

From: James Guichard <[email-masked]>
Date: Mon, 8 Jul 2019 13:15:07 +0000

Dear WG:

Before closing this WG Last Call, we (the chairs) would like to better understand the level of interest and commitment the WG has on progressing OAM work for SFC, starting with draft-ietf-sfc-oam-framework as a baseline. Please reply to this email with either support for the document, or non-support (we do not need this document). Silence does not imply support or lack thereof so please take time to state your opinions with a brief rational for support/non-support.

Thanks!

Jim & Joel

From: James Guichard
Sent: Tuesday, May 28, 2019 10:30 AM
To: [email-masked]
Subject: WG Last Call draft-ietf-sfc-oam-framework-06

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

---

From: <[email-masked]>
Date: Mon, 8 Jul 2019 13:23:55 +0000

Hi Jim, all,

I do support this effort. This is IMHO one of the missing pieces (in addition to standardizing key metadata TLVs).

Cheers,
Med

De : sfc [mailto:[email-masked]] De la part de James Guichard
Envoyé : lundi 8 juillet 2019 15:15
À : [email-masked]
Objet : Re: [sfc] WG Last Call draft-ietf-sfc-oam-framework-06

Dear WG:

Thanks!

Jim & Joel

From: James Guichard

Dear WG:

Thanks!

Jim & Joel

---

From: Sami Boutros <[email-masked]>
Date: Mon, 8 Jul 2019 16:48:40 +0000

Support,

A good document describing the scope of OAM functions for SFC.

Thanks,

Sami
From: James Guichard <[email-masked]<mailto:[email-masked]>>
Date: Mon, Jul 8, 2019, 6:16 AM
Subject: Re: [sfc] WG Last Call draft-ietf-sfc-oam-framework-06
To: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>

Dear WG:

Thanks!

Jim & Joel

From: James Guichard
Sent: Tuesday, May 28, 2019 10:30 AM
To: [email-masked]<mailto:[email-masked]>
Subject: WG Last Call draft-ietf-sfc-oam-framework-06

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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-sfc-oam-framework%2F&data=02%7C01%7Cboutross%40vmware.com%7Ca9b2438850c14648e93308d703b04295%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636981927879391322&sdata=qWyv5pDGVzHGs%2FzEVhvYTGNJ8b%2FAbTYYUErFyTTZCGg%3D&reserved=0> for publication as an Informational RFC.

Thanks!

Jim & Joel

_______________________________________________
sfc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sfc<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsfc&data=02%7C01%7Cboutross%40vmware.com%7Ca9b2438850c14648e93308d703b04295%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636981927879391322&sdata=Y%2BGbFAa4HROq1WJ3h%2BnAiZz2tcTxf0Qs4k8JVpdl1xI%3D&reserved=0>

---

From: Anoop Ghanwani <[email-masked]>
Date: Mon, 8 Jul 2019 17:45:04 -0700

I support both the framework doc (co-author) and the development of OAM
solutions for SFC.

Thanks,
Anoop

On Mon, Jul 8, 2019 at 6:15 AM James Guichard <
[email-masked]> wrote:

> Dear WG:
>
>
>
> Before closing this WG Last Call, we (the chairs) would like to better
> understand the level of interest and commitment the WG has on progressing
> OAM work for SFC, starting with draft-ietf-sfc-oam-framework as a baseline.
> Please reply to this email with either support for the document, or
> non-support (we do not need this document). Silence does not imply support
> or lack thereof so please take time to state your opinions with a brief
> rational for support/non-support.
>
>
>
> Thanks!
>
>
>
> Jim & Joel
>
>
>
>
>
> *From:* James Guichard
> *Sent:* Tuesday, May 28, 2019 10:30 AM
> *To:* [email-masked]
> *Subject:* WG Last Call draft-ietf-sfc-oam-framework-06
>
>
>
> 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
>
>
>
>
>
>
>
>
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc
>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 9 Jul 2019 00:35:07 +0000

Jim & Joel,

I share Med’s opinion that progressing OAM for SFC is one of the key missing pieces in this WG.

The framework document structures and “frames” the topic in a useful level way.

Looking at the SFC Charter, i.e., the contract between the WG and IETF [RFC 2418], this would be Deliverable #5.

    5. OAM Framework document to provide a common basis for OAM work.

And the following (second-to-last) overdue milestone:

Oct 2018        Informational document defining the Operation, Administration and Maintenance (OAM) framework for SFC
Oh, “support” :-)

Thanks,

Carlos.

On Jul 8, 2019, at 9:15 AM, James Guichard <[email-masked]<mailto:[email-masked]>> wrote:

Dear WG:

Thanks!

Jim & Joel

From: James Guichard

Dear WG:

Thanks!

Jim & Joel

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 8 Jul 2019 18:50:38 -0700

Hi Jim,
I've reviewed the latest version of the document and find that many of my
earlier comments, questions have not yet been answered, addressed. In
particular, I'd like to return to the question I've asked authors What is
"availability"? As we know, OAM provides tools for Fault Management and
Performance Monitoring ('F' and 'P' in FCAPS). Where does "availability",
as discussed in this document,  fit? Is it to detect a defect? Or is it a
performance metric? If it is the former, then how it is related to other
known FM OAM methods - connectivity verification and continuity check? If
it is the latter,i.e., performance metric, then how it is measured? What is
the unit of "availability" - second, number of packets?
I've asked this question and have to bring it up again because I don't see
in the document an explanation, definition, or reference to an existing
document.
I hope that the WG and you ask authors to address my comment and questions.
Please note that I'm preparing more comments on the current version and
will share them later this week (apologies, had to beat the IETF cut-off
submission deadline).

Regards,
Greg

---

From: Sam Aldrin <[email-masked]>
Date: Mon, 8 Jul 2019 23:09:17 -0700

This document forms OAM solutions for SFC and is part of the charter.
Would support this work, both as author and end-user.

-sam

---

From: "Vengada Prasad Govindan (venggovi)" <[email-masked]>
Date: Tue, 9 Jul 2019 11:43:57 +0000

Support,

A useful document that outlines the layering and the options available for OAM functions for SFC.
A nit -  the second paragraph talks about initiators that are relevant to S-BFD only but it begins with "BFD or S-BFD ...". This could be made briefer to limit it to S-BFD only.

Thanks,
Prasad

From: sfc <[email-masked]> On Behalf Of James Guichard
Sent: Monday, July 8, 2019 18:45
To: [email-masked]
Subject: Re: [sfc] WG Last Call draft-ietf-sfc-oam-framework-06

Dear WG:

Thanks!

Jim & Joel

From: James Guichard

Dear WG:

Thanks!

Jim & Joel

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 10 Jul 2019 15:33:24 -0700

Hi Jim, Joel, et al.,
I have a question about the scope of the SFC OAM Framework. In Section 1.1
the scope is defined as:
   The focus of this document is to provide an architectural framework
   for SFC OAM, particularly focused on the aspect of the Operations
   component within OAM.  Actual solutions and mechanisms are outside
   the scope of this document.
But after reading it several times over, I believe that the scope of the
document is more narrow and includes only OAM for SFC NSH. I couldn't find
any discussion of OAM for SFC based on RFC 8595, nor I could find it being
referenced in the framework. If it is outside the scope of this document,
should it provide an explanation, identify it as an outstanding work for
the future?

Regards,
Greg

---

From: Jeff Tantsura <[email-masked]>
Date: Wed, 10 Jul 2019 19:59:57 -0700

Jim,

I support progressing the OAM work for SFC, it is very much needed to build a proper and well designed set of solutions.

Regards,
Jeff

> On Jul 8, 2019, at 06:15, James Guichard <[email-masked]> 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/ for publication as an Informational RFC.
> 
>  
>

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 11 Jul 2019 17:36:37 -0700

Dear Jim, Joel, et al.
I'd like to share my comments and questions to Section 5 Gap Analysis:

   - in Table 3 raises some questions:
      - E-OAM is  not expanded, nor referenced in the rest of the document
      - MPLS_PM is  not expanded, nor referenced in the rest of the document
      - IPPM is expanded in Terminology but it is not clear how IP
      Performance Metrics are relevant to Performance Monitoring OAM solutions
      - NVo3 OAM - it is not clear what is included in it, especially since
      there are no WG documents in NVO3 WG on OAM and the discussion of
      encapsulation of an active OAM in Geneve is about to begin
      - the title on the next page refers to Table 4: OAM Tool GAP Analysis
      (contd.)
      - one row assigned for SFC. Here, I think, maybe some mixed
      terminology. In Introduction SFC is for Service Function
Chaining while in
      Terminology it is expanded as Service Function Chain. I recommend
      reassigning the row to SFP.
      - Configuration (the first column) in Table 4 is usually not
      considered as part of OAM. And neither Orchestration or Topology
      (discovery). I recommend removing that portion of the table from the
      document altogether.
      - also, Why the same readily available tools that provide Topology
      (discovery) and Notifications for overlay and underlay networks cannot be
      used for SF and SFC/SFP?

It appears that the conclusion expressed in section 5.2 contradicts the
discussion in some of the further sections, for example, sections 6.4.1 and
6.4.2.
Section 5.3 Required OAM Functions refers to O&M, not OAM functions in the
following:

   Configuration, orchestration and manageability of SF and SFC could be
   performed using CLI, NETCONF, etc.

Since the scope of the document includes only SFC OAM, not O&M (RFC 6291
<https://tools.ietf.org/html/rfc6291> explains the variances of OAM soup in
great details), I recommend removing the sentence.

Regards,
Greg

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Fri, 12 Jul 2019 13:24:06 +0000

Thank you for your comments, Greg.

Please see inline.

On Jul 11, 2019, at 8:36 PM, Greg Mirsky <[email-masked]<mailto:[email-masked]>> wrote:

Dear Jim, Joel, et al.

  *   in Table 3 raises some questions:
     *   E-OAM is  not expanded, nor referenced in the rest of the document
     *   MPLS_PM is  not expanded, nor referenced in the rest of the document
     *   IPPM is expanded in Terminology but it is not clear how IP Performance Metrics are relevant to Performance Monitoring OAM solutions
     *   NVo3 OAM - it is not clear what is included in it, especially since there are no WG documents in NVO3 WG on OAM and the discussion of encapsulation of an active OAM in Geneve is about to begin
     *   the title on the next page refers to Table 4: OAM Tool GAP Analysis (contd.)
     *   one row assigned for SFC. Here, I think, maybe some mixed terminology. In Introduction SFC is for Service Function Chaining while in Terminology it is expanded as Service Function Chain. I recommend reassigning the row to SFP.
     *   Configuration (the first column) in Table 4 is usually not considered as part of OAM. And neither Orchestration or Topology (discovery). I recommend removing that portion of the table from the document altogether.
     *   also, Why the same readily available tools that provide Topology (discovery) and Notifications for overlay and underlay networks cannot be used for SF and SFC/SFP?

Great points on the terminology ad acronym mis-uses. These should be fixed. From expanding PM and fixing SFC’s expansion to explaining for IPPM is the protocols not the metrics.

It appears that the conclusion expressed in section 5.2 contradicts the discussion in some of the further sections, for example, sections 6.4.1 and 6.4.2.
Section 5.3 Required OAM Functions refers to O&M, not OAM functions in the following:
   Configuration, orchestration and manageability of SF and SFC could be
   performed using CLI, NETCONF, etc.
Since the scope of the document includes only SFC OAM, not O&M (RFC 6291<https://tools.ietf.org/html/rfc6291> explains the variances of OAM soup in great details), I recommend removing the sentence.

On configuration, I am OK removing the table column and sentence. I’m also OK moving that paragraph (and the one that follows) to a Manageability Considerations section.

Does the WG have a preference?

Thanks,

Carlos.

Regards,
Greg

On Tue, May 28, 2019 at 7:37 AM James Guichard <[email-masked]<mailto:[email-masked]>> wrote:

Dear WG:

Thanks!

Jim & Joel

---

From: James Guichard <[email-masked]>
Date: Fri, 12 Jul 2019 18:28:18 +0000

Hi Greg,

That is correct; OAM work within the SFC WG is to support the encapsulation developed by the WG which is NSH.

Regards,

Jim & Joel

From: Greg Mirsky <[email-masked]>
Sent: Wednesday, July 10, 2019 6:33 PM
To: James Guichard <[email-masked]>
Cc: [email-masked]
Subject: Re: [sfc] WG Last Call draft-ietf-sfc-oam-framework-06

Hi Jim, Joel, et al.,
I have a question about the scope of the SFC OAM Framework. In Section 1.1 the scope is defined as:
   The focus of this document is to provide an architectural framework
   for SFC OAM, particularly focused on the aspect of the Operations
   component within OAM.  Actual solutions and mechanisms are outside
   the scope of this document.
But after reading it several times over, I believe that the scope of the document is more narrow and includes only OAM for SFC NSH. I couldn't find any discussion of OAM for SFC based on RFC 8595, nor I could find it being referenced in the framework. If it is outside the scope of this document, should it provide an explanation, identify it as an outstanding work for the future?

Regards,
Greg

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%7C47025cacedc4489298f308d70586a75d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636983948205639558&sdata=rMbJ1lHWZ7ebYZZRYxlHqNwFyMx18Q%2FymDelgVTx8So%3D&reserved=0> for publication as an Informational RFC.

Thanks!

Jim & Joel

_______________________________________________
sfc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sfc<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsfc&data=02%7C01%7Cjames.n.guichard%40futurewei.com%7C47025cacedc4489298f308d70586a75d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636983948205639558&sdata=1Gd6%2BpgfSvWdBTv8THeXlpuM1PZL85YHFv67AA0dTSQ%3D&reserved=0>

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 22 Jul 2019 10:42:21 -0400

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

---

From: "Nagendra Kumar Nainar (naikumar)" <[email-masked]>
Date: Tue, 23 Jul 2019 17:58:11 +0000

Hi Greg,

Thank you for the comments. Please see our responses below.

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.

<Authors> Section 4.1 already list some of the OAM functions that can be performed as part of connectivity function.

More so, it appears that connectivity verification is being mixed with re-ordering detection, Path MTU Discovery, data integrity monitoring,

<Authors> Please refer Section 2.2.7 of RFC7276 that explains MTU verification as part of Connectivity verification. Section 3.1.1 already explains the rationale behind including policy verification.

and some sort of policy verification. Real kitchen sink.

<Authors> The intention is to capture/highlight various OAM functions based on the unique characteristics of SFC. Please read section 3.1.1 about SF availability. It is already explained about what is (or why) policy verification for SF availability. Accordingly, we humbly deny on this comment.

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.

<Authors> We dont understand your concern here. SFC OAM components explains what is availability and PM for SF/SFC (Refer section 3.1.x and 3.2.x) and tied it up with the function in section 4. The relevant sections also highlight the difference in SFC (For example, what is availability in terms of SF).

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.

<Authors> Thanks for highlighting this. We will add the same point under Section 4.2. Hope that satisfies your concern.

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?

<Authors> Thanks. To avoid any confusion, we modified it as below. Does the below modification help?

"It could be observed that ICMP at its current stage may not be able
   to perform all required SFC OAM functions, but as explained above, it
   can be used for some of the connectivity 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.

<Authors> Thanks, this looks like a valid point. We can change the same as below:

"BFD or S-BFD could be leveraged to perform continuity function for SF or 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.

<Authors> The intention is not to explain how it works for each BFD mode. But to explain the common behavior. AFAIK/R, setting relevant DIAG code in the response packet is common for both BFD and S-BFD. So we dont see any confusion here.

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?

<Authors> Section 6.4 is all about the applicability of different tools. It neither concludes nor prefers one over the other. How the data is collected, interpreted, used for failure detection or signaled back to the Initiator are expected to be explained in the solution document that proposes iOAM as the tool for SFC OAM. As mentioned in the document scope, any solution specific info is outside the scope of this document and accordingly we dont see a reason to include those details in this document.

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.

<Authors> This was already clarified by Carlos in different thread. The concept in the draft is already implemented and available in ODL.

Hope the above clarifies your queries. We are addressing the agreed comments and editorial comments that you raised in the other thread. We will submit a new version with the fixes.

Thanks,
Nagendra

From: sfc <[email-masked]> on behalf of Greg Mirsky <[email-masked]>
Date: Monday, July 22, 2019 at 10:44 AM
To: James Guichard <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [sfc] WG Last Call draft-ietf-sfc-oam-framework-06

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

Dear WG:

Thanks!

Jim & Joel

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 23 Jul 2019 16:38:41 -0400

Hi Nagendra,
thank you for your expedient response to my comments and questions. I am at
IETF this week and will respond with my notes after IETF. Apologies for the
delay, hope you'll understand.

Regards,
Greg

On Tue, Jul 23, 2019 at 1:58 PM Nagendra Kumar Nainar (naikumar) <
[email-masked]> wrote:

> 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.
>
>
>
> <Authors> Section 4.1 already list some of the OAM functions that can be
> performed as part of connectivity function.
>
>
>
> More so, it appears that connectivity verification is being mixed with
> re-ordering detection, Path MTU Discovery, data integrity monitoring,
>
>
>
> <Authors> Please refer Section 2.2.7 of RFC7276 that explains MTU
> verification as part of Connectivity verification. Section 3.1.1 already
> explains the rationale behind including policy verification.
>
>
>
> <Authors> The intention is to capture/highlight various OAM functions
> based on the unique characteristics of SFC. Please read section 3.1.1 about
> SF availability. It is already explained about what is (or why) policy
> verification for SF availability. Accordingly, we humbly deny on this
> comment.
>
>
>
> 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.
>
>
>
> <Authors> We dont understand your concern here. SFC OAM components
> explains what is availability and PM for SF/SFC (Refer section 3.1.x and
> 3.2.x) and tied it up with the function in section 4. The relevant sections
> also highlight the difference in SFC (For example, what is availability in
> terms of SF).
>
>
>
> 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.
>
>
>
> <Authors> Thanks for highlighting this. We will add the same point under
> Section 4.2. Hope that satisfies your concern.
>
>
>
> Also, the very last sentence of Section 4.1 concludes that ICMP in SFC
> 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.
>
>
>
> <Authors> The intention is not to explain how it works for each BFD mode.
> But to explain the common behavior. AFAIK/R, setting relevant DIAG code in
> the response packet is common for both BFD and S-BFD. So we dont see any
> confusion here.
>
>
>
>
>
> 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
> <Authors> Section 6.4 is all about the applicability of different tools.
> It neither concludes nor prefers one over the other. How the data is
> collected, interpreted, used for failure detection or signaled back to the
> Initiator are expected to be explained in the solution document that
> proposes iOAM as the tool for SFC OAM. As mentioned in the document scope,
> any solution specific info is outside the scope of this document and
> accordingly we dont see a reason to include those details in this document.
>
>
>
> 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.
>
>
>
> <Authors> This was already clarified by Carlos in different thread. The
> concept in the draft is already implemented and available in ODL.
>
>
>
> Hope the above clarifies your queries. We are addressing the agreed
> comments and editorial comments that you raised in the other thread. We
> will submit a new version with the fixes.
>
>
>
> Thanks,
>
> Nagendra
>
>
>
>
>
> *From: *sfc <[email-masked]> on behalf of Greg Mirsky <
> [email-masked]>
> *Date: *Monday, July 22, 2019 at 10:44 AM
> *To: *James Guichard <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>
> *Subject: *Re: [sfc] WG Last Call draft-ietf-sfc-oam-framework-06
>
>
>
> Dear Jim, Joe, et al.,
>
>    - 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
>    - 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?

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 30 Jul 2019 09:12:16 -0400

Hi Nagendra,
much appreciate your responses. Please find my notes in-line tagged GIM>>.

Regards,
Greg

> performed as part of connectivity function.
GIM>> My question was about the definition of the connectivity verification
function used in the document. Also, do you believe that connectivity
verification is a composite function that includes other OAM functions?

> explains the rationale behind including policy verification.
GIM>> Thank you for the reference to RFC 7276 but it does not state that
Path MTU Discovery (PMTUD) is part of CV. I believe that PMTUD can as well
be supported by the continuity check function and one of the examples is
the method described in draft-ietf-bfd-large-packets
<https://tools.ietf.org/html/draft-ietf-bfd-large-packets-00>. So, I don't
feel you've addressed my question.

> verification for SF availability. Accordingly, we humbly deny on this
GIM>> " Accordingly, we humbly deny on this comment." Which leaves me with
no other option but to state that you've failed to resolve my technical
comment.

> also highlight the difference in SFC (For example, what is availability in
GIM>> "SFC OAM components explains what is availability ..."
Can you provide the quote from this or other SFC OAM document that defines
the SFC availability? I've been asking for one to no avail. Thank you in
advance for clarifying this.
GIM>> "The relevant sections also highlight the difference in SFC (For
example, what is availability in terms of SF)."
So, do you believe that SFC availability has some differences from SF
availability? What are they? Is there a difference in measuring method or
measurement units between the availability of an SFC and an SF? Please
clarify.

> Section 4.2. Hope that satisfies your concern.
GIM>> Not really. Section 4.1 opens with "Connectivity is mainly an
on-demand function ..." and closes with "Proactively test alternate or
protected paths ..". That draws the question How on-demand function can be
used to proactively monitor a path? Perhaps you can add an example.

>    can be used for some of the connectivity functions."
GIM>> The text is an improvement, thank you. But it refers to "all required
SFC OAM functions" and I cannot find such list in the document. Can you
propose another text?

> "BFD or S-BFD could be leveraged to perform continuity function for SF or
GIM>> Thank you, that works.

> the response packet is common for both BFD and S-BFD. So we dont see any
GIM>> I am not saying that there's "any confusion", I'm pointing to clear
technical mistake in the description of how BFD in Asynchronous mode
operates. You may split the description of the mechanism for BFD and S-BFD
or find another way to fix the erroneous text.

> accordingly we dont see a reason to include those details in this document.
GIM>> I cannot find in your response what is being detected by iOAM. How,
from OAM PoV, is the reception of iOAM packet at the edge SFF is different
from receiving any data packet of the same flow? Without the clearly stated
distinction, without explaining the benefit of using iOAM for this function
the statement has no technical foundation and doesn't stand.

> concept in the draft is already implemented and available in ODL.
GIM>> I cannot evaluate how the implementation is compared to the long-ago
expired draft, so using that draft as the reference is not helpful to a
reader. Can yu find another source?

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 30 Jul 2019 09:26:34 -0400

Dear Jim, Joel, Editors, and All,
-010 version was published recently. I was quite surprised to find that the
discussion of O&M in SFC, i.e., SFC manageability, is now in its own
section. To confuse things even more, Editors kept the original title of
the table that lists various management tools: Table 4: OAM Tool GAP
Analysis. That raises several questions:

   - How O&M tools related to the scope of the document on OAM?
   - Are Editors committed to resolving comments or hope that a commentator
   would not check back?

I'm asking that last question because none of my comments from this note
has been addressed by the recent update.

Regards,
Greg

On Fri, Jul 12, 2019 at 9:24 AM Carlos Pignataro (cpignata) <
[email-masked]> wrote:

> On Jul 11, 2019, at 8:36 PM, Greg Mirsky <[email-masked]> wrote:
>
> Dear Jim, Joel, et al.
>       - NVo3 OAM - it is not clear what is included in it, especially
>       since there are no WG documents in NVO3 WG on OAM and the discussion of
>       - the title on the next page refers to Table 4: OAM Tool GAP
>       Analysis (contd.)
>       terminology. In Introduction SFC is for Service Function Chaining while in
> Great points on the terminology ad acronym mis-uses. These should be
> fixed. From expanding PM and fixing SFC’s expansion to explaining for IPPM
> is the protocols not the metrics.
>
> <https://tools.ietf.org/html/rfc6291> explains the variances of OAM soup
> in great details), I recommend removing the sentence.
>
>
> On configuration, I am OK removing the table column and sentence. I’m also
> OK moving that paragraph (and the one that follows) to a Manageability
> Considerations section.
>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 30 Jul 2019 22:01:13 +0000

Dear Greg,

Thank you for checking the new revision expeditiously, and for your follow-up.

Let me first address your second question below. I find the tone of your comment unprofessional and the content ad-hominem (it speaks about authors and their intentions and not about technical comments (it is really borderline insulting)). I debated whether to respond to that part, but I find that kindness and putting oneself in the other person shoes, seeking win-wins, is a most effective path. We are here to collaborate on making the Internet better. What we write here gets archived, and there is no need to resort to unnecessarily confrontational language or to assume the worst in others.

So, responding with a smile, please see the diffs at https://tools.ietf.org/rfcdiff?url2=draft-ietf-sfc-oam-framework-10.txt

You will see that two new terms were added to the acronyms, and a third was corrected. That is in direct response to your comment as agreed in the email below, when I thanked you for finding those editorials.

You will also see consolidation of the table and text exactly as described in the response below also. I gave a proposal and asked the WG for preference, but saw no replies. That answers your first question.

Consequently, when you say that none of your comments were addressed, that statement is factually incorrect. In addition to the changes in the document as per diffs, comments are also addressed on the list. Not everything will result in the specific textual change you envision.

It could very well be that we missed something, and if so we would love to be notified about it and will do our best to follow the WG’s direction. Tell us what we missed. But please be specific and technically focused. Instead of accusing, please quadruple check and ask.

At this point I’ll pass the token to the WG chairs to give directions and call whatever they see that needs to happen in the editing of this document. I feel we wasted lots of cycles on non-tech.

Best,

Thumb typed by Carlos Pignataro.
Excuze typofraphicak errows

2019/07/30 15:27、Greg Mirsky <[email-masked]<mailto:[email-masked]>>のメール:

Dear Jim, Joel, Editors, and All,
-010 version was published recently. I was quite surprised to find that the discussion of O&M in SFC, i.e., SFC manageability, is now in its own section. To confuse things even more, Editors kept the original title of the table that lists various management tools: Table 4: OAM Tool GAP Analysis. That raises several questions:

  *   How O&M tools related to the scope of the document on OAM?
  *   Are Editors committed to resolving comments or hope that a commentator would not check back?

I'm asking that last question because none of my comments from this note has been addressed by the recent update.

Regards,
Greg

On Fri, Jul 12, 2019 at 9:24 AM Carlos Pignataro (cpignata) <[email-masked]<mailto:[email-masked]>> wrote:
Thank you for your comments, Greg.

Please see inline.

Dear Jim, Joel, et al.

Thanks,

Carlos.

Regards,
Greg

Dear WG:

Thanks!

Jim & Joel

---

From: James Guichard <[email-masked]>
Date: Tue, 30 Jul 2019 22:31:12 +0000

Dear Greg,

For outstanding issues that you feel are not addressed in v-10 of this document, please provide a detailed list of items (with specific suggestions on textual changes if required) so that the editors may respond on the mailing list to each item and hopefully we can come to a timely resolution.

Thank you,

Jim

From: Carlos Pignataro (cpignata) <[email-masked]>
Sent: Tuesday, July 30, 2019 6:01 PM
To: Greg Mirsky <[email-masked]>
Cc: James Guichard <[email-masked]>; [email-masked]
Subject: Re: [sfc] WG Last Call draft-ietf-sfc-oam-framework-06

Dear Greg,

So, responding with a smile, please see the diffs at https://tools.ietf.org/rfcdiff?url2=draft-ietf-sfc-oam-framework-10.txt<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-sfc-oam-framework-10.txt&data=02%7C01%7Cjames.n.guichard%40futurewei.com%7Cae469def65704703051208d715397337%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637001208804262067&sdata=qDzFSKXnQPAy2ntu0uLnsDd0APuqYPN3YozFyzdeWqo%3D&reserved=0>

Best,

Regards,
Greg

Please see inline.

Dear Jim, Joel, et al.

Since the scope of the document includes only SFC OAM, not O&M (RFC 6291<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc6291&data=02%7C01%7Cjames.n.guichard%40futurewei.com%7Cae469def65704703051208d715397337%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637001208804272055&sdata=68dip4XjIdGSBZRWKcFB%2FYUAkhGAfKuHG7zLbtgMPNA%3D&reserved=0> explains the variances of OAM soup in great details), I recommend removing the sentence.

Thanks,

Carlos.

Regards,
Greg

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%7Cae469def65704703051208d715397337%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637001208804272055&sdata=PDneffIQfjlOgkwpnK5m4UN6drZUfLghUMTgM1T55Ls%3D&reserved=0> for publication as an Informational RFC.

Thanks!

Jim & Joel

_______________________________________________
sfc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sfc<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsfc&data=02%7C01%7Cjames.n.guichard%40futurewei.com%7Cae469def65704703051208d715397337%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637001208804282049&sdata=Jmyt5ABUwp%2FTypJV39xEqT6pXjp%2Bz8sw%2Fa2qH3COT70%3D&reserved=0>
_______________________________________________
sfc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sfc<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsfc&data=02%7C01%7Cjames.n.guichard%40futurewei.com%7Cae469def65704703051208d715397337%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637001208804282049&sdata=Jmyt5ABUwp%2FTypJV39xEqT6pXjp%2Bz8sw%2Fa2qH3COT70%3D&reserved=0>