hi les, assuming option 1 and a local knob e.g. 'algorithm <n> offset <x>' as per your example below i got the following question(s):
1) how does a computing router know that a downstream router has got the 'offset per-algo knob' configured, such that it can map outgoing label values to the correct label value (SRGB + algo offset) of the downstream routers ? - 2) is the expectation that 'algorithm <n> offset <x>' is configured identical on all the routers in the network ? 3) if so - isn't this considered a rather 'fragile / error prone' approach to operating a network ? /hannes On Tue, Jul 21, 2015 at 08:58:51PM +0000, Les Ginsberg (ginsberg) wrote: | 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!! J ) | | | | 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 [[1]mailto:[email protected]] On Behalf Of Jon | Mitchell | | > Sent: Tuesday, July 21, 2015 14:35 | | > To: Chris Bowers | | > Cc: [2][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 | | > [3][email protected] | | > [4]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 | | > [5][email protected] | | > [6]https://www.ietf.org/mailman/listinfo/spring | | References | | Visible links | 1. mailto:[email protected] | 2. mailto:[email protected] | 3. mailto:[email protected] | 4. https://www.ietf.org/mailman/listinfo/spring | 5. mailto:[email protected] | 6. https://www.ietf.org/mailman/listinfo/spring | _______________________________________________ | spring mailing list | [email protected] | https://www.ietf.org/mailman/listinfo/spring _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
