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
Date: Thu, 5 Nov 2015 01:30:45 +0000
Message-ID: <E6C17D2345AC7A45B7D054D407AA205C4AFD0EA2@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>
In-Reply-To: <563AAF89.8010007@pi.nu>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/2xOmaIVBLUzfjABQsdCcfa-kNw4>
Cc: "mpls@ietf.org" <mpls@ietf.org>
Subject: Re: [mpls] Solicit Opinions on Definition of MPLS Global Label
Precedence: list

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 scop=
e 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 dev=
ice, as long as it understand the device understands it, where ever that de=
vice 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 cert=
ain 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, whet=
her 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=20
> than 1 year ago, neither does SFC.
>
> Since you solicit opinions, mine is that /global labels are not needed=20
> anywhere / because, quoting from RFC 1925=20
> <https://tools.ietf.org/html/rfc1925>, "/In protocol design,=20
> perfection has been reached not when there is nothing left to add, but=20
> when there is nothing left to take away/". Since global labels can=20
> always be taken away, any design that uses them would be less than perfec=
tL.
>
> My 2c,
>
> Sasha
>
> Office: +972-39266302
>
> Cell:      +972-549266302
>
> Email:   Alexander.Vainshtein@ecitele.com
>
> *From:*mpls [mailto:mpls-bounces@ietf.org] *On Behalf Of=20
> *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=20
> Label
>
> Hi Robin,
>
> Since I did not get the chance to express my comment during the=20
> 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=20
> 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=20
> (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,=20
> 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=20
> bit misleading. (I can't be more specific since during the meeting, I=20
> could see the slides but could not comment, and now I can comment but=20
> 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=20
> beyond
> RFC3031 are proposed. And in segment routing MPLS label can be
>
> allocated and flooded in the network which means the meaning of the=20
> lablel can be understood by all nodes in the network. It is totally=20
> different from
>
> the label distribution behavior of LDP, RSVP-TE, and MP-BGP. From my=20
> point of view we need not argue if it is global label or global ID. In=20
> fact, the
>
> possible persons who read the drafts of protocol extensions for=20
> segment routing which incorporate the label allocation may be confused=20
> that MPLS WG as
>
> the base of MPLS work seems to have nothing with the work. But the=20
> challenge of definition of global label truly exists which has been=20
> proposed in the draft
>
> https://www.ietf.org/id/draft-li-mpls-global-label-usecases-03.txt.=20
> Hope you can refer to Section 4 of the draft.
>
> The debates on MPLS global label have lasted for a long time. The=20
> opinions can be classified as following:
>
> Opinion 1: Segment Routing has nothing with global label and please do=20
> not make it bother MPLS WG. But it seems a little hard to convince=20
> some MPLSers.
>
> Opinion 2: The usecase truly exists. But the concept of global label=20
> is too big. It is hard to allocate a label which is unique spanning=20
> multiple domains or
>
> as IP address which is unique all over world since it is not a=20
> scalable way or it is hard to achieve the goal. Then maybe it is a=20
> better way to narrow the
>
> scope to rename the global label as Domain-wide label, Network-wide=20
> label, etc.
>
> Opinion 3: The global label can be kept to cover more label concepts=20
> which label behaviors in the control plane and forward plane are=20
> different form the
>
> traditional LDP/RSVP-TE/MP-BGP.
>
> Since I could not get more time in my presentation to collect your=20
> opinions, if convenient please help feedback your opinion in your=20
> 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=20
> confidentielles ou privilegiees et ne doivent donc
>
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez=20
> recu ce message par erreur, veuillez le signaler
>
> a l'expediteur et le detruire ainsi que les pieces jointes. Les=20
> messages electroniques etant susceptibles d'alteration,
>
> Orange decline toute responsabilite si ce message a ete altere,=20
> deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or=20
> 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=20
> delete this message and its attachments.
>
> As emails may be altered, Orange is not liable for messages that have=20
> 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