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
