Last Call Review of draft-ietf-mpls-sfc-04
review-ietf-mpls-sfc-04-rtgdir-lc-chen-2018-12-21-00

Hello,

I have been selected as the Routing Directorate reviewer for this draft. The
Routing Directorate seeks to review all routing or routing-related drafts as
they pass through IETF last call and IESG review, and sometimes on special
request. The purpose of the review is to provide assistance to the Routing ADs.
For more information about the Routing Directorate, please see
http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments
are primarily for the use of the Routing ADs, it would be helpful if you could
consider them along with any other IETF Last Call comments that you receive,
and strive to resolve them through discussion or by updating the draft.

Document: draft-ietf-mpls-sfc-04.txt
Reviewer: Mach Chen
Review Date: 2018-12-21
IETF LC End Date: date-if-know
Intended Status: Standards Track

Summary:
*       This draft is well written and easy to read. I have some minor concerns
about this document that I think should be resolved before publication.

Major Issues:
*       None.

Minor Issues:
*       Section 13 says:
"
   b.  When the packet arrives at SFFa it strips any labels associated
       with the tunnel that runs from the classifier to SFFa.  SFFa
       examines the top labels and matches the SPI/SI to identify that
       the packet should be forwarded to SFa.  The packet is forwarded
       to SFa unmodified.

   c.  SFa performs its designated function and returns the packet to
       SFFa.

   d.  SFFa modifies the SI in the lower label stack entry (to 254) and
       uses the SPI/SI to look up the forwarding instructions.  It sends
       the packet with two label stack entries:
"
>From above text, it seems that an SFF will have different process for a packet
that has the same SPI/SI.
  1) if a packet is received from a previous SFF, it will match the SPI/SI and
  determine to where the packet will be sent. 2)if a packet is received from an
  SF, it will directly modify the inner label, and then by matching the new
  SPI/SI to determine to where the packet will be sent.

Is this the intention ? If so, how does an SFF determine whether a packet is
from an SFF or from SF?

In addition, how does an SFF apply the swap and/or pop operations here. E.g.,
when an SFF looks up the SPI, it matches an item in a local table; what
operation (swap or pop) will apply to the SPI label? According to " The packet
is forwarded to SFa unmodified." It seems implies that there is no any
operation will be applied. If so, this will not align with the MPLS.

If the above issues exist, the " context/SF" case has the similar issues.

BR,
Mach