Last Call Review of draft-ietf-mpls-sfc-04

Request Review of draft-ietf-mpls-sfc
Requested rev. no specific revision (document currently at 07)
Type Last Call Review
Team Routing Area Directorate (rtgdir)
Deadline 2018-12-21
Requested 2018-12-04
Requested by Deborah Brungard
Authors Adrian Farrel, Stewart Bryant, John Drake
Draft last updated 2018-12-21
Completed reviews Rtgdir Last Call review of -04 by Mach Chen (diff)
Secdir Last Call review of -04 by Russ Mundy (diff)
Secdir Telechat review of -05 by Russ Mundy (diff)
Prep for Last Call
Assignment Reviewer Mach Chen
State Completed
Review review-ietf-mpls-sfc-04-rtgdir-lc-chen-2018-12-21
Reviewed rev. 04 (document currently at 07)
Review result Has Issues
Review completed: 2018-12-21



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
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

*	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

   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.