Re: [mpls] MPLS WG last call on draft-ietf-mpls-special-purpose-labels-03

[Lizhong Jin <[e-mail]>]

>
>
> > However, I think we need to look if there are other cases there what
> > is proposed by Kireeti leads to increasing complexity.
> >
> > If we for example we know that the 16 lowest values are not in
> > the ranges allocated for extended label space that might simplify
> > the search of the labels in the extended space.
> >
> > Any HW aspects on this?
>
> I don't believe so, and unless someone speaks up, I'll assume not :)
>
> Kireeti.
>

[Lizhong] let me try to explain my concern from HW aspects.
1. the HW will not process the MPLS label one by one like software,
instead, the HW will process the lable with pipeline. If the HW supports to
process 3 MPLS application label, then it always will process the 3 labels
at the same time.
2. that means the HW behavior will not search a label with 7, and ignore
other labels before and after 7. HW will always check the label before
7(ELI).
Then from my view, the benefit Kireeti try to get does not exist in some HW
implementations as I know.

Then the increasing complexity it brings is the Extended Special Purpose
MPLS Label table looking up. Now we will have two reserved label tables:
1. 0~15, it is the traditional reserved label table. This table is
directly indexed by the reserved label.
2. 7, 16~1048575, it is the Extended Special Purpose label table. The table
could not be directly indexed by the label, because the labels are not
consecutive. You have to use addtional logic to index to the table.

Anyway, this is not a block issue, and allowing 15/7 label may benefit some
other implementations that I do not know.

Thanks
Lizhong




> > <chair hat on>
> >
> > /Loa
>
>
>