Re: [mpls] MPLS extension header

Haoyu song <haoyu.song@huawei.com> Thu, 09 August 2018 23:50 UTC

Return-Path: <haoyu.song@huawei.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 140A6130FB4 for <mpls@ietfa.amsl.com>; Thu, 9 Aug 2018 16:50:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 Y-2mR0mnw76H for <mpls@ietfa.amsl.com>; Thu, 9 Aug 2018 16:50:11 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 83D97128BAC for <mpls@ietf.org>; Thu, 9 Aug 2018 16:50:10 -0700 (PDT)
Received: from lhreml707-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id DFC0540778E36 for <mpls@ietf.org>; Fri, 10 Aug 2018 00:50:06 +0100 (IST)
Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.399.0; Fri, 10 Aug 2018 00:50:07 +0100
Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.107]) by SJCEML701-CHM.china.huawei.com ([169.254.3.151]) with mapi id 14.03.0399.000; Thu, 9 Aug 2018 16:50:05 -0700
From: Haoyu song <haoyu.song@huawei.com>
To: "徐小虎(义先)" <xiaohu.xxh@alibaba-inc.com>, "mpls@ietf.org" <mpls@ietf.org>
Thread-Topic: [mpls] MPLS extension header
Thread-Index: AdQvZQVDLmAHjMN2R8663ePuS7//AQAYihOAAAFxsgAAEoHQgAAXPssAAA5H9rA=
Date: Thu, 09 Aug 2018 23:50:04 +0000
Message-ID: <78A2745BE9B57D4F9D27F86655EB87F93750D00E@sjceml521-mbx.china.huawei.com>
References: <78A2745BE9B57D4F9D27F86655EB87F93750CBB5@sjceml521-mbx.china.huawei.com>, <ed42ce65-7281-4c4b-b67f-0d50b86a6759.xiaohu.xxh@alibaba-inc.com> <a0f06f7b-5679-491c-aa19-310c7f46721e.xiaohu.xxh@alibaba-inc.com>, <78A2745BE9B57D4F9D27F86655EB87F93750CF32@sjceml521-mbx.china.huawei.com> <ab1fe64b-bbdf-495c-a3be-7fdb3e5694a6.xiaohu.xxh@alibaba-inc.com>
In-Reply-To: <ab1fe64b-bbdf-495c-a3be-7fdb3e5694a6.xiaohu.xxh@alibaba-inc.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.209.217.138]
Content-Type: multipart/alternative; boundary="_000_78A2745BE9B57D4F9D27F86655EB87F93750D00Esjceml521mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/ytGZLZsg09_fYnFUYxZIyjM4rR8>
Subject: Re: [mpls] MPLS extension header
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.27
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: Thu, 09 Aug 2018 23:50:14 -0000

Inline. But please remember that is just one possible solution and not an essential one, and we prefer to delay its discussion until we finish the current work.

Haoyu

From: 徐小虎(义先) [mailto:xiaohu.xxh@alibaba-inc.com]
Sent: Thursday, August 09, 2018 4:33 PM
To: Haoyu song <haoyu.song@huawei.com>; mpls@ietf.org
Subject: Re: [mpls] MPLS extension header

Please see my response inline.

------------------------------------------------------------------
From:Haoyu song <haoyu.song@huawei.com<mailto:haoyu.song@huawei.com>>
Send Time:2018年8月10日(星期五) 03:28
To:徐小虎(义先) <xiaohu.xxh@alibaba-inc.com<mailto:xiaohu.xxh@alibaba-inc.com>>; mpls@ietf.org<mailto:mpls@ietf.org> <mpls@ietf.org<mailto:mpls@ietf.org>>
Subject:RE: [mpls] MPLS extension header

For example, no support of network programming in MPLS-SR

[Xiaohu] What concrete network programming capability is expected for MPLS-SR?
[Haoyu] Not study it in detail yet. I guess it’s something similar as in SRv6.

For another example, no support of metadata if MPLS-SR is used for SFC ☺

[Xiaohu] As for how metadata is carried in the MPLS-SR-based SFC mechanism, please see section 7.1 of https://tools.ietf.org/html/draft-xuclad-spring-sr-service-chaining-01.
[Haoyu] Well, here you point to the same draft again. Yes that’s one possible solution, yet here we just use the EH to support it and at the same time, for the same arguments, to cover other extensions as well.

Xiaohu

Haoyu

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of ???(??)
Sent: Wednesday, August 08, 2018 8:37 PM
To: 徐小虎(义先) <xiaohu.xxh@alibaba-inc.com<mailto:xiaohu.xxh@alibaba-inc.com>>; mpls@ietf.org<mailto:mpls@ietf.org>
Subject: Re: [mpls] MPLS extension header


By the way, I just noticed the following text in your draft:

"

   Segment Routing:  MPLS extension header can support the

      implementation of a new flavor of the MPLS-based segment routing,

      with better performance and richer functionalities.  The details

      will be described in another draft."



What's the rationale of implementing a new flavor of MPLS-based Segment Routing? In other words, what potential issues with the current MPLS-SR are to be addressed by the MPLS extension header-based MPLS-SR variation?



Best regards,

Xiaohu
------------------------------------------------------------------
From:徐小虎(义先) <xiaohu.xxh@alibaba-inc.com<mailto:xiaohu.xxh@alibaba-inc.com>>
Send Time:2018年8月9日(星期四) 10:56
To:mpls <mpls-bounces@ietf.org<mailto:mpls-bounces@ietf.org>>; mpls@ietf.org<mailto:mpls@ietf.org> <mpls@ietf.org<mailto:mpls@ietf.org>>
Subject:Re: [mpls] MPLS extension header

Hi Haoyu,

I believe it's worthwhile to introduce an MPLS payload indicator into MPLS so as to support various MPLS payload types in a long run. However, I wonder whether the mechanism as described in (https://tools.ietf.org/html/draft-xu-mpls-payload-protocol-identifier) has met this demand.

Best regards,
Xiaohu
------------------------------------------------------------------
From:Haoyu song <haoyu.song@huawei.com<mailto:haoyu.song@huawei.com>>
Send Time:2018年8月9日(星期四) 06:24
To:mpls@ietf.org <mpls@ietf.org<mailto:mpls@ietf.org>>
Subject:[mpls] MPLS extension header

Dear all,

In IETF102 we presented the idea of MPLS extension header and received a lot of discussion. We have updated the draft to reflect the feedbacks we received.
It seems most people agree that we need extension headers (EH) to support multiple emerging in-network services, but there could be debate on how to indicate the existence of the EHs.
In the document we provide our investigations and suggestions but we do want to see your opinion. Hopefully we can achieve a consensus before IETF103.
Thank you in advance for your help!

https://www.ietf.org/id/draft-song-mpls-extension-header-01.txt

Best regards,
Haoyu