Hi Eric, Indeed we are getting into as multi-dimentional thread :)
Stewart comment was to protect local significance of a label. Label X allocated by node N must be only used by node N. That is something I commented on. You on the other hand are more worried about allocation algorithm chosen by given implementation. I think both are quire orthogonal aspects. I can see that without breaking any of your model I could still use label X to be meaningful on more then single node. Simply I allocate a block of L labels (even in the table model by null prepopulation of the table) and give to higher application to use such block. That is all fine and I do not think we are in any discussion breaking that. Regards, R. On Tue, Nov 26, 2013 at 6:24 PM, Eric Gray <[email protected]> wrote: > > Hmmm. Maybe we're arguing semantics in more than one way. > > The simplest (i.e. - proof of concept) approach to label allocation is that > an LSR > plugs label interpretation information into a row in a table, and gives the > row > number as the label. This doesn't necessarily have to happen in this order, > but > an LSR cannot properly interpret a label allocated in this way until it has > created > the row - hence it will not normally allocate and distribute the label until > it has > completed the corresponding row-entry. > > Architecturally, this "table" corresponds to (at least) the ILM (RFC 3031). > In a > very simple implementation, this row may combine both ILM and NHLFE. > > A very simple implementation (consistent with the model referenced above) > may only support a smaller subset of the possible 1M rows in its table, hence > asking this implementation to provide a specific label that may fall outside > of a > limited range will not work. In addition, asking this LSR to allocate any > specific > label - even from within the supported range - either risks a collision with > that > label (if already allocated for some other purpose) or a sparse population of > table rows and a need to track which labels have already been given, and will > result in complicating the allocation process by fragmenting row population. > > One reason to "protect" this reference implementation approach is that it can > (quite quickly) become difficult to justify use of MPLS at all if > implementations > using this (or a similar) approach are not allowed (or become significantly > less > than optimal) because of subsequent proposals. > > If I end up having to do a CAM lookup to find the row corresponding to a > label, > it is not clear at all why I don't just do a CAM lookup for key fields in the > IP > header. > > If you're talking about making the (commonly used) internal allocation > function > available to a higher-layer entity, that doesn't break this paradigm at all. > But I > would not get that from your earlier mail, nor would I be able to determine - > based on this - how this is inconsistent with Stewart's comment. > > -- > Eric > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of Robert Raszuk > Sent: Tuesday, November 26, 2013 11:32 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 > > 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
