Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 068511B3168 for ; Wed, 4 Nov 2015 07:15:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kDuwvzBC5XXq for ; Wed, 4 Nov 2015 07:15:41 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0786.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::786]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 251391B3144 for ; Wed, 4 Nov 2015 07:15:40 -0800 (PST) Received: from DB3PR03MB0780.eurprd03.prod.outlook.com (10.161.55.12) by DB3PR03MB0779.eurprd03.prod.outlook.com (10.161.55.11) with Microsoft SMTP Server (TLS) id 15.1.318.15; Wed, 4 Nov 2015 15:15:21 +0000 Received: from DB3PR03MB0780.eurprd03.prod.outlook.com ([10.161.55.12]) by DB3PR03MB0780.eurprd03.prod.outlook.com ([10.161.55.12]) with mapi id 15.01.0318.003; Wed, 4 Nov 2015 15:15:21 +0000 From: Alexander Vainshtein To: "bruno.decraene@orange.com" , Lizhenbin , "Nobo Akiya (nobo) (nobo@cisco.com)" Thread-Topic: Solicit Opinions on Definition of MPLS Global Label Thread-Index: AdEWs37wCLrB6MbkTaujhtDJQWTFpwAEVISAABM6O5A= Date: Wed, 4 Nov 2015 15:15:21 +0000 Message-ID: References: <5A5B4DE12C0DAC44AF501CD9A2B01A8D8CA63EA4@nkgeml506-mbx.china.huawei.com> <6524_1446618416_5639A530_6524_1437_1_53C29892C857584299CBF5D05346208A0F69BE62@OPEXCLILM21.corporate.adroot.infra.ftgroup> In-Reply-To: <6524_1446618416_5639A530_6524_1437_1_53C29892C857584299CBF5D05346208A0F69BE62@OPEXCLILM21.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Alexander.Vainshtein@ecitele.com; x-originating-ip: [147.234.56.21] x-microsoft-exchange-diagnostics: 1; DB3PR03MB0779; 5:QGwaEHyWNyxgHK7SgcarWpGgjazQoQQ3XM6B0Y93CmGtWgYwnt6dL54OVMhPVMiPZ3qa1hbcwqW4GHyn69Yapq5FMyqQFmYDzJxSivoBa4D8PvQTJC9K1NagQoEIiFS/IRwCbBWrOl5uLYTUZ0AMdw==; 24:/9TAoJp3h3HDATf5RcnjE/ikwA649PNUgTeWO99fvSzfZvGai98/6XiGYYqbhnpo98K8O+6zCnSWHcPCp6qJCgp+ukzhwsRRnN4Di8Y0ifE=; 20:qKOROc6rwKY75I6pIWsN+fbi2jPSSLxu0HZzA+nI+M7dfLH8+pgypYZpGeZcEEH7fUZtnUKYx/ubgLAobpMeQA== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB3PR03MB0779; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(18271650672692)(279101305709854)(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(520078)(3002001)(10201501046); SRVR:DB3PR03MB0779; BCL:0; PCL:0; RULEID:; SRVR:DB3PR03MB0779; x-forefront-prvs: 0750463DC9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(37854004)(199003)(189002)(252514010)(377454003)(53754006)(2950100001)(76576001)(5003600100002)(5008740100001)(86362001)(19625215002)(2900100001)(101416001)(16236675004)(2501003)(5001770100001)(5890100001)(19580395003)(11100500001)(66066001)(81156007)(5007970100001)(19300405004)(5004730100002)(5002640100001)(40100003)(97736004)(54356999)(50986999)(76176999)(74316001)(5001960100002)(19617315012)(19580405001)(102836002)(122556002)(77096005)(19609705001)(105586002)(106356001)(92566002)(10400500002)(15975445007)(189998001)(33656002)(87936001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR03MB0779; H:DB3PR03MB0780.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ecitele.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB3PR03MB0780225100B2E64AF44E13C49D2A0DB3PR03MB0780eurp_" MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Nov 2015 15:15:21.1668 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR03MB0779 Archived-At: Cc: "mpls@ietf.org" Subject: Re: [mpls] Solicit Opinions on Definition of MPLS Global Label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2015 15:15:46 -0000 --_000_DB3PR03MB0780225100B2E64AF44E13C49D2A0DB3PR03MB0780eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I concur with Bruno: SR does not need global labels. And, as Nobo has explained more than 1 year ago, neither does SFC. Since you solicit opinions, mine is that global labels are not needed anywh= ere because, quoting from RFC 1925, "= In protocol design, perfection has been reached not when there is nothing l= eft to add, but when there is nothing left to take away". Since global labe= ls can always be taken away, any design that uses them would be less than p= erfect:(. 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@orang= e.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/SR: - is compliant with the MPLS architecture (RFC 3031) - in particular, in the control plane labels are locally al= located 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 SRG= B) - 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 i= s free to re-open the debate, but this is not a spring thing. 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 Subject: [mpls] Solicit Opinions on Definition of MPLS Global Label Hi MPLSers, As the development of MPLS technologies, many new label concepts beyond RFC= 3031 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 rou= ting 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 challeng= e 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 yo= u 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 doma= ins 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 t= he 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. Hop= e through the discussion we can make some consensus. Best Regards, Zhenbin(Robin) ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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. --_000_DB3PR03MB0780225100B2E64AF44E13C49D2A0DB3PR03MB0780eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,=

I concur with Bruno: SR d= oes not need global labels.

And, as Nobo has explained more than 1 year ago, neither does SFC.

 <= /p>

Since you solicit opinion= s, mine is that global labels are not needed anywhere  because, quoting from RFC 1925, “In protocol design, perfection has been reached not when there is nothi= ng left to add, but when there is nothing left to take away̶= 1;. Since global labels can always be taken away, any design that uses them would be less than perfectL.

 <= /p>

 <= /p>

From: mpls [mailto:mpls-bounces@iet= f.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 La= bel

 

Hi Robin,

 

Since I did not get the c= hance to express my comment during the meeting, I’ll do over email.

 

<spring co-chair hat o= n>

SPRING/SR:

- is compliant with the M= PLS architecture (RFC 3031)

    &= nbsp;           - in part= icular, in the control plane labels are locally allocated and in the forwar= ding plane, labels (of global segments) are SWAPed

- does NOT need global/do= main wide label

    &= nbsp;           - local s= egments uses local labels

    &= nbsp;           - global = segments uses global index + local labels (aka SRGB)

- is not requesting the M= PLS 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 yo= ur slides referring to “SR uses cases” seem a bit misleading. (= I can’t be more specific since during the meeting, I could see the sl= ides but could not comment, and now I can comment but can’t see the slide= s 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
Subject: [mpls] Solicit Opinions on Definition of MPLS Global Label<= /span>

 

Hi MPLSers,=

As the development of MPLS technolog= ies, many new label concepts beyond RFC3031 are proposed. And in segme= nt 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 th= e network. It is totally different from=

the label distribution behavior of L= DP, RSVP-TE, and MP-BGP. From my point of view we need not argue if it is g= lobal label or global ID. In fact, the

possible persons who read the drafts= of protocol extensions for segment routing which incorporate the label all= ocation 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 trul= y 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 hav= e lasted for a long time. The opinions can be classified as following:

Opinion 1: Segment Routing has nothi= ng 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 ov= er 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 k= ept 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&n= bsp;my presentation to collect your opinions, if convenient please hel= p feedback your opinion in your mailing list. Hope through

the discussion we can make some cons= ensus.

 =

 =

 =

Best Regards,

Zhenbin(Robin)

 = 

____________________________________________________=
_____________________________________________________________________<=
/o:p>
 
Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces j=
ointes. 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 confide=
ntial or privileged information that may be protected by law;
they should not be distributed, used or copied witho=
ut authorisation.
If you have received this email in error, please not=
ify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.

Thank you.
--_000_DB3PR03MB0780225100B2E64AF44E13C49D2A0DB3PR03MB0780eurp_--