Les, You have clearly misunderstood the scenario/question :)
I am talking not about anycast to SR devices (what the draft you quote is all about), but periodic anycast across N topologies to the same prefix on the single device. If I allocate single SID to prefix regardless which protocol/topology advertitses such tuple how do I construct different data plane forwarding in transit nodes assuming flat LFIBs ? And with that I do not want to readvertise anything in IGP each type my forwarding preference to said prefix across topologies changes. Also as Eric commented already a workaround to bring up new prefix in such case has severe application level consequences, hence - while doable from network point of view - it would rather not be a wise deployment choice. Best, r. On Tue, Aug 25, 2015 at 11:49 PM, Les Ginsberg (ginsberg) < [email protected]> wrote: > Robert – > > > > You have asked exactly the opposite of the question you should have asked. > J > > IF there is a consistent SRGB – not only among multiple protocols on a > given node – but also among all the nodes in the network – then anycast is > easy. > > Where things get complicated is when SRGBs differ. Read Pushpasis’s > draft: > https://www.ietf.org/id/draft-psarkar-spring-mpls-anycast-segments-00.txt > > > > Les > > > > > > *From:* [email protected] [mailto:[email protected]] *On Behalf Of *Robert > Raszuk > *Sent:* Tuesday, August 25, 2015 1:17 PM > *To:* Les Ginsberg (ginsberg) > *Cc:* Peter Psenak (ppsenak); [email protected]; > [email protected]; Pushpasis Sarkar ([email protected]); Eric C Rosen > > *Subject:* Re: [spring] SRGBs, indexes, and topologies within a domain > > > > Les, > > > > How do you do anycast in data plane in your proposal ? > > > > Thx, > > R. > > > > On Tue, Aug 25, 2015 at 9:53 PM, Les Ginsberg (ginsberg) < > [email protected]> wrote: > > Robert (and Stephane) - > > > > *From:* spring [mailto:[email protected]] *On Behalf Of *Robert > Raszuk > *Sent:* Tuesday, August 25, 2015 4:15 AM > *To:* Peter Psenak (ppsenak) > *Cc:* [email protected]; [email protected]; Pushpasis Sarkar ( > [email protected]); Eric C Rosen > *Subject:* Re: [spring] SRGBs, indexes, and topologies within a domain > > > > 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. > > *[Les:] This is true until you face the problem of redistribution. If you > have assigned SIDs 0 – 100 in the protocol specific SRGBs to the prefixes > that each IGP is originating (and it would be “natural” to do that) then if > I redistribute a prefix from one protocol to another the destination > protocol has to assign a different SID to the redistributed prefix because > the SID specified by the originating protocol conflicts w an existing use > in the destination protocol. This can be done of course – but it is more > complex and uses more resources (you now need multiple incoming labels for > the same prefix in the forwarding plane).* > > *Contrast this with a single SRGB shared by all protocols. SIDs are > assigned per prefix w/o regard to what protocol advertises them. When a > prefix is redistributed no second SID needs to be allocated and only a > single incoming label is required per prefix.* > > *For the case where two networks are being merged, the per protocol SRGB > may be helpful because you likely already have conflicting SIDs. But > extending this idea to be the way things need to be in all deployments > ignores the more common case where we do not have SID conflicts and > therefore have a much simpler deployment model using a protocol independent > SRGB.* > > *Please reread Acee’s posts- he has most clearly and succinctly stated the > position that a number of us favor i.e., protocol independent SRGB for the > most common cases – per protocol SRGB available for those cases where it > may avoid SID reassignment.* > > *Stephane – as the advocate of “SID consistency” I hope you appreciate the > advantage of the global SRGB for most deployments.* > > * Les* > > > > 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
