Re: [spring] New Version Notification for draft-bowers-spring-adv-per-algorithm-label-blocks-02.txt
Hi all, As a network operator, please see my 2cents inline [Bruno] > From: Ahmed Bashandy (bashandy) > Sent: Tuesday, November 10, 2015 1:54 AM > > Thanks a lot Les for the elaborate explanation > > One small addition to what Les mentioned. The functionality proposed by > the draft can be achieved by having a base prefix-SID index and then > configuring an offset (instead of an SRGB) for each topology/algorithm > pair from that base prefix-SID index value. Based on the configured > offset, the router would then calculate the corresponding prefix-SID > index for each topology/algorithm pair and advertise it using existing > mechanisms [Bruno] This is correct. However, IMO this is a drawback to have: a) the network operator configure a specific value (offset) attached to a specific item (algo/topology) b) the protocol (and hence the logs/show/dumps...) advertise a different value (SID+offset) attached to a different item (prefix) I fear that this would not help the troubleshooting, in particular in difficult situations (e.g. significant network issue, with significant pressure and possibly with non-expert people involved. e.g. "I know why this does not work: the offset configured is not advertised" or "The SID advertised does not match the configured one" ...) So I don't feel that the "offset" proposal is fully equivalent. Thanks -- Bruno > Note that the above is NOT a suggestion to use the offset mechanism to > configure prefix-SID indices. The objective is to show that the draft > does not offer enough benefits to warrant all the questions marks that > are outlined in Les's email. > > Thanks > > Ahmed > > On 11/9/2015 1:11 AM, Les Ginsberg (ginsberg) wrote: > > Chris - > > > > I have a number of questions - but in order to properly frame them I need > to recount some history - please bear with me. > > > > In the very early days of SR there was a proposal to reserve a fixed label > range on all routers (16000 - 23999) for the use of SR. This seemed workable > but there was concern that the same range would not be available on all > routers so the SR community agreed that we needed to allow the > advertisement of a different SRGB range on each SR capable router. > > > > Then, another concern was raised that a single contiguous range large > enough to meet the SR requirements might not be available on all routers and > therefore we needed to support the advertisement of multiple SRGB ranges > from a given node. This capability has been added - though it has also raised > other concerns regarding how many ranges might be enough and how to deal > with inconsistencies (overlaps) in the advertised ranges should some error > occur. > > > > Now, in support of multiple algorithms/topologies, this draft proposes that > algorithm/topology specific SRGBs be advertised - and that to fully get the > benefits of consistent SID assignment for the same prefix across > algorithms/topologies (the major goal of this draft) that all routers be able > to > support identical ranges for each algorithm/topology. (Section 5 goes into > this > in detail) - and to be able to allocate new ranges for newly configured > algorithms/topologies on demand. Section 6 goes on to suggest that it would > be a wonderful goal if all routers could assign the same base label/range to > each algorithm/topology so that the labels could be derived algorithmically > (though you admit this may not always be possible). > > > > My first question is how do you reconcile this requirement for consistency > on all nodes with the earlier decisions to support inconsistency as regards > SRGB base values/range sizes? > > > > My second question is associated with the assumption of a single > "node_index" per node. I for one would be delighted if we could get > agreement on using a single host address/node (or at least one per AF) for all > traffic to that node. But this does not meet the deployment requirements in > all cases and so we support multiple "node_indeces" for a given node. This > means that we do not map SIDs to nodes - we map SIDs to prefixes. So it is > conceptually more straightforward and less problematic to configure SIDs for > prefix ranges. This is in fact how SRMS advertisements are constructed i.e. > > > >(Prefix/Prefix length, Starting SID, Range) > > > > How would you propose to incorporate this style of SID assignment into your > algorithms? Do you assume a maximum number of node-sids required for > every node in the network and require the range for each algorithm/topology > be sized large enough for the worst case? This seems potentially wasteful - > especially if a deployment chooses to use a particular address for a topology > as a traffic differentiator. > > > > My third question relates to the algorithm/topology independence of the > SID assignment that you propose. Throughout the document you assume that > you have a single SID for a given prefix and you simply add the appropriate > algorithm/topology sp
Re: [spring] New Version Notification for draft-bowers-spring-adv-per-algorithm-label-blocks-02.txt
I also don’t see the big value add on this draft from what we have. Given it introduces backward compatibility issues from existing implementation/deployments I don’t see why we should proceed with this work in the WG. On 09/11/15 10:11, "spring on behalf of Les Ginsberg (ginsberg)" wrote: >Chris - > >I have a number of questions - but in order to properly frame them I need to >recount some history - please bear with me. > >In the very early days of SR there was a proposal to reserve a fixed label >range on all routers (16000 - 23999) for the use of SR. This seemed workable >but there was concern that the same range would not be available on all >routers so the SR community agreed that we needed to allow the advertisement >of a different SRGB range on each SR capable router. > >Then, another concern was raised that a single contiguous range large enough >to meet the SR requirements might not be available on all routers and >therefore we needed to support the advertisement of multiple SRGB ranges from >a given node. This capability has been added - though it has also raised other >concerns regarding how many ranges might be enough and how to deal with >inconsistencies (overlaps) in the advertised ranges should some error occur. > >Now, in support of multiple algorithms/topologies, this draft proposes that >algorithm/topology specific SRGBs be advertised - and that to fully get the >benefits of consistent SID assignment for the same prefix across >algorithms/topologies (the major goal of this draft) that all routers be able >to support identical ranges for each algorithm/topology. (Section 5 goes into >this in detail) - and to be able to allocate new ranges for newly configured >algorithms/topologies on demand. Section 6 goes on to suggest that it would >be a wonderful goal if all routers could assign the same base label/range to >each algorithm/topology so that the labels could be derived algorithmically >(though you admit this may not always be possible). > >My first question is how do you reconcile this requirement for consistency on >all nodes with the earlier decisions to support inconsistency as regards SRGB >base values/range sizes? > >My second question is associated with the assumption of a single "node_index" >per node. I for one would be delighted if we could get agreement on using a >single host address/node (or at least one per AF) for all traffic to that >node. But this does not meet the deployment requirements in all cases and so >we support multiple "node_indeces" for a given node. This means that we do not >map SIDs to nodes - we map SIDs to prefixes. So it is conceptually more >straightforward and less problematic to configure SIDs for prefix ranges. This >is in fact how SRMS advertisements are constructed i.e. > > (Prefix/Prefix length, Starting SID, Range) > >How would you propose to incorporate this style of SID assignment into your >algorithms? Do you assume a maximum number of node-sids required for every >node in the network and require the range for each algorithm/topology be sized >large enough for the worst case? This seems potentially wasteful - especially >if a deployment chooses to use a particular address for a topology as a >traffic differentiator. > >My third question relates to the algorithm/topology independence of the SID >assignment that you propose. Throughout the document you assume that you have >a single SID for a given prefix and you simply add the appropriate >algorithm/topology specific SRGB base value to this SID to derive the >forwarding label. However, current protocol advertisements for SIDs include >both algorithm and topology as context for the SID. This reflects the current >SR architecture which has been defined with algorithm/topology as an explicit >context for a SID. Your proposal fundamentally changes this and therefore all >existing encodings of SID advertisements (prefix reachability, SRGB, SRMS >advertisements) would have to be changed in a non-backwards compatible way in >order to support your proposal. Other than definition of a new SRGB >advertisement, you do not discuss this in the draft. How do you intend to >address this major issue? > > Les > > >> -Original Message- >> From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Chris Bowers >> Sent: Monday, October 05, 2015 12:31 PM >> To: spring@ietf.org >> Subject: [spring] FW: New Version Notification for draft-bowers-spring-adv- >> per-algorithm-label-blocks-02.txt >> >> SPRING WG, >> >> There was quite a lot of discussion in person after we presented draft- >> bowers-spring-adv-per-algorithm-label-blocks-01 in Prague, and there was >> also much discussion on this list about the issue raised by this draft. We >> have >> made two main additions to this revision of the draft to further this >> discussion. >> >> 1) We have included discussion of multiple topologies in addition to multiple >> algorithms, and we have m
Re: [spring] New Version Notification for draft-bowers-spring-adv-per-algorithm-label-blocks-02.txt
Thanks a lot Les for the elaborate explanation One small addition to what Les mentioned. The functionality proposed by the draft can be achieved by having a base prefix-SID index and then configuring an offset (instead of an SRGB) for each topology/algorithm pair from that base prefix-SID index value. Based on the configured offset, the router would then calculate the corresponding prefix-SID index for each topology/algorithm pair and advertise it using existing mechanisms Note that the above is NOT a suggestion to use the offset mechanism to configure prefix-SID indices. The objective is to show that the draft does not offer enough benefits to warrant all the questions marks that are outlined in Les's email. Thanks Ahmed On 11/9/2015 1:11 AM, Les Ginsberg (ginsberg) wrote: Chris - I have a number of questions - but in order to properly frame them I need to recount some history - please bear with me. In the very early days of SR there was a proposal to reserve a fixed label range on all routers (16000 - 23999) for the use of SR. This seemed workable but there was concern that the same range would not be available on all routers so the SR community agreed that we needed to allow the advertisement of a different SRGB range on each SR capable router. Then, another concern was raised that a single contiguous range large enough to meet the SR requirements might not be available on all routers and therefore we needed to support the advertisement of multiple SRGB ranges from a given node. This capability has been added - though it has also raised other concerns regarding how many ranges might be enough and how to deal with inconsistencies (overlaps) in the advertised ranges should some error occur. Now, in support of multiple algorithms/topologies, this draft proposes that algorithm/topology specific SRGBs be advertised - and that to fully get the benefits of consistent SID assignment for the same prefix across algorithms/topologies (the major goal of this draft) that all routers be able to support identical ranges for each algorithm/topology. (Section 5 goes into this in detail) - and to be able to allocate new ranges for newly configured algorithms/topologies on demand. Section 6 goes on to suggest that it would be a wonderful goal if all routers could assign the same base label/range to each algorithm/topology so that the labels could be derived algorithmically (though you admit this may not always be possible). My first question is how do you reconcile this requirement for consistency on all nodes with the earlier decisions to support inconsistency as regards SRGB base values/range sizes? My second question is associated with the assumption of a single "node_index" per node. I for one would be delighted if we could get agreement on using a single host address/node (or at least one per AF) for all traffic to that node. But this does not meet the deployment requirements in all cases and so we support multiple "node_indeces" for a given node. This means that we do not map SIDs to nodes - we map SIDs to prefixes. So it is conceptually more straightforward and less problematic to configure SIDs for prefix ranges. This is in fact how SRMS advertisements are constructed i.e. (Prefix/Prefix length, Starting SID, Range) How would you propose to incorporate this style of SID assignment into your algorithms? Do you assume a maximum number of node-sids required for every node in the network and require the range for each algorithm/topology be sized large enough for the worst case? This seems potentially wasteful - especially if a deployment chooses to use a particular address for a topology as a traffic differentiator. My third question relates to the algorithm/topology independence of the SID assignment that you propose. Throughout the document you assume that you have a single SID for a given prefix and you simply add the appropriate algorithm/topology specific SRGB base value to this SID to derive the forwarding label. However, current protocol advertisements for SIDs include both algorithm and topology as context for the SID. This reflects the current SR architecture which has been defined with algorithm/topology as an explicit context for a SID. Your proposal fundamentally changes this and therefore all existing encodings of SID advertisements (prefix reachability, SRGB, SRMS advertisements) would have to be changed in a non-backwards compatible way in order to support your proposal. Other than definition of a new SRGB advertisement, you do not discuss this in the draft. How do you intend to address this major issue? Les -Original Message- From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Chris Bowers Sent: Monday, October 05, 2015 12:31 PM To: spring@ietf.org Subject: [spring] FW: New Version Notification for draft-bowers-spring-adv- per-algorithm-label-blocks-02.txt SPRING WG, There was quite a lot of discuss
Re: [spring] New Version Notification for draft-bowers-spring-adv-per-algorithm-label-blocks-02.txt
Chris - I have a number of questions - but in order to properly frame them I need to recount some history - please bear with me. In the very early days of SR there was a proposal to reserve a fixed label range on all routers (16000 - 23999) for the use of SR. This seemed workable but there was concern that the same range would not be available on all routers so the SR community agreed that we needed to allow the advertisement of a different SRGB range on each SR capable router. Then, another concern was raised that a single contiguous range large enough to meet the SR requirements might not be available on all routers and therefore we needed to support the advertisement of multiple SRGB ranges from a given node. This capability has been added - though it has also raised other concerns regarding how many ranges might be enough and how to deal with inconsistencies (overlaps) in the advertised ranges should some error occur. Now, in support of multiple algorithms/topologies, this draft proposes that algorithm/topology specific SRGBs be advertised - and that to fully get the benefits of consistent SID assignment for the same prefix across algorithms/topologies (the major goal of this draft) that all routers be able to support identical ranges for each algorithm/topology. (Section 5 goes into this in detail) - and to be able to allocate new ranges for newly configured algorithms/topologies on demand. Section 6 goes on to suggest that it would be a wonderful goal if all routers could assign the same base label/range to each algorithm/topology so that the labels could be derived algorithmically (though you admit this may not always be possible). My first question is how do you reconcile this requirement for consistency on all nodes with the earlier decisions to support inconsistency as regards SRGB base values/range sizes? My second question is associated with the assumption of a single "node_index" per node. I for one would be delighted if we could get agreement on using a single host address/node (or at least one per AF) for all traffic to that node. But this does not meet the deployment requirements in all cases and so we support multiple "node_indeces" for a given node. This means that we do not map SIDs to nodes - we map SIDs to prefixes. So it is conceptually more straightforward and less problematic to configure SIDs for prefix ranges. This is in fact how SRMS advertisements are constructed i.e. (Prefix/Prefix length, Starting SID, Range) How would you propose to incorporate this style of SID assignment into your algorithms? Do you assume a maximum number of node-sids required for every node in the network and require the range for each algorithm/topology be sized large enough for the worst case? This seems potentially wasteful - especially if a deployment chooses to use a particular address for a topology as a traffic differentiator. My third question relates to the algorithm/topology independence of the SID assignment that you propose. Throughout the document you assume that you have a single SID for a given prefix and you simply add the appropriate algorithm/topology specific SRGB base value to this SID to derive the forwarding label. However, current protocol advertisements for SIDs include both algorithm and topology as context for the SID. This reflects the current SR architecture which has been defined with algorithm/topology as an explicit context for a SID. Your proposal fundamentally changes this and therefore all existing encodings of SID advertisements (prefix reachability, SRGB, SRMS advertisements) would have to be changed in a non-backwards compatible way in order to support your proposal. Other than definition of a new SRGB advertisement, you do not discuss this in the draft. How do you intend to address this major issue? Les > -Original Message- > From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Chris Bowers > Sent: Monday, October 05, 2015 12:31 PM > To: spring@ietf.org > Subject: [spring] FW: New Version Notification for draft-bowers-spring-adv- > per-algorithm-label-blocks-02.txt > > SPRING WG, > > There was quite a lot of discussion in person after we presented draft- > bowers-spring-adv-per-algorithm-label-blocks-01 in Prague, and there was > also much discussion on this list about the issue raised by this draft. We > have > made two main additions to this revision of the draft to further this > discussion. > > 1) We have included discussion of multiple topologies in addition to multiple > algorithms, and we have modified the proposed ISIS extension to handle > both multiple topologies and multiple algorithms. > > 2) We have tried to accurately describe a proposal, which was outlined on > this list, for managing the assignment of per-topology/per-algorithm node > index values, which we refer to as the "configured offset mapping method". > > We welcome feedback from the working group on this
