Les, Pls see inline…
From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com] Sent: Thursday, July 30, 2015 3:59 AM To: Robert Raszuk <rob...@raszuk.net> Cc: stephane.litkow...@orange.com; Uma Chunduri <uma.chund...@ericsson.com>; Aissaoui, Mustapha (Mustapha) <mustapha.aissa...@alcatel-lucent.com>; spring@ietf.org; Shraddha Hegde <shrad...@juniper.net>; Pushpasis Sarkar <psar...@juniper.net>; Hannes Gredler <han...@juniper.net> Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Robert - From: rras...@gmail.com<mailto:rras...@gmail.com> [mailto:rras...@gmail.com] On Behalf Of Robert Raszuk Sent: Wednesday, July 29, 2015 2:45 PM To: Les Ginsberg (ginsberg) Cc: stephane.litkow...@orange.com<mailto:stephane.litkow...@orange.com>; Uma Chunduri; Aissaoui, Mustapha (Mustapha); spring@ietf.org<mailto:spring@ietf.org>; Shraddha Hegde (shrad...@juniper.net<mailto:shrad...@juniper.net>); 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 Hi Les, > This makes no sense to me operationally or architecturally. Fundamentally I fully agree with you. However architecturally: However at least looking at group of folks who claim that it is impossible to get same SRGB block in *any* network between two or more vendors I think Stephane's intention would be to at least get it per one protocol even if platform wide the intersecting pool may be mission impossible. [Les:] This is an unrelated issue. Placing SRGB in global context does not mean all routers have to have the same SRGB. There is no controversy here. and now operationally: Another reason would be idea of dual overlapping SRGBs perhaps quite useful during migrations between protocols where the exact same SRGB is set on both then just based on admin distance one vs the other protocol is chosen. While a standard practice in protocol migrations not sure if anyone looked at that from SR perspective. [Les:] Not sure what you are trying to say. If the two SRGBs are the same – why do we need to configure them per protocol? If the two SRGBs are not the same, other routers in the network have no idea which protocol is going to win on your box. So your neighbor has no idea whether it should use the SRGB advertised by OSPF or the SRGB advertised by IS-IS. [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. Les Cheers, R. On Wed, Jul 29, 2015 at 11:01 PM, Les Ginsberg (ginsberg) <ginsb...@cisco.com<mailto:ginsb...@cisco.com>> wrote: Stephane – What is the requirement to have a per-protocol SRGB config? This makes no sense to me operationally or architecturally. (I am not talking about what may or may not have been implemented by vendors – the YANG model should be architecturally correct) Les
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
