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

Yes, exactly!

Besides Special Purpose Labels (7274) and locally assigned per-platform labels the rest are subtypes of context labels (5331) i.e. a label can only be looked up in context of some additional information

Cheers,
Jeff

On 11/5/15, 10:30, "mpls on behalf of David Allan I" <mpls-bounces@ietf.org on behalf of david.i.allan@ericsson.com> 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
>
>_______________________________________________
>mpls mailing list
>mpls@ietf.org
>https://www.ietf.org/mailman/listinfo/mpls