Pushpasis - > -----Original Message----- > From: spring [mailto:[email protected]] On Behalf Of Pushpasis Sarkar > Sent: Wednesday, August 26, 2015 7:44 AM > To: Les Ginsberg (ginsberg); [email protected]; Uma > Chunduri; Peter Psenak (ppsenak); Eric Rosen; SPRING WG > Subject: Re: [spring] SRGBs, indexes, and topologies within a domain > > Hi Les, > > > > > On 8/26/15, 7:45 PM, "Les Ginsberg (ginsberg)" <[email protected]> > wrote: > > >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. > [Pushpasis] What if we use the current SR-capability sub-TLVs only for single > topology deployments? And use a new MT-SR-Capability SubTLV for MT > deployments? Please note, I am not saying MT cannot be supported with > current SR-Cap SubTLV. It can be, but with the limitation (as I like to see > this > cuurently) is that we MUST use separate SID-index for the same prefix in > separate topologies. If operator does not want to live with the limitation > then all the vendor implementations must implement the new MT-SR-Cap > SubTLV and make it happen. If the operator can live with the implementation > they continue with per-topology SID-index and single SRGB for all topology.
[Les:] What you propose does not alter the fact that unless all implementations agree that SIDs in MT prefix advertisements have to be applied against a topology specific SRGB we will have interoperability problems. So the specs have to be revised and the implementations have to be revised to match. Existing code will not interoperate. Les > > Thanks > -Pushpasis > > > > > 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 > _______________________________________________ > spring mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/spring _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
