Hi Acee, From: "Acee Lindem (acee)" <a...@cisco.com<mailto:a...@cisco.com>> Date: Thursday, July 30, 2015 at 7:18 PM To: Pushpasis Sarkar <psar...@juniper.net<mailto:psar...@juniper.net>> Cc: Shraddha Hegde <shrad...@juniper.net<mailto:shrad...@juniper.net>>, "Les Ginsberg (ginsberg)" <ginsb...@cisco.com<mailto:ginsb...@cisco.com>>, Robert Raszuk <rob...@raszuk.net<mailto:rob...@raszuk.net>>, "Aissaoui, Mustapha (Mustapha)" <mustapha.aissa...@alcatel-lucent.com<mailto:mustapha.aissa...@alcatel-lucent.com>>, Stephane Litkowski <stephane.litkow...@orange.com<mailto:stephane.litkow...@orange.com>>, "spring@ietf.org<mailto:spring@ietf.org>" <spring@ietf.org<mailto:spring@ietf.org>>, Uma Chunduri <uma.chund...@ericsson.com<mailto:uma.chund...@ericsson.com>>, Hannes Gredler <han...@juniper.net<mailto:han...@juniper.net>> Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang
Robert, Pushpasis, Shraddha, I guess I don't understand why this gives you any operational advantage when you are migrating between protocol (e.g., from IS-IS to OSPF ;^). In fact, if you are using separate label spaces it will make migration more difficult and you will have to migrate your routing domain in shot rather than incrementally. [Pushpasis] All routers will program both transit mpls labels and create two parallel MPLS data planes well before the last step when all the ingress router will be instructed to switch traffic onto the new MPLS data plane (programmed by the new protocol) by changing the admin distance. That way the migration shall become seamless. And then once all ingreess routers has been swicthed to the new protocol and new MPLS dataplane, the old protocol and old MPLS data plane can be just removed from all the routers. Hope it is clear now... Thanks, Acee On Jul 30, 2015, at 3:11 AM, Pushpasis Sarkar <psar...@juniper.net<mailto:psar...@juniper.net>> wrote: +1 From: Shraddha Hegde <shrad...@juniper.net<mailto:shrad...@juniper.net>> Date: Thursday, July 30, 2015 at 8:58 AM To: "Les Ginsberg (ginsberg)" <ginsb...@cisco.com<mailto:ginsb...@cisco.com>>, Robert Raszuk <rob...@raszuk.net<mailto:rob...@raszuk.net>> Cc: "stephane.litkow...@orange.com<mailto:stephane.litkow...@orange.com>" <stephane.litkow...@orange.com<mailto:stephane.litkow...@orange.com>>, Uma Chunduri <uma.chund...@ericsson.com<mailto:uma.chund...@ericsson.com>>, "Aissaoui, Mustapha (Mustapha)" <mustapha.aissa...@alcatel-lucent.com<mailto:mustapha.aissa...@alcatel-lucent.com>>, "spring@ietf.org<mailto:spring@ietf.org>" <spring@ietf.org<mailto:spring@ietf.org>>, Pushpasis Sarkar <psar...@juniper.net<mailto:psar...@juniper.net>>, Hannes Gredler <han...@juniper.net<mailto:han...@juniper.net>> Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang [Shraddha] route preference is local to router and the neighbor never knows what the other is going to choose. If there are inconsistencies in two protocols, there are going to be loops even when they use same SRGB. Keeping different labels makes it easier to troubleshoot. _______________________________________________ spring mailing list spring@ietf.org<mailto:spring@ietf.org> https://www.ietf.org/mailman/listinfo/spring
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring