hi peter,
how is the computing router supposed to know that the downstream router
supports this per-algo partitioning of the label-space ?
i mena by looking at the downstream routers announcment, how can it "see"
that the downstream router is bringing indeed the packet closer
to the destination and is not just a "ordinary" router with a large
SRGB space ? and how do you want to detect misconfigurations e.g.
"dislike offsets for algos".
lets say we have the following sample network.
R1----R2----R3
each router is advertising a SRGB [16000, 17999].
we have two algorithms (0 and 2 (latency based SPF))
now there is a misconfiguration such that R2 maps the algo2
to SRGB offset 750, where everybody else does it to 500.
so when R1 calculates the algo 2 destination to R3 it
pushes an outgoing label of 16000+500+R3Idx which
R2 does not understand (R2 has a per-algo offset of 750)
result is blackhole, worst case forward somewhere where it
loops.
thoughts ?
/hannes
On Mon, Jul 27, 2015 at 11:11:29AM +0200, Peter Psenak wrote:
| 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
