Using an offset may be dangerous as if your network growth your algo1 SIDs may collision with algo2 SIDs because the offset is no more enough ... (you always need more ...) using an offset is similar to splitting the SRGB in 2 SRGBs with the limitation of not being able to extend the first part. Option 2 allows this extension. You may say let's put a very very large SRGB and offset of +20000 ... yes but it's wasting resources ...
-----Original Message----- From: spring [mailto:[email protected]] On Behalf Of Jon Mitchell Sent: Tuesday, July 21, 2015 14:35 To: Chris Bowers Cc: [email protected] Subject: Re: [spring] FW: New Version Notification for draft-bowers-spring-adv-per-algorithm-label-blocks-01.txt 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 _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
