Hi Robert, On 24 Jul 2014, at 03:21, Robert Raszuk <rob...@raszuk.net> wrote:
> > Therefor an alternative of using any form of entropy labels in data plane all > together would be to allocate a SID blocks (say 64 or 128 wide) and allow > SPRING header imposition to use such pools of SIDs per group of flows to > effectively allow for efficient load balancing in the network. Sorry, maybe I’m missing something here, but I found your message a little cryptic. >From what I comprehend, you are saying that we define that a single SID maps >to N labels. These labels are split somehow into a “forwarding” and “hash” >value. Simplistically, this could say that we have the first 12 bits as the >“forwarding” and the bottom 8 as the “hash” value. e.g. Node A advertises an Adj-SID with value 0b00000101000 (40), anything that is in the range 0b0000010100000000000 (10240) - 0b0000010100011111111 (10495) has the same forwarding behaviour, but the last 8 bits are used to hash (allowing 256 different hash-able objects). If I understood right - then this seems to have a number of challenges to me: - For Node-SIDs, we now must sterilise the SRGB to be as wide as (number of required entries)*(number of hash-able objects required) - which means that we must be able to determine a label block that can be used for this. - We reduce the size of the label space from 20-bits to a smaller value - this might be a material concern in cases where we have many other labels that are allocated on a device (per-prefix label allocation within an L3VPN environment that has many prefixes might be a concern?). - We need every device in the network to comprehend this new format of label allocation and imposition - such that we do not increase the number of forwarding entries that are required (as Stephane and Kireeti have observed). This is problematic where we have limited LFIB already since instead of programming a number of LFIB entries O(the number of labelled endpoints) then we instead need to have O(number of labelled endpoints * number of hashable objects). Equally, I think the assertion that you have made is that deeper EL is not “easily supported by most of [today’s] shipping routers”. I think that we need to determine whether this is really the case — given that MPLS WG has standardised EL we need to figure *why* a change from this is required — which is (I guess) the intention of the draft we’re discussing here. *If* we conclude that none of the options that are presented using existing technology are suitable, then potentially then we can look at new solutions. If my reading of your mail is completely whacky, then please ignore the above - and a clarifying example would be greatly appreciated. thx, r. _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
