Subject: RE: L3VPN Digest, Vol 113, Issue 25

From: "Zhoupeng (Jewpon)" <[email-masked]>
Date: Wed, 27 Nov 2013 02:34:55 +0000

Hi Eric,
Actually, the global label here used is partial global. That means only PEs in same RG need sense it. Other nodes can be same as before.

I agree with Raszuk that we do need some innovation to deal with centralized control, such as PCE, SDN etc. The shared label is a kind of centralized control in some sense.

Regards,
Zhoupeng

Date: Tue, 26 Nov 2013 15:17:06 +0000
From: Eric Gray <[email-masked]>
To: Robert Raszuk <[email-masked]>, "[email-masked]"
	<[email-masked]>
Cc: "UTTARO, JAMES" <[email-masked]>, "[email-masked]"
	<[email-masked]>
Subject: RE: Why we consider the method of "label sharing for fast PE
	protection"
Message-ID:
	<[email-masked]>
Content-Type: text/plain; charset="us-ascii"

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-masked]] On Behalf Of Robert Raszuk
Sent: Tuesday, November 26, 2013 10:12 AM
To: [email-masked]
Cc: UTTARO, JAMES; [email-masked]
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-masked]> 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