I agree with Jon’s comments. The only possible benefit is that a human could associate a given SID/label with its usage. However, that benefit is only realized if one has consistent per algorithm/topology SRGBs throughout the routing domain. Thanks, Acee
On 7/21/15, 2:34 PM, "spring on behalf of Jon Mitchell" <[email protected] on behalf of [email protected]> wrote: >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 _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
