[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. 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. Recall that this discussion started with a claim that even one SRGB per algorithm was in violation of the architecture. 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 ... 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? [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? [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. [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; 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. [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
