Subject: Re: [spring] FW: New Version Notification for draft-bowers-spring-adv-per-algorithm-label-blocks-01.txt

From: Jon Mitchell <[email-masked]>
Date: Tue, 21 Jul 2015 08:34:59 -0400

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

---

From: Hannes Gredler <[email-masked]>
Date: Tue, 21 Jul 2015 14:44:14 +0200

hi jon,

see inline - prefixed by HG>

> algorithms aren't you more likely to consume more overall space with
HG> i might argue that the 'unused' (='fractured') label space is not 
that i am much worried.
what practically matters is what ends up in the forwarding plane.
both option 1 and 2 have no difference in that respect.
so the significant part here is really does operators want to juggle
N indexes for a given node, or just 1 ?
> sequentially this seems to work just as well...
HG> ahmed has got certainly a possible proposal - the practical downside 
is that the SRGB
may grow big ... given the practical max SRGB boundaries we have seen from
many implementations it may not advisable to do this on existing platforms.

/hannes

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 21 Jul 2015 12:51:38 +0000

I agree with Jon’s comments. The only possible benefit is that a human
could associate a given SID/label with its usage. However, that benefit is
only realized if one has consistent per algorithm/topology SRGBs
throughout the routing domain.
Thanks,
Acee 

On 7/21/15, 2:34 PM, "spring on behalf of Jon Mitchell"
<[email-masked] on behalf of [email-masked]> wrote:

>> This updated version of the draft includes a concrete proposal for ISIS
>>extensions to implement per-algorithm label blocks.
>> 
>
>Chris -
>
>_______________________________________________
>spring mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/spring

---

From: <[email-masked]>
Date: Tue, 21 Jul 2015 14:52:22 +0000

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-masked]] On Behalf Of Jon Mitchell
Sent: Tuesday, July 21, 2015 14:35
To: Chris Bowers
Cc: [email-masked]
Subject: Re: [spring] FW: New Version Notification for draft-bowers-spring-adv-per-algorithm-label-blocks-01.txt

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

_________________________________________________________________________________________________________________________

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.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 21 Jul 2015 20:58:51 +0000

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!! :) )

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

> From: spring [mailto:[email-masked]] On Behalf Of

> [email-masked]

> Sent: Tuesday, July 21, 2015 7:52 AM

> To: Jon Mitchell; Chris Bowers

> 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 ...

> Cc: [email-masked]<mailto:[email-masked]>

> Subject: Re: [spring] FW: New Version Notification for draft-bowers-spring-

> adv-per-algorithm-label-blocks-01.txt

> 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?

> 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...

> [email-masked]<mailto:[email-masked]>

> __________________________________________________________

> __________________________________________________________

> _____

> 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.

> [email-masked]<mailto:[email-masked]>

---

From: <[email-masked]>
Date: Wed, 22 Jul 2015 08:32:48 +0000

Hi Les,

Inline comments

From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
Sent: Tuesday, July 21, 2015 22:59
To: LITKOWSKI Stephane SCE/IBNF; Jon Mitchell; Chris Bowers
Cc: [email-masked]
Subject: RE: [spring] FW: New Version Notification for draft-bowers-spring-adv-per-algorithm-label-blocks-01.txt

Stephane/Chris -

[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).

[SLI] Agree , this is true in both cases.

[SLI] Agree

[SLI] Agree

[SLI] Fully agree

[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.

[SLI] Fully agree. But both options are affected by this.

   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.

  Les

> [email-masked]<mailto:[email-masked]>

---

From: Hannes Gredler <[email-masked]>
Date: Mon, 27 Jul 2015 10:47:50 +0200

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-masked]] On Behalf Of
| 
|    > [email-masked]
| 
|    > Sent: Tuesday, July 21, 2015 7:52 AM
| 
|    > To: Jon Mitchell; Chris Bowers
| 
|    > Cc: [email-masked]
| 
|    > 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-masked]] On Behalf Of Jon
|    Mitchell
| 
|    > Sent: Tuesday, July 21, 2015 14:35
| 
|    > To: Chris Bowers
| 
|    > Cc: [2][email-masked]
| 
|    > 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-masked]
| 
|    > [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-masked]
| 
|    > [6]https://www.ietf.org/mailman/listinfo/spring
| 
| References
| 
|    Visible links
|    1. mailto:[email-masked]
|    2. mailto:[email-masked]
|    3. mailto:[email-masked]
|    4. https://www.ietf.org/mailman/listinfo/spring
|    5. mailto:[email-masked]
|    6. https://www.ietf.org/mailman/listinfo/spring

| _______________________________________________
| spring mailing list
| [email-masked]
| https://www.ietf.org/mailman/listinfo/spring

---

From: Peter Psenak <[email-masked]>
Date: Mon, 27 Jul 2015 11:11:29 +0200

Hi Hannes,

>     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

> .

---

From: Hannes Gredler <[email-masked]>
Date: Wed, 29 Jul 2015 09:26:31 +0200

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-masked]] On Behalf Of
| >|
| >|    > [email-masked]
| >|
| >|    > Sent: Tuesday, July 21, 2015 7:52 AM
| >|
| >|    > To: Jon Mitchell; Chris Bowers
| >|
| >|    > Cc: [email-masked]
| >|
| >|    > 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-masked]] On Behalf Of Jon
| >|    Mitchell
| >|
| >|    > Sent: Tuesday, July 21, 2015 14:35
| >|
| >|    > To: Chris Bowers
| >|
| >|    > Cc: [2][email-masked]
| >|
| >|    > 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-masked]
| >|
| >|    > [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-masked]
| >|
| >|    > [6]https://www.ietf.org/mailman/listinfo/spring
| >|
| >| References
| >|
| >|    Visible links
| >|    1. mailto:[email-masked]
| >|    2. mailto:[email-masked]
| >|    3. mailto:[email-masked]
| >|    4. https://www.ietf.org/mailman/listinfo/spring
| >|    5. mailto:[email-masked]
| >|    6. https://www.ietf.org/mailman/listinfo/spring
| >
| >| _______________________________________________
| >| spring mailing list
| >| [email-masked]
| >| https://www.ietf.org/mailman/listinfo/spring
| >
| >_______________________________________________
| >spring mailing list
| >[email-masked]
| >https://www.ietf.org/mailman/listinfo/spring
| >.
| >
|

---

From: Peter Psenak <[email-masked]>
Date: Wed, 29 Jul 2015 09:57:02 +0200

Hi Hannes,

please see inline:

> "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.

> result is blackhole, worst case forward somewhere where it

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