Reviewer: Carlos Pignataro Review Result: Has Issues I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. This document is highly readable, includes very clear textual descriptions, and is very well organized. Easy to read in its simplicity. However, it would benefit from a more explicit connection to the transport encap mechanics from RFC 8300 (e.g., S4, S6.1). Specifically, I'd recommend adding a Figure or an SFF NSH Mapping Table example, to depict and/or exemplify the SFF function. From an Operational standpoint, the document seems largely appropriate in terms of dataplane considerations. Some key considerations are explicitly out of scope: The method used by the downstream receiving node to advertise SFF Labels to the upstream sending node is out of scope of this document. This really seems to mean that, with the simple definition in this Informational document, interoperable implementations cannot yet exist. If there is no mechanism to advertise the SFF Label or to manage the semantics of this particular label, how will it know? Static configuration, which is not covered anyway, is not in my humble opinion a manageable scalable approach. Title: MPLS Encapsulation For The SFC NSH RFC 8300 makes an explicit distinction between the terms 'encapsulation' and 'transport encapsulation' (see e.g., Figure 1, Section 1.5 5., and Section 4 of RFC 8300). It seems to me that this is the "MPLS Transport Encapsulation for the SFC NSH" 2. MPLS Encapsulation Using an SFF Label Similarly, "2. MPLS Transport Encapsulation Using an SFF Label" The encapsulation is a standard MPLS label stack [RFC3032] with an SFF Label at the bottom of the stack, followed by a NSH as defined by [RFC8300] and the NSH payload. Insteadf of "NSH payload" I think "orignal packet" is meant. Also, this encapsulation is Underdefined: What is the value of TTL? TC? Much like a pseudowire label, an SFF Label is allocated by the downstream receiver of the NSH from its per-platform label space. A PW Label is more restrictive. RFC 8077 says it MUST be allocated as per-platform: egress LSR only. Note that the PW label must always be at the bottom of the packet's label stack, and labels MUST be allocated from the per-platform label space. Is this the case for the SFF Label as well? If so, what is the implication of the MUST? If not, why is it different than other equivalent similar labels? 2. Push the SFF Label to identify the desired SFF in the receiving MPLS node. TTL value? 1? 2? 255 for GTSM? GTSM RFC 5082 could be used here. 4. Operations, Administration, and Maintenance (OAM) Considerations OAM at the SFC Layer is handled by SFC-defined mechanisms [RFC8300]. However, OAM may be required at the MPLS transport layer. If so, then standard MPLS-layer OAM mechanisms such as the Generic Associated Channel [RFC5586] label may be used. RFC 5586 is _not_ an OAM mechanism. It is an associated channel creation mechanism, over which OAM could be carried. Thus, what traditional MPLS OAM can be carried here? Things like RFC 4379 / RFC 8029 would need the definition of an SFF Label FEC (which does not exist). Which other one? IP/ICMP seems of very limited value. 6. Security Considerations Have you considered the use of GTSM? 8. References [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function Chaining (SFC) Architecture", RFC 7665, DOI 10.17487/RFC7665, October 2015, . SHould RFC 7665 be Normative? It defines the "SFF" which is quite central to understanding this document. Other Nits and Editorials: SFF Labels are similar to other service labels at the bottom of an MPLS label stack that denote the contents of the MPLS payload being other than IP, such as a layer 2 pseudowire, an IP packet that is routed in a VPN context with a private address, or an Ethernet virtual private wire service. This says "being other than IP, such as IP", which seems to be self-contradictory :-) Best, Carlos Pignataro.