答复: Why we consider the method of "label sharing for fast PE protection"

Lizhenbin <lizhenbin@huawei.com> Thu, 21 November 2013 02:57 UTC

Return-Path: <lizhenbin@huawei.com>
X-Original-To: l3vpn@ietfa.amsl.com
Delivered-To: l3vpn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E8E31AE028 for <l3vpn@ietfa.amsl.com>; Wed, 20 Nov 2013 18:57:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.563
X-Spam-Level: *
X-Spam-Status: No, score=1.563 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.525, 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 nXSOWLjUzDga for <l3vpn@ietfa.amsl.com>; Wed, 20 Nov 2013 18:57:38 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id C1A551AE01F for <l3vpn@ietf.org>; Wed, 20 Nov 2013 18:57:37 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AYD69474; Thu, 21 Nov 2013 02:57:29 +0000 (GMT)
Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 21 Nov 2013 02:57:14 +0000
Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 21 Nov 2013 02:57:25 +0000
Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.72]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Thu, 21 Nov 2013 10:57:20 +0800
From: Lizhenbin <lizhenbin@huawei.com>
To: Jakob Heitz <jakob.heitz@ericsson.com>, "UTTARO, JAMES" <ju1738@att.com>
Subject: 答复: Why we consider the method of "label sharing for fast PE protection"
Thread-Topic: Why we consider the method of "label sharing for fast PE protection"
Thread-Index: AQHO3ANwfo46SQrvy0meF2QzgZz4npokQx8AgAYBf4CAADdSgIAAED0AgAAjbICABFqrUA==
Date: Thu, 21 Nov 2013 02:57:20 +0000
Message-ID: <5A5B4DE12C0DAC44AF501CD9A2B01A8D081E0352@nkgeml506-mbx.china.huawei.com>
References: <4552F0907735844E9204A62BBDD325E733660DBA@nkgeml508-mbx.china.huawei.com> <2F3EBB88EC3A454AAB08915FBF0B8C7E02EB9CCC@eusaamb109.ericsson.se> <5284D566.8000704@cisco.com> <4552F0907735844E9204A62BBDD325E73367FF48@nkgeml508-mbx.china.huawei.com> <20ECF67871905846A80F77F8F4A2757210468E9C@xmb-rcd-x09.cisco.com>, <B17A6910EEDD1F45980687268941550F0630332E@MISOUT7MSGUSR9I.ITServices.sbc.com> <B8E18D92-CA8D-40A7-B334-08AADC56A8D2@ericsson.com>
In-Reply-To: <B8E18D92-CA8D-40A7-B334-08AADC56A8D2@ericsson.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.76.77]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "l3vpn@ietf.org" <l3vpn@ietf.org>, "Stewart Bryant (stbryant)" <stbryant@cisco.com>
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <l3vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l3vpn/>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Nov 2013 02:57:40 -0000

Hi Jakob & Eric,
Regarding your questions, I explain more as follows:
A. Regarding the boot up scenario, maybe we have to discuss by distinguishing different label allocation methods:
1. Statically configure label range and the allocated label for VPN: This is the simplest method. For this method, the algorithm is static configuration. The same label can be guaranteed even if two routers using the same algorithm boot up at different times and/or with different neighbors. 
2. Statically configure label range and ICCP-based label allocation for VPN: The same label range can be guaranteed when routers boot up since it is configured statically. For the same label allocation for VPN when routers boot up, the existing similar process like graceful start or NSR(Non-Stop Routing) can be reused.
3.Global label allocation by the central controller: As I mentioned at the MIKE, draft-li-mpls-global-label-usecases-00 and draft-li-mpls-global-label-framework-00 discuss the use cases and label allocation method for the label sharing method. It can simplify the same label allocation. I think the topic is also in the initial phase in IETF to be discussed. And also YES, the GR or NSR process should be taken into account when routers boot up.

B. Regarding the normal same label allocation mentioned by Eric's "So you either end up statically allocating labels or making sure you have the same label allocation algorithm on every pair of primary/backup PEs.":
It is not like this way. For the ICCP-based label allocation method, the primary PE is allocate the label for VPN by its own label allocation algorithm. The backup PE is just to allocate the label specified by the primary PE. The process is just like label backup. They need not use the same label allocation algorithm.


Thanks
Robin



-----邮件原件-----
发件人: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] 代表 Jakob Heitz
发送时间: 2013年11月18日 23:57
收件人: UTTARO, JAMES
抄送: l3vpn@ietf.org; Stewart Bryant (stbryant)
主题: Re: Why we consider the method of "label sharing for fast PE protection"

"same algorithm" is not good enough on its own. If two routers using the same algorithm boot up at different times and/or with different neighbors, they still won't allocate the same labels.

The algorithm cannot just be "same". It must be restricted in other ways.

--
Jakob Heitz.


On Nov 18, 2013, at 5:51 AM, "UTTARO, JAMES" <ju1738@att.com> wrote:

> That sounds doable ;)
> 
> -----Original Message-----
> From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf 
> Of Eric Osborne (eosborne)
> Sent: Monday, November 18, 2013 7:52 AM
> To: Mingui Zhang; Stewart Bryant (stbryant); Jakob Heitz; 
> l3vpn@ietf.org
> Subject: RE: Why we consider the method of "label sharing for fast PE protection"
> 
> It's not just the range, right?  You have to allocate the same label per VRF.  So you either end up statically allocating labels or making sure you have the same label allocation algorithm on every pair of primary/backup PEs.
> 
> 
> 
> 
> 
> eric
> 
>> -----Original Message-----
>> From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On 
>> Behalf Of Mingui Zhang
>> Sent: Monday, November 18, 2013 4:34 AM
>> To: Stewart Bryant (stbryant); Jakob Heitz; l3vpn@ietf.org
>> Subject: RE: Why we consider the method of "label sharing for fast PE 
>> protection"
>> 
>> Hi Stewart,
>> 
>> Operators can configure the PEs in an RG to reserve the same label 
>> range for sharing.
>> 
>> With the ICCP connection established between the primary and backup 
>> PE, the primary PE can mandate the sharing label range out of the 
>> intersection of the unused label space.
>> 
>> Thanks,
>> Mingui
>> 
>>> -----Original Message-----
>>> From: Stewart Bryant [mailto:stbryant@cisco.com]
>>> Sent: Thursday, November 14, 2013 9:52 PM
>>> To: Jakob Heitz; Mingui Zhang; l3vpn@ietf.org
>>> Subject: Re: Why we consider the method of "label sharing for fast 
>>> PE protection"
>>> 
>>> Isn't the normal problem that the two systems will be independently
>> allocating
>>> labels from their default label table, possibly with different 
>>> hardware
>> base and
>>> range, so there may not be a common label available that can be
>> allocated by
>>> both.
>>> 
>>> - Stewart
>>> 
>>> On 07/11/2013 21:50, Jakob Heitz wrote:
>>> 
>>> 
>>>    Several people at the mike asked this question:
>>>    How do you make sure that the PEs allocate the same label?
>>> 
>>>    This needs to be part of the document, because it is quite
>> important.
>>>    If an external entity allocates the labels, the protocol
>>>    between the PEs and that entity needs to be standardized.
>>>    Since this is a feature that provides redundancy, the
>>>    label allocating entity also needs to be backed up by a
>>>    redundant entity. The protocol between the redundant
>>>    label allocators needs to be standardized.
>>> 
>>> 
>>> 
>>>    --
>>> 
>>>    Jakob Heitz.
>>> 
>>> ________________________________
>>> 
>>>    From: l3vpn-bounces@ietf.org [l3vpn-bounces@ietf.org] on behalf 
>>> of Mingui Zhang [zhangmingui@huawei.com]
>>>    Sent: Thursday, 07 November 2013 11:40 AM
>>>    To: l3vpn@ietf.org
>>>    Subject: Why we consider the method of "label sharing for fast PE 
>>> protection"
>>> 
>>> 
>>> 
>>>    Hi,
>>> 
>>>    As a choice of fast PE protection,
>>> 
>>>    1. This solution is simple and light-weight. We need not 
>>> introduce
>> the
>>> complex context label table in PE routers. So label table need not 
>>> be
>> stored
>>> repeatedly on RG members.
>>> 
>>> 
>>>    2. Also, it's easy to be deployed. It does not bring any change 
>>> to
>> P routers
>>> (control plane & data plane). It even does not change the data plane 
>>> of
>> PE
>>> routers.
>>> 
>>> 
>>>    3. In addition, it does not bear the restriction of "no 
>>> penultimate-hop-popping".
>>> 
>>> 
>>> 
>>>    Thanks,
>>>    Mingui
>>> 
>>> 
>>> 
>>> 
>>> --
>>> For corporate legal information go to:
>>> 
>>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html
>