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)" <spring-boun...@ietf.org on behalf of ginsb...@cisco.com> 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 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 draft. >> >> Thanks, >> Chris >> >> -----Original Message----- >> From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] >> Sent: Monday, October 05, 2015 2:05 PM >> To: Uma Chunduri <uma.chund...@ericsson.com>; Hannes Gredler >> <han...@juniper.net>; Pushpasis Sarkar <psar...@juniper.net>; Chris >> Bowers <cbow...@juniper.net>; Chris Bowers <cbow...@juniper.net>; >> Uma Chunduri <uma.chund...@ericsson.com>; Pushpasis Sarkar >> <psar...@juniper.net>; Hannes Gredler <han...@juniper.net> >> Subject: New Version Notification for draft-bowers-spring-adv-per- >> algorithm-label-blocks-02.txt >> >> >> A new version of I-D, draft-bowers-spring-adv-per-algorithm-label-blocks- >> 02.txt >> has been successfully submitted by Chris Bowers and posted to the IETF >> repository. >> >> Name: draft-bowers-spring-adv-per-algorithm-label-blocks >> Revision: 02 >> Title: Advertising Per-Topology and Per-Algorithm Label Blocks >> Document date: 2015-10-05 >> Group: Individual Submission >> Pages: 14 >> URL: https://www.ietf.org/internet-drafts/draft-bowers-spring-adv- >> per-algorithm-label-blocks-02.txt >> Status: https://datatracker.ietf.org/doc/draft-bowers-spring-adv-per- >> algorithm-label-blocks/ >> Htmlized: https://tools.ietf.org/html/draft-bowers-spring-adv-per- >> algorithm-label-blocks-02 >> Diff: >> https://www.ietf.org/rfcdiff?url2=draft-bowers-spring-adv-per- >> algorithm-label-blocks-02 >> >> Abstract: >> When segment routing is used in a network that is controlled by a >> link state IGP (such as ISIS or OSPF), each node in the network can >> be assigned one or more index numbers, known as "node-SIDs". The >> node-SIDs are unique within the network, and are known to all the >> nodes in the network. If an ingress node has a data packet to be >> sent to an egress node, the ingress node may select a node-SID >> corresponding to the egress node, and "translate" that node-SID to an >> MPLS label. The MPLS label represents a particular path to the >> egress node; the path is determined by applying a routing algorithm >> to a particular view of the network topology and a particular set of >> metric assignments to the links of that topology. The packet can >> then be forwarded by pushing the label on the packet's label stack >> and transmitting the packet to the next hop on the corresponding path >> to the egress node. This document compares two different procedures >> for translating a node-SID to the MPLS label that represents a path >> chosen by a particular algorithm operating on a particular topology. >> It also specifies the ISIS extensions needed to support one of the >> procedures (known as the "per-topology/per-algorithm label block" >> procedure). >> >> >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> >> _______________________________________________ >> spring mailing list >> spring@ietf.org >> https://www.ietf.org/mailman/listinfo/spring > >_______________________________________________ >spring mailing list >spring@ietf.org >https://www.ietf.org/mailman/listinfo/spring _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
