Hi Robert, >it's reconfiguration across >entire domain to find common block across required set of devices is not >possible.
That's the misinterpretation. The proposal never requires a common block in the _entire_ domain. The common block is required only in the scope of an RG. Imagine the real use cases in IPRAN and MAN, most likely one POP will deploy only two PEs for each RG. Think about other redundant connection techniques, e.g., MC-LAG, two PEs in an RG are even from one vendor in most cases. Anyway, I think it's able to reserve a common block for just two PEs. >Ask operator to remove such PEs from the network ? Certainly not, the proposal is designed to be incrementally deployable in the network. The trick is confined in the RG. Other P and PE routers are unaware of the change. I think you didn't follow all the comments. Let me explain the most rigid incremental deployment scenario: a legacy PE and a label sharing PE form an RG. Since the proposal does not require data plane update on PE routers in the RG. Operators need only update the software of the legacy PE. Thanks, Mingui >-----Original Message----- >From: [email protected] [mailto:[email protected]] On Behalf Of Robert >Raszuk >Sent: Tuesday, November 19, 2013 7:31 PM >To: Mingui Zhang >Cc: [email protected]; Jakob Heitz; Eric Osborne (eosborne); UTTARO, JAMES; >[email protected] >Subject: Re: Why we consider the method of "label sharing for fast PE >protection" > >Hi Mingui, > >Imagine PE implementation that has no option to configure label ranges for LDP, >SR, PE protection, RSVP-TE or that even if it does it's reconfiguration across >entire domain to find common block across required set of devices is not >possible. That is what Stewart referred to as "SPRING lesson" and the solution >to play with block + index hack. > >What do you do then with your scheme ? > >Ask operator to remove such PEs from the network ? > >Best, >R. > > >On Tue, Nov 19, 2013 at 11:01 AM, Mingui Zhang <[email protected]> >wrote: >> 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.h >>>>>>>>> tm >>>>>>>>> l >>>> . >>>> >>> >>> >>>-- >>>For corporate legal information go to: >>> >>>http://www.cisco.com/web/about/doing_business/legal/cri/index.html >>
