True .. But one can't escape from "careful configuration" .. imagine if you would assign wrong IP addresses to interfaces :) So allocating VPN X for given VRF in the config is at the end not that hard. After all in any decent size configuration of any router and it's deltas are all automated and scripted.
I think to conclude if MPLS folks will keep protecting the original MPLS assumptions we will see more and more transition to VXLAN or NVGRE where application demux is no longer required to be of the magic 4 letters 20 bits ..... Would that simplify existing products ? Best, r. On Tue, Nov 26, 2013 at 5:56 PM, Jakob Heitz <[email protected]> wrote: > To my understanding, one reason for the private allocation invariant of MPLS > is that all the participating entities can boot up and down in any order or > not at all and the system "just works" without any careful configuration. > > -- > Jakob Heitz. > > > On Nov 26, 2013, at 8:32 AM, "Robert Raszuk" <[email protected]> wrote: > >> Hi Eric, >> >>> Otherwise, existing implementations would be continually at risk of being >>> required >>> to support arbitrary and increasingly complex "novel" semantic >>> interpretations of >>> the labels they allocate. >> >> I am actually not sure what you mean by "existing implementations" In >> none of the proposals there is any change suggested to "existing >> implementations" both control or data plane as far as processing the >> labels. >> >> Where I am getting to is that we do see growing need for opening APIs >> for label allocations. I2RS is a good protocol example which can >> support it. That's it. Today depending on applications labels are >> allocated from a local pool via local function call. >> >> The same function call could be remote to SDN controller or PCE and I >> do see some benefits. In fact such allocation mode could be push/pull. >> >> This does break original local label significance of MPLS what Stuart >> based his point on - and that was what I reacted to as something I do >> not agree with in principle. >> >> Best, >> R. >> >> >> On Tue, Nov 26, 2013 at 5:02 PM, Eric Gray <[email protected]> wrote: >>> Possibly, I have misunderstood. :-) >>> >>> Stewart made the point that allocation of labels is the business of the >>> device that >>> needs to interpret them. >>> >>> I agree with this. >>> >>> You seemed to argue that this is not necessary, saying that you: >>> >>> "do not find the principle of MPLS label to be of only local significance >>> to the >>> node which allocated it to be sufficient reason to limit one's >>> innovation of >>> using mpls label [SIC] in new and novel ways." >>> >>> The way that I understand this statement is that you feel that it is okay >>> to make >>> most currently deployed MPLS implementations (which currently operate based >>> on >>> the "principle" that they are mostly free to allocate labels on whatever >>> basis they >>> later will use to interpret them) change this fundamental operating >>> principle to suit >>> arbitrary "novel" approaches. >>> >>> My further understanding - based on this - is that you feel that >>> complicating existing >>> and deployed implementations in favor of some arbitrary set of "novel" >>> approaches >>> is okay. >>> >>> Since it is not impossible to support arbitrarily many uses with currently >>> deployed >>> implementations, it seems likely that the reason to suggest different >>> approaches >>> is to simplify some proposed "novel" approach (or set of approaches). >>> >>> This is certainly not a new idea. This gets proposed by someone every few >>> months. >>> >>> So, the ongoing issue with these proposals is simply this: without a very >>> compelling >>> reason to do so - specific to any proposal in question - changing the >>> paradigm used >>> in allocating labels to suit that proposal should not be given serious >>> consideration. >>> Otherwise, existing implementations would be continually at risk of being >>> required >>> to support arbitrary and increasingly complex "novel" semantic >>> interpretations of >>> the labels they allocate. >>> >>> In my understanding, the yardstick against which to measure the degree to >>> which >>> any "novel" proposal is compelling is to consider it in comparison to >>> similar proposals >>> made in the past, against the degree to which the proposed approach is >>> actually >>> needed, against the finite resources that will be consumed (such as >>> demultiplexing >>> code points - e.g. - Ethertypes, etc.) and the complexity required to >>> support it in an >>> existing implementation. >>> >>> To date, the only proposal (I am immediately aware of) that has measured >>> up using >>> this yardstick is the need to provide for upstream allocation to support >>> P2MP LSPs. >>> >>> If the above understanding is incorrect, please feel free to tell me in >>> what way I have >>> misunderstood you. >>> >>> -- >>> Eric >>> >>> PS - I addressed my previous mail to "R" as that was how you signed the >>> mail to >>> which I was responding. If you wish to address replies to "E", that is >>> fine with me, >>> but it is not how I have indicated that I wish to be addressed. >>> >>> -----Original Message----- >>> From: [email protected] [mailto:[email protected]] On Behalf Of Robert >>> Raszuk >>> Sent: Tuesday, November 26, 2013 10:20 AM >>> To: Eric Gray >>> Cc: [email protected]; UTTARO, JAMES; [email protected] >>> Subject: Re: Why we consider the method of "label sharing for fast PE >>> protection" >>> Importance: High >>> >>> E, >>> >>> I think you have misunderstood. >>> >>> What do you refer as "deployed implementations" as more complex in the >>> light of using notion of global label in segment routing ? >>> >>> That was my point regarding innovation in local vs global label >>> allocation paradigm. >>> >>> r. >>> >>> On Tue, Nov 26, 2013 at 4:17 PM, Eric Gray <[email protected]> wrote: >>>> R, >>>> >>>> I agree with Stewart and find nothing particularly appealing about >>>> any form >>>> of "innovation" that makes a proposed approach simpler at a cost of making >>>> deployed >>>> implementations more complex. >>>> >>>> -- >>>> Eric >>>> >>>> -----Original Message----- >>>> From: L3VPN [mailto:[email protected]] On Behalf Of Robert Raszuk >>>> Sent: Tuesday, November 26, 2013 10:12 AM >>>> To: [email protected] >>>> Cc: UTTARO, JAMES; [email protected] >>>> Subject: Re: Why we consider the method of "label sharing for fast PE >>>> protection" >>>> >>>> Hi Stewart, >>>> >>>>> It is an MPLS invariant that: the label range supported >>>>> is a private matter, and you seem to wish to break >>>>> that invariant. That is a bad idea. >>>> >>>> Well let's be fair ... there is nothing wrong with using global/domain >>>> wide labels. As you know segment routing mpls forwarding is based on >>>> that too. >>>> >>>> I think using same application label for reasons stated before is not >>>> trivial, if so we should ask for given VPN_ID a PCE/SDN like device to >>>> return same label for N PEs attached to such VPN. Maybe for the >>>> disjoined label ranges it would not be supported. >>>> >>>> Moreover the granularity could be more then per vrf. >>>> >>>> Practically we already have solution for this problem using context >>>> labels and personally I do not find sufficient need for another >>>> solution for the exact same problem. >>>> >>>> But I - as someone involved with MPLS for a long time - do not find >>>> the principle of MPLS label to be of only local significance to the >>>> node which allocated it to be sufficient reason to limit one's >>>> innovation of using mpls label in new and novel ways. >>>> >>>> Best regards, >>>> R. >>>> >>>> On Tue, Nov 26, 2013 at 1:31 PM, Stewart Bryant <[email protected]> wrote: >>>>> On 25/11/2013 07:41, Mingui Zhang wrote: >>>>>> >>>>>> Hi Stewart, >>>>>> >>>>>>>> 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. >>>>>>> >>>>>>> Only if the equipment type is the same. h/w varies >>>>>>> as to label base and range. >>>>>> >>>>>> At least we know that the proposal is feasible for PEs with the same h/w. >>>>>> >>>>>> For PEs with different h/w, it's still possible that they can find out a >>>>>> common block. >>>>>> >>>>>> If they cannot find a common block, the connection between them will end >>>>>> up with failure, then they have to fall back to the non-redundant mode. >>>>>> >>>>> The success of the IETF protocol suite sits on a policy of >>>>> establishing protocol invariants and designing our >>>>> protocols withing the constraints of those invariants. >>>>> >>>>> It is an MPLS invariant that: the label range supported >>>>> is a private matter, and you seem to wish to break >>>>> that invariant. That is a bad idea. >>>>> >>>>> Sure you can make this work if the h/w is compatible >>>>> in an unspecified (in MPLS) way, but that mortgages >>>>> the future of the network that this will be deployed >>>>> in, and I do not think that is something the IETF >>>>> should support. >>>>> >>>>> - Stewart
