Telechat Review of draft-ietf-sfc-multi-layer-oam-26
review-ietf-sfc-multi-layer-oam-26-intdir-telechat-bernardos-2023-06-28-00

I am an assigned INT directorate reviewer for draft-ietf-sfc-multi-layer-oam.
These comments were written primarily for the benefit of the Internet Area
Directors. Document editors and shepherd(s) should treat these comments just
like they would treat comments from any other IETF contributors and resolve
them along with any other Last Call comments that have been received. For more
details on the INT Directorate, see
https://datatracker.ietf.org/group/intdir/about/
<https://datatracker.ietf.org/group/intdir/about/>.

Based on my review, if I was on the IESG I would ballot this document as NO
OBJECTION.

The following are other issues I found with this document that SHOULD be
corrected before publication, including also minor issues (typos, misspelling,
minor text improvements):

Section 2.2:
I’d add references to the documents where the acronyms are defined/introduced.

Section 3:
“Segment SFC OAM” is not introduced/defined before in the document and I think
it’d be good to do it.

“For example, in the E2E FM SFC OAM case, the egress, SFF3, in the example in
Figure 1, could be the entity that detects the SFP's failure by monitoring a
flow of periodic test packets” —> this can be rewritten, to avoid repetitive
use of “example”

“*REQ#8: Can be addressed by an extension of the SFC Echo Request/ Reply
described in this document adding proxy capability“ —> I find this not easy to
parse (it refers to a way to satisfy a previously enumerated requirement, but
it is written differently to the other ones). Besides, it mentions “proxy
capability” and this is not mentioned using these words anywhere else in the
document.

Section 4:
It mentions message and packet. I guess both terms are used to refer to the
same thing, but I’d just use one term.

Section 5:
I’d probably explicitely add over which protocols an “Active SFC OAM Header”
can be transported.

Any requirement on the length/alignment of the SFC Active OAM Control Packet?

Section 6.3.1:
Should the title of this be “Source ID TLV”? Same applies to the caption of
Figure 5. I find a bit misleading using “Source TLV” and “Source ID TLV” and
“SFC Source TLV”.

I find the first paragraph of this section a bit too convoluted, because it
describes which destination IP and UDP to use, while these fields are in the
TLV message described after this paragraph.

When describing the “IP address” field it says that the value of the field MUST
be used as the destination IP address. But this is not said when describing the
“Port Number” field. I’d do the same for consistency.

Section 6.4:
When the document says “the control plane is triggered”, does this mean when an
SFC Echo Reply is triggered? It is not 100% clear what is referred here.

Again “Source TLV” should be checked for consistency and use whatever term is
finally used.

Section 6.5.3:
Minor: any recommendation on how many past SFC Echo Requests to keep to match
agains Echo Replies received?

Section 6.6.1:
“Must to include” —> “MUST include”

“SF Information Sub-TLV: The sub-TLV is as defined in Figure 10.”
—> I’d use “Section 6.6.2” instead of “Figure 10”.

Section 6.6.2:
Any alignment considerations for the “SF Identifier” field?

Sections 6.6.3.1 and 6.6.3.2:
Though I understand that there is a semantic difference, should we use the same
nomenclature in Figure 11 and Figure 12 regarding “CVRep1(SF1,SF2)” and
“CVRep1({SF1a,SF1b})”.

Section 7:
“To protect against unauthorized sources trying to obtain information about the
overlay and/or underlay, an implementation MAY check that the source of the
Echo Request is indeed part of the SFP.” —> I personally find this MAY weird.
Either it is left to the implementation how to check if the source of the Echo
Request is authorized (independently of whether is part of the SFP or not) or
I’d change this to be a SHOULD or a MUST if the sender has to be part of the
SFP.