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.