Re: [mpls] MPLS extension header

Haoyu song <haoyu.song@huawei.com> Thu, 09 August 2018 19:28 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 73E0E130EC7 for <mpls@ietfa.amsl.com>; Thu, 9 Aug 2018 12:28:58 -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 3sxSBLKxEY5J for <mpls@ietfa.amsl.com>; Thu, 9 Aug 2018 12:28:56 -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 6B216130EBD for <mpls@ietf.org>; Thu, 9 Aug 2018 12:28:56 -0700 (PDT)
Received: from LHREML710-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 8D6CA1C1304AA for <mpls@ietf.org>; Thu, 9 Aug 2018 20:28:52 +0100 (IST)
Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.399.0; Thu, 9 Aug 2018 20:28:53 +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 12:28:48 -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//AQAYihOAAAFxsgAAEoHQgA==
Date: Thu, 09 Aug 2018 19:28:48 +0000
Message-ID: <78A2745BE9B57D4F9D27F86655EB87F93750CF32@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>
In-Reply-To: <a0f06f7b-5679-491c-aa19-310c7f46721e.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_78A2745BE9B57D4F9D27F86655EB87F93750CF32sjceml521mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/TY7x-R87b-oLoX7IADXrkVqgGQ8>
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 19:28:59 -0000

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

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