Reviewer: Carlos Pignataro
Review result: Has Issues
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,
<https://www.rfc-editor.org/info/rfc7665>.
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.
