Re: [mpls] Solicit Opinions on Definition of MPLS Global Label

David Allan I <david.i.allan@ericsson.com> Thu, 05 November 2015 01:53 UTC

Return-Path: <david.i.allan@ericsson.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 E6E451B3669 for <mpls@ietfa.amsl.com>; Wed, 4 Nov 2015 17:53:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 UgloIUZks2IQ for <mpls@ietfa.amsl.com>; Wed, 4 Nov 2015 17:53:49 -0800 (PST)
Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5209D1A883F for <mpls@ietf.org>; Wed, 4 Nov 2015 17:53:49 -0800 (PST)
X-AuditID: c6180641-f792c6d00000686a-36-563a4935ed19
Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 86.3F.26730.5394A365; Wed, 4 Nov 2015 19:06:45 +0100 (CET)
Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.03.0248.002; Wed, 4 Nov 2015 20:53:48 -0500
From: David Allan I <david.i.allan@ericsson.com>
To: Loa Andersson <loa@pi.nu>, Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>, "bruno.decraene@orange.com" <bruno.decraene@orange.com>, Lizhenbin <lizhenbin@huawei.com>, "Nobo Akiya (nobo) (nobo@cisco.com)" <nobo@cisco.com>
Thread-Topic: [mpls] Solicit Opinions on Definition of MPLS Global Label
Thread-Index: AdEWs37wCLrB6MbkTaujhtDJQWTFpwAEVISAABM6O5AAIC9sgAAKUwaA//+y8QCAAFHB0A==
Date: Thu, 05 Nov 2015 01:53:47 +0000
Message-ID: <E6C17D2345AC7A45B7D054D407AA205C4AFD10ED@eusaamb105.ericsson.se>
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> <E6C17D2345AC7A45B7D054D407AA205C4AFD0EA2@eusaamb105.ericsson.se> <563AB42E.9000604@pi.nu>
In-Reply-To: <563AB42E.9000604@pi.nu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [147.117.188.11]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrIIsWRmVeSWpSXmKPExsUyuXRPgq6pp1WYwYVZ1hZTt35gtvixYw6z xe7GP+wW/+YCWbeWrmS1mN0R78DmMeX3RlaPTf+OM3q0HHnL6rFkyU8mj5ZnJ9k8Zk1vYwtg i+KySUnNySxLLdK3S+DK+Nt9jK2gyb3i2KbTTA2Mryy6GDk4JARMJNY1KXcxcgKZYhIX7q1n A7GFBI4wSvy9rdDFyAVkL2OUOHllBxNIgk3AQGLP/y+MIAkRgXeMEh8+rWQDGcQsoCxx6q4M SI2wgLvEuh1zWUBsEQEPiTmf/kPZYRK32g8zg9gsAioSG3+1s4LYvAK+EtsePmaDWDafWeJN 40RGkJmcAqoS/9c7gNQwAh33/dQasBuYBcQlbj2ZzwRxtIDEkj3nmSFsUYmXj/+xQthKEh9/ z2eHqNeRWLD7ExuErS2xbOFrZoi9ghInZz5hmcAoNgvJ2FlIWmYhaZmFpGUBI8sqRo7S4tSy 3HQjw02MwIg7JsHmuINxwSfLQ4wCHIxKPLwFslZhQqyJZcWVuYcYJTiYlUR4C2YChXhTEiur Uovy44tKc1KLDzFKc7AoifPOm3E/VEggPbEkNTs1tSC1CCbLxMEp1cAYV/Av16l12o8td8zL vVgvzt2nsXXOlsITt/VFYx4y5l7+PofP1Cvgl8/Z3/+N2dra9hzIvr1/3onadTxlFm+8vM9G 8MyxuvUjUldjZZdCuYIua/qDCy592l073ues1RZxtjkqfLDf/FGXUIX1Eu5l7xV9WfQubNSe taxx47KCF1MTzrmqzOJSYinOSDTUYi4qTgQAQYkc77QCAAA=
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/TNAdmZo0ulh4QMvPG93k-HNgXVY>
Cc: "mpls@ietf.org" <mpls@ietf.org>
Subject: Re: [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 01:53:52 -0000

HI Loa

I could generalize the principle embodied in the description to say "the label must be unique across the scope of the administering entity". Hence whether it is per interface, per platform, per implementation (reserved) or per domain simply falls out of this.

Only issue then is agreeing on how to disseminate information on what labels belong to which administering entity.... we have it sorted out for per interface, per platform and per implementation....

Cheers
D

-----Original Message-----
From: Loa Andersson [mailto:loa@pi.nu] 
Sent: Thursday, November 05, 2015 10:43 AM
To: David Allan I; Alexander Vainshtein; bruno.decraene@orange.com; Lizhenbin; Nobo Akiya (nobo) (nobo@cisco.com)
Cc: mpls@ietf.org
Subject: Re: [mpls] Solicit Opinions on Definition of MPLS Global Label

Dave,

There are a couple of usages of "label space", the RFC 3031 says:

    When these conditions hold, an LSR may use labels that have "per
    interface" scope, i.e., which are only unique per interface.  We may
    say that the LSR is using a "per-interface label space".  When these
    conditions do not hold, the labels must be unique over the LSR which
    has assigned them, and we may say that the LSR is using a "per-
    platform label space."

But as far as I understand that is not the "label space" we are discussing here.

/Loa

On 2015-11-05 10:30, David Allan I wrote:
> Aren't you really discussing label spaces....
>
> You have well known labels (reserved, or administered by the "designers"), and the other label spaces have properties based upon a combination of scope and "who" administers them...
>
> Cheers
> Dave
>
>
>
> -----Original Message-----
> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson
> Sent: Thursday, November 05, 2015 10:23 AM
> To: Alexander Vainshtein; bruno.decraene@orange.com; Lizhenbin; Nobo 
> Akiya (nobo) (nobo@cisco.com)
> Cc: mpls@ietf.org
> Subject: Re: [mpls] Solicit Opinions on Definition of MPLS Global 
> Label
>
> 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
>