Hi Les,
On 8/26/15, 7:45 PM, "Les Ginsberg (ginsberg)" <ginsb...@cisco.com> 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. Thanks -Pushpasis > > Les > > >> -----Original Message----- >> From: spring [mailto:spring-boun...@ietf.org] On Behalf Of >> stephane.litkow...@orange.com >> 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:psar...@juniper.net] >> 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)" <ginsb...@cisco.com> >> 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 >> spring@ietf.org >> https://www.ietf.org/mailman/listinfo/spring _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
