Hi Robert,
On 26 Jul 2014, at 23:26, Robert Raszuk <rob...@raszuk.net> wrote:
> Perhaps you can expand on how an LSR programs its LFIB such that it has
> multiple labels matched with a single entry please?
>
> When you install a label to LFIB you also pass its depth ie number of
> significant bits to match on.
>
> Hardware will treat the remaining bits as "do not care". That is pretty basic
> logical function for any match operation.
rjs> So, this is exactly akin to the description I gave of partitioning the
label space - since it requires one to sterilise some of the label space
(N-bits are now significant for forwarding, with the remaining (20-M) being
used for entropy).
> At least I am quite sure it is much simpler then any other form of search for
> ELI/EL within the SR deep stack :)
rjs> The look-up logic has to change somewhat for the data-plane. Particularly
as:
- We need to check whether the top-most label is within the block of labels
that we are using for this function.
- If it is, we do a lookup based on the first N-bits to determine the next-hop.
- if it’s not, we need to do a lookup based on the entire label.
- If this was in the entropy block we determine the OIF by matching this
next-hop along with the hash of the remaining (20-N) bits.
- else we fallback to the existing hashing procedures.
Alternatively, we need to:
- Look-up the next-hop based on the top-most label.
- If the ELI is in the label stack, take the following label as the EL.
- Determine the OIF based on the next-hop and the EL value received.
- if the EL is not present, then hash based on existing procedures.
Is the former “much simpler”? I am no hardware expert, but I would say they
seem roughly analogous in terms of decision process that needs to be made -
other than the latter needs visibility into more of the packet (such that
ELI/EL is included in the header that is extracted).
It’s notable that the latter logic must be implemented anyway at an LSR,
because we have now standardised ELI/EL and it is implemented.
> I’m struggling to comprehend how this fits into the existing implementations,
> or can be realised without requiring some forwarding/entropy split of the
> 20-bit label as I described before.
>
> The split I have in mind is passed explicitiely in control plane. So there
> is no additional logic required for it.
>
> Now you may rightfully state that this requires an upgrade. Well true but
> any alternative discussed here requires an upgrade as well. Moreover even
> support of SR requires an upgrade :)
>
> Control plane vs data plane .. EL based solution requires both day one. Label
> mask does not strictly require any data plane change during the transition
> period as it could install all atomic labels till the mask support in LFIB is
> available later.
>
rjs> In smaller nodes (aggregation/access nodes) then this might have
significant impact, given LFIB limitations. If we need to have M*(number of
destination FECs) installed in the LFIB then this might bust some limits.
Whilst label mask is a potential solution, my view is that we should continue
to leverage the EL work already done by this WG.
Kind regards,
> Cheers,
> R.
>
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
