Hi Robert, On 24 Jul 2014, at 16:21, Robert Raszuk <[email protected]> wrote:
> I see your interpretation and where it could be confusing. You have clearly > went beyond my boldest intentions :) Thanks for the clarification. > > 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. Operationally — this doesn’t seem ideal to me. AIUI, If we have some forwarding issue between two LSRs, then we might end up with partial reachability if a subset of the paths do not have correct LFIB entries throughout the network. It introduces a requirement, where failure detection is required, to run N different OAM probes to be able to monitor reachability (one for each Node-SID assigned to the remote device - even in cases where we have 1 available path). I think the question for the MPLS WG here is whether there is any appetite to introduce a new means by which entropy in MPLS networks is introduced. We already have Entropy Label which has been published and implemented. The question to me seems to be why we need anything else. Fewer solutions seems optimal :-) Cheers, r. > Best, > r. > > > > > > > On Thu, Jul 24, 2014 at 8:31 PM, Rob Shakir <[email protected]> wrote: > Hi Robert, > > On 24 Jul 2014, at 03:21, Robert Raszuk <[email protected]> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/spring >
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
