Hi Les, From: "Les Ginsberg (ginsberg)" <ginsb...@cisco.com<mailto:ginsb...@cisco.com>> Date: Thursday, July 30, 2015 at 9:46 AM To: Pushpasis Sarkar <psar...@juniper.net<mailto:psar...@juniper.net>>, "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>>, Shraddha Hegde <shrad...@juniper.net<mailto:shrad...@juniper.net>>, Hannes Gredler <han...@juniper.net<mailto:han...@juniper.net>> Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang
Pushpassis – It is clear to me that what you propose is more complex to implement and more costly in its consumption of labels. [Pushpasis] I read through the entire repsponse and I still don’t see why you think this is complex. Also, while distributing from one protocol to another you may want to attach another index with the FEC (in scenarios when you want to keep the index-management of destination protocol independent of the index-management of soruce protocol). Having per-protcol SRGB opens up lots of possibilities. One more point, you are only talking about the IP-route on the ingress box. We need to also consider the MPLS transit labels on transit boxes downloaded by each protocol. Shraddha in a previous thread has already pointed out cases with ‘ships in the night’ mode of migration from one protocol to another where this simplifies the micgration without causing any unwanted loops. What I do not yet appreciate is what capabilities protocol specific SRGBs provide which cannot be supported using a protocol independent SRGB. Could you please provide some specific examples? Please do not use an RSVP/LDP analogy – please use a proposed SR deployment case. [Pushpasis] One such example (migration from one protocol to another) has already been mentioned by Shraddha. But I can come with another example with BGP-LU prefix segment in Datacenter. A boundary router (between DCN and the DCI) will be running SR on two protocols — BGP-LU towards the home DCN as well as to the boubdray routers on remote DCNs across the DCI — ISIS/OSPF with all the routers within the DCI. If we have to keep the index management of DCNs independent of the index-management of DCI (I.e. Same index can be used on DCN as well as DCI) we need to make sure the transit label allocated on the boundary router by BGP-LU for a destination in DCN is separate from the transit label allocated by ISIS/OSPF for another destination in DCI network, even though BGP-LU and ISIS may use the same index for these two different destination routers. BTW, why do I say your proposal is more complex/costly? On a node where redistribution of routes is occurring, the source of redistribution (the “best route”) obviously allocates a local label based on its SRGB. But now the destination protocol for redistribution also has to allocate a local label based on its SRGB because it is expected that neighbors of the destination protocol will use a label from the destination protocol SRGB. So, you now have new requirements on the destination protocol and you have consumed twice as many local labels. Your forwarding plane now has to deal with the added complexity/cost – and your label manager has to manage more label ranges. [Pushpasis] I still don’t get what added complexity is involved here. How does it matter if the label-manager has to manage 1 partition or N partitions? The complexity involved is same. I agree that we will need added labels, but if you see, we will need to enable SR on multiple protocols, only in the following cases. I cannot foresee any other scenarios as of now. — Migrating from IGP1to IGP2. — Border routers in MSDC environment running BGP-LU + some IGP. What I want to know is what do we gain for this added complexity? Thanx. [Pushpasis] 1. Index-management in a one protocol can be completely independent of the index-mamagement in another protocol even if the same router participates in multiple protocols with different topologies. 2. Eases debuggability and avoids routing loops in case of migration scenarios Thanks -Pushpasis Les From: Pushpasis Sarkar [mailto:psar...@juniper.net] Sent: Wednesday, July 29, 2015 11:16 PM To: Les Ginsberg (ginsberg); stephane.litkow...@orange.com<mailto:stephane.litkow...@orange.com>; Uma Chunduri; Aissaoui, Mustapha (Mustapha); spring@ietf.org<mailto:spring@ietf.org>; Shraddha Hegde; Hannes Gredler Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Hi Les, From: "Les Ginsberg (ginsberg)" <ginsb...@cisco.com<mailto:ginsb...@cisco.com>> Date: Wednesday, July 29, 2015 at 11:01 PM To: "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>>, 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 Stephane – What is the requirement to have a per-protocol SRGB config? This makes no sense to me operationally or architecturally. [Pushpasis] In current MPLS architecture, the same label is not allocated by both RSVP and LDP in a given box. With SR mapped to MPLS data-plane, we would like to retain the same behavior. For the same destination the label allocated by ISIS should be different than the label allocated by OSPF. This can be achieved in two ways: 1. ISIS and OSPF using same SRGBs but different index ranges. 2. ISIS and OSPF using different SRGBs but can have the same index ranges. I prefer option 2, as the operator does not need to maintain two different index ranges (one per-protocol). (I am not talking about what may or may not have been implemented by vendors – the YANG model should be architecturally correct) Les From:stephane.litkow...@orange.com<mailto:stephane.litkow...@orange.com> [mailto:stephane.litkow...@orange.com] Sent: Wednesday, July 29, 2015 5:11 AM To: Uma Chunduri; Les Ginsberg (ginsberg); 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 all, What if we keep the SRGB block config in “segment-routing” global module, and if we allow for YANG configuration of carving this block inside each protocol (maybe as a feature) ? Stephane From: Uma Chunduri [mailto:uma.chund...@ericsson.com] Sent: Friday, July 24, 2015 16:59 To: Les Ginsberg (ginsberg); Aissaoui, Mustapha (Mustapha); LITKOWSKI Stephane SCE/IBNF; spring@ietf.org<mailto:spring@ietf.org> Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang >Suggesting that the forwarding instruction (AKA label) needs to be different >depending on what protocol provided >the instruction is completely unnecessary – it simply wastes label space. [Uma]: Les, No - I never suggested anything like that. SRGB for a routing instance to be advertised should be part of the routing instance provisioning as far as the yang model is concerned. Carving out the label space for SR is a local matter and agree, of course, this can be done in so many ways through CLI, dynamically, statically etc... -- Uma C. _________________________________________________________________________________________________________________________ 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
