[RTG-DIR] RtgDir review: draft-ietf-mpls-sfc-04.txt

Mach Chen <mach.chen@huawei.com> Fri, 21 December 2018 14:22 UTC

Return-Path: <mach.chen@huawei.com>
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 2BEF612426A; Fri, 21 Dec 2018 06:22:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id uERx70w9XQ1J; Fri, 21 Dec 2018 06:22:01 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 578A6123FFD; Fri, 21 Dec 2018 06:22:01 -0800 (PST)
Received: from lhreml701-cah.china.huawei.com (unknown []) by Forcepoint Email with ESMTP id 4C4BDD8F9B468; Fri, 21 Dec 2018 14:21:57 +0000 (GMT)
Received: from DGGEML421-HUB.china.huawei.com ( by lhreml701-cah.china.huawei.com ( with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 21 Dec 2018 14:21:58 +0000
Received: from DGGEML530-MBS.china.huawei.com ([]) by dggeml421-hub.china.huawei.com ([]) with mapi id 14.03.0415.000; Fri, 21 Dec 2018 22:21:51 +0800
From: Mach Chen <mach.chen@huawei.com>
To: "rtg-ads@ietf.org" <rtg-ads@ietf.org>
CC: "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "mpls@ietf.org" <mpls@ietf.org>, "draft-ietf-mpls-sfc.all@ietf.org" <draft-ietf-mpls-sfc.all@ietf.org>
Thread-Topic: RtgDir review: draft-ietf-mpls-sfc-04.txt
Thread-Index: AdSZOHGt85HegsS7TxCSGyYrh2LDDQ==
Date: Fri, 21 Dec 2018 14:21:51 +0000
Message-ID: <F73A3CB31E8BE34FA1BBE3C8F0CB2AE2927E4EA8@dggeml530-mbs.china.huawei.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/6dlusbUhfqt35krK6HuZGlncTm8>
Subject: [RTG-DIR] RtgDir review: draft-ietf-mpls-sfc-04.txt
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Dec 2018 14:22:04 -0000


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

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