Robert - From: [email protected] [mailto:[email protected]] On Behalf Of Robert Raszuk Sent: Wednesday, August 26, 2015 12:29 AM 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, You have clearly misunderstood the scenario/question :) [Les:] Don’t think so. 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 ? [Les:] In regards to topology, there are two models being discussed: 1)Topology independent SRGB. This is we have today – and clearly we can do anycast – and we can do it in any topology because we have different SIDs/labels for the same prefix (anycast or not) in each topology. 2)Topology specific SRGB. In this case you would have the same SID for the same prefix (anycast or not) in all topologies – but you would still have topology unique labels. So again anycast can be supported. Your question seems more directed at #2 – which of course is not what I am advocating. So I think your question is better directed at the topology specific SRGB advocates – though as I said above I think anycasr can be done w either model. And with that I do not want to readvertise anything in IGP each type my forwarding preference to said prefix across topologies changes. [Les:] It’s a bit hard to parse the above sentence – not quite sure what you are trying to say. IGPs necessarily have to advertise what prefixes are reachable in each topology – we do not assume that because a prefix is reachable in topology A that it is also reachable in Topology B. And since the SID advertisement is associated with the topology specific prefix advertisement, whether I happen to have the same SID for the same prefix across topologies or not I still have to advertise it in each topology. I would strongly object to a model which required the SID for a prefix in Topology B to be retrieved from the advertisement for the same prefix in Topology A. Les 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]<mailto:[email protected]>> wrote: Robert – You have asked exactly the opposite of the question you should have asked. ☺ 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]> [mailto:[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]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; Pushpasis Sarkar ([email protected]<mailto:[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]<mailto:[email protected]>> wrote: Robert (and Stephane) - From: spring [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Robert Raszuk Sent: Tuesday, August 25, 2015 4:15 AM To: Peter Psenak (ppsenak) Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; Pushpasis Sarkar ([email protected]<mailto:[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]<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
