Hi Pushpasis, On Jul 30, 2015, at 2:22 AM, Pushpasis Sarkar <psar...@juniper.net<mailto:psar...@juniper.net>> wrote:
HI Acee, From: "Acee Lindem (acee)" <a...@cisco.com<mailto:a...@cisco.com>> Date: Thursday, July 30, 2015 at 2:03 AM To: "Les Ginsberg (ginsberg)" <ginsb...@cisco.com<mailto:ginsb...@cisco.com>> Cc: Robert Raszuk <rob...@raszuk.net<mailto:rob...@raszuk.net>>, 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>>, Shraddha Hegde <shrad...@juniper.net<mailto:shrad...@juniper.net>>, Uma Chunduri <uma.chund...@ericsson.com<mailto:uma.chund...@ericsson.com>>, Pushpasis Sarkar <psar...@juniper.net<mailto:psar...@juniper.net>>, "Aissaoui, Mustapha (Mustapha)" <mustapha.aissa...@alcatel-lucent.com<mailto:mustapha.aissa...@alcatel-lucent.com>>, Hannes Gredler <han...@juniper.net<mailto:han...@juniper.net>> Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang On Jul 29, 2015, at 6:28 PM, Les Ginsberg (ginsberg) <ginsb...@cisco.com<mailto:ginsb...@cisco.com>> wrote: 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. Actually, if the same prefix in the same topology is advertised by two protocols, I would think that the SID should map to the same label. I see no advantage at all in having separate labels. [Pushpasis] We are talking about the MPLS transit label for the destination FEC here. Like RSVP and LDP, in MPLS data plane today, the FEC maybe same but the transit label allocated by each protocol are different. This is not a good analogy. LDP normally follows the IP routed path while RSVP is used to set up a TE engineered path. Similarly for SR mapped to MPLS data plane the transit label allocated by ISIS and OSPF for the same destination FEC should be different. Hence the need of per-protocol SRGB. This is a circular argument. Why would the IP unicast routed path require a different label for ISIS vs OSPF? Acee Acee 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<mailto:spring@ietf.org> https://www.ietf.org/mailman/listinfo/spring
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
