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

[Lizhenbin <[e-mail]>]

Hi Bruno,

Thanks for your comments. I can agree your some statement with spring co-chair hat on. I would like to propose the definition of draft-ietf-isis-segment-routing-extensions-05:

1. "2.1.  Prefix Segment Identifier (Prefix-SID Sub-TLV)

         V-Flag: Value flag.  If set, then the Prefix-SID carries a
         value (instead of an index).  By default the flag is UNSET.
         L-Flag: Local Flag.  If set, then the value/index carried by
         the Prefix-SID has local significance.  By default the flag is
         UNSET.



      SID/Index/Label: according to the V and L flags, it contains
      either:
      *

         A 4 octet index defining the offset in the SID/Label space
         advertised by this router using the encodings defined in
         Section 3.1.  In this case the V and L flags MUST be unset.


         A 3 octet local label where the 20 rightmost bits are used for
         encoding the label value.  In this case the V and L flags MUST
         be set"



Regarding these definition, since the combination of V-Flag and L-Flag should have four types. But now it only defines two types. If V-Flag is SET and L-Flag is UNSET, what should be contained

in SID/Index/Label? If with co-author of the draft hat on, can you help explain? Or will you define definitely in the draft that this case MUST NOT happen?

In addition, I learn some implementation can directly use Prefix-SID Sub-TLV to advertise the domain-wide label value directly instead of using your proposed "global segments uses global index +

local labels (aka SRGB)". If this case happens, what should we say? Is it that the implementation is totally wrong or the implementation can also be accepted or it is an

special case that the domain-wide label happens to be the same as the "global segments uses global index + local labels (aka SRGB)"?



Best Regards,

Zhenbin(Robin)









________________________________
发件人: [e-mail] [[e-mail]]
发送时间: 2015年11月4日 14:26
收件人: Lizhenbin
抄送: [e-mail]; John G. Scudder
主题: RE: 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]
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.