Hi Hannes,
please see inline:
On 7/29/15 09:26 , Hannes Gredler wrote:
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".
there is an 'Algorithm' field in the Prefix SID Sub-TLV, so receiving
router knows which algo is each SID associated with. There is no need
for offsets to be consistent on all routers. The only requirement is for
each SID to be unique.
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.
R3 advertises two SIDs:
1. alg 0 25
2. alg 2 525
when R1 calculates the algo 2 destination to R3 it pushes an outgoing
label of 16525, nothing changes to the regular SR with alg 0.
Offset used on R2 is orthogonal to the rest of the routers. It is only
used for making configuration easier on R2 (one index is configured for
local prefix on R2, but 2 SIDs are advertised, one per algo) . As far as
the SIDs are unique, there is no problem.
thanks,
Peter
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
