Cool ... as long as I can have a freedom to run multiple instances of ISIS (one per topology) with different blocks I am happy !
Cheers, R. On Aug 25, 2015 1:19 PM, "Peter Psenak" <[email protected]> wrote: > Robert, > > On 8/25/15 13:14 , Robert Raszuk wrote: > >> 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" >> > > per node means per IGP. Nobody can prevent you to advertise different > SRGBs in different IGPs. > > thanks, > Peter > > >> 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] >> <mailto:[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]> >> <mailto:[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]>> >> <mailto:[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]>>> >> <mailto:[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]>>> >> <mailto:[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] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/spring >> >> >> >
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
