[mpls] 答复: Solicit Opinions on Definition of MPLS Global Label
Lizhenbin <lizhenbin@huawei.com> Thu, 05 November 2015 04:58 UTC
Return-Path: <lizhenbin@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 39CEB1B3932 for <mpls@ietfa.amsl.com>; Wed, 4 Nov 2015 20:58:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.739
X-Spam-Level: *
X-Spam-Status: No, score=1.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, 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 E2KLBjVwhF2t for <mpls@ietfa.amsl.com>; Wed, 4 Nov 2015 20:58:05 -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 04D4D1B393A for <mpls@ietf.org>; Wed, 4 Nov 2015 20:58:04 -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 CDR49107; Thu, 05 Nov 2015 04:58:02 +0000 (GMT)
Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 5 Nov 2015 04:57:53 +0000
Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.20]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0235.001; Thu, 5 Nov 2015 12:57:48 +0800
From: Lizhenbin <lizhenbin@huawei.com>
To: Eric Gray <eric.gray@ericsson.com>, Loa Andersson <loa@pi.nu>
Thread-Topic: [mpls] Solicit Opinions on Definition of MPLS Global Label
Thread-Index: AdEWs37wCLrB6MbkTaujhtDJQWTFpwAEVISAABM6O5AABPGugAAB7wSAABVDJ9k=
Date: Thu, 05 Nov 2015 04:57:47 +0000
Message-ID: <5A5B4DE12C0DAC44AF501CD9A2B01A8D8CA65A85@nkgeml506-mbx.china.huawei.com>
References: <5A5B4DE12C0DAC44AF501CD9A2B01A8D8CA63EA4@nkgeml506-mbx.china.huawei.com> <6524_1446618416_5639A530_6524_1437_1_53C29892C857584299CBF5D05346208A0F69BE62@OPEXCLILM21.corporate.adroot.infra.ftgroup> <DB3PR03MB0780225100B2E64AF44E13C49D2A0@DB3PR03MB0780.eurprd03.prod.outlook.com>, <563AAF89.8010007@pi.nu>,<08B0A2A1-33A0-4F26-98EA-694882BD8F63@ericsson.com>
In-Reply-To: <08B0A2A1-33A0-4F26-98EA-694882BD8F63@ericsson.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.81]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.563AE1DA.00D4, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.20, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: eee857013ebad0b6a57b4a1e79e6e341
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/nwbXyMXoefrpgQwhlsPK6dAEdSU>
Cc: "mpls@ietf.org" <mpls@ietf.org>
Subject: [mpls] 答复: Solicit Opinions on Definition of MPLS Global Label
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: Thu, 05 Nov 2015 04:58:09 -0000
Hi Folks, I agree you about the possbile division about the per-platform label space, context-specific label space and special purpose label space. In sec 4 of our draft draft-li-mpls-global-label-usecases-03, I explained two pairs of label concept: 1. per-platform label space and context-specific label space 2. local label and global label (If you think the concept is confused, in the following section I will use another name "TBD label". Regarding the first pair of concept, it is just to define different label space, it is easy work. I can also agree that the special purpose label can also be separated from the per-platform label space. But my issues to solicit opinion is not for this pair of label concept. I would like to collect your opinion on that shown in the figure 3 of the draft draft-li-mpls-global-label-usecases-03. In the figure, it shows that a group of labels which are allocated by LDP/RSVP-TE/MP-BGP whose meaning are always understood by the local upstream nodes and downstream nodes. We can easily define it as "local label". But there are another group label ideas on the opposite these label ideas such as upstream label, entropy/label, domain-wide label etc. We tried to abstract common characteristics to define it as "TBD label". Regarding these label ideas, in the control plane, it seems all of them can take different means to make label meaning to be learned by more nodes other than the local upstream nodes and downstream nodes. In the forwarding plane, it also introduce some new forwarding mechanism. In my opinion, both "local label" and "TBD label" can be allocated from the per-platform label space or context-specific label space (including per-interface label space). But they has different behaviors in the control plane and forwarding plane. I would like to change my description of my proposedo pinions: Opinion 1: Segment Routing has nothing with "TBD label" and please do not make it bother MPLS WG. But it seems a little hard to convince some MPLSers. Opinion 2: The usecase truly exists. But the concept of "TBD label" is too big. It is hard to allocate a label whose meaning is unique spanning multiple domains or the same as IP address which is unique all over world since it is not a scalable way or it is hard to achieve the goal. Then maybe it is a better way to narrow the scope to rename the global label as Domain-wide label, Network-wide label, etc. Opinion 3: The "TBD label" can be kept to cover more label concepts which label behaviors in the control plane and forward plane are different form the traditional LDP/RSVP-TE/MP-BGP. Hope you can understand it is not a simple issue to divide label space with Special Purpose Label Space, Per-Plaform Label Space and Context-specific Label Space. It involves abstraction of label behavior in the forwarding plane and the control plane. And hope you can go on feedback your opinions. Best Regards, Zhenbin(Robin) ________________________________________ 发件人: mpls [mpls-bounces@ietf.org] 代表 Eric Gray [eric.gray@ericsson.com] 发送时间: 2015年11月5日 10:18 收件人: Loa Andersson 抄送: mpls@ietf.org 主题: Re: [mpls] Solicit Opinions on Definition of MPLS Global Label I agree. In fact, it seems to me that any effort to do something along these lines would require a thorough analysis of how any such effort might be able to maintain backward compatibility. Sent from my iPad > On Nov 5, 2015, at 10:23 AM, Loa Andersson <loa@pi.nu> wrote: > > Working Group, > > We a long-standing usage (though not always well-documented) of > some of our labels > > global labels - that is a label that have the same meaning for any > mpls device, as long as it understand the device understands it, > where ever that device is found. > As far as I'm concerned there are only one set of such "global labels", > we have chosen to call those Special Purpose Labels. > > context specific labels - that are sets of labels that are know within > certain context, this context could be any number of things, e.g. a > domain. > > link local labels - labels that are know over a link between two LSRs, > whether the LSRs are adjacent or not. > > I don't think we want to move away from this long-standing usage. > > /Loa > >> On 2015-11-05 00:15, Alexander Vainshtein wrote: >> Hi all, >> >> I concur with Bruno: SR does not need global labels. >> >> And, as Nobo has explained >> <http://www.ietf.org/mail-archive/web/mpls/current/msg12640.html> more >> than 1 year ago, neither does SFC. >> >> Since you solicit opinions, mine is that /global labels are not needed >> anywhere / because, quoting from RFC 1925 >> <https://tools.ietf.org/html/rfc1925>, “/In protocol design, perfection >> has been reached not when there is nothing left to add, but when there >> is nothing left to take away/”. Since global labels can always be taken >> away, any design that uses them would be less than perfectL. >> >> My 2c, >> >> Sasha >> >> Office: +972-39266302 >> >> Cell: +972-549266302 >> >> Email: Alexander.Vainshtein@ecitele.com >> >> *From:*mpls [mailto:mpls-bounces@ietf.org] *On Behalf Of >> *bruno.decraene@orange.com >> *Sent:* Wednesday, November 04, 2015 8:27 AM >> *To:* Lizhenbin >> *Cc:* mpls@ietf.org >> *Subject:* Re: [mpls] Solicit Opinions on Definition of MPLS Global Label >> >> Hi Robin, >> >> Since I did not get the chance to express my comment during the meeting, >> I’ll do over email. >> >> <spring co-chair hat on> >> >> SPRING/SR: >> >> - is compliant with the MPLS architecture (RFC 3031) >> >> - in particular, in the control plane labels are >> locally allocated and in the forwarding plane, labels (of global >> segments) are SWAPed >> >> - does NOT need global/domain wide label >> >> - local segments uses local labels >> >> - global segments uses global index + local labels (aka >> SRGB) >> >> - is not requesting the MPLS WG to work on global/domain wide label. >> (i.e. the debate is closed from the SPRING standpoint.). Obviously, the >> MPLS WG is free to re-open the debate, but this is not a spring thing. >> >> </spring co-chair hat on> >> >> Based on this, some of your slides referring to “SR uses cases” seem a >> bit misleading. (I can’t be more specific since during the meeting, I >> could see the slides but could not comment, and now I can comment but >> can’t see the slides as they are not online). >> >> Thanks >> >> -- Bruno >> >> *From:*mpls [mailto:mpls-bounces@ietf.org] *On Behalf Of *Lizhenbin >> *Sent:* Wednesday, November 04, 2015 2:27 PM >> *To:* mpls@ietf.org <mailto:mpls@ietf.org> >> *Subject:* [mpls] Solicit Opinions on Definition of MPLS Global Label >> >> Hi MPLSers, >> >> As the development of MPLS technologies, many new label concepts beyond >> RFC3031 are proposed. And in segment routing MPLS label can be >> >> allocated and flooded in the network which means the meaning of the >> lablel can be understood by all nodes in the network. It is totally >> different from >> >> the label distribution behavior of LDP, RSVP-TE, and MP-BGP. From my >> point of view we need not argue if it is global label or global ID. In >> fact, the >> >> possible persons who read the drafts of protocol extensions for segment >> routing which incorporate the label allocation may be confused that MPLS >> WG as >> >> the base of MPLS work seems to have nothing with the work. But the >> challenge of definition of global label truly exists which has been >> proposed in the draft >> >> https://www.ietf.org/id/draft-li-mpls-global-label-usecases-03.txt. Hope >> you can refer to Section 4 of the draft. >> >> The debates on MPLS global label have lasted for a long time. The >> opinions can be classified as following: >> >> Opinion 1: Segment Routing has nothing with global label and please do >> not make it bother MPLS WG. But it seems a little hard to convince some >> MPLSers. >> >> Opinion 2: The usecase truly exists. But the concept of global label is >> too big. It is hard to allocate a label which is unique spanning >> multiple domains or >> >> as IP address which is unique all over world since it is not a scalable >> way or it is hard to achieve the goal. Then maybe it is a better way to >> narrow the >> >> scope to rename the global label as Domain-wide label, Network-wide >> label, etc. >> >> Opinion 3: The global label can be kept to cover more label concepts >> which label behaviors in the control plane and forward plane are >> different form the >> >> traditional LDP/RSVP-TE/MP-BGP. >> >> Since I could not get more time in my presentation to collect your >> opinions, if convenient please help feedback your opinion in your >> mailing list. Hope through >> >> the discussion we can make some consensus. >> >> Best Regards, >> >> Zhenbin(Robin) >> >> _________________________________________________________________________________________________________________________ >> >> 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 mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls
- [mpls] Solicit Opinions on Definition of MPLS Glo… Lizhenbin
- Re: [mpls] Solicit Opinions on Definition of MPLS… bruno.decraene
- Re: [mpls] Solicit Opinions on Definition of MPLS… Loa Andersson
- [mpls] 答复: Solicit Opinions on Definition of MPLS… Lizhenbin
- Re: [mpls] 答复: Solicit Opinions on Definition of … Loa Andersson
- Re: [mpls] Solicit Opinions on Definition of MPLS… Huub van Helvoort
- [mpls] 答复: Solicit Opinions on Definition of MPLS… Lizhenbin
- Re: [mpls] Solicit Opinions on Definition of MPLS… Alexander Vainshtein
- Re: [mpls] Solicit Opinions on Definition of MPLS… Jeffrey (Zhaohui) Zhang
- Re: [mpls] Solicit Opinions on Definition of MPLS… Jeffrey (Zhaohui) Zhang
- Re: [mpls] Solicit Opinions on Definition of MPLS… Jeffrey (Zhaohui) Zhang
- Re: [mpls] Solicit Opinions on Definition of MPLS… Loa Andersson
- Re: [mpls] Solicit Opinions on Definition of MPLS… David Allan I
- Re: [mpls] Solicit Opinions on Definition of MPLS… Loa Andersson
- Re: [mpls] Solicit Opinions on Definition of MPLS… Jeff Tantsura
- Re: [mpls] Solicit Opinions on Definition of MPLS… David Allan I
- Re: [mpls] Solicit Opinions on Definition of MPLS… Loa Andersson
- Re: [mpls] Solicit Opinions on Definition of MPLS… Eric Gray
- [mpls] 答复: Solicit Opinions on Definition of MPLS… Lizhenbin
- Re: [mpls] Solicit Opinions on Definition of MPLS… bruno.decraene
- Re: [mpls] Solicit Opinions on Definition of MPLS… Stewart Bryant