hi jon,
see inline - prefixed by HG>
On 7/21/15 14:34, Jon Mitchell wrote:
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?
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 ?
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...
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
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
