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