On 24/06/15 23:09 +0000, Chris Bowers wrote: > This updated version of the draft includes a concrete proposal for ISIS > extensions to implement per-algorithm label blocks. >
Chris - As you discussed in the meeting today in option 2 (the proposal) there is a "savings" that is achieved by not allocating a large label space as is required in option 1 since we may not be able to predict the future of algorithm needs in the network. But wouldn't you agree that since you are allocating a node index in every fractured address space (whether required or not) in option 2, since address space that is partitioned typically consumes more space than unfractured space (due to loss because of imperfect planning), as you increase the number of algorithms aren't you more likely to consume more overall space with this technique? Secondly there was a statement made that there is an advantage to option 2 that it allows easier provisioning of node index value (as it's reused) per algorithm. Isn't it just as easy for an implementation to allow the user to just configure a local implementation offset for an algorithm which requires no protocol changes and has more flexiblity as it doesn't need to be configured for prefix SID's that don't require it (similar as Ahmed suggested at the mic, i.e. algorithm 2 = +1000) that could be configured at every node? Assuming OSS provisions SID's sequentially this seems to work just as well... Thanks, Jon _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
