Re: [mpls] New Version Notification for draft-xu-sfc-using-mpls-spring-04.txt

Xuxiaohu <xuxiaohu@huawei.com> Mon, 02 November 2015 06:48 UTC

Return-Path: <xuxiaohu@huawei.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CE801A00E6; Sun, 1 Nov 2015 22:48:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.76
X-Spam-Level:
X-Spam-Status: No, score=-1.76 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8BNqZ8ebkmZU; Sun, 1 Nov 2015 22:48:47 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E1B51A00DC; Sun, 1 Nov 2015 22:48:45 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CDJ77298; Mon, 02 Nov 2015 06:48:43 +0000 (GMT)
Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 2 Nov 2015 06:48:42 +0000
Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.187]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0235.001; Mon, 2 Nov 2015 14:48:38 +0800
From: Xuxiaohu <xuxiaohu@huawei.com>
To: Thomas Narten <narten@us.ibm.com>
Thread-Topic: New Version Notification for draft-xu-sfc-using-mpls-spring-04.txt
Thread-Index: AQHQ6uEhwUT+nrZsQk6IpAAbYfyXTp4z7JRggEylwuCAAEs5gIABG47wgAJPYQCABFL7aQ==
Date: Mon, 02 Nov 2015 06:48:37 +0000
Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0CB4184E@NKGEML512-MBS.china.huawei.com>
References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0CB3DFAF@NKGEML512-MBS.china.huawei.com> <m3a8r3dkvk.wl-narten@us.ibm.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0CB3E2EE@NKGEML512-MBS.china.huawei.com>, <m3vb9oumf1.wl-narten@us.ibm.com>
In-Reply-To: <m3vb9oumf1.wl-narten@us.ibm.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.194.185.102]
Content-Type: multipart/alternative; boundary="_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0CB4184ENKGEML512MBSchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/rtbPqpFFLpyyQ7N6yog4dY7E9Ls>
Cc: "'mpls@ietf.org'" <mpls@ietf.org>, "mpls-chairs@tools.ietf.org" <mpls-chairs@tools.ietf.org>, "'sfc@ietf.org'" <sfc@ietf.org>, "sfc-chairs@tools.ietf.org" <sfc-chairs@tools.ietf.org>
Subject: Re: [mpls] New Version Notification for draft-xu-sfc-using-mpls-spring-04.txt
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Nov 2015 06:48:49 -0000

Hi Thomas,

________________________________________
发件人: Thomas Narten [narten@us.ibm.com]
发送时间: 2015年10月31日 4:33
收件人: Xuxiaohu
抄送: 'sfc@ietf.org'; sfc-chairs@tools.ietf.org; 'mpls@ietf.org'; mpls-chairs@tools.ietf.org
主题: Re: New Version Notification for draft-xu-sfc-using-mpls-spring-04.txt

> According to the following statement quoted from the current SFC charter:
>
> "... The WG will examine existing identifier schemes,
>   if there is a need for such identifiers in the context of the Generic SFC
>   encapsulation, before defining any new identifier scheme.
> ..."
>
> It seems that this MPLS-SPRING-based SFC encapsulation scheme should be
> relevant to the SFC WG. At least, it could be investigated as a light-weight
> SFC encapsulation approach (from the aspect of reducing and even avoiding any
> impact on the data plane).

The charter also says:

   3. Generic SFC Encapsulation: This document will describe a single
      service-level data plane encapsulation format that:

I want to emphasize the term "a single ... encapsulation format" It
has been my understanding that the intention of this WG from the
beginning was to produce one encapsulation, not multiple ones.

[Xiaohu] My understanding is that the intention of this WG from the
beginning was to produce one encapsulation IF NEEDED. That' s why the following text is contained in the charter:

 "... The WG will examine existing identifier schemes,
if there is a need for such identifiers in the context of the Generic SFC
encapsulation, before defining any new identifier scheme..."


I think it has been clear for some time already that the WG has
selected the NSH document as its desired approach.

[Xiaohu] I wonder whether the work of examining existing identifier schemes as mentioned in the charter been finished or the WG now believe that work is not neccessary anymore?



Best regards,

Xiaohu

Are you suggesting that the WG take on this document as an additional
encapsulation for SFC? I do not think that is consistent with the
intent of the charter. Also, my read of the overall list discussion
with respect to this document is that the WG has not shown a strong
interest in this document nor indicated a compelling need for it.

If the WG disagrees with this assessment, I expect folk would speak
up.

Thomas