Hi, In a real network, one PE cannot be freely interconnected with any PE in any geographic position to form an RG. In most cases, one PE is connected to the left and right PEs to form the RG. The example you propose is complex enough. For your example, let RG1 = (PE1, PE2), RG2=(PE2, PE3), RG3=(PE1, PE3). Then each label is shared for each VPN in the scope of each RG.
Firstly, statically allocating can always serve as a choice. The second way is to let both PEs in an RG to have the "same algorithm". Operators reserve a label range for each RG and use a _hashing_ algorithm to allocate each label for each VPN in each RG. This hashing algorithm can be designed independent of the router boot time. Each PE sort the VPNs and then assign labels one by one according to the hashing algorithm. Let me introduce the third way: the "synchronization" method. In each RG, one master PE will be elected according to their priorities. The master PE mandates the range and also assign the VPN route label for each VPN in this RG. The backup PE acks the assignment. They can also do periodic synchronization of their label assignment to cope with exceptions. Thanks, Mingui >-----Original Message----- >From: Jakob Heitz [mailto:[email protected]] >Sent: Tuesday, November 19, 2013 12:06 AM >To: Eric Osborne (eosborne) >Cc: UTTARO, JAMES; Mingui Zhang; Stewart Bryant (stbryant); [email protected] >Subject: Re: Why we consider the method of "label sharing for fast PE >protection" > >We are on the same page. >I misinterpreted your :) > >I guess it could be done at small scale with certain restrictions. >It's definitely not a generic solution. > >-- >Jakob Heitz. > > >On Nov 18, 2013, at 7:59 AM, "Eric Osborne (eosborne)" <[email protected]> >wrote: > >> 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 >>>>
