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

[Loa Andersson <[e-mail]>]

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:[e-mail]] On Behalf Of Loa Andersson
> Sent: Thursday, November 05, 2015 10:23 AM
> To: Alexander Vainshtein; [e-mail]; Lizhenbin; Nobo Akiya (nobo) ([e-mail])
> Cc: [e-mail]
> 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: [phone]
>>
>> Cell:      [phone]
>>
>> Email:   [e-mail]
>>
>> *From:*mpls [mailto:[e-mail]] *On Behalf Of
>> *[e-mail]
>> *Sent:* Wednesday, November 04, 2015 8:27 AM
>> *To:* Lizhenbin
>> *Cc:* [e-mail]
>> *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:[e-mail]] *On Behalf Of *Lizhenbin
>> *Sent:* Wednesday, November 04, 2015 2:27 PM
>> *To:* [e-mail] <mailto:[e-mail]>
>> *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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mpls
>>
>
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls
>