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

["Adrian Farrel" <[e-mail]>]

Hi, 

 

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

 

Thanks,

Adrian

 

===

 

The document has 6 front-page authors: I assume the document shepherd 

will handle this with the AD.

 

---

 

The RFC Editor's preferred expansion of "OAM" is "Operations, 

Administration, and Maintenance" per RFC 6291.

 

---

 

Requirements language should use the latest boilerplate that includes

the reference to RFC 8174.

 

---

 

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.

 

---

 

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.

 

---

 

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

 

---

 

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.

 

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

 

---

 

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.

 

---

 

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

 

---

 

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.

 

---

 

I think [RFC0792] and [RFC4443] could afford to be Informative 

References as they are used in the same way as BFD, etc.

 

From: sfc <[e-mail]> On Behalf Of James Guichard
Sent: 28 May 2019 15:30
To: [e-mail]
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://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatrack
er.ietf.org%2Fdoc%2Fdraft-ietf-sfc-oam-framework%2F&data=02%7C01%7Cjames.n.g
uichard%40futurewei.com%7Ce47e5eb13f224f18c46408d6e378b2f7%7C0fee8ff2a3b2401
89c753a1d5591fedc%7C1%7C0%7C636946504868870205&sdata=lkKvAgmKik7lkqGANQpnIvB
RdbjKAqYtzTUdTfB9f3Y%3D&reserved=0>
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