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
