Hi Eric, You scenario is truly complex which I think it can confuse the service providers if they likes to design such scenarios for their own. Regarding your mentioned scenario, it is not only for VPN, but also for the service providers to configure complex route policy to guarantee it. Even so, the label sharing is just a little additional label allocation for the route distribution controlled by the complex route policies. I just simply to point how to solve the scenario:
PE1: VRF-A primary, VRF-B backup -- Simulate a shared virtual IP address: IP(AB). Allocate a shared label: Label(AB) PE2: VRF-B primary, VRF-C backup -- Simulate a shared virtual IP address: IP(BC). Allocate a shared label: Label(BC) PE3: VRF-C primary, VRF-A backup -- Simulate a shared virtual IP address: IP(CA). Allocate a shared label: Label(CA) Then since the route policy will control what routes in VPN use VRFA/B/C as primary or backup, then they will use different virtual IP address and shared label to advertise the route by BGP. Then it can work. Thanks, Robin -----邮件原件----- 发件人: [email protected] [mailto:[email protected]] 代表 Eric Osborne (eosborne) 发送时间: 2013年11月19日 0:00 收件人: Jakob Heitz; UTTARO, JAMES 抄送: [email protected]; Stewart Bryant (stbryant) 主题: RE: Why we consider the method of "label sharing for fast PE protection" Oh, yeah. I'm not actually proposing that there's a workable solution. I'm trying to point out that there isn't one. The problem gets harder, too. PE1: VRF-A primary, VRF-B backup PE2: VRF-B primary, VRF-C backup PE3: VRF-C primary, VRF-A backup and so forth. eric > -----Original Message----- > From: Jakob Heitz [mailto:[email protected]] > Sent: Monday, November 18, 2013 10:57 AM > To: UTTARO, JAMES > Cc: Eric Osborne (eosborne); Mingui Zhang; Stewart Bryant (stbryant); > [email protected] > Subject: 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" <[email protected]> wrote: > > > That sounds doable ;) > > > > -----Original Message----- > > From: [email protected] [mailto:[email protected]] On > > Behalf > Of Eric Osborne (eosborne) > > Sent: Monday, November 18, 2013 7:52 AM > > To: Mingui Zhang; Stewart Bryant (stbryant); Jakob Heitz; > [email protected] > > 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: [email protected] [mailto:[email protected]] On > Behalf > >> Of Mingui Zhang > >> Sent: Monday, November 18, 2013 4:34 AM > >> To: Stewart Bryant (stbryant); Jakob Heitz; [email protected] > >> 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:[email protected]] > >>> Sent: Thursday, November 14, 2013 9:52 PM > >>> To: Jakob Heitz; Mingui Zhang; [email protected] > >>> 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: [email protected] [[email protected]] on behalf > of > >>> Mingui Zhang [[email protected]] > >>> Sent: Thursday, 07 November 2013 11:40 AM > >>> To: [email protected] > >>> 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 > >
