Hi Stewart, >The authors need to take onboard the findings of the SPRING designers.
I am not sure I've got the point. Are your still talking about the label allocation issue? Could you please explain it more specifically? >If the PE equipments are different the label ranges supported by h/w may be >disjoint. PEs can reserve some label ranges to be shared before they boot up. Then it becomes easy for an RG to figure out a common range. Thanks, Mingui >-----Original Message----- >From: Stewart Bryant [mailto:[email protected]] >Sent: Tuesday, November 19, 2013 2:41 AM >To: Jakob Heitz; Eric Osborne (eosborne) >Cc: UTTARO, JAMES; Mingui Zhang; [email protected] >Subject: Re: Why we consider the method of "label sharing for fast PE >protection" > >The authors need to take onboard the findings of the SPRING designers. > >If the PE equipments are different the label ranges supported by h/w may be >disjoint. > >Stewart > >On 18/11/2013 16:05, Jakob Heitz wrote: >> 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.htm >>>>>>> l >> . >> > > >-- >For corporate legal information go to: > >http://www.cisco.com/web/about/doing_business/legal/cri/index.html
