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
