Stephane/Chris -
Defining an offset, whether explicitly as Ahmed/Jon have suggested or implicitly as the draft Option #2 defines can be problematic in either case. If you don't plan for as many labels as you might need in the future then when the day comes when you run out of labels you need to allocate more. If I use one SRGB for all algorithms, then I have the (non-disruptive) options of: * Extending the existing SRGB space * Reserving an additional SRGB space If I use one SRGB for each algorithm, then if I run out of labels/algorithm I have the same options - but now I have to do this for each algorithm specific set of SRGBs. (There are disruptive ways to address this by completely redefining the SRGBs w/o regard to the existing config - but I think we all understand that this option is very undesirable and this is true in both options.) Of course it is better to be generous enough with your initial SRGB allocation so as to avoid the need for ever having to extend an SRGB - in which case the amount of label space you need to reserve initially is the same in both cases. (Sorry - no free lunch!! :) ) Option #1 however avoids a number of issues which complicate Option #2: Under Option #2 support for a new algorithm now requires not only advertising support for the algorithm but also advertising a new (set of) algorithm specific SRGB ranges. We have to check for the presence of both algorithm support and the algorithm specific SRGB(s) before declaring a node as supporting a given algorithm. Each of these algorithm specific set of ranges has to be checked for both intra-algorithm consistency (no overlap within the algorithm specific ranges) and inter-algorithm consistency. I would also suggest that for many implementations, any reservation of label space AFTER startup can be problematic. Label space is typically managed by declaring two types of ranges: 1)reserved for a specific use (like segment routing) 2)available for dynamic allocation (unreserved) The unreserved space is typically everything that isn't reserved. If I need to reserve additional space after startup I face the possibility that some of the additional range I would like to reserve may be in use via dynamic allocation. In such a case I cannot successfully reserve the range until all the existing dynamic allocations are released - which can be awkward to do and may very well be disruptive to the entity using the dynamically allocated labels. So this is best avoided. I understand why making config easier for the user is desirable - and Option #2 provides that - but it is also easy to do so using Option #1. One can imagine a syntax similar to: algorithm <n> offset <x> And, as described above, this does not require us to reserve more labels than we would need under Option #2. I am not seeing any advantage to Option #2. Though it is well motivated, everything you want to achieve w Option #2 can easily be achieved using Option #1. Les > -----Original Message----- > From: spring [mailto:[email protected]] On Behalf Of > [email protected] > Sent: Tuesday, July 21, 2015 7:52 AM > To: Jon Mitchell; Chris Bowers > Cc: [email protected] > Subject: Re: [spring] FW: New Version Notification for draft-bowers-spring- > adv-per-algorithm-label-blocks-01.txt > > 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]<mailto:[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]<mailto:[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]<mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/spring
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
