Uma - > -----Original Message----- > From: Uma Chunduri [mailto:[email protected]] > Sent: Tuesday, August 25, 2015 6:02 PM > To: Les Ginsberg (ginsberg); [email protected]; Peter Psenak > (ppsenak); Eric C Rosen; Pushpasis Sarkar; SPRING WG > Subject: RE: [spring] SRGBs, indexes, and topologies within a domain > > In the 1st example below (separate unique index per topology) it seems > topology 2 can have only 500 nodes but in the 2nd example all 10 topologies > *can* have 1000 nodes. So it's not necessary to have/configure 1000 label > space for topology 2 in the 2nd example. My point is to illustrate the point > of > running out SRGB space is an issue in the example below and that ought to > handle any ways in either case.
[Les:] I deliberately used an example where in neither approach would SRGB allocation be required after startup. This is to avoid the problematic scenario where you need to dynamically reserve more label space but it isn't available because some other application is using at least one label in the space you want to reserve. I tried to be fair by making sure neither approach had an advantage regarding this point. With either approach you could run out of SRGB space and you could encounter the same problems as regards trying to reserve more. This isn't a difference or an advantage for either method. > > But I would note - maintaining unique indices across all nodes (starting from > the starting point of the SRGB) for each topology is way harder than > maintaining one set of unique index per node. With 10 topologies in the > below example, with 1000 nodes per topology, in per index case operator > ought to maintain 10 * 1000 = 10000 unique objects. But in the other case of > per topology SRGB operator has to only maintain > 1000 (unique labels/SID Index) + 10 (SRGB offsets) = 1010 unique objects in > total. I am not sure how maintaining > *more* unique objects would be easier. [Les:] Regardless of approach, you have a unique label for a given prefix/topology pair. So you have the same number of "objects" in both cases. This is very clear if you look at what is installed in the forwarding plane. Do not make the mistake of confusing CLI syntax w the number of labels being used. > > Remember also in the first case across all nodes, starting point of SRGB for > each topology has to be maintained without indicating the same through the > underlying protocol (IGP). [Les:] Indeed - which is less information for the IGPs to advertise. So one could consider this a (small) advantage for the one SRGB approach. :-) > > I would request this to capture the essence of the discussion in the > architecture document and leave this to operators on how they feel to > provision and maintain the network. But flexibility to have either way is > critical and I don't see any reason to deny the per topology SRGB option. [Les:] Topology specific SRGBs requires a specification change for the IGPs. The new advertisements are NOT backwards compatible w existing implementations. So we cannot simply say "do what you please". Peter has repeatedly made this point - and also pointed out that since the prefix advertisements as currently defined in the IGP drafts includes topology identifiers including the topology identifier in the SRGB advertisement is redundant. Les > > -- > Uma C. > > > -----Original Message----- > From: spring [mailto:[email protected]] On Behalf Of Les Ginsberg > (ginsberg) > Sent: Tuesday, August 25, 2015 5:03 PM > To: [email protected]; Peter Psenak (ppsenak); Eric C Rosen; > Pushpasis Sarkar; SPRING WG > Subject: Re: [spring] SRGBs, indexes, and topologies within a domain > > Stephane - > > > -----Original Message----- > > From: spring [mailto:[email protected]] On Behalf Of > > [email protected] > > Sent: Tuesday, August 25, 2015 4:28 PM > > To: Peter Psenak (ppsenak); Eric C Rosen; Pushpasis Sarkar; SPRING WG > > Subject: Re: [spring] SRGBs, indexes, and topologies within a domain > > > > Hi Peter, > > > > As I already pointed to Les, using an offset creates some holes in > > index space that we need to manage when extending a block. > > > > Let's say that we have SRGB [100-199] (to simplify) and you divide > > your block in two so you will have topology #1 using [100-149] and > > topology #2 using [150-199] using an offset of 50. > > Now I need to add a 51th node in my network, I cannot use index 51 > > because it will overlap with topology#2 :(, so I will need to skip > > indexes from 51 to 100, and restarts my numbering with index 101. This > > management of holes is not automated. > > [Les:] The same issue arises w topology specific SRGBs. Let's take an > example. > > I am setting up my network for SR. I anticipate that I will need 500 labels > per > topology and I anticipate a maximum of 5 topologies. In order to be prepared > for the "worst case" I decide to allocate enough for 1000 labels/topology and > 10 topologies and I reserve it all up front because - as you have documented > in an earlier post - assuming I can allocate additional SRGB space when I need > it without either rebooting the node or shutting down some applications I am > using is not safe. > > Using the offset approach: > > srgb 16000-25999 > srgb offset topology 1 1000 !Please don't quibble about syntax :-) > srgb offset topology 2 2000 > > I only configure offsets for the topologies that are currently active. Since I > have reserved the label space in a topology independent way I am free to > allocate space for each topology only when they are needed - and if I find > that I am using far less than 1000 labels when the next topology is enabled I > could choose to do: > > srgb offset topology 3 2500 > > And now I can support more topologies than originally planned for if > necessary. > > Now let's look at a per topology approach. You could allocate topology > specific SRGBs only when you need them, but this leaves you open to cases > where the desired label space is in use - so again you decide to allocate all > of > the label space up front. But now you have to decide how many SRGBs to > allocate. So you do: > > srgb 16000 16999 topology 0 > srgb 17000 17999 topology 1 > ... > srgb 25000 25999 topology 9 > > You can support 10 topologies - but if you find that 1000 labels/topology is > far > more than you need but 10 topologies is fewer than you need you can't > easily accommodate the additional topologies without reconfiguring the > srgb's. > > The key points here are: > > o Allocating all the labels you will ever need up front is the safest method > o Allocating a single SRGB and partitioning it as you need it provides a bit > more flexibility > o In either approach you likely have unused label space ("holes"). > > Clearly either method will work . > But the main point is that the single SRGB is not more problematic than per > topology SRGB (as your reply suggests) - if anything it is more flexible. > > Les > > > > > Best Regards, > > > > Stephane > > > > -----Original Message----- > > From: Peter Psenak [mailto:[email protected]] > > Sent: Tuesday, August 25, 2015 13:18 > > To: LITKOWSKI Stephane SCE/IBNF; Eric C Rosen; Pushpasis Sarkar; > > SPRING WG > > Subject: Re: [spring] SRGBs, indexes, and topologies within a domain > > > > Hi Stephane, > > > > On 8/25/15 12:58 , [email protected] wrote: > > > Hi Peter, > > > > > >>> 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. > > > > > > Could you explain how ? Based on past discussions, it does not seem > > > to be > > so easy. > > > > simply by associating an offset and size from SRGP on a per topology basis. > > > > Example: > > > > SRGB 1600-24000 > > > > I would assume that when you start to assign your SIDs for the default > > topology, you would not pick random values, but start from the > > beginning. So let' assume you are using 16001 to 16500 for nodes in default > topology. > > > > Now you need to add a new topology. You configure and offset of 2k for > > it, so the advertised SIDs for the new topology would start from 18001. > > If we assume that the 2k would be a reasonable size for each topology > > you can have 4 topologies with 2k SIDs per topology. > > > > If for whatever reason you run out of the SID space in any topology, > > you can configure another offset for those SIDs which do not fit into > > the existing range for such topology. > > > > All of the above is internal to the node and no per topology SRGB > > advertisement is required. You advertise unique SID on a per prefix > > and per topology basis, but you do not need to configure each SID > manually. > > Al you need to configure is the single prefix SID and per topology > offset/size. > > It gives you the same simplicity for configuration as per topology > > SRGB, but without the need to advertise SRGB per topology. > > > > thanks, > > Peter > > > > > > > > > Best Regards, > > > > > > Stephane > > > > > > > > > > > > > > > __________________________________________________________ > > ____________ > > > ___________________________________________________ > > > > > > Ce message et ses pieces jointes peuvent contenir des informations > > > confidentielles ou privilegiees et ne doivent donc pas etre > > > diffuses, exploites ou copies sans autorisation. Si vous avez recu > > > ce message par erreur, veuillez le signaler a l'expediteur et le > > > detruire ainsi que les > > pieces jointes. Les messages electroniques etant susceptibles > > d'alteration, Orange decline toute responsabilite si ce message a ete > > altere, deforme ou falsifie. Merci. > > > > > > This message and its attachments may contain confidential or > > > privileged information that may be protected by law; they should not > > > be > > distributed, used or copied without authorisation. > > > If you have received this email in error, please notify the sender > > > and delete > > this message and its attachments. > > > As emails may be altered, Orange is not liable for messages that > > > have been > > modified, changed or falsified. > > > Thank you. > > > > > > > > > > > > > __________________________________________________________ > > > __________________________________________________________ > > _____ > > > > Ce message et ses pieces jointes peuvent contenir des informations > > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, > > exploites ou copies sans autorisation. Si vous avez recu ce message > > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi > > que les pieces jointes. Les messages electroniques etant susceptibles > > d'alteration, Orange decline toute responsabilite si ce message a ete > > altere, > deforme ou falsifie. Merci. > > > > This message and its attachments may contain confidential or > > privileged information that may be protected by law; they should not > > be distributed, used or copied without authorisation. > > If you have received this email in error, please notify the sender and > > delete this message and its attachments. > > As emails may be altered, Orange is not liable for messages that have > > been modified, changed or falsified. > > Thank you. > > > > _______________________________________________ > > spring mailing list > > [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
