Last Call Review of draft-ietf-mpls-sfc-encapsulation-02
review-ietf-mpls-sfc-encapsulation-02-opsdir-lc-pignataro-2019-02-20-00

Request Review of draft-ietf-mpls-sfc-encapsulation
Requested rev. no specific revision (document currently at 04)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2019-02-26
Requested 2019-02-12
Authors Andrew Malis, Stewart Bryant, Joel Halpern, Wim Henderickx
Draft last updated 2019-02-20
Completed reviews Rtgdir Last Call review of -02 by Christian Hopps (diff)
Opsdir Last Call review of -02 by Carlos Pignataro (diff)
Secdir Last Call review of -02 by Paul Wouters (diff)
Genart Last Call review of -02 by Meral Shirazipour (diff)
Assignment Reviewer Carlos Pignataro
State Completed
Review review-ietf-mpls-sfc-encapsulation-02-opsdir-lc-pignataro-2019-02-20
Reviewed rev. 02 (document currently at 04)
Review result Has Issues
Review completed: 2019-02-20

Review
review-ietf-mpls-sfc-encapsulation-02-opsdir-lc-pignataro-2019-02-20

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.