Peter, If on a given node I run OSPF and ISIS and I advertise differe SRGB block with each of them what is really "per node scope"
Each igp thinks it is per node in their understanding of what the node is, but between them I see no relation at all. It would be rather a mistake to assue both igp have congruent base topologies which such condition seems not easy to avoid if you treat block as something sitting above both of them. Thx, R. On Aug 25, 2015 12:53 PM, "Peter Psenak" <[email protected]> wrote: > Robert, > > On 8/25/15 11:50 , Robert Raszuk wrote: > >> So as long you can also configure multiple SRGBs per node the discussion >> is over :) >> > > the discussion is not about advertising multiple SRGBs, but about the > scope of the SRGB advertisement - currently it is a per node. The fact that > you can advertise multiple SRGBs does not change its scope. > > thanks, > Peter > > > >> But that perhaps is a topic outside of IETF and one should express >> preferences directly with their vendors. >> >> Thx Peter ! >> R. >> >> On Aug 25, 2015 11:44 AM, "Peter Psenak" <[email protected] >> <mailto:[email protected]>> wrote: >> >> On 8/25/15 11:36 , Robert Raszuk wrote: >> >> Peter, >> >> In first sentence you say "single block" in second one you say >> "multiple >> blocks" so which one it is ? >> >> >> you can advertise multiple SGRBs per node. >> >> Peter >> >> >> >> Thx, >> R. >> >> On Aug 25, 2015 11:25 AM, "Peter Psenak" <[email protected] >> <mailto:[email protected]> >> <mailto:[email protected] <mailto:[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]> >> <mailto:[email protected] <mailto:[email protected]>> >> <mailto:[email protected] <mailto:[email protected]> >> <mailto:[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]> <mailto:[email protected] >> <mailto:[email protected]>> <mailto:[email protected] >> <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>>> >> https://www.ietf.org/mailman/listinfo/spring >> >> >> >> >> >> _______________________________________________ >> spring mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/spring >> >> >
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
