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

Hi, Adrian,

Thank you for the review! Please see inline.

On May 31, 2019, at 5:49 PM, Adrian Farrel <adrian@olddog.co.uk> wrote:

Hi,

I support publication, but there are a number of minor issues.

Thanks for the support and for flagging this.

Thanks,
Adrian

===

The document has 6 front-page authors: I assume the document shepherd
will handle this with the AD.

A publication request is a good gate to handle this, indeed.

---

The RFC Editor's preferred expansion of "OAM" is "Operations,
Administration, and Maintenance" per RFC 6291.

Indeed. I can see a “comma” missing in several places since the document expands to “Operation, Administration and Maintenance". This needs fixing. Any other instances you see?

---

Requirements language should use the latest boilerplate that includes
the reference to RFC 8174.

OK/

---

Section 2

  Multiple layers come into play for implementing the SFC.  These
  include the service layer and the underlying layers (Network, Link
  etc)
Missing two periods.
s/etc)/etc.)./

OLD
  o  The service layer in Figure 1, consists of SFC data plane elements
     that includes classifiers, Service Functions (SF), Service
     Function Forwarders (SFF), SFC Proxy.  This layer uses the overlay
     network for ensuring connectivity between SFC data plane elements.
NEW
  o  The service layer in Figure 1 consists of SFC data plane elements
     that include classifiers, Service Functions (SF), Service
     Function Forwarders (SFF), and an SFC Proxy.  This layer uses the
     overlay network for ensuring connectivity between SFC data plane
     elements.
END

Ditto s/Figure 1,/Figure 1/ in all of the subsequent bullets.

Thanks for these editorials — we will fix.

---

Looking at Figure 1, I don't understand how the overlay network has more
granularity than the underlay network. Surely the "legs" in the overlay
shown between VM1-VM2 and VM2-VM3 cannot exist without "legs" in the
underlay network.

Seems like there’s a “leg” missing.

---

In each of the bullets in Section 3, you say "OAM solutions for this
component" but Section 1.1 has already said "Actual solutions and
mechanisms are outside the scope of this document."

I think you could change 1.1 to read "Details of actual solutions and
mechanisms are outside the scope of this document." But maybe it would
be better if the bullets in Section 3 were "OAM functions applicable at
this component".

Or both. I agree with this, due to overloading of the word “solution”. I like changing to “functions” and also being more specific and prescriptive on the scope.

Or you could use "OAM requirements" as in Section 3.1.1 etc.

---

Section 3

s/Below figure/Figure 2/

The arrow for "Service Function Chain OAM" is misaligned in Figure 2

Ack.

---

Section 5 does not sit easily. It is good to have a list of exist OAM
solutions that might be applicable. But by presenting it as a gap
analysis there is an implication that these solutions are to be used
for SFC OAM. That is in opposition to the statement in Section 1.1.

Maybe the way to handle this is to rebrand Section 5 as an informational
list of pre-existing OAM solutions that might be applicable to SFC OAM.
And then to state that an analysis of their applicability is for future
study.

I think an analysis of gap with existing solutions does not imply that those must be used.

However, a bit of rewording would not hurt, particularly clarifying the future study / future decision.

But then Section 6.4 is a worry because it does talk about the
applicability of solutions. That would probably mean changing the tilt
of the whole document to be "Service Function Chaining (SFC) Operation,
Administration, and Maintenance (OAM) Framework and Applicability of
Existing OAM Tools to SFC.”

The potential applicability of existing solutions is part of a framework.

---

Section 6.3 has

  The Next Protocol field in NSH header may be
  used to indicate what OAM function is it intended to or what toolset
  is used.

s/is it/is/

But (!) I think this is solution text. It is completely true that this
is one way to do it, it might even be the best way to do it, but I think
it is out of scope.

I’ll push back on this one a bit.

While it is self-dictated out of scope to define specific OAM solution and protocols, it is quite necessary to guide on a normalized way on which the potentially different OAMs may be carried and pointed to. This is not specifying what solution, but the framework on top of what solutions ride.

---

Sections 6.5, 6.6, and 6.7, need to be out-dented to 7., 8., and 9.

OK.

---

The security considerations are a little weak. In particular, isn't
there a confidentiality issue. That is, if the results of OAM can be
inspected by a third party, they can deduce a lot about the network
and the structure of the Service function Chain. Since the chains are
themselves often used for security functions, this sort of information
is sensitive.

We could list confidentiality but that would be not beyond RFC 8300 text.

---

I think [RFC0792] and [RFC4443] could afford to be Informative
References as they are used in the same way as BFD, etc.

Agreed. Let’s move.

Thanks again Adrian for the comments that, once we address and incorporate fixes, will improve the doc!

Carlos.

From: sfc <sfc-bounces@ietf.org> On Behalf Of James Guichard
Sent: 28 May 2019 15:30
To: sfc@ietf.org
Subject: [sfc] 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/ 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

_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/mailman/listinfo/sfc