Peter, "You can partition it in many ways, but the block is just one."
As you recall mpls architecture does not have such limitation. You can have per interface overlapping label space. Likewise to me SRGB blocks for MT or MI do not need to be continuos what your earlier suggestion regarding offset would result with. So I think the crux of this entire debate is this: are we allowing non continous SRGB pools per node or not (say one per topology). If not what you and Les are saying may indeed be ok, however for deployment flexibility I would rather tend to opt for it. Best, R. On Aug 25, 2015 9:48 AM, "Peter Psenak" <[email protected]> wrote: > Hi Eric, > > please see inline: > > On 8/24/15 17:08 , Eric C Rosen wrote: > > [Peter] What you need is a different label for same prefix per > > MTID/algorithm - that we agree on. To achieve that you either need > > single SID and per MTID/algorithm SRGB or single SRGB with per > > MTID/algorithm SIDs. > > > > Peter, my reading of the architecture is that a prefix-SID is "global" > > and that an SRGB is per-node. > > Prefix SID has a prefix scope, SRGB has a node scope. > > > > > This seems to be at odds with the way the control plane encodings have > > been defined, which suggests that either the architecture or the > > encodings needs adjustment. > > I do not see any odds with the encodings. Current IGP encoding supports > SRGB per each instance of the IGP. > > > > > Recall that this discussion started with a claim that even one SRGB per > > algorithm was in violation of the architecture. > > SR architecture never claimed per algorithm SRGB. > > > > > If we assume that the signaling drafts capture what the architecture is > > supposed to have said, then I see the following issues. > > > > 1. If a new topology is added by use of the MT features of an IGP, then > > a new set of prefix-SIDs must be provisioned. This seems like a major > > provisioning task. The alternative would be to have an SRGB per > > topology; then when you add a new topology, you only have one quantity > > to provision (or one per platform perhaps). I hear some hand-waving > > about how easy it is to provision new prefix-SIDs for every new > > topology, but ... > > I will keep repeating myself that such provisioning can be made > automatic, so the above point is not really convincing to me. > > > > > 2. The multi-topology feature of an IGP is just one way of setting up > > multiple "underlays". If you set up two underlays by using two > > instances of OSPF, you can assign a SRGB to each underlay. If you set > > up two underlays by using two topologies in one instance of OSPF, you > > can't. Why the difference? I find this really confusing -- exactly > > what is the scope of uniqueness of a prefix-SID supposed to be? > > the difference is because SRGB is a node property and SID is a prefix > property. Each prefix can have many attributes and SID is just another > prefix attribute. It's similar to prefix metric, which has a per > topology scope. SRGB is like any other node capability. This actually > fits very well in the existing IGP architecture - node capabilities are > never per topology. At the end you only have a single label block on a > device. You can partition it in many ways, but the block is just one. > > > > > [Peter] The SR architecture from the very beginning assumed per > > MTID/algorithm SID, not per MTID/algorithm SRGB and IGP encoding has > > been designed with that in mind. > > > > Can you point to a place in the architecture document where it says that > > SIDs are only "global" per MTID/algorithm and/or that SRGBs are > > per-algorithm? > > form draft-ietf-spring-segment-routing-04.txt: > > "SR Global Block (SRGB): local property of an SR node." > > "IGP-prefix Segment, Prefix-SID: an IGP-Prefix Segment is an IGP > segment attached to an IGP prefix. > > Above makes it clear to me that SRGB has a per node property and is > advertised by IGP as such. Prefix-SID is a prefix property and as such > can be advertised per MTID topology, as any other prefix attribute. > > IGP encodings for OSPF and ISIS have been designed by a team of people > from multiple vendors and some of them contributed to the SR > architecture document as well - the fact that we designed the IGP > encoding the way it is clearly indicates what was the common > understanding of the SR architecture. > > We can surely improve the wording in the SR architecture document if you > feel so. > > > > > [Peter] If you add MTID and algorithm in SRGB as well, you end up with > > the MTID and algorithm fields at two different TLVs for the same > > topology - inside SRGB and inside the Prefix SID sub-TLV, which is > > clearly redundant. > > > > I don't really understand what problem is being stated above. > > the problem is that you create an overlap, where both SRGB and > prefix-SID would be carrying the same values. I suppose you agree that > we do not need these fields to be associated with both SRGB and SIDs. > > > > > > [Pushpasis] I am trying give both options to a operator (i.e. Single > > SRGB with per-topology SID-index as well as single SID-index with > > per-topology SRGB). Depending on which one the operators prefer, one of > > them becomes redundant. > > > > [Peter] I'm not sure we want to advertise redundant data to allow more > > configuration flexibility. From both architecture and encoding > > perspective it's preferable to pick single approach. > > > > I see this issue differently. We already allow (but do not require) a > > different SRGB to be assigned to each instance of each routing > > algorithm; > > no, we don't. SRGB scope is IGP instance. There is no algorithm there. > > > but a different SRGB cannot be assigned to each topology of a > > given instance of a given algorithm. This means there are already > > multiple ways of assigning SIDs/SRGBs, with some restrictions that don't > > seem to make much sense. > > > > Also I don't think it's a good trade-off to limit configuration > > flexibility in order to simplify an encoding. > > > > [Peter] please bear in mind that there are implementations out there in > > the field with the existing encoding. > > > > I'm sure any changes could be made in a backwards compatible manner. > > to change the existing encoding one would need a strong reason. I do not > see anything which can not be done with the existing encodings. > > thanks, > Peter > > > > > [Peter] If you move the MTID/algorithm fields from Prefix SID to SRGB, > > what is the MTID/algorithm fields in prefix SID used for? Having the > > MTID/algorithm fields in both Prefix SID and SRGB would be redundant and > > confusing. > > > > Tthe encoding could be designed to not only be backwards compatible, but > > also to give unambiguous semantics to all combinations. > > > > > > > > > > > > _______________________________________________ > spring mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/spring >
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
