Hi, Completely agree with Robert, add to this - operation folks use label ranges for troubleshooting, i.e. They (their tools) know what label range to look for is there is a particular issue with LDP or RSVP, etc so changing the range is not so trivial
Cheers, Jeff -----Original Message----- From: "[email protected]" <[email protected]> Date: Tuesday, November 19, 2013 3:30 AM To: Mingui Zhang <[email protected]> Cc: "[email protected]" <[email protected]>, "UTTARO, JAMES" <[email protected]>, "[email protected]" <[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.htm >>>>>>>>> l >>>> . >>>> >>> >>> >>>-- >>>For corporate legal information go to: >>> >>>http://www.cisco.com/web/about/doing_business/legal/cri/index.html >>
