Subject: [sfc] Moving forward with https://datatracker.ietf.org/doc/draft-ietf-sfc-oam-framework/

From: James N Guichard <[email-masked]>
Date: Wed, 2 Aug 2017 15:34:12 +0000

Dear WG:

During our meeting at IETF99 it was clear that the WG wants to move forward with https://datatracker.ietf.org/doc/draft-ietf-sfc-oam-framework/. However, we would like to get more clarity on what the WG would like to see in the document and what changes are needed so that the document can progress. Please do provide comments to the mailing list so that we can improve the document (if needed) and move it forward toward publication.

Thanks!

Jim & Joel

---

From: Carlos Pignataro <[email-masked]>
Date: Wed, 2 Aug 2017 11:58:42 -0400

Jim, Joel,

A couple of thoughts from my perspective:

Given the diversity of OAM functions, solutions, and protocols, there is a need for a document to anchor the conversation around architectural framing. This document should serve that main goal. At the same time, a “framework only” document is too fluffy and we need to bring it down to realities, and consequently:
OAM Architectural component, layering, function specification within scope. Main goal of the document
SF OAM out of scope.
Also, “requirements listing” not useful!
Use cases (i.e., Functions) within scope -> Continuity, Trace, PM, etc.
Catalog of existing protocols and solutions within scope
Description of protocols and mapping to functions is *very* useful to keep things concrete.
Specification of new protocols out of scope.
Applicability also useful

My $0.02.

Thanks,

Carlos.

> On Aug 2, 2017, at 11:34 AM, James N Guichard <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Dear WG:
>  
> During our meeting at IETF99 it was clear that the WG wants to move forward with https://datatracker.ietf.org/doc/draft-ietf-sfc-oam-framework/ <https://datatracker.ietf.org/doc/draft-ietf-sfc-oam-framework/>. However, we would like to get more clarity on what the WG would like to see in the document and what changes are needed so that the document can progress. Please do provide comments to the mailing list so that we can improve the document (if needed) and move it forward toward publication.
>  
> Thanks!
>  
> Jim & Joel
>  
>  
>  
> _______________________________________________
> sfc mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/sfc <https://www.ietf.org/mailman/listinfo/sfc>
—
Carlos Pignataro, [email-masked] <mailto:[email-masked]>

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

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 2 Aug 2017 17:41:22 -0700

Hi Jim, Joel, et. al,
thank you for bringing the state and the direction of the SFC OAM Framework
document to discussion. I agree that this document is overdue and we should
look into how to complete it in the shortest time possible while making it
useful. Hence my proposal to how WG can change the document:

   - remove or move to Appendix section 5 Gap Analysis. The section does
   not provide any value for SFC OAM solution work and may have only limited
   historical interest for the next generations;
   - remove added into the last version section 6.4. If the intention of
   Editors was to list all SFC OAM solutions, then we would not be able to
   finish this document until the WG agrees that SFC OAM solutions defined in
   either published RFCs or in adopted by WF drafts are sufficient. Just last
   meeting there were four drafts presented that are not yet listed in the
   section 6.4 of SFC OAM Framework. If the selection of drafts  referenced in
   section 6.4 reflects personal opinions of the Editors, then I shall remind
   that section 2.3 RFC 2028 defines the responsibility of Document Editor as:

   The Document Editor is responsible for ensuring that the contents
of the document accurately reflect the decisions that have been made
by the working group.

After WG decides on the content of the document, then, I believe, the
discussion of the SFC OAM model and assumptions made, e.g. "... the

   SFC's are generally unidirectional in nature ...", will be more
efficient and productive.

Regards,

Greg

On Wed, Aug 2, 2017 at 8:34 AM, James N Guichard <
[email-masked]> wrote:

> Dear WG:
>
>
>
> During our meeting at IETF99 it was clear that the WG wants to move
> forward with https://datatracker.ietf.org/doc/draft-ietf-sfc-oam-
> framework/. However, we would like to get more clarity on what the WG
> would like to see in the document and what changes are needed so that the
> document can progress. Please do provide comments to the mailing list so
> that we can improve the document (if needed) and move it forward toward
> publication.
>
>
>
> Thanks!
>
>
>
> Jim & Joel
>
>
>
>
>
>
>
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc
>
>

---

From: <[email-masked]>
Date: Thu, 3 Aug 2017 09:19:44 +0000

Hi Jim, all,

I like the document and its current scope.

The document needs some work. FWIW, my comments are available at https://github.com/boucadair/draft-ietf-sfc-oam-framework/blob/master/draft-ietf-sfc-oam-framework-02-rev%20Med.doc

Cheers,
Med

De : sfc [mailto:[email-masked]] De la part de James N Guichard
Envoyé : mercredi 2 août 2017 17:34
À : [email-masked]
Objet : [sfc] Moving forward with https://datatracker.ietf.org/doc/draft-ietf-sfc-oam-framework/

Dear WG:

Thanks!

Jim & Joel