Re: [mpls] MPLS extension header

" 徐小虎(义先) " <xiaohu.xxh@alibaba-inc.com> Fri, 10 August 2018 00:03 UTC

Return-Path: <xiaohu.xxh@alibaba-inc.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 B2EF1130FBA; Thu, 9 Aug 2018 17:03:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.019
X-Spam-Level:
X-Spam-Status: No, score=-1.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alibaba-inc.com
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 Ov0dzRYOD3Ne; Thu, 9 Aug 2018 17:03:51 -0700 (PDT)
Received: from out0-133.mail.aliyun.com (out0-133.mail.aliyun.com [140.205.0.133]) (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 C3687130F8D; Thu, 9 Aug 2018 17:03:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1533859426; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type; bh=Vd1todWHZBaFAtXfQlreGaTRzz5kiTRxNoLGg+dWNHo=; b=H8iaLTO43+B8GW4aENBNQvn0cn9FeOaaR5K3+RIiEZ+dIeMeYg1zDZx1nSv7zKz1cZYvBhwnzJqJbwADdRr2BoM6VzFX5Hg9nIvZB1uMmNZT/dkPafoiqVdhVDo3qgVPsnt7xdwUUSky1wDQ3pn8EnUIKPZLdW2555h4jhuJA0s=
X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R861e4; CH=green; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e01e01546; MF=xiaohu.xxh@alibaba-inc.com; NM=1; PH=DW; RN=4; SR=0; TI=W4_5335686_v5ForWebDing_0A9323E5_1533858731746_o7001c56n;
Received: from WS-web (xiaohu.xxh@alibaba-inc.com[W4_5335686_v5ForWebDing_0A9323E5_1533858731746_o7001c56n]) by e01l07390.eu6 at Fri, 10 Aug 2018 08:03:38 +0800
Date: Fri, 10 Aug 2018 08:03:38 +0800
From: "徐小虎(义先)" <xiaohu.xxh@alibaba-inc.com>
To: Haoyu song <haoyu.song@huawei.com>, Stewart Bryant <stewart.bryant@gmail.com>
Cc: "mpls@ietf.org" <mpls@ietf.org>, mpls <mpls-bounces@ietf.org>
Reply-To: "徐小虎(义先)" <xiaohu.xxh@alibaba-inc.com>
Message-ID: <1092f301-a7fa-4472-a068-f24224340bc1.xiaohu.xxh@alibaba-inc.com>
X-Mailer: [Alimail-Mailagent revision 7][W4_5335686][v5ForWebDing][Safari]
MIME-Version: 1.0
References: <78A2745BE9B57D4F9D27F86655EB87F93750CBB5@sjceml521-mbx.china.huawei.com> <ed42ce65-7281-4c4b-b67f-0d50b86a6759.xiaohu.xxh@alibaba-inc.com> <C52EA1C4-862A-43E5-BEBF-0C3ACC3397D4@gmail.com>, <78A2745BE9B57D4F9D27F86655EB87F93750CF15@sjceml521-mbx.china.huawei.com> <2eab7b09-9e9d-460e-97de-e57a02f58d40.xiaohu.xxh@alibaba-inc.com>, <78A2745BE9B57D4F9D27F86655EB87F93750CFF5@sjceml521-mbx.china.huawei.com>
In-Reply-To: <78A2745BE9B57D4F9D27F86655EB87F93750CFF5@sjceml521-mbx.china.huawei.com>
x-aliyun-mail-creator: W4_5335686_v5ForWebDing_QvNTW96aWxsYS81LjAgKE1hY2ludG9zaDsgSW50ZWwgTWFjIE9TIFggMTBfMTJfNikgQXBwbGVXZWJLaXQvNjA0LjUuNiAoS0hUTUwsIGxpa2UgR2Vja28pIFZlcnNpb24vMTEuMC4zIFNhZmFyaS82MDQuNS42La
Content-Type: multipart/alternative; boundary="----=ALIBOUNDARY_6469_4e92a940_5b6cd65a_25ceca"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/iqPd_M_Ii8BWFqWccehB-2HVyQ4>
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: Fri, 10 Aug 2018 00:03:54 -0000

See inline

------------------------------------------------------------------
From:Haoyu song <haoyu.song@huawei.com>
Send Time:2018年8月10日(星期五) 07:41
To:徐小虎(义先) <xiaohu.xxh@alibaba-inc.com>; Stewart Bryant <stewart.bryant@gmail.com>
Cc:mpls@ietf.org <mpls@ietf.org>; mpls <mpls-bounces@ietf.org>
Subject:RE: [mpls] MPLS extension header


Inline

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

Please see my reply inline.
 
------------------------------------------------------------------
From:Haoyu song <haoyu.song@huawei.com>
Send Time:2018年8月10日(星期五) 03:26
To:Stewart Bryant <stewart.bryant@gmail.com>; 徐小虎(义先) <xiaohu.xxh@alibaba-inc.com>
Cc:mpls@ietf.org <mpls@ietf.org>; mpls <mpls-bounces@ietf.org>
Subject:RE: [mpls] MPLS extension header

Hi Xiaohu and Stewart,

First,  the intention of this draft is not to tell the protocol type of the MPLS payload, but to indicate the existence of EHs. I admit the high level idea is similar: we need some indicator for something.  

[Xiaohu] Either using the protocol type field or using the EH, we need to indicate the existence of it between MPLS label stack and the MPLS payload. 
[Haoyu] Correct.

Here are some considerations for choosing the EH indicator:
(1) Support multiple in-network service headers to be encapsulated into MPLS packets. Most existing proposals only assume there is one extra header.

[Xiaohu] Could you give a concrete example where multiple EHs are needed especially in the case where each in-network service header itself has a protocol field?. 
         [Haoyu] We listed several use cases in the draft. Several of them can be applied at the same time (e.g., iOAM+SFC). It’s true for some headers they already defined a protocol field (e.g., NSH). But for others, there is not a protocol field (e.g., iOAM). My feeling is that many of these headers should not be considered as protocol header but rather service header, so they are better to be treated as extension headers.  

【Xiaohu1】Should those headers which lack a protocol field first fix their own issue, just as what we want to do with MPLS?

(2) Because each node needs to check the existence of EHs, for performance considerations, we don’t want to force the indicator to be at the bottom of the stack; Besides, too many proposals have already competed for the BoS location, and such proposals also often impair the ECMP capability based on the payload header.

[Xiaohu] Could you explain more concretely how the ECMP capability is impaired when the indicator label is at the bottom of the label stack? 
         [Haoyu] In case the original packet after MPLS labels is IPv4, the IP 5-tuple header is used as hash key for ECMP. Now if there is something else in between, you can’t do it anymore unless you parse the new stuff and skip it. With the EH we proposed, we have the similar situation but we provide a mechanism to skip all EHs in one step without needing to parse them.

[Xiaohu1] How to skip all EHs if the EHL and EHs are not recognized by intermediate routers?

Xiaohu

(3) For the same reason, we prefer an indicator that can directly tell the existence of EHs, rather than overloading some existing labels, and then jumping to another control word after the label stack to see if there are actually EHs. 

[Xiaohu] Leave this to Stewart

Best regards,
Xiaohu

To meet these requirements, we listed several possible solutions in the draft (there may be others we neglected). If you have a strong opinion to prefer one over the others, please let me know with your reason. 

Best regards,
Haoyu

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Stewart Bryant
Sent: Thursday, August 09, 2018 12:35 AM
To: "徐小虎(义先)" <xiaohu.xxh@alibaba-inc.com>
Cc: mpls@ietf.org; mpls <mpls-bounces@ietf.org>
Subject: Re: [mpls] MPLS extension header

Xiahou

A better approach for metadata would be s/PIL/GAL as described in:

https://www.ietf.org/archive/id/draft-guichard-sfc-mpls-metadata-00.txt

I cannot see why we need another reserved label when the one we have would work fine in this application, and many more.

Stewart



Sent from my iPad

 On 9 Aug 2018, at 05:56, 徐小虎(义先) <xiaohu.xxh@alibaba-inc.com> wrote:

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>
Send Time:2018年8月9日(星期四) 06:24
To:mpls@ietf.org <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

_______________________________________________
 mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls