Hi Les, Inline comments
From: Les Ginsberg (ginsberg) [mailto:[email protected]] Sent: Tuesday, July 21, 2015 22:59 To: LITKOWSKI Stephane SCE/IBNF; 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 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. [SLI] Option #2 is not really an offset ... even if we can think that it's similar it's not. Option#1 with offset proposal : consider a SRGB [100-1100] that I split in two parts administratively to allocate SIDs for two algos. Algo#1 from index 0 to 499, Algo#2 from 500 to 1000. If you have 501 nodes, you will need to allocate a new SRGB and split again [1101 - 2100]. So you will have some "fragmentation" in your SID allocation scheme for algos while we wanted to pack SIDs for each algo. Algo#1 would be 0-499 and 1001 - 1500; Algo#2 500-1000, 1501 - 2100. That works for sure, but it requires a good management ... as pointed, I'm taking about using offset as proposed during the meeting, flat allocation is still possible (first come first served). 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. [SLI] Agree , this is true in both cases. 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 [SLI] Agree 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. [SLI] Agree (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!! :) ) [SLI] Fully agree 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. [SLI] Is it really different from having multiple SRGBs common from all algorithm ? you need to check that there is no overlap, so I think that number of operation to perform are the same. The change is that you need to manage the list of SRGB per algorithm rather than globally. 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. [SLI] Fully agree. But both options are affected by this. 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> [SLI] As pointed at the beginning this does not work as soon as you need an additional SRGB or you need to bring a bit more intelligence to hide the fragmentation in the SID packing per algo. 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]<mailto:[email protected]> > Sent: Tuesday, July 21, 2015 7:52 AM > To: Jon Mitchell; 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 > > 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 _________________________________________________________________________________________________________________________ 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
