Re: [mpls] MPLS extension header
Haoyu song <haoyu.song@huawei.com> Thu, 09 August 2018 18:57 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 07BB2130EA6 for <mpls@ietfa.amsl.com>; Thu, 9 Aug 2018 11:57:56 -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 fWsTcMtGiHAs for <mpls@ietfa.amsl.com>; Thu, 9 Aug 2018 11:57:52 -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 75199130E2B for <mpls@ietf.org>; Thu, 9 Aug 2018 11:57:52 -0700 (PDT)
Received: from lhreml702-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 59A85FFDCAB1D for <mpls@ietf.org>; Thu, 9 Aug 2018 19:57:48 +0100 (IST)
Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.399.0; Thu, 9 Aug 2018 19:57:49 +0100
Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.107]) by SJCEML702-CHM.china.huawei.com ([169.254.4.139]) with mapi id 14.03.0399.000; Thu, 9 Aug 2018 11:57:44 -0700
From: Haoyu song <haoyu.song@huawei.com>
To: "stephane.litkowski@orange.com" <stephane.litkowski@orange.com>, "mpls@ietf.org" <mpls@ietf.org>
Thread-Topic: MPLS extension header
Thread-Index: AdQvZQVDLmAHjMN2R8663ePuS7//AQAirTPAAAg4WsA=
Date: Thu, 09 Aug 2018 18:57:43 +0000
Message-ID: <78A2745BE9B57D4F9D27F86655EB87F93750CEC0@sjceml521-mbx.china.huawei.com>
References: <78A2745BE9B57D4F9D27F86655EB87F93750CBB5@sjceml521-mbx.china.huawei.com> <2437_1533826308_5B6C5504_2437_497_1_9E32478DFA9976438E7A22F69B08FF924B26D95F@OPEXCLILMA4.corporate.adroot.infra.ftgroup>
In-Reply-To: <2437_1533826308_5B6C5504_2437_497_1_9E32478DFA9976438E7A22F69B08FF924B26D95F@OPEXCLILMA4.corporate.adroot.infra.ftgroup>
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_78A2745BE9B57D4F9D27F86655EB87F93750CEC0sjceml521mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/htVY91zC0BCHxAVKom05OQzymHw>
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 18:57:57 -0000
Hi Stephane, Thank you very much for the question and comments. If the EH is applied in a single network domain and all the devices are upgraded to support it, then there is no need to signal the EHL. I think this is a possible scenario. For your second question, I don't quite understand it. Only the EHL is in the label stack. The HEH and EHs are fields located between the MPLS label stack and the payload. Unless some EHs are no longer needed, they are always there waiting for being parsed and processed, so there is no need for "copy back". Please let me know if I misunderstood your question. Best regards, Haoyu From: stephane.litkowski@orange.com [mailto:stephane.litkowski@orange.com] Sent: Thursday, August 09, 2018 7:52 AM To: Haoyu song <haoyu.song@huawei.com>; mpls@ietf.org Subject: RE: MPLS extension header Hi "An EHL can be located in anywhere in an MPLS label stack. However, if there are legacy devices which do not recognize the EHL in the network, then for backward compatibility, the EHL must be located at the bottom of the stack (i.e., only the MPLS tunnel ends and EHL-aware nodes will look up and process it). Otherwise, the EHL can be located close to the top of the stack for better lookup performance." I don't like the statement that the EHL can be located anywhere. As you mentioned in the text, the ingress needs to know if transit nodes and the tailend are able to process EHL. How do you plan to signal this ? Let's say that all transit+tail end support the EHL. In such a case, you propose to place the EHL close to the top of the stack. In the example below, what is the behavior of Node B ? After parsing the EHs, does it copy back the EHs above Node_SID_F to let them available for other nodes ? A-B-C-D-E-F A: ingress node pushing label stack [Adj_SID_BC, EHL, HEH,..., Node_SID_F } From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Haoyu song Sent: Thursday, August 09, 2018 00:24 To: 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 _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
- [mpls] MPLS extension header Haoyu song
- Re: [mpls] MPLS extension header 徐小虎(义先)
- Re: [mpls] MPLS extension header 徐小虎(义先)
- Re: [mpls] MPLS extension header Stewart Bryant
- Re: [mpls] MPLS extension header stephane.litkowski
- Re: [mpls] MPLS extension header Haoyu song
- Re: [mpls] MPLS extension header Haoyu song
- Re: [mpls] MPLS extension header Haoyu song
- Re: [mpls] MPLS extension header 徐小虎(义先)
- Re: [mpls] MPLS extension header 徐小虎(义先)
- Re: [mpls] MPLS extension header Haoyu song
- Re: [mpls] MPLS extension header John E Drake
- Re: [mpls] MPLS extension header Haoyu song
- Re: [mpls] MPLS extension header Haoyu song
- Re: [mpls] MPLS extension header 徐小虎(义先)
- Re: [mpls] MPLS extension header Haoyu song
- Re: [mpls] MPLS extension header 徐小虎(义先)
- Re: [mpls] MPLS extension header Tianran Zhou
- Re: [mpls] MPLS extension header stephane.litkowski
- Re: [mpls] MPLS extension header Adrian Farrel
- Re: [mpls] MPLS extension header Haoyu song
- Re: [mpls] MPLS extension header Haoyu song