Hi Hannes,
On 7/27/15 10:47 , Hannes Gredler wrote:
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 ?
-
there is no need for the computing node to know.
Let's assume we have a node N that has single SRGB (16000-23999) and it
supports 4 algorithms. Internally the node splits its SRGB to 4 blocks,
one per algorithm:
alg 0: [16000, 17999]
alg 1: [18000, 19999]
alg 2: [20000, 21999]
alg 3: [22000, 23999]
For prefix P1 on node N, user configures single index 25. Node N then
advertises:
SID 16025 - alg 0
SID 18025 - alg 1
SID 20025 - alg 2
SID 22025 - alg 3
thanks,
Peter
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
.
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
