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
