Hi Les, Sure. However I am more interested in the prevention than the cure. But I agree that a cure is needed as well.
Thanks -Pushpasis From: "Les Ginsberg (ginsberg)" <ginsb...@cisco.com<mailto:ginsb...@cisco.com>> Date: Wednesday, August 12, 2015 at 12:18 AM To: Pushpasis Sarkar <psar...@juniper.net<mailto:psar...@juniper.net>>, "rabah.gued...@orange.com<mailto:rabah.gued...@orange.com>" <rabah.gued...@orange.com<mailto:rabah.gued...@orange.com>>, LITKOWSKI Stephane SCE/IBNF <stephane.litkow...@orange.com<mailto:stephane.litkow...@orange.com>>, Jeff Tantsura <jeff.tants...@ericsson.com<mailto:jeff.tants...@ericsson.com>>, "spring@ietf.org<mailto:spring@ietf.org>" <spring@ietf.org<mailto:spring@ietf.org>> Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Pushpasis/Rabah – The conflicting SRGB range issue is neither new nor specific to protocol specific SRGBs. There is already a (somewhat lively) discussion going on about what to do w conflicting SRGB ranges when received (see attached email). IMO if you want to discuss this issue it would be better done in the context of the attached thread – not this one. Les From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Pushpasis Sarkar Sent: Tuesday, August 11, 2015 9:54 AM To: rabah.gued...@orange.com<mailto:rabah.gued...@orange.com>; LITKOWSKI Stephane SCE/IBNF; Jeff Tantsura; spring@ietf.org<mailto:spring@ietf.org> Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Hi Rabah, Totally agree to your point. And that is why IMO, the configuration module on any router MUST NOT allow any of the per-protocol SRGBs to overlap. All the per-protcol SRGBs MUST be non-overlapping. Thanks -Pushpasis From: spring <spring-boun...@ietf.org<mailto:spring-boun...@ietf.org>> on behalf of "rabah.gued...@orange.com<mailto:rabah.gued...@orange.com>" <rabah.gued...@orange.com<mailto:rabah.gued...@orange.com>> Date: Tuesday, August 11, 2015 at 8:00 PM To: LITKOWSKI Stephane SCE/IBNF <stephane.litkow...@orange.com<mailto:stephane.litkow...@orange.com>>, Jeff Tantsura <jeff.tants...@ericsson.com<mailto:jeff.tants...@ericsson.com>>, "spring@ietf.org<mailto:spring@ietf.org>" <spring@ietf.org<mailto:spring@ietf.org>> Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang I strongly support option #2 but a Problem may occur in that case, if the per-protocol SRGBs share a subSpace. so let us consider the following example where node N is a SPRING node with two SR-IGP instances SR-OSPF and SR-ISIS running, if we configure OSPF-SRGB [8000, 10000] and ISIS-SRGB [9000, 11000]. actually accepting this configuration may result in the same label for two IGP prefixes (EX : OSPF-Prefix-index 1001 and ISIS-prefix-index 1 will have the label 9001) which get translated into two entries in the forwarding table. to solve that I suggest to add a new notification of type let's say “SRGB-collusion-detected “ which will be raised upon the detection of the SRGBs collusion Rabah De : spring [mailto:spring-boun...@ietf.org] De la part de stephane.litkow...@orange.com<mailto:stephane.litkow...@orange.com> Envoyé : vendredi 31 juillet 2015 10:52 À : Jeff Tantsura; spring@ietf.org<mailto:spring@ietf.org> Objet : Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Looks that consensus is for option#2, so let’s move SRGB to protocol configuration. From: Jeff Tantsura [mailto:jeff.tants...@ericsson.com] Sent: Friday, July 31, 2015 08:04 To: LITKOWSKI Stephane SCE/IBNF; spring@ietf.org<mailto:spring@ietf.org> Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Hi, Architecturally I agree – label manager shouldn’t care less how labels have been learnt Operationally I’m strongly for #2, in case of ISIS possibly under AF. Cheers, Jeff From: spring <spring-boun...@ietf.org<mailto:spring-boun...@ietf.org>> on behalf of Stephane Litkowski <stephane.litkow...@orange.com<mailto:stephane.litkow...@orange.com>> Date: Wednesday, July 22, 2015 at 7:19 PM To: "spring@ietf.org<mailto:spring@ietf.org>" <spring@ietf.org<mailto:spring@ietf.org>> Subject: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Hi WG, In the current version of the config Yang model for SR, the SRGB list is configured at SR top level, so it is agnostic to the routing protocol. We had some comment in Dallas on difficulties that having common label range shared between protocols could lead to. During discussion in our design team, some point was also raised on routing protocol migrations that may be safer using a per protocol SRGB (so configuration the SRGB at IGP level rather than globally). We would like to hear from the WG about the preference and arguments for both approaches : Approach 1) keep SRGB configuration at top level, and so routing protocols will share the same label space (today proposal) Approach 2) move SRGB configuration to protocols, each routing protocol manages its own label space. Thanks to provide your feedback in order to solve this issue and have a consensus. [Orange logo]<http://www.orange.com/> Stephane Litkowski Network Architect Orange/SCE/EQUANT/IBNF/ENDD/NDE Orange Expert Future Networks phone: +33 2 23 28 49 83 <https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%202%2023%2028%2049%2083%20> mobile: +33 6 37 86 97 52 <https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%206%2037%2086%2097%2052%20> stephane.litkow...@orange.com<mailto:stephane.litkow...@orange.com> _________________________________________________________________________________________________________________________ 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. _________________________________________________________________________________________________________________________ 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. _________________________________________________________________________________________________________________________ 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
