[Int-dir] Éric Vyncke's No Objection on draft-ietf-sfc-oam-framework-13: (with COMMENT)

[Éric Vyncke via Datatracker <[e-mail]>]

Éric Vyncke has entered the following ballot position for
draft-ietf-sfc-oam-framework-13: No Objection

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/



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

Thank you for the work put into this document. The document is easy to read;
BTW, I found that its content is more about the justifications / requirements
for an OAM system and tools descriptions than about for a framework description.

The core of the document appears to be section 6: this should probably be
reflected in the abstract and introduction

Please address the comments raised in the Internet directorate review by Carlos
Bernardos:
https://mailarchive.ietf.org/arch/msg/int-dir/TgQulH7hytGPNxdAPWcSgkTx1IM

Please find below a couple on non-blocking COMMENTs. I would really appreciate
a reply to all these COMMENTs.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

I would not refer to BCP 14 (RFC 8174) as this is an architectural/framework
document (informational) and not a protocol specification.

It seems that most of the described tools are about synthetic traffic. Is there
any other means to do OAM in SFC (not that I have any suggestion...)?.

-- Section 1 --
About "to be applied to packets and/or frames", for me packets are layer-3 PDUs
and frames are layer-2 PDUs. While I am not familiar with SFC, I could envision
SFC being applied to transport or application layers PDUs. So, why restricting
the use of this document to layers 2 and 3 only ?

-- Section 2 --
Is there a reason why all 'virtual links' are not mentioned in this section?
I.e., SR-IOv network, tun/tap, ...

Similar question about why limiting the example of VM and not including
containers ?

-- Section 3 --
The word "performance" is often used in the document but it is not described in
depth though: is it about the SF CPU/memory or 'client traffic' latency &
throughput ? Section 4 partially addresses my question but not completely;
also, adding forward pointers to section 4 would be nice.

-- Section 4.3 --
Please bear with my ignorance of SFC world... but, if a SF is doing proxying /
rewriting the application message, how useful is an end-to-end PMTUd check? As
there are two stitched TCP connections ?

The overall assumption of this section is that all SF are pure layer-3, leaving
the IP header intact so that ECMP & TTL checks can be done. Is it always the
case ?

Section 5.2 addresses the above points, but, I suggest that section 4.3 to be
restricted to ' link-layer OAM'

-- Section 6.4.1 --
"TTL field in NSH header to 63", not familiar with NSH, but, if there is a TTL
field in NSH, then it could be useful to point to the RFC & section describing
it. Esp in a section whose title is "ICMP" (referring obviously to the IP
header).

-- Section 8 --
In this security section, I wonder whether the trace tool deserves a paragraph
or two as if trusted while being forgeable/spoofed, then operators could trust
a SFC which is "owned" and not reliable (i.e., with a bypass of some security
SF). Trusting the security AD to raise a DISCUSS if they think it is a DISCUSS.

== NITS ==

-- section 6.3 --
Is it really required to re-specify the use of bit O in NSH ?

-- Section 6.4.1 --
Sigh... using the IPv4 terminology of TTL...