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
