Hi Rob, I see your interpretation and where it could be confusing. You have clearly went beyond my boldest intentions :)
> From what I comprehend, you are saying that we define > that a single SID maps to N labels. Nope. That is perhaps key difference. My proposal is that node advertises block of Node-SIDs which in turn map 1:1 to MPLS labels. The block of Node-SIDs as as big as largest expected number of parallel links. /* There is no harm in wrong estimation as simply you will just readvertise larger or smaller block */ While this could be accomplished today and may work fine in number of deployments as is there is clear opportunity for optimization. That say that SID block can be represented as prefix so naturally corresponding to it MPLS labels. That said there are two things missing ... * fundamental the SR architecture does not accommodate that * MPLS data plane can be optimized to reduce number of LFIB entries. And that's it. How you use it seems just natural both on ingress as well as on the transit nodes. Best, r. On Thu, Jul 24, 2014 at 8:31 PM, Rob Shakir <r...@rob.sh> wrote: > 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 >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
