Hi Les, IMO, backward compatibility mean that we are compatible with the old flavor functionality. Let's assume that we create a new subTLV that will override the current SR capability subTLV (just as example). The new subTLV will contain encoding for per algo, per topo SRGB. I think we can define compatibility rules : We have the simple network A - B - C - D, with two topologies #1 and #2 and SRGB [100,200], A uses index 1 (topo#1), index 2 (topo#2), B uses index 3 (topo#1) and 4 (topo#2) ...
- for sure during the migration period, we cannot use a different SRGB per topo, we need to keep backward compatibility with same level of functions, so common SRGB between topologies. - We activate the support of the new subTLV on B, without changing SRGB, B advertise the same SRGB for the two topologies in the new subTLV and keep advertising the SRGB in legacy subTLV. Node B receives legacy SR-cap from A and C and understand it well, it considers the index 1 as part of SRGB in legacy subTLV and computes the appropriate value. To reach index 7 on D (topo#1), it programs the label computed with index 7 + SRGB advertised by C in legacy subTLV. Now, what about A, A receives advertisement from B, it does not understand the newsubTLV, A computes path to B using index 3 (topo#1) and SRGB from B in legacy subTLV. As B moved to newsubTLV, it allocates labels per topology based on the per topology SRGB and while we advertise the legacy subTLV, it ensures that a label is programmed using the ex global SRGB. In this case, as migration is not done, B has allocated a unique label for topo#1 index 3 using the ex global SRGB (per topology label is the same). Same process for A computing a path to C, A uses index 6 (topo#2) and uses the legacy subTLV advertisement from B. B has programmed a forwarding plane entry for the legacy label. - Now we activate the support on C, B to reach D knows that C supports the new subTLV and use it in priority. As all nodes still advertise the global SRGB (let's call it legacySRGB) in the the newsubTLV, forwarding plane is not changed. - Now we decide on C to start changing SRGB to per topology SRGB. As there is some legacy traffic, C still need to keep the legacy subTLV and legacy SRGB. C associate SRGB_C1 to topo#1 and SRGB_C2 to topo#2. These new advertisement are part of the new subTLV. Let's assume traffic from A to D. A sends traffic using label#1=legacySRGB_start_on_B+index 7 to B for topo#1 traffic and using label#2=legacySRGB_start_on_B+index 8 to B for topo#2. B programs the forwarding entry taking into account that the C supports per topo SRGB : label#1 swapped to SRGB#1+7, label#2 swapped to SRGB#1+8. C programs the new forwarding entries (from labels in SRGB#1 and #2) pointing to a label value computed using legacySRGB_start_on_D+index 7 or 8. Now if we need to renumber indexes to use the same index value, we need to wait for all nodes to support the new extension, as using the same index is a new feature. So IMO, backward compatibility is feasible. I think changing SRGBs per topology is feasible in an incremental way. Using the same index requires a full network deployment (not incrementally deployable) but it's normal as the current behavior does not support it. -----Original Message----- From: Les Ginsberg (ginsberg) [mailto:[email protected]] Sent: Wednesday, August 26, 2015 16:16 To: LITKOWSKI Stephane SCE/IBNF; Pushpasis Sarkar; Uma Chunduri; Peter Psenak (ppsenak); Eric Rosen; SPRING WG Subject: RE: [spring] SRGBs, indexes, and topologies within a domain Stephane - Implementations based on the drafts that currently exist advertise a topology independent SRGB. A SID which is advertised in a specific MT Prefix Reachability advertisement is interpreted as an index into the topology independent SRGB. This is NOT compatible with an implementation which is written assuming that a SID is an index into a topology specific SRGB. So the introduction of topology specific SRGBs would have to be supported network-wide before it could be deployed. Sub-TLVs cannot resolve this incompatibility. Les > -----Original Message----- > From: spring [mailto:[email protected]] On Behalf Of > [email protected] > Sent: Wednesday, August 26, 2015 12:25 AM > To: Pushpasis Sarkar; Les Ginsberg (ginsberg); Uma Chunduri; Peter > Psenak (ppsenak); Eric Rosen; SPRING WG > Subject: Re: [spring] SRGBs, indexes, and topologies within a domain > > Hi Pushpasis, > > I just want to remember that the discussion is not only for MT, but > there was also a thread for per algorithm SRGB (as presented in > Prague). IMO, there must be some consistency in the choice we do. > Regarding encoding nothing is impossible (as example a new subTLV can > be created ensuring backward compatibility). > I would say let's first have a consensus of what is good to do > independently of the encoding. > > Best Regards, > > -----Original Message----- > From: Pushpasis Sarkar [mailto:[email protected]] > Sent: Wednesday, August 26, 2015 07:36 > To: Les Ginsberg (ginsberg); Uma Chunduri; LITKOWSKI Stephane > SCE/IBNF; Peter Psenak (ppsenak); Eric Rosen; SPRING WG > Subject: Re: [spring] SRGBs, indexes, and topologies within a domain > > Hi Les, > > > > > On 8/26/15, 7:13 AM, "Les Ginsberg (ginsberg)" <[email protected]> > wrote: > > >[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. > [Pushpasis] Why not add a MT-SR_Capability Sub/TLV then? That way it > won’t break backward compatibility? > > Thanks > -Pushpasis > > __________________________________________________________ > __________________________________________________________ > _____ > > 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 _________________________________________________________________________________________________________________________ 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
