Peter, In first sentence you say "single block" in second one you say "multiple blocks" so which one it is ?
Thx, R. On Aug 25, 2015 11:25 AM, "Peter Psenak" <[email protected]> wrote: > Robert, > > On 8/25/15 11:05 , Robert Raszuk wrote: > >> 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). >> > > No matter how many partitions you have, still it's a single block > consisting of multiple partitions. > > Yes, we are allowing non continuous SRGB per node - you can advertise > multiple SRGB blocks per node - please see the OSPF/ISIS SR extensions. > > thanks, > Peter > > > >> 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] >> <mailto:[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] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/spring >> >> >
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
